یک قرارداد توسعه نرم‌افزار و برنامه‌نویسی هم می‌تواند به شکل پروژه‌ای باشد و هم به شکل ساعتی. در ایران فرم پروژه‌ای رواج خیلی بیشتری دارد. آن معدود قراردادهای ساعتی هم که وجود دارد بیشتر مخصوص حالاتی است که در آن کارفرما شناخت مستقیم و اطمینان زیادی نسبت به شخص یا تیم توسعه‌دهنده دارد. در حالی که قرارداد ساعتی مدل بی‌عیب و نقصی نیست، اما من اعتقاد دارم که همین قراردادهای ساعتی تناسب بیشتری با موضوع توسعه نرم‌افزار دارند، حداقل در پروژه‌های کوچک.

یکی از اولین توافقاتی که هنگام شروع یک پروژه جدید انجام می‌شود توافق روی ساعتی بودن یا پروژه‌ای بودن کار است که البته بیشتر وقت‌ها انتخابی جز پروژه‌ای وجود ندارد. کارفرما یا مشتری اطمینانی به مجری ندارد. فکر می‌کند که یک قرارداد ساعتی هیچ وقت به سر انجام نمی‌رسد و اگر هم برسد با هزینه خیلی بیشتر است که به جواب می رسد. البته همیشه هم مثال‌های خیلی زیادی علیه قراردادهای ساعتی وجود دارد.

دفاع از حقوق مجری

اولین مشکلی که یک قرارداد ساعتی حل می‌کند، دفاع از حقوق مجری و راحت کردن خیال او از تغییرات مداوم و بی‌پایان پروژه است. مشکلی که خصوصاً برنامه‌نویسان Freelancer حداقل یک بار در عمرشان با آن دست و پنجه نرم کرده‌اند. یک قرارداد خوب قراردادی است که حقوق دو طرف در آن رعایت شده باشد و نه فقط حقوق کارفرما. خیلی از قراردادهای توسعه نرم‌افزار در ایران یک طرفه نوشته می‌شوند. مجری چه یک Freelancer تازه‌کار باشد چه یک شرکت نرم‌افزاری با یک تیم برنامه‌نویسی ده نفره و سابقه کار 15 ساله، مجبور است تضمین‌های قابل توجهی روی قرارداد ارائه دهد. از چک و سفته گرفته تا ضمانت نامه بانکی. معمولاً هم زمان پایان قرارداد یک مقدار موش و گربه بازی هست تا قرارداد تسویه شود.

البته کارفرما هم تا اندازه‌ای حق دارد. او مار گزیده‌ای است که از ریسمان سیاه و سفید می‌ترسد. اما این روال باید عوض شود. قرارداد پروژه‌ای (در یک سری موارد مشخص) از یک طرف ضایع کردن حق مجری است و از طرف دیگر باعث خراب شدن بازار توسعه نرم افزار سفارش مشتری و نهایتاً ضرر غیر مستقیم کارفرما.

کارفرما با جزییات تولید نرم‌افزار آشنا نیست

نا آشنایی کارفرما با پروسه تولید نرم‌افزار یکی از اولین مشکلاتی است که باید حل شود. خیلی از کارفرماها و مشتری‌ها درک خوبی از بزرگی یا کوچکی یک Feature ندارند. بعضی امکانات اولیه برای آنها خیلی بزرگ است و بعضی چیزهای خیلی پیچیده و زمان‌بر از نظر آنها خیلی ساده است. بعضی وقت‌ها یک جستجوی ساده دیتابیسی از نظر آنها آخر تکنولوژی است در حالی که بعضی وقت‌ها مباحث پیچیده‌ای مثل Sync یا Offline Working برایشان یک کار یک روزه به نظر می‌رسد.

