تخمین زمان و هزینه در پروژه نرمافزاری
قانونی نانوشته در این صنعت هست: هر پروژه دو برابر تخمین اولیه طول میکشد. و وقتی این را میدانید و تخمین را دو برابر میکنید، باز هم دو برابر میشود.
این شوخی قدیمی است اما پشتش یک واقعیت آماری خوابیده که فهمیدنش تخمین شما را بهتر میکند: مسئله خوشبینی نیست، عدمتقارن است.
چرا تخمینها یکطرفه غلط میشوند
کاری که تخمین دو روز خورده، ممکن است یک روز و نیم تمام شود. حداکثر صرفهجویی شما نصف روز است.
همان کار ممکن است ده روز طول بکشد — چون معلوم شد سرویس بیرونی مستند غلط دارد، یا دادهای که فرض شده بود موجود است نیست.
پس توزیع خطا متقارن نیست: کف دارد و سقف ندارد. جمع تعداد زیادی تخمین با این شکل، همیشه از مجموع اعداد اسمی بزرگتر درمیآید. این ریاضیات است، نه بیانضباطی تیم.
نتیجهٔ عملی: اگر تیم شما مدام سی درصد عقب است، لزوماً بد تخمین نمیزند. احتمالاً عدد میانه را میگوید و شما آن را بهعنوان تعهد میشنوید.
تخمین با تعهد یکی نیست
مهمترین تفکیک این مقاله و شایعترین سوءتفاهم بین تیم فنی و کارفرما.
تخمین یک پیشبینی است با عدمقطعیت. «حدود شش هفته.»
تعهد یک قول است که پشتش برنامهریزی و حاشیهٔ اطمینان خوابیده. «تا پایان مهر تحویل میدهیم.»
وقتی برنامهنویس میگوید «حدود سه روز» و مدیر آن را در تقویم بهعنوان تاریخ قطعی مینویسد، یک تخمین به تعهد تبدیل شده بدون اینکه کسی حاشیهای اضافه کرده باشد. از این لحظه، شکست تضمینشده است و بعدش هم اعتماد از بین میرود.
راهحل ساده است و باید عادت شود: هر تخمین با درجهٔ اطمینانش گفته شود. «سه روز، با اطمینان متوسط؛ اگر ساختار دادهشان آنطور که گفتهاند نباشد، میشود هشت روز.»
چهار روشی که کار میکنند
تخمین نسبی، نه مطلق
آدمها در گفتن «این کار چند ساعت است» بد عمل میکنند و در گفتن «این کار از آن یکی بزرگتر است» خوب.
پس بهجای ساعت، کارها را با هم مقایسه کنید. یک کار مرجع انتخاب کنید که همه دیدهاند و بقیه را نسبت به آن بسنجید. بعد از چند دوره، نرخ تبدیل نسبت به زمان واقعی از دادههای خودتان درمیآید.
مزیت اصلیاش این است که نسبتها بین آدمها پایدارترند، در حالی که «سه روز» برای دو نفر دو معنی دارد.
تخمین سهنقطهای
برای هر کار سه عدد بگیرید: خوشبینانه، محتمل، بدبینانه. بعد میانگین وزنی:
(خوشبینانه + ۴ × محتمل + بدبینانه) ÷ ۶
ارزش اصلی این روش خودِ فرمول نیست؛ پرسیدن عدد بدبینانه است. همان سؤال، تیم را وادار میکند به بلندبلند فکر کردن دربارهٔ اینکه چه چیزی ممکن است بد پیش برود — و اغلب همانجا ریسکی کشف میشود که کسی به آن فکر نکرده بود.
و فاصلهٔ خوشبینانه تا بدبینانه، خودش سنجهٔ عدمقطعیت است. کاری که بازهاش دو تا بیست روز است، اصلاً آمادهٔ تخمین نیست؛ آمادهٔ تحقیق است.
تخمین گروهی و همزمان
اگر تیم دور هم بنشیند و یکی اول عددش را بگوید، بقیه به آن عدد لنگر میاندازند. این خطای شناختی مستند و قوی است.
راهش این است که همه همزمان عددشان را رو کنند. جایی که اختلاف زیاد است، همانجا فرضهای متفاوتی وجود دارد — و بحث دربارهٔ آن فرضها ارزشمندتر از خود عدد است.
قیاس با کار گذشته
قویترین روش، اگر داده داشته باشید: «کار مشابه پارسال چقدر طول کشید؟»
برای همین، ثبت زمان واقعی کارها ارزش دارد — نه برای ارزیابی افراد، که بهسرعت داده را خراب میکند، بلکه برای تخمین بعدی. تیمی که سه سال داده دارد، تخمینهایش از هر روشی دقیقتر است.
آنچه در تخمین جا میماند
فهرستی که در پروژههای خودمان بهعنوان چکلیست استفاده میکنیم، چون هر بار که نبوده جا مانده است:
- تست و اصلاح باگ. معمولاً بین سی تا پنجاه درصد زمان توسعه.
- بازبینی کد و رفتوبرگشتهایش.
- استقرار و پیکربندی محیطها.
- جلسهها و هماهنگی. در تیم پنجنفره کم نیست.
- مهاجرت داده. قلمی که تقریباً همیشه کم برآورد میشود؛ چرایش را در مهاجرت داده نوشتهایم.
- اتصال به سرویسهای بیرونی. هر اتصال یک قلم مستقل است، نه «جزئیات».
- آموزش کاربر و مستندسازی.
- دورهٔ تثبیت پس از راهاندازی. هفتهٔ اول همیشه شلوغ است.
و دو قلم که خاص پروژههای ایرانیاند:
استعلام و مجوز. اتصال به سامانههای حاکمیتی — مؤدیان، بانک، ثبت احوال — فقط کار فنی نیست؛ فرایند اداری دارد که هفتهها طول میکشد و در دست شما نیست. این را بهعنوان قلم زمانی مستقل و موازی برنامهریزی کنید، نه بهعنوان بخشی از کار توسعه.
تعطیلات. نوروز عملاً دو هفته از ظرفیت سال را برمیدارد. پروژهای که در بهمن شروع میشود، تقویمش با پروژهای که در مهر شروع میشود یکی نیست.
عدد را چطور به کارفرما بگوییم
توصیهٔ ما: بازه بدهید، نه عدد واحد. «بین شش تا نه هفته» صادقانهتر از «هفت هفته» است و برخلاف تصور، اعتماد را بیشتر میکند نه کمتر.
اگر کارفرما بازه را نمیپذیرد و عدد واحد میخواهد، سقف بازه را بدهید — نه میانه. عددی که هفتاد درصد مواقع درست است، سی درصد مواقع اعتماد را میسوزاند.
و تخمین را بازبینی کنید. تخمین روز اول با کمترین اطلاعات ممکن زده شده. بعد از دو هفته، همان تخمین با اطلاعات بهمراتب بیشتری قابل زدن است. این را از اول در قرارداد بگذارید تا بازبینی بهمعنای بدقولی فهمیده نشود.
وقتی تخمین ممکن نیست
گاهی صادقانهترین جواب این است: «نمیدانم، و کسی هم نمیداند.»
برای کارهایی که فناوریشان ناشناخته است یا دامنهشان مبهم، بهجای تخمین الکی، زمانجعبه بگذارید: «یک هفته روی این کار میگذاریم و بعدش تصمیم میگیریم.» بعد از آن هفته، هم میدانید چقدر کار دارد و هم چیزی به دست آوردهاید.
این روش برای پروژههای هوش مصنوعی تقریباً اجباری است — چون تا داده را نبینید، هیچ عددی معنا ندارد. همان چیزی که در هزینهٔ پروژهٔ هوش مصنوعی گفتیم.
اگر کارفرما هستید
سه سؤالی که پاسخشان کیفیت تخمینی که میگیرید را تعیین میکند:
«این تخمین چه چیزهایی را شامل نمیشود؟» جواب این سؤال بیشتر از خود عدد به شما میگوید.
«بزرگترین ریسکش چیست؟» تیمی که جوابی ندارد، بهاندازهٔ کافی فکر نکرده.
«اگر فلان فرض غلط باشد، عدد چقدر میشود؟» حساسیت تخمین را نشان میدهد.
و یک هشدار: پیمانکاری که سریعترین و ارزانترین عدد را میدهد، معمولاً کمترین فکر را کرده. تفاوت در پایان پروژه ظاهر میشود، جایی که تفاوت گرانتر است. معیارهای مقایسه را در انتخاب پیمانکار جدا نوشتهایم.
اگر پروژهای دارید و میخواهید بدانید عدد واقعیاش چقدر است، با ما صحبت کنید — اولین جلسه رایگان است و خروجیاش، حتی اگر با ما کار نکنید، فهرست همان قلمهایی است که معمولاً از برآوردها جا میمانند.