چرا پروژه‌های نرم‌افزاری دیر و گران تمام می‌شوند؟ هفت دلیل واقعی و راه جلوگیری از هر کدام
بیشتر وقت‌ها دلیل دیر و گران شدن یک پروژه، کد بد نیست. چیزهایی است که پیش از اولین خط کد اتفاق افتاده‌اند. این هفت دلیل رایج را می‌گوید، و برای هر کدام کاری که قبل از شروع از دستت برمی‌آید.
اگر تا حالا پروژه‌ای نرم‌افزاری سفارش داده‌ای و دیرتر و گران‌تر از وعده تمام شده، بدان تنها نیستی؛ و بدان که تقصیر معمولاً یک آدم نیست. این‌ها الگوهایی‌اند که بارها تکرار می‌شوند، و بیشترشان را می‌شود قبل از شروع دید.
یک نکته از اول: هیچ‌کدام از این‌ها به معنای «برنامه‌نویس بد» نیست. بدترین برنامه‌نویس دنیا هم می‌تواند پروژه‌ای را دیر کند، و بهترین‌شان هم نمی‌تواند چیزی را که هیچ‌کس ننوشته بسازد.
۱. دامنه‌ای که هیچ‌وقت نوشته نشد
اسمش را می‌گذارند «افزایش دامنه»، ولی اغلب دامنه‌ای نبوده که بزرگ شود. چیزی که هست، تصوری است که در ذهن کارفرما بوده و برای برنامه‌نویس به‌طور خودکار روشن نبوده. وقتی بعد از ماه دوم می‌گویی «منظورم این بود که کاربر بتواند با گوگل هم وارد شود» و او می‌گوید «این در قرارداد نبود»، هر دو راست می‌گویید.
کاری که می‌شود کرد: قبل از شروع، دو فهرست بنویس: چه چیزی داخل نسخهٔ اول است و چه چیزی نیست. راهنمای بریف دقیقاً برای همین است.
۲. تصمیم‌گیرندهٔ نامشخص
اگر سه نفر از طرف تو نظر می‌دهند و هیچ‌کدام مسئول حرف آخر نیست، هر تغییر یک دور بازگشت می‌شود. برنامه‌نویس یک چیز می‌سازد، نفر اول می‌گوید نه، نفر دوم می‌گوید همین خوب بود، و تا تکلیف روشن شود یک هفته رفته.
کاری که می‌شود کرد: یک نفر را به‌عنوان مرجع نهایی معرفی کن. لازم نیست او همه‌چیز را بداند؛ فقط باید بتواند «بله» یا «نه» بگوید.
۳. «ساده است» که ساده نیست
دو جمله هستند که بیشترین هزینهٔ پنهان را می‌سازند: «فقط یک درگاه پرداخت وصل کن» و «فقط داده‌های قبلی را منتقل کن».
اتصال به یک سرویس بیرونی یعنی خواندن مستنداتی که شاید قدیمی باشند، رفتار سرویس وقتی خطا می‌دهد، حالتی که پرداخت انجام شده ولی پاسخ نرسیده، و آزمایش با حساب واقعی. انتقال داده یعنی داده‌هایی که ده سال با دست وارد شده‌اند و هر کدام یک‌جور نوشته شده. هیچ‌کدام کار «سریع» نیست.
کاری که می‌شود کرد: همهٔ سیستم‌های بیرونی و داده‌های موجود را در بریف فهرست کن، حتی اگر به نظرت جزئی‌اند. برنامه‌نویس خوب سر همین‌ها بیشترین سؤال را می‌پرسد، و این سؤال‌ها را باید نشانهٔ خوبی بدانی.
۴. بازخورد دیر
اگر نتیجه را فقط در پایان می‌بینی، هر سوءتفاهمی تا پایان زنده می‌ماند. سه ماه بعد صفحه‌ای را می‌بینی که با تصورت فرق دارد، و حالا درست کردنش یعنی بازسازی نه تعدیل.
کاری که می‌شود کرد: تحویل کوچک و مرتب. هر یکی دو هفته چیزی که بشود دید و امتحان کرد، حتی ناقص. چنین توافقی را از اول بنویس، نه وسط راه. نوشتهٔ قرارداد می‌گوید چطور.
۵. چیزهایی که از طرف تو می‌آیند و دیر می‌رسند
متن‌ها، تصویرها، دسترسی به سرور، مستندات سرویس‌های بیرونی، تأیید طرح، پاسخ به یک سؤال. هر کدام چند روز دیر برسد، برنامه‌نویس یا منتظر می‌ماند یا سراغ کار دیگری می‌رود و برگشتنش هزینه دارد. بسیاری از «تأخیرهای برنامه‌نویس» در واقع تأخیرهای ورودی‌اند.
کاری که می‌شود کرد: فهرستی از «چیزهایی که من باید بدهم» همراه با تاریخ داشته باش و همان‌قدر جدی بگیر که فهرست چیزهایی که او باید بدهد.
۶. میان‌بری که بدهی می‌شود
برای رسیدن به یک تاریخ، چیزی را موقتی می‌نویسند: بدون تست، با یک راه‌حل سرهم‌شده، با ساختار داده‌ای که فقط برای همین حالت جواب می‌دهد. گاهی کاملاً درست است؛ ولی «موقتی» تقریباً هیچ‌وقت جایش را به «اصولی» نمی‌دهد مگر اینکه صریحاً برایش وقت بگذاری. بدهی فنی مثل بدهی مالی است: اگر ندانی چقدر است، نمی‌دانی کی باید پرداخت.
کاری که می‌شود کرد: از برنامه‌نویس بخواه هر میان‌بر را بگوید و بگوید اگر بعداً بخواهی درستش کنی چقدر هزینه دارد. یک خط در یک سند کافی است؛ مهم این است که پنهان نماند.
۷. هیچ‌کس مالک «تمام شد» نیست
اگر تعریف مشخصی از اتمام نداری، همیشه یک تغییر دیگر هست. «یک رنگ را عوض کنیم»، «این دکمه یک‌کم بزرگ‌تر شود». هر کدام کوچک است، ولی با هم ماه‌ها طول می‌کشد.
کاری که می‌شود کرد: معیار موفقیت را از اول بنویس. «وقتی کاربر بتواند X را انجام بدهد و من Y را ببینم». بعد از رسیدن به آن، هر چیز دیگر یک درخواست تازه است، نه ادامهٔ کار قبلی.
پنج سؤال قبل از شروع
اگر وقت نداری همهٔ این‌ها را بخوانی، فقط این پنج سؤال را جواب بده. اگر هر کدام را نمی‌توانی، پروژه هنوز آمادهٔ شروع نیست.
- مشکل چیست، و معیار موفقیت چطور اندازه‌گیری می‌شود؟
- چه چیزی در نسخهٔ اول داخل است و چه چیزی نیست؟
- چه سیستم‌ها و داده‌هایی از قبل هست که باید وصل یا منتقل شود؟
- چه کسی تصمیم نهایی را می‌گیرد، و چه چیزهایی را من باید در چه تاریخی بدهم؟
- بعد از تحویل، چه کسی نگهش می‌دارد؟
اگر می‌خواهی هر پنج را همین‌جا و قدم‌به‌قدم جواب بدهی، ویزارد بریف پروژه همین‌ها را می‌پرسد.