تعدادی از کارفرماها در تفکیک امکانات Application از OS و Platform مشکل دارند. زمانی که نرم‌افزارهای تحت وب تازه مد شده بود، تفاوت اینترنت و اینترانت برای بعضی‌ها کمی سخت بود. مقایسه یک نرم‌افزار پیشرفته و بزرگ مثل Microsoft Office با یک پروژه سفارش مشتری که حداکثر 4 نفر روی آن کار می‌کنند اشتباه رایجی بین سفارش دهندگان است. بعضی از به اصطلاح مجری‌ها، دستی به سر و روی یک پروژه Open Source کشیده و آن را به جای یک نرم‌افزاری سفارشی تحویل داده‌اند. این کار باعث به وجود آمدن این باور بین بعضی کارفرماها شده که مجری خیلی کد نمی‌نویسد بلکه بیشتر آن را از اینترنت پیدا می‌کند. بعضی از مشتری‌ها تفاوت بین Config کردن و نصب چیزی مثل WordPress را با نوشتن یک CMS که زمان بسیار زیادتری نیاز دارد را نمی‌دانند.

کارفرما چون اینها را نمی‌داند به برنامه‌نویس بدبین می‌شود. در نتیجه از قرارداد ساعتی امتناع می‌کند. کارفرما چون پروژه را نمی‌شناسد و نمی‌تواند بخش‌های مختلف آن را از هم تفکیک کند ترجیح می‌دهد که کل کار را یک باره به صورت یک پروژه کامل واگذار کند. همین شناخت پایین باعث می‌شود کارفرما نتواند جزییات کار تیم توسعه نرم‌افزار را متوجه شود و دنبال کند.

تغییرات مداوم توسط کارفرما

به جز در پروژه های خیلی روتین مثل نرم افزار حسابداری، کارفرما معمولا تغییرات مداومی در طول پروژه خواهد داشت. جلوی این تغییرات را خیلی نمی شود گرفت. چون واقعاً اگر بعضی تغییرات و اصلاحات اعمال نشود کل آن پروژه زیر سوال خواهد رفت. وقتی که قرارداد به صورت پروژه ای بسته شده باشد، دود این تغییرات به چشم مجری خواهد رفت. برداشت او از پروژه مدام تغییرا پیدا می‌کند. مجبور است بخش های که طراحی شده و پیاده سازی هم شده را تغییر دهد. به دنبال همه این ها تخمین زمانی و هزینه ای پروژه ای هم بالا و پایین می‌شود. خیلی وقت‌ها متمم‌هایی به قرارداد اضافه می‌شود تا تغییرات جدید را پوشش دهد. اما اولاً که این متمم‌ها برای تغییرات عمده است نه تغییرات کوچکی که معمولاً فرکانس بالایی هم دارند. و ثانیاً این که خود این متمم‌ها به بلای اصل قرارداد دچار هستند. یعنی پروژه‌ای هستند نه ساعتی.

کارفرما می‌تواند بخشی از این مشکل را با افزایش شناخت خودش از پروژه حل کند. او می‌تواند یک مستند شناخت سیستم تهیه و حسابی روی آن کار کند. آن را به شرکا و سرمایه‌گذاران نشان دهد و از دیگر برنامه نویسان راجع به کیفیت آن سوال کند. اما خوب این اتفاق در عمل نمی‌افتد و خود کارفرما تازه حین پروژه است که شناخت کاملی از پروژه پیدا می‌کند.

اگر قرارداد وسط کار نصفه نیمه ول شد چه اتفاقی می‌افتد؟

اگر یک قرارداد ساعتی وسط کار Cancel شود، حالا چه توسط کارفرما چه توسط مجری، تکلیف تا اندازه‌ای روشن است. اگر فرض کنیم تسویه حساب‌ها هفتگی انجام می‌شده‌اند و هر صورتحسابی نیاز به تایید توسط کارفرما داشته آن وقت می‌توانیم حدس بزنیم که فقط صورتحساب هفته آخر است که ممکن است دچار دردسر شود. البته در این مدل قرارداد باید در پایان هر هفته کل کارهای انجام شده شامل سورس کد، مستندات و غیره هم به کارفرما تحویل داده شود. و چیزی هم که تحویل می‌شود باید قابل اجرا و قابل استفاده (تا آن مرحله از کار) باشد. تا کارفرما هم دستش خالی نمانده و دچار ضرر و زیان نشود.

