تاریخ برنامه‌ای در برابر تاریخ واقعی: تأخیر را اندازه بگیرید، پنهانش نکنید

کارتی را در نظر بگیرید که سررسیدش ۱۰ مهر بود. ۹ مهر کسی آن را به ۱۵ مهر تغییر داد، ۱۴ مهر به ۲۰ مهر، و ۱۹ مهر کار تمام شد. روی تابلو این کارت «به‌موقع» تمام شده است. در واقعیت ۹ روز دیر شد و هیچ ردی از آن نمانده است.

این عادت تقریباً همه‌جا هست و معمولاً از بدجنسی نیست؛ از این است که ابزارها فقط یک فیلد تاریخ دارند و کسی نمی‌خواهد کارتش قرمز بماند. ولی هزینه‌اش سنگین است: تیمی که تأخیرش را پاک می‌کند، هیچ‌وقت یاد نمی‌گیرد بهتر تخمین بزند، و مدیری که فقط تاریخ‌های جابه‌جاشده را می‌بیند، روزی غافلگیر می‌شود که دیگر جابه‌جا کردن ممکن نیست.

این مقاله در ادامهٔ راهنمای جامع برنامه‌ریزی اسپرینت است و به یک سؤال ساده می‌پردازد: چرا برای هر کار باید دو تاریخ داشت و با این دو تاریخ چه می‌شود کرد.

دو تاریخ، دو سؤال متفاوت

تاریخ برنامه‌ای جواب این سؤال است: «وقتی برنامه ریختیم، فکر می‌کردیم کی؟» این تاریخ یک انتظار است، یک قرار. بقیهٔ آدم‌ها، از تستر تا مشتری، بر اساس آن برنامهٔ خودشان را می‌چینند.

تاریخ واقعی جواب این سؤال است: «واقعاً کی اتفاق افتاد؟» این تاریخ یک واقعیت است و بعد از ثبت، دیگر عوض نمی‌شود.

وقتی فقط یک فیلد دارید و آن را بازنویسی می‌کنید، دارید یک واقعیت (اینکه برنامه چه بود) را با یک واقعیت دیگر (اینکه چه شد) پاک می‌کنید. اطلاعات مفید دقیقاً در فاصلهٔ بین این دو است، و با بازنویسی، همان فاصله ناپدید می‌شود.

چرا جابه‌جا کردن بی‌صدای تاریخ برنامه‌ای مضر است

یادگیری از بین می‌رود

انسان‌ها در تخمین زمان کارهای خودشان به‌طور سیستماتیک خوش‌بین‌اند. روان‌شناسان این را «خطای برنامه‌ریزی» (Planning Fallacy) نامیده‌اند: ما حتی وقتی می‌دانیم کارهای مشابه قبلی دیرتر از برنامه تمام شده‌اند، برای کار بعدی باز هم خوش‌بینانه تخمین می‌زنیم. تنها پادزهر شناخته‌شده‌اش نگاه کردن به سابقهٔ واقعی است، و سابقهٔ واقعی فقط وقتی وجود دارد که آن را ثبت کرده باشید.

اعتماد آرام‌آرام می‌ریزد

مشتری یا مدیری که سه بار دیده تاریخ قول‌داده‌شده بی‌خبر عقب رفته، دیگر به هیچ تاریخی اعتماد نمی‌کند و خودش یک «ضریب اطمینان» رویش می‌گذارد. از آن به بعد، برنامه‌ریزی برای همه بازی حدس زدن است. برعکس، تیمی که می‌گوید «برنامه ۱۰ مهر بود، الان پیش‌بینی ما ۱۵ مهر است و دلیلش این است» اعتماد می‌سازد، حتی وقتی دیر کرده است.

آدم‌های وابسته غافلگیر می‌شوند

تستری که برای ۱۰ مهر آماده شده بود، آموزش‌دهنده‌ای که جلسهٔ معرفی قابلیت را برای ۱۲ مهر گذاشته بود، همه با جابه‌جایی بی‌صدا غافلگیر می‌شوند. تاریخ برنامه‌ای فقط مال تیم نیست؛ قراری است که دیگران به آن تکیه کرده‌اند.

چه تاریخ‌هایی ثبت کنیم

لازم نیست برای همه‌چیز تاریخ بگذارید. ولی برای کارهایی که تاریخ دارند، این چهار فیلد را پیشنهاد می‌کنم:

همین منطق در سطح نسخه هم کار می‌کند: شروع توسعه، پایان توسعه، ورود به آزمون پذیرش و لایو شدن، هر کدام با تاریخ برنامه‌ای و واقعی. چرا نقطهٔ سوم را جدا می‌کنم در مقالهٔ UAT چیست و چرا تاریخ ورود به آن را جدا ثبت کنیم توضیح داده‌ام.

تأخیر را چطور بخوانیم

دو تاریخ داشتن تازه شروع کار است. ارزش اصلی در خواندن آن‌هاست.

تأخیر در شروع یا تأخیر در انجام؟

این دو تأخیر علت‌های کاملاً متفاوتی دارند:

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

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

یک جدول نمونه

فرض کنید پنج کارت یک اسپرینت این‌طور ثبت شده‌اند (اعداد فرضی‌اند و مدت‌ها به روز کاری):

از همین جدول کوچک دو چیز معلوم می‌شود: کارت «گزارش ماهانه» احتمالاً باید پیش از شروع شکسته می‌شد، و کارت‌هایی که دیر شروع شده‌اند نشان می‌دهند ستون «در حال انجام» شلوغ‌تر از ظرفیت بوده است. هیچ‌کدام از این دو نتیجه با یک فیلد سررسید به دست نمی‌آمد.

