چگونه کار توسعه را تخمین بزنیم

ممکن است تعجب کنی که این موضوع در فهرست آمده؛ Tighten به این معروف است که به آدم‌ها می‌گوید تخمین نمی‌زنیم. با وجود ایدئولوژی #NoEstimates، هنوز جاهایی هست که مشتری — معمولاً مشتری بالقوه — باید حسی از هزینه و زمان داشته باشد. سؤال مت این است: تعادل کجاست؟

میل به زمان و هزینه معقول است؛ خطا این است که فکر کنی برآورده می‌شود

مشتری، چه مشتری آژانس باشد چه «مشتری» تیم داخلی (معمولاً محصول یا بیزنس)، می‌خواهد بداند یک فیچر چقدر طول می‌کشد و چقدر می‌ارزد. در این میل لزوماً چیزی غلط نیست.

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

مسئله این است که چون خواسته معقول است، فکر می‌کنند واقعاً هم برآورده می‌شود.

خانهٔ تکراری، خانهٔ سفارشی، نرم‌افزار سفارشی

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

تخمین همیشه نادقیق است مگر اینکه دقیقاً همان کار را قبلاً کرده باشی — که آن‌وقت هم کمی نادقیق است. نرم‌افزار سفارشی است. کسی که با تیم‌هایی کار کرده که ددلاین وعده داده‌اند، از تجربه می‌داند آخر پروژه یکی از این سه اتفاق می‌افتد: اسکوپ را می‌بُری، تایملاین را تمدید می‌کنی، و/یا کسی ضرر می‌کند.

چرا؟ اول از همه: هیچ‌وقت کمتر از روز اول دربارهٔ پروژه نمی‌دانی. هیچ‌وقت همه‌چیزِ پیشِ رو را نمی‌دانی. دقیقاً این پروژه را در دقیقاً این شرایط انجام نداده‌ای. پس حدس زیاد است و راهی نیست از قبل بدانی چه می‌شود.

#NoEstimates: تخمین به دولوپر کمک نمی‌کند؛ آسیب می‌زند

همین آگاهی که همهٔ تخمین‌ها نادقیق‌اند، گفت‌وگویی راه انداخت به نام #NoEstimates — در اصل از Woody Zuill، بیشتر روی توییتر. هشتگ می‌گوید «تخمین نه»؛ اگر نوشته‌ها و صحبت‌های وودی و بقیه را بخوانی، معمولاً دارند می‌گویند تخمین به دولوپرها کمک نمی‌کند. بخش لازم یا حتی مفید فرایند توسعه نیست.

مت فراتر می‌رود — و فکر می‌کند آن‌ها هم همین را می‌گویند: تخمین برای دولوپر خطرناک است.

اول: تخمین زمانی است که صرف توسعه نمی‌شود. اتلاف است. باید زمانِ غیرتوسعه را تا حد ممکن کم کرد.

دوم: تخمین معمولاً به انتظار تحویل در یک بازه می‌رسد. چون تخمین نادقیق است، ته پروژه دولوپر را فشار می‌دهی، می‌سوزانی، عصبی می‌کنی، و تقریباً همه ناراضی‌اند. Office Space را تصور کن: «این آخر هفته بیا سر کار.»

چهار مسکن که مسئله را حل نمی‌کنند

برنامه‌ریزیِ همهٔ جزئیات گاهی هزینهٔ discovery را مشتری می‌دهد. مت می‌گوید خروجی به‌مراتب بدتر می‌شود: نیازمندی‌ها وسط پروژه عوض می‌شوند و آن‌همه برنامه‌ریزی هدر می‌رود. بعضی نگرانی‌ها را کم می‌کند. جواب خوب نیست؛ لااقل کمی جواب است.

پد درصد کمک می‌کند، ولی نه همیشه به اندازه. بعد مشتری — داخلی یا خارجی — برای کار کوچک تو را عظیم می‌بیند و نمی‌خواهد باهات کار کند. گران می‌شوی.

story points را Ron Jeffries ساخت. مت موقع تحقیق این پروژه فهمید هدف اصلی‌اش این بود: مدت را مبهم کند تا بعضی مدیرها تیم را سر تخمین فشار ندهند. محافظت در برابر کسانی که نمی‌توانستند از تخمینِ ناقص دست بردارند، و «بدون تخمین» را هم نمی‌پذیرفتند. بعد Agile صنعتی — همراه velocity و اسپرینت — آن را بلعید. حالا فقط یک راه دیگر است برای گفتن «سریع‌تر و سخت‌تر کار کن». جادوی مبهم‌سازی از بین رفته.

ideal time می‌گوید اگر همه‌چیز مطابق حدس پیش برود — از جمله اینکه تو نیازت را از اول خوب بگویی، هرچند می‌دانیم نمی‌گویی — این‌قدر طول می‌کشد. شبیه پد درصد، فقط درصد را اول اضافه نمی‌کنی. به مشتری و تیم بستگی دارد که ارزشی داشته باشد.

