موضوع پروژه را به خروجی قابل بررسی تبدیل کنید
عبارت‌هایی مثل «سایت حرفه‌ای» یا «طراحی کامل» برای مدیریت اجرا کافی نیستند. فهرست صفحات، قابلیت‌ها، زبان‌ها، نقش‌های کاربری و اتصال‌ها را در پیوست مشخص کنید. تعیین کنید چه چیزی در نسخه اول انجام می‌شود و چه مواردی بیرون از محدوده است.
برای قابلیت‌های مهم، مثال پذیرش بنویسید. مثلاً پس از ثبت فرم معتبر، درخواست باید در پنل دیده شود و شماره پیگیری به کاربر نمایش داده شود. چنین توضیحی از اختلاف درباره معنای «تکمیل‌شدن» کم می‌کند.
نقش و تعهد هر طرف را بنویسید
مسئول تهیه متن، تصویر، اطلاعات محصول، دسترسی سرویس‌ها و مجوزهای لازم را مشخص کنید. از سمت کارفرما یک نفر اختیار جمع‌بندی نظرها و تأیید مراحل را داشته باشد. از سمت تیم اجرا نیز مسئول پاسخ‌گویی و مسیر ثبت تصمیم‌ها معلوم باشد.
اگر تحویل محتوا یا دسترسی به سامانه‌ای پیش‌نیاز کار است، اثر تأخیر آن را در برنامه روشن کنید. گفتگو درباره وابستگی‌ها باید پیش از شروع انجام شود.
پرداخت را به مرحله‌های قابل سنجش وصل کنید
برنامه پرداخت، مبلغ، واحد پول، شرایط صورتحساب و خروجی متناظر هر مرحله را مشخص کنید. برای بازبینی و اعلام نقص، مهلت و روش ثبت نظر در نظر بگیرید. از عبارت‌های مبهم درباره تأیید خودکار یا تحویل کلی پرهیز کنید.
تغییرات و اصلاحات را تفکیک کنید
اصلاح یک خطا با افزودن قابلیت تازه تفاوت دارد. در قرارداد روشن کنید چند دور بازبینی طراحی پیش‌بینی شده و درخواست خارج از محدوده چگونه ارزیابی و تأیید می‌شود.
برای تغییر مهم، شرح تغییر، اثر آن بر مبلغ و زمان و تأیید دو طرف را ثبت کنید. پیام پراکنده بدون ثبت نتیجه می‌تواند باعث اختلاف در اولویت‌ها شود.
مالکیت، مجوز و دسترسی را جداگانه بررسی کنید
درباره حقوق استفاده و توسعه، تحویل کد و فایل طراحی، اجزای از پیش موجود و مجوز سرویس‌های ثالث گفتگو کنید. داشتن حساب مدیریت سایت با دریافت همه فایل‌ها یا حقوق همه اجزا یکسان نیست؛ هرکدام باید روشن شوند.
قانون حمایت از حقوق پدیدآورندگان نرم‌افزارهای رایانه‌ای به نرم‌افزار سفارشی نیز می‌پردازد. متن قرارداد و شرایط پروژه می‌توانند در تعیین حقوق اثر داشته باشند؛ برای تنظیم بندهای حقوقی از بررسی تخصصی متناسب با قرارداد استفاده کنید.
متن قانون حمایت از حقوق پدیدآورندگان نرم‌افزار در WIPO Lex
تحویل و پشتیبانی را قابل پیگیری کنید
فهرست فایل‌ها، حساب‌ها، مستندات و آموزش را در تحویل ثبت کنید. مدت رفع نقص، زمان پاسخ، روش گزارش مشکل و هزینه نگهداری پس از پایان دوره اولیه را جدا بنویسید. همچنین روش پایان همکاری، تسویه و انتقال دسترسی‌ها باید روشن باشد.
این چک‌لیست برای آماده‌سازی گفتگو است و متن آماده قرارداد محسوب نمی‌شود. پیش از امضا، سازگاری بندها با وضعیت طرفین، قوانین قابل اعمال و شرایط واقعی پروژه بررسی شود.
پیوست محدوده را به بخشی از قرارداد تبدیل کنید
عنوان پروژه یا عبارت «طراحی سایت کامل» برای تعیین تعهد کافی نیست. محدوده را با فهرست صفحه‌ها، نقش‌های کاربری، جریان‌های اصلی، زبان‌ها، اتصال‌ها و اقلام تحویل توضیح دهید. مواردی که عمداً در نسخهٔ نخست نیستند نیز نوشته شوند. این شفافیت جلوی اختلاف دربارهٔ این‌که یک قابلیت بدیهی بوده یا درخواست تازه محسوب می‌شود را می‌گیرد.
برای هر رفتار مهم، یک معیار پذیرش قابل مشاهده بنویسید. مثلاً کاربر پس از ثبت فرم معتبر پیام پیگیری ببیند، مدیر بتواند رکورد را در پنل مشاهده کند و اعلان به گیرندهٔ تعیین‌شده برسد. معیار نباید فناوری داخلی را بی‌دلیل تحمیل کند؛ باید بگوید نتیجهٔ مورد انتظار چیست و چگونه بررسی می‌شود. مسیرهای خطا و دادهٔ نامعتبر را نیز برای قابلیت‌های حساس مشخص کنید.
تقویم، وابستگی‌ها و مسئولیت‌ها را دقیق ثبت کنید
تاریخ آغاز، موعدهای مرحله‌ای، بازهٔ بررسی کارفرما و شرایط جابه‌جایی زمان باید کنار هم دیده شوند. فهرست کنید چه چیزی از سمت شما پیش‌نیاز کار است: محتوا، مجوز تصویر، اطلاعات محصول یا دسترسی آزمایشی. مشخص کنید اگر ورودی دیر برسد، برنامه چگونه بازبینی می‌شود و چه کسی تغییر تاریخ را اعلام می‌کند. از عبارت «تحویل در اولین فرصت» برای موعد قراردادی استفاده نکنید.
نام مسئول ارتباط و تأیید از هر طرف را بیاورید. بنویسید درخواست رسمی تغییر از چه کانالی ثبت می‌شود، صورت‌جلسه‌ها کجا نگهداری می‌شوند و چه کسی اختیار تأیید مبلغ و زمان تازه را دارد. اگر شرکت چند واحد تصمیم‌گیر دارد، یک مالک تصمیم نهایی تعیین کنید. ثبت مسئولیت‌ها به تیم کمک می‌کند از تأییدهای متناقض یا پیام‌هایی که مبنای قرارداد نیستند جلوگیری کند.
پرداخت را با مرحله و صورتحساب روشن کنید
مبلغ، واحد پول، مالیات یا هزینه‌های جانبی، تاریخ سررسید و روش پرداخت را واضح بنویسید. برای هر قسط، مرحله یا خروجی متناظر مشخص باشد. اگر پرداخت به پذیرش کار وابسته است، روش اعلام نقص و زمان بازبینی را تعریف کنید. شرایط پیش‌پرداخت، توقف موقت پروژه و هزینهٔ کارهای انجام‌شده هنگام خاتمه نیز باید با واقعیت همکاری هماهنگ باشند.
پیش از امضا دربارهٔ خرید سرویس‌های بیرونی هم توافق کنید. گاهی دامنه، سرور، پیامک یا مجوز نرم‌افزار به نام مجری تهیه می‌شود و پس از پایان همکاری انتقال آن دشوار خواهد بود. مشخص کنید هزینه به چه حسابی پرداخت می‌شود، رسید در اختیار چه کسی است و مالک اشتراک چه کسی خواهد بود. این موارد را در پیشنهاد و قرارداد یکسان نگه دارید.
فرایند تغییر را جدا از رفع نقص تعریف کنید
خطا یعنی خروجی با معیار پذیرش توافق‌شده مطابقت ندارد؛ تغییر محدوده یعنی قابلیت یا رفتار تازه‌ای درخواست شده است. برای هر دو مسیر، روش ثبت و پاسخ را مشخص کنید. در قرارداد بنویسید چند دور بازبینی طرح شامل مبلغ است و نظرها در چه قالبی باید ارسال شوند. از عبارت نامحدود «اصلاح تا رضایت کامل» پرهیز کنید، چون مرز میان اصلاح و تغییر را روشن نمی‌کند.
هر تغییر مهم باید شرح کوتاه، دلیل، اثر بر هزینه و زمان و تأیید طرفین داشته باشد. تیم نباید پیش از تأیید، تغییر خارج از محدوده را اجراشده فرض کند؛ کارفرما نیز نباید انتظار داشته باشد درخواست تازه بدون بررسی به برنامهٔ ثابت اضافه شود. یک فهرست تصمیم‌ها و تغییرات نگهداری کنید تا نسخهٔ جاری توافق برای هر دو طرف قابل دسترسی باشد.
برآورد پروژه و اثر تغییر محدوده
مالکیت کد، طراحی و اجزای دارای مجوز را تفکیک کنید
در مورد فایل طراحی، کد منبع، داده، مستندات و دسترسی مخزن جداگانه توافق کنید. مشخص کنید چه زمانی هر مورد تحویل می‌شود و آیا دریافت آن به تسویهٔ مرحله وابسته است. کتابخانه‌ها، قالب‌ها و اجزای از پیش ساخته‌شده ممکن است تحت مجوز جداگانه باشند؛ مالکیت نرم‌افزار سفارشی به‌تنهایی مجوز همهٔ وابستگی‌ها را تغییر نمی‌دهد. فهرست مجوزهای ثالث و هزینهٔ تمدید باید قابل بررسی باشد.
دربارهٔ حق استفاده، توسعه توسط تیم دیگر و محدودیت‌های انتشار گفت‌وگو کنید. اگر محصول برای کارفرمای خاص ساخته می‌شود، دامنهٔ واگذاری حقوق و اجزای عمومی که مجری پیش از پروژه داشته است را از هم جدا کنید. قانون حمایت از حقوق پدیدآورندگان نرم‌افزارهای رایانه‌ای در WIPO Lex قابل مشاهده است؛ این منبع جای بررسی حقوقی متناسب با قرارداد، طرفین و شرایط واقعی را نمی‌گیرد.
متن قانون حمایت از حقوق پدیدآورندگان نرم‌افزار در WIPO Lex
دسترسی، محرمانگی و دادهٔ کاربران را در نظر بگیرید
اگر مجری با اطلاعات مشتری یا داده‌های کسب‌وکار شما کار می‌کند، دستهٔ داده، هدف استفاده، سطح دسترسی و روش انتقال آن را روشن کنید. اطلاعات ورود مشترک ارسال نکنید؛ برای هر فرد حساب جدا بسازید و پس از پایان نیاز، دسترسی را لغو کنید. دربارهٔ نسخه‌های پشتیبان، محیط آزمایشی، گزارش رخداد امنیتی و حذف یا بازگرداندن داده هنگام پایان همکاری توافق داشته باشید.
اگر سرویس بیرونی اطلاعات را پردازش می‌کند، نام آن و مسئولیت پیکربندی حساب را ثبت کنید. برای نمونه، اعلان پیامکی، تحلیل بازدید یا ذخیره‌سازی فایل می‌تواند داده را به سرویس دیگری منتقل کند. حریم خصوصی سایت باید با رفتار واقعی محصول هماهنگ باشد. از درج وعده‌ای که امکان اجرای فنی یا حقوقی آن را بررسی نکرده‌اید خودداری کنید و دسترسی‌های لازم را با حداقل سطح ممکن بدهید.
پشتیبانی، ضمانت رفع نقص و توسعهٔ آینده را جدا کنید
مدت رفع نقص‌های قراردادی را از پشتیبانی دوره‌ای و توسعهٔ قابلیت جدید جدا بنویسید. مشخص کنید هر درخواست از چه کانالی ثبت می‌شود، ساعت کاری چیست، زمان تأیید دریافت چقدر است و چه مواردی از قرارداد خارج‌اند. زمان پاسخ، زمان شروع بررسی و زمان رفع کامل سه مفهوم متفاوت هستند؛ اگر شاخص زمانی تعریف می‌کنید، معنای آن را دقیق توضیح دهید.
شرایط به‌روزرسانی وابستگی‌ها، تمدید سرویس‌ها و بررسی نسخهٔ پشتیبان را هم تعیین کنید. اگر کارفرما مسئول نگهداری پس از تحویل است، آموزش و مستندات لازم را در اقلام تحویل بگنجانید. اگر تیم اجرا نگهداری را ادامه می‌دهد، محدوده، گزارش و روش خاتمهٔ خدمت مشخص باشد. این تفکیک کمک می‌کند نقص اولیه به‌عنوان درخواست توسعه صورتحساب نشود و تغییر جدید هم رایگان فرض نشود.
خاتمهٔ همکاری و انتقال محصول را از پیش پیش‌بینی کنید
قرارداد باید توضیح دهد هر طرف در چه شرایطی می‌تواند همکاری را خاتمه دهد، چه اخطاری لازم است و هزینهٔ کار تکمیل‌شده چگونه محاسبه می‌شود. وضعیت پیش‌پرداخت، فایل‌های موجود، دسترسی‌های موقت و اطلاعات مشتری را هنگام پایان مشخص کنید. اگر بخشی از کار به تیم دیگر منتقل می‌شود، مسئول آماده‌کردن مستندات و زمان لازم برای تحویل را تعیین کنید.
راه انتقال کد و داده را با قالب و ابزارهای متداول هماهنگ کنید. وابستگی به حساب شخصی، مخزن غیرقابل انتقال یا رمز ذخیره‌شده نزد یک فرد ممکن است ادامهٔ پروژه را دشوار کند. برای بخش‌های حیاتی، نسخهٔ پشتیبان و روش بازیابی را مستند کنید. خاتمهٔ همکاری بهتر است به فرایند فنی روشنی منتهی شود تا کسب‌وکار بتواند محصول را بدون وقفه به تیم دیگر بسپارد.
چک‌لیست دریافت فایل‌ها و دسترسی‌های پروژه
پیش از امضا این پرسش‌ها را مرور کنید
آیا محدوده و موارد خارج از آن روشن‌اند؟ آیا پرداخت با خروجی و مهلت بازبینی پیوند دارد؟ چه کسی محتوا و دسترسی را فراهم می‌کند؟ تغییر درخواست چگونه قیمت‌گذاری می‌شود؟ کد، طراحی و حساب سرویس‌ها چه زمانی تحویل می‌شوند؟ نقص پس از انتشار از چه مسیری گزارش می‌شود؟ پاسخ کوتاه به این پرسش‌ها نشان می‌دهد کدام بندها هنوز نیازمند گفتگو هستند.
چک‌لیست این مقاله ابزار آماده‌سازی گفتگو است و متن حقوقی آمادهٔ امضا محسوب نمی‌شود. قرارداد باید با وضعیت کسب‌وکار، طرفین، نوع داده و قوانین قابل اعمال سازگار باشد. در پروژهٔ بزرگ یا دارای ریسک حقوقی و مالی بالا، بررسی متخصص حقوقی را پیش از امضا در برنامه قرار دهید. نسخهٔ نهایی را با پیشنهاد فنی و صورت‌جلسه‌ها تطبیق دهید تا تعارضی میان اسناد باقی نماند.
درخواست بررسی پروژه و محدودهٔ همکاری
پذیرش نسخه را با آزمون و صورت‌جلسه پیش ببرید
برای تحویل مرحله‌ای، مهلت بررسی، مسیر اعلام نقص و معیار رفع را پیش از امضا تعیین کنید. اگر کارفرما فرصت آزمون ندارد، نتیجهٔ مرحله چگونه ثبت می‌شود؟ اگر نقص در یک مسیر اصلی باشد، آیا انتشار متوقف می‌شود؟ پاسخ به این پرسش‌ها را روشن کنید. تأیید شفاهی یا پیام پراکنده را با صورت‌جلسهٔ کوتاه و نسخهٔ مورد بررسی همراه کنید تا بعداً معلوم باشد کدام خروجی تأیید شده است.
سناریوهای پذیرش را با کار واقعی بنویسید، نه فقط نام صفحه. برای نمونه در فرم سفارش، ثبت دادهٔ معتبر، خطای دادهٔ ناقص، مشاهدهٔ درخواست در پنل و دریافت اعلان را بررسی کنید. در اپلیکیشن ممکن است آزمون به نقش کاربر، قطع اتصال یا نسخهٔ دستگاه وابسته باشد. این سناریوها مبنای منصفانه‌تری برای تحویل می‌سازند و به تیم اجازه می‌دهند ابهام معیار را پیش از اجرا رفع کند.
از قرارداد امضاشده نسخهٔ اجرایی نگهداری کنید
پس از امضا، نسخهٔ نهایی قرارداد، پیوست محدوده، جدول پرداخت و تغییرهای تأییدشده را در محل مشترک و امن نگهداری کنید. نسخه‌های پیش‌نویس را از نسخهٔ لازم‌الاجرا جدا کنید و تاریخ تغییرها را ثبت کنید. هر تصمیم مهم جدید باید با قرارداد سازگار و قابل پیگیری باشد. اگر دو سند دربارهٔ یک موضوع متفاوت می‌گویند، پیش از اجرا آن را روشن کنید تا تیم براساس برداشت خودش انتخاب نکند.
در طول پروژه، فهرست کوتاهی از تصمیم‌های باز و مسئول پیگیری نگه دارید. این فهرست جای قرارداد نیست؛ ابزار روزمره‌ای برای جلوگیری از فراموشی است. اگر تغییری اثر مالی یا زمانی دارد، ثبت آن را به روش رسمی توافق‌شده ارجاع دهید. پیش از پرداخت نهایی، اقلام تحویل را با قرارداد تطبیق کنید و نقص‌های باقی‌مانده و موعدشان را در صورت‌جلسه بیاورید.
راهنمای تحویل فایل و دسترسی‌های نرم‌افزار
پیوست محدوده را با فرم سفارش تطبیق دهید
پیش از امضا، انتخاب‌های فرم اولیه را با پیوست قرارداد مقایسه کنید. اگر کارفرما اپلیکیشن برای هر دو پلتفرم خواسته، قرارداد نباید فقط عبارت کلی «توسعه موبایل» داشته باشد. اگر تولید محتوا یا درج محصول درخواست شده، تعداد، نوع محتوا و روش تأیید آن مشخص شود. فرم درخواست جای قرارداد را نمی‌گیرد؛ اطلاعاتش نقطه شروع گفتگو است و هر مورد باید در پیشنهاد نهایی تعیین تکلیف شود.
برای رابط‌های پیچیده، تحویل طراحی و تأیید مستند آن را یک مرحله مستقل بنویسید. معلوم باشد چه کسی از سمت کارفرما اختیار تأیید دارد و تغییر پس از تأیید چگونه ارزیابی می‌شود. بهتر است نسخه فایل طراحی یا سند تأیید قابل شناسایی باشد تا برداشت‌ها درباره خروجی مورد توافق متفاوت نشود. همین روش را برای نمونه داده، گزارش‌ها و اتصال به سرویس بیرونی نیز به کار ببرید.
در بخش مالی، خدماتی مانند سئو، اتصال به ترب و ایمالز، ورود محصول و تولید محتوا را از دستمزد پایه جدا کنید. هاست، دامنه و تعرفه ابزارهای بیرونی نیز مسئول پرداخت مشخص می‌خواهند. دوره پشتیبانی رایگان، محدوده رفع اشکال و شرایط قرارداد بعدی باید روشن باشند. برای قرارداد متناسب با وضعیت خاص کسب‌وکار، بررسی توسط مشاور حقوقی واجد صلاحیت می‌تواند لازم باشد؛ این راهنما جای ارزیابی حقوقی اختصاصی را نمی‌گیرد.
دیدگاه‌ها
۰ دیدگاه تأییدشدههنوز دیدگاه تأییدشدهای ثبت نشده است. آغازگر گفتگو باشید.