ضریب واقعی تیم

اگر چند اسپرینت داده جمع کنید، می‌توانید نسبت مدت واقعی به مدت برنامه‌ای را برای تیم (یا برای نوع خاصی از کار) حساب کنید. اگر این نسبت مدام حدود ۱٫۵ است، دفعهٔ بعد که کسی گفت «دو روزه تمام می‌شود»، بی‌آنکه به کسی توهین شود، می‌دانید سه روز واقع‌بینانه‌تر است. این همان ایدهٔ «پیش‌بینی بر اساس طبقهٔ مرجع» است: به‌جای تکیه به حس خودمان دربارهٔ کار تازه، به سابقهٔ کارهای مشابه نگاه کنیم.

یک هشدار: این ضریب ابزار یادگیری تیم است، نه معیار ارزیابی آدم‌ها. اگر از آن برای مقایسهٔ افراد استفاده کنید، همه از فردا تخمین‌ها را باد می‌کنند و داده بی‌ارزش می‌شود.

فرهنگ: تأخیرِ گفته‌شده بهتر از تأخیرِ پنهان

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

چند قاعده که در تیم‌هایم جواب داده است:

• تأخیر وقتی اطلاعات است که زود گفته شود. «احتمالاً دو روز دیر می‌شود» در روز دوم، هدیه است؛ همان جمله در روز آخر، خبر بد است. بهترین جا برای گفتنش جلسهٔ روزانهٔ پای تابلو است.
• دربارهٔ کارت حرف بزنید، نه دربارهٔ آدم. «این کارت چرا سه روز بیشتر طول کشید؟» سؤالی دربارهٔ کار است و معمولاً جوابش چیزی است که همه می‌توانند از آن یاد بگیرند.
• مدیر اول تأخیر خودش را ثبت کند. اگر تصمیمی که قرار بود مدیر بگیرد دیر شد و همین کار را عقب انداخت، آن هم باید روی تابلو دیده شود.

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

وقتی برنامه واقعاً عوض می‌شود

گاهی تغییر تاریخ برنامه‌ای کاملاً مشروع است: مشتری دامنهٔ کار را بزرگ کرد، اولویت‌ها عوض شد، یا کار به نسخهٔ بعد منتقل شد. در این حالت تاریخ را عوض کنید، ولی بی‌صدا نه:

1. یک کامنت روی کارت بگذارید: تاریخ قبلی چه بود، تاریخ تازه چیست و چرا.
2. اگر دلیل تغییر دامنه است، تغییر را هم در توضیح کارت بنویسید تا معلوم باشد کار امروز با کار روز برنامه‌ریزی یکی نیست.
3. آدم‌های وابسته را همان روز خبر کنید.

تفاوت «برنامه را آگاهانه عوض کردیم» با «تاریخ را جابه‌جا کردیم چون عقب بودیم» همین ردِ نوشته‌شده است.

پیاده‌سازی روی تابلو

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

شروع برنامه‌ای: 1405/07/01
پایان برنامه‌ای: 1405/07/04
شروع واقعی:
پایان واقعی:

در بردماگ این چهار فیلد روی خود کارت هست و کارت عقب‌افتاده علامت می‌خورد. ستون‌هایی که اسپرینت علامت خورده‌اند هم برای نقاط اصلی نسخه تاریخ برنامه‌ای و واقعی دارند و در سربرگشان مقدار تأخیر را نشان می‌دهند، مثل «۲ روز تأخیر»، همه به تقویم شمسی. ولی مهم‌تر از ابزار، قراری است که تیم می‌گذارد: تاریخ برنامه‌ای بی‌صدا عوض نمی‌شود.

نمایش تأخیر روی تابلو هم به همان شفافیتی کمک می‌کند که در راهنمای جامع کانبان درباره‌اش گفته‌ام: وقتی همه یک تصویر را می‌بینند، بحث از «کی مقصر است» به «چه کار کنیم» می‌رود.

چک‌لیست شروع

1. برای کارت‌های اسپرینت بعدی، تاریخ شروع و پایان برنامه‌ای را در جلسهٔ برنامه‌ریزی، با هم، ثبت کنید.
2. قرار بگذارید تاریخ‌های واقعی همان روز ثبت شوند، نه آخر هفته از حافظه.
3. قرار بگذارید هر تغییر تاریخ برنامه‌ای یک کامنت با دلیل داشته باشد.
4. در پایان اسپرینت، یک جدول مثل جدول بالا بسازید و ده دقیقه درباره‌اش حرف بزنید.
5. بعد از سه یا چهار اسپرینت، ضریب واقعی تیم را حساب کنید و در برنامه‌ریزی بعدی از آن استفاده کنید.

جمع‌بندی

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

منابع و مطالعهٔ بیشتر

• Planning fallacy — Wikipedia — خطای برنامه‌ریزی و پژوهش‌های کانمن و تورسکی دربارهٔ خوش‌بینی در تخمین
• Reference class forecasting — Wikipedia — پیش‌بینی بر اساس سابقهٔ کارهای مشابه، پادزهر خطای برنامه‌ریزی
• Purpose Of Estimation — Martin Fowler — اینکه تخمین را برای چه می‌خواهیم و کی ارزش زحمتش را دارد
• Hofstadter’s law — Wikipedia — قانون طنزآمیز هافستادتر دربارهٔ طول کشیدن کارها