پیش‌فرض Tighten: تخمین نده؛ چند هفته کار نشان بده

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

وقتی اجتناب ممکن نیست: Ballpark

گاهی بدون بودجه امضا نمی‌گیری و تصمیم می‌گیری باز هم کار کنی. معمولاً غیرانتفاعی. خیلی از کسب‌وکارها فکر می‌کنند باید تخمین داشته باشند و Tighten سخت فشار می‌آورد که ندهند. ولی غیرانتفاعی اغلب باید قبل از نوشتن گرنت بداند کار چقدر درمی‌آید تا اصلاً پول بگیرد. قیدِ نشکن است.

بهترین تخمین از کارِ قبلاً انجام‌شده می‌آید: اگر ۷۰۰ توالت نصب کرده باشی، توالت بعدی را با اطمینان معقول حدس می‌زنی. Tighten از همین ایده چیزی می‌سازد که مت اسمش را Ballpark می‌گذارد. ایدهٔ جدیدی برای کتاب و دامنه نیست؛ زبانِ ترجیحی او برای چیزی است که خیلی‌ها elapsed time می‌نامند.

حرف به مشتری بالقوه این است: وقتی کار مشابهی در گذشته کرده‌ایم، حدود این‌قدر زمان برده که حدود این‌قدر هزینه داشته. اگر باید پولی کنار بگذاری، این مقدار معقول است. تمام. باید خیلی روشن باشد: هیچ وعده‌ای نیست که پروژهٔ تو همین‌قدر دربیاید. فقط نقطهٔ شروع معقول برای حدس یا بودجه‌بندی است. اگر پروژه را ببندیم، بهترین کار ممکن را داخل همان بودجه می‌کنیم — چه کارِ در حال انجام به طرح اولیه مربوط باشد چه نباشد؛ اغلب نیست.

نمونهٔ ایمیل Ballpark:

موضوع: محدودهٔ هزینه برای پورتال اعضا — Ballpark، نه تعهد

سلام سارا،

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

این وعده نیست که پروژهٔ شما دقیقاً همین‌قدر طول بکشد
یا همین‌قدر هزینه داشته باشد. نرم‌افزار سفارشی حدس است،
نه نصب توالتِ صدم. اگر کار را شروع کنیم، بهترین کاری را
که در همان بودجه ممکن است انجام می‌دهیم — حتی اگر خروجی
نهایی با طرح اولیه فرق کند.

جزئیات را در Statement of Work می‌آوریم تا بعداً
نه شما و نه تیم حقوقی غافلگیر نشوید.

مت
Tighten

تفاوت با تخمین: زبان، قید، سند حقوقی

شبیه تخمین است؛ مت انکار نمی‌کند. مثل تخمین می‌خواهی بفهمی چقدر درمی‌آید؛ مثل تخمین مشتری ممکن است بدود و بگوید Tighten وعده داد. پس فرق چیست؟

مثل story points، هدف زبان این است که آدم‌ها خیال نکنند تخمین آینده را پیش‌بینی می‌کند. کلمهٔ Ballpark به‌جای estimate، به‌اضافهٔ قیدهای زیاد دورش: فقط توصیف کاری است که در گذشته مشابهش طول کشیده، نه آنچه این کار می‌تواند طول بکشد. هر زبانی می‌توانی بگذاری — elapsed time یا هر چیز دیگر — فقط باید روشن باشد این تخمینی نیست که بشود باهاش آینده را قفل کرد.

و این خیلی مهم است: همان زبان را داخل سند حقوقی می‌گذارند. برای تیم داخلی شاید کمتر حیاتی باشد؛ برای پیمانکار، در Statement of Work و قرارداد می‌گویند فقط وعده می‌دهیم بهترین کار ممکن را در تایملاین داده‌شده انجام دهیم. گاهی SOW پنج قلم را لیست می‌کند که «به آن‌ها پرداخته می‌شود»؛ وفاداری و سطح تحویل هر قلم می‌تواند بسته به زمان و روند کار عوض شود.

این زبان نباید غافلگیر کند. در مکالمه‌های اول باید سنگین رویش بروی. اگر تخمین اجتناب‌ناپذیر است و سعی کردی منصرفشان کنی، باید بدانند تخمین — یا Ballpark — چه هست و چه نیست. کلی disclaimer بده تا وضعیت حقوقی الآن یا بعداً کسی را شوکه نکند.

بند نمونه برای Statement of Work:

Statement of Work — محدوده، وفاداری، و زمان