اما در یک قرارداد پروژه‌ای اوضاع خیلی فرق می‌کند. حتی اگر تحویل کار و تسویه حساب فاز به فاز یک ماهه هم در نظر گرفته شود باز هم مشکلاتی به وجود می‌آیند. اول این که فازهای پروژه معمولاً بیش از یک ماه طول می‌کشند. دوم این که مرز فازها آنقدرها هم که فکر می‌کنیم مشخص و واضح نیستند. یک نفر باید بیاید و بین طرفین وساطت کند. چون معلوم نیست تعریف فاز در کار انجام شده می گنجد یا نه. چون کار هم پروژه‌ای پیش می‌رفته ممکن است در لحظه قطع کار، همه چیز آماده تحویل نباشد.

نیاز به مشاور

کارفرما برای آن که بتواند یک قرارداد مشاوره‌ای را به سر انجام برساند نیاز به مشاور دارد. در غیر این صورت ممکن است در هزار توی تعاریف Business Logic، تکنولوژی‌های مورد استفاده، متودولوژی تولید، Open Source و چندین مبحث دیگر گم شود. علاوه بر گم شدن باید نگران مجری ناوارد یا مجری که قصد دور زدن دارد هم بود.

کارفرما باید بتواند کار مجری را در پایان هر هفته ارزیابی کرده و تحویل بگیرد. کار تحویلی هر هفته می‌تواند شامل سورس کد باشد یا مستندات. ولی به هر حال چیزی که تحویل گرفته می‌شود باید قابلیت اجرا و استفاده داشته باشد. یک کارفرمای معمولی خودش به تنهایی نمی‌تواند این کار را انجام بدهد. یک مشاور فنی می‌تواند به او کمک کند تا این کارها را بهتر انجام دهد.

کارفرما و مجری باید روابط دوستانه داشته باشند اما در عین حال کارفرما باید همیشه طوری تحویل کار منظم و همیشگی داشته باشد که انگار همین فرداست که کار یک باره قطع شده و همکاری متوقف گردد. بنابراین هدایت کلیت کار باید طوری باشد که کار توسط تیم دیگر هم قابل ادامه باشد. کاری که از یک تیم تحویل گرفته می‌شود باید طوری باشد که تیم جدید بتواند آن را خوب بفهمد، اجرا کند و تغییرات را ادامه دهد. یک مشاور خوب در این زمینه هم می‌تواند کمک کند.

پیدا کردن تیم خوب

یکی از مشکلات کارفرما در راستای قرارداد ساعتی، پیدا کردن تیم خوب است. انجام این کار برای کارفرما سخت است. در عین حال در یک قرارداد ساعتی نیاز به شناخت خوبی از تیم هست و بعضاً نیاز به عوض کردن تیم هم هست. نتیجه این که کارفرما ترجیح می‌دهد از روش دیگری به جز قرارداد ساعتی استفاده کند.

اگر پیدا کردن تیم برنامه‌نویسی برای کارفرما راحت باشد و بتواند در مواقع لزوم تیم را عوض کند، آن وقت راحت‌تر به قرارداد ساعتی تن می‌دهد.

خلاصه

به طور کلی در تکمیل موارد بالا می‌توان گفت که تعریف کامل پروژه بار حقوقی دارد و برای یک پروژه کوچک یا متوسط توجیه ندارد. در نتیجه خیلی از قراردادهای پروژه‌ای بدون تعریف دقیق پروژه تعریف شده و انجام می‌شوند. تازه تعریف دقیق مرزهای پروژه نیاز به صرف زمان و بررسی و تحقیق دارد. چیزی که کارفرمای معمولی در ابتدای کار در اختیار ندارد. خیلی از کارفرماها تازه وسط پروژه است که درک‌شان از پروژه کامل می‌شود.

به طور کلی، کار تولید نرم‌افزار مثل یک پروژه EPC روتین نیست که بشود برای آن خیلی راحت پروژه تعریف کرد. اصولا همین پروژه‌های ساختمانی هستند که الگوی بدی برای توسعه نرم‌افزار شده‌اند.

در همین راستا مطالب زیر را هم بخوانید:

• چالش بین صاحب ایده‌ها و پروژه‌های توسعه نرم‌افزار
• ابزار ارتباطی تیمی: تلگرام یا اسلک؟