چرا تخمینزدن کارها دیگه بیفایدهست؟
خلاصهٔ کاملتر
نویسنده میگه مدتیه که کلاً تخمینزدن کارها رو کنار گذاشته، چون یاد گرفته این کار چقدر انرژی هدر میده، پتانسیل رو محدود میکنه و انتظارات اشتباه میسازه. به گفتهٔ او خیلی از تیمها هنوز یهجور سایزگذاری دارن که رایجترینش استوری پوینته، که در ضمن بیشترین سوءتفاهم هم دربارهش وجود داره.
نویسنده به قانون پارکینسون اشاره میکنه: «کار اونقدر کش میاد تا زمانی که براش گذاشتی رو پر کنه». به گفتهٔ او تخمینها دقیقاً همین بلا رو سرت میارن و بهجای کمک، جلوی پیشرفت رو میگیرن. الگوی رایج اینه که تیم تو جلسهٔ refinement با استوری پوینت سایز میزنه، ازش velocity حساب میکنه، و تو planning بر اساس اون ظرفیت آیتم برمیداره؛ که اغلب هم همهش تحویل داده نمیشه.
نویسنده اسم اینها رو «دیوارهای نامرئی» میذاره. میگه ما از سایزهایی استفاده میکنیم که همه واقعاً درکشون نمیکنن، بعد با همون سایزها سرعتمون رو تعریف میکنیم و اون میشه دیواری که کسی نمیتونه ازش رد شه. از طرفی آدمهای کسبوکار هم از تغییر تخمین خوششون نمیاد، درحالیکه همه میدونن تخمین ذاتاً غلطه؛ و آخرش وقتت تو جلسهها صرف بهترکردن پیشبینیپذیری میشه بهجای خلق ارزش.
نویسنده یه تجربهٔ واقعی تعریف میکنه: یه بار همهٔ تخمینها رو از بکلاگ حذف کرده و planning رو جور دیگهای شروع کرده. بهجای velocity، مهمترین چالش اون هفته (کاهش churn) رو مطرح کرده و از تیم پرسیده چی کار کنیم. مهندسها خودشون آیتمهای مرتبط رو برداشتن، بعد ازشون پرسیده چقدر مطمئنن که تو دو هفته تحویلش بدن. تیم اول ۵۰ درصد اطمینان داشته، ولی با کموزیادکردن چند آیتم رسیدن به ۹۰ درصد. آخر دو هفته تیم همهچیز رو تحویل داده و چند آیتم اضافه هم برداشته؛ در عمل ۵۳ استوری پوینت بهجای velocity همیشگی ۴۲.
خلاصهٔ روش پیشنهادی نویسنده اینه: اول مشخص کن الان چی مهمه، بعد با تیم توافق کن برای یکی دو هفته چی رو commit میکنین، و بعد ازشون بپرس چقدر مطمئنن؛ که پیشنهاد میکنه بین ۷۰ تا ۹۰ درصد باشه تا هم چالش بمونه هم واقعبینانه.
حرف عمیقتر نویسنده اینه که چرا تخمین امروز فقط حواسپرتیه. به گفتهٔ او دههها توسعهٔ نرمافزار گلوگاه بوده و همین تخمین رو «اجباری» کرده، ولی امروز گلوگاه دیگه توسعه نیست، بلکه جهتگیریه. کاری که قبلاً ماهها طول میکشید حالا تو چند روز انجام میشه. نویسنده فرق کلیدی رو اینطور میذاره: تخمین ازت میخواد اثر یا پیچیدگی یه کار رو پیشبینی کنی، ولی سرمایهگذاری مجبورت میکنه تصمیم بگیری چقدر ارزش داره روی یه کار وقت بذاری. حالا که هرچیزی رو میشه سریع ساخت، سؤال درست دیگه «چقدر طول میکشه» نیست، بلکه «چقدرش ارزش سرمایهگذاری داره» هست؛ وگرنه فقط یه کارخانهٔ فیچرِ بیهدف میسازی.
نکات کلیدی:
- تخمینزدن انرژی هدر میده و بر اساس قانون پارکینسون کار رو کش میده
- velocity و ظرفیت یه دیوار نامرئی میسازن که جلوی ارزشآفرینی رو میگیره
- بهجای تخمین، هدف هفته رو روشن کن و از تیم میزان اطمینان (بین ۷۰ تا ۹۰ درصد) بپرس
- تو تجربهٔ نویسنده حذف تخمینها خروجی رو بهتر کرد، نه بدتر
- حالا که توسعه سریع شده، تصمیم درست دربارهٔ ارزش و سرمایهگذاریه، نه تخمین اثر