پیمانکار متعهد می‌شود در بازه و بودجهٔ توافق‌شده،
بهترین کار ممکن را انجام دهد. فهرست اقلام این سند
جهت‌گیری کار است، نه تعهد به تحویل با وفاداری ثابت.
سطح جزئیات هر قلم ممکن است با پیچیدگی واقعی کار تغییر کند.

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

تیم داخلیِ تمام‌وقت: Shape Up و کوچک‌ترین قطعهٔ مهم

جایی که دولوپر یا تیم تمام‌وقت روی پروژه است و نگرانی این نیست که با رسیدن به سقف هزینه بردارندت، آزادی بیشتری برای برنامه‌ریزی دیگری داری. اینجا غالباً Shape Up بیس‌کمپ یا سیستم‌های شبیه کار می‌کند: متعهد می‌شوی نسخه‌ای از یک فیچر را در یک بازه تحویل بدهی؛ اگر بیشتر خواست، از همان‌جا iterate می‌کنی.

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

وقتی سازمان می‌پرسد این فیچر بزرگ چقدر طول می‌کشد، بهترین جواب اگر ممکن باشد این است: «مهم‌ترین قطعه‌اش را برمی‌دارم، ظرف یک هفته چیزی تحویل می‌دهم، و همین را تکرار می‌کنم تا راضی باشی — که ممکن است همان هفتهٔ اول باشد.»

اگر بهترین تخمین از کارِ انجام‌شده می‌آید و باز هم برنامه‌ریزی بیشتری می‌خواهند: وقتی یک هفته با همین تیم روی همین پروژه کار کرده باشم، حس خیلی بهتری از پیشرفت هفتهٔ دوم و سوم دارم. می‌توانند انتظار داشته باشند همین فرایند تکرار شود و pace — یا اگر دوست دارند بگویند velocity — تیم را بهتر بفهمند.

این سمتِ سالم velocity است: نه هدف و نه چیزی که بشود کنترل کرد؛ اندازهٔ گذشته که باهاش برای آینده تصمیم آگاهانه می‌گیری.

مت می‌داند جواب کامل نیست. هدفش تا حد ممکن عوض کردن مکالمه با محصول و بیزنس است: از «دقیقاً بگو این فیچرِ کامل کی می‌آید» به «بهترین کاری که این هفته برای سازمان می‌توانیم بکنیم چیست.»

VP محصول: این فیچر کامل کی به پروداکشن می‌رسد؟

تو: کامل را نمی‌دانم — هیچ‌کس روز اول نمی‌داند.
    مهم‌ترین قطعه‌اش را این هفته تحویل می‌دهم.
    هفتهٔ بعد همان کار را تکرار می‌کنیم تا تو راضی باشی.
    بعد از همین یک هفته، pace هفتهٔ ۲ و ۳ را خیلی بهتر می‌فهمیم.
    velocity اینجا عدد گذشته است، نه شلاق اسپرینت.

VP: من تاریخ Q3 را به هیئت گفته‌ام.

تو: تاریخ قفل‌شده بدون مهندسی، تخمین نیست؛ تعهد یک‌طرفه است.
    بهترین کار این هفته برای سازمان را با هم انتخاب کنیم.
    اگر گرنت یا هیئت عددی می‌خواهد، Ballpark می‌دهم:
    کار مشابه قبلاً حدود X طول کشید — وعده نیست.

هدف شماره یک: تخمین را کنار بگذار

تخمین برای دولوپر و تیم بد است. همیشه غلط است؛ در نرم‌افزار سفارشی معمولاً غلط‌تر. ابزار خوبی برای بهتر کردن تخمین نداریم. ابزارهایی داریم که کم‌و‌بیش درمانده تلاش می‌کنند از دست کسانی محافظت کنند که انتظار تخمینِ کامل و پیش‌بینی دقیق آینده دارند.

در Tighten تا حد ممکن تخمین را کنار می‌گذارند. وقتی برای دلیل کسب‌وکاریِ مشروع مجبور شوند، با زبان حقوقی، قید بی‌پایان، و کلمهٔ Ballpark فاصله می‌گذارند از این انتظار که توصیف کار گذشته، تعهد تایملاین آینده باشد.

هدف شماره یک تو باید این باشد که تخمین را کلاً کنار بگذاری. اگر نمی‌توانی، هر کاری می‌توانی بکن تا روشن باشد تخمین — با هر اسمی — نمی‌تواند تعهد معقولی به تایملاین آینده باشد.

به زبان ساده

تخمین همیشه غلط است. اگر مجبوری، Ballpark بگو: کار شبیه قبلاً حدود این‌قدر طول کشید — قول آینده نیست.

مثال واقعی

Tighten ترجیح می‌دهد چند هفته کار نشان بدهد تا مشتری نگران جا ماندن از سرعت تیم شود نه ددلاین. برای گرنت غیرانتفاعی همان عدد را با زبان Ballpark و بند حقوقی SOW می‌دهند.