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