مشکل تخمین از کجا شروع میشه؟
احتمالاً تجربه‌ی حضور در شرایطی رو داشته باشین که تیم تو فشار بوده و مدیر فنی از شما درخواست تخمین زمان‌بندی نسبتاً دقیقی از تسکی داشته که در حال انجامش هستین. اون هم برای این که بتونه به مدیرعامل زمان اعلام کنه تا برنامه‌ریزی کارهای مارکتینگی و پلن‌های بیزینسی درست چیده بشه و به موقع جلو بره. ماجرا وقتی پیچیده‌تر میشه که تسکی که دستتونه کاملاً براتون جدیده، نیازمند یادگیری و تجربه و تحقیقه و از جنس اینتگریشن داخل کل سیستم نرم افزارتونه (یعنی عملاً گیتهاب و استک اورفلو و هوش مصنوعی و روش‌های سه نقطه‌ای و مثلثاتی تخمین نمی تونن کمک خاصی بهتون بکنن). هر چند که اگه بتونین از این روش‌ها و سایر رویکردها مثل پلنینگ پوکر و تحلیل ریسک کمک بگیرین و انتظارات رو مدیریت کنین، اوضاع بهتر میشه. با این وجود، خیلی وقتا این جور کارها رو نمیشه خورد کرد و از این جنسن که دو تا استیت بیشتر نداره: یا انجامش میدین و کار می کنه، و یا همچنان دارین باهاش کلنجار میرین و هرچی جلوتر میرین بیشتر گیج میشین که چقدر دیگه قراره طول بکشه. مدیران هم اصرار دارن که زودتر تخمین درست و حسابی بدین. خب در این جور مواقع چه باید کرد؟
حالا چی کار کنیم؟
در ابتدا لازمه که این موارد و پیچیدگی‌های تخمین در موردشون رو با مدیریت مطرح کنین و باهاشون شفاف باشین که تسک نیاز به تحقیق و یادگیری داره و به یک‌باره امکانش نیست که تخمین دقیق و درستی بدین. اما با این وجود وقتی که فشار بالاست، آدما در منطقی‌ترین حالت خودشون نیستن و یه وقتایی اصرار هم بالاست و تخمین‌ها دست پایین لحاظ میشن (یا فورس میشن) تا کار زودتر از آب دربیاد. یعنی این چالش بیشتر از جنس نحوه‌ی تعامل و ارتباط و شفاف‌سازیه تا از جنس تخمین. با این حال وقتی ازتون عدد می‌خوان، ممکنه چاره‌ای براتون نذارن جز این که خودتون یه عددی بگین تا زمان‌بندی نامعقولی بهتون فورس نشه.
در کل، تخمین دادن کار سختیه چون هر کاری که راجع به نرم‌افزار انجام میشه یک کار جدید در یک کانتکست جدیده و نمیشه تخمین دقیق داد. تخمین دادن مشکلات خودش رو داره که شاید به خاطر همین مشکلات باشه که برنامه‌ریزی مبتنی بر شواهد یا از سمت دیگه، جنبش‌های بدون تخمین راه افتادند. با این وجود، بیشتر جاها بر مبنای تخمین جلو میرن و بدون تخمین نمی‌تونن برنامه‌ریزی درست و مناسبی داشته باشن. در این راستا چند تا راهکار به ذهن میرسه:
یکی از استراتژی‌ها اینه که قبل از اعلام عددی برای تخمین، چند روز برای تحقیق و توسعه زمان درخواست کنین. روش تایم باکسینگ بهتون کمک می کنه تا شم کلی از کار و پیچیدگی‌هاش دستتون بیاد و در صورت امکان سعی کنین یه نسخه کوچیک از مسئله رو بازسازی و حل کنین و طی این مسیر، یافته‌هاتون رو داکیومنت کنین و با گذر زمان، تخمینی که بهشون داده بودین رو آپدیت کنین و هر بار زمان واقعی‌تری رو اعلام کنین. اگر بهتون وقت بدن خوبه ولی مشکل این روش با توجه به طبیعت تسکی که دستتونه اینه که راه‌حل شما خیلی وقتا اون قدر طول می‌کشه تا بشه راه‌حل نهایی اولین نسخه :) و طی تمام این مدت همش تو فشارین که زودتر یه عدد اعلام کنین.
یکی دیگه از استراتژی‌هایی که به طور معمول به ذهن میرسه اینه که به جای یک تایم فیکس شده، یک بازه‌ی زمانی رو اعلام کنین. مثلاً بگین برآوردتون بین ۸ تا ۱۵ روزه. که اینم شبیه همون روش سه نقطه‌ای میشه. با این حال، این کار هم ممکنه مشکلتون رو حل نکنه. چون اصلاً ایده‌ای ندارین که چقدر ممکنه طول بکشه و علاوه بر این که بازه‌ی اعلامی می‌تونه بزرگ و بی‌ارزش باشه، تجربه نشون داده وقتی که تیم تو فشاره، مدیران راغب‌ترن تا کمترین تخمین شما رو به عنوان تخمین اصلی لحاظ کنن و بگن خب پس ما ۸ روز براش در نظر می‌گیریم یا اصلاً ۱۲ رو نشنون و شما نگران بشین که حالا اگه یه وقتی ۱۲ روز طول کشید کارتون خراب نشه. در این شرایط بعضیا توصیه می‌کنن با مدیرتون راجع بهش حرف بزنین، یا تخمینتون رو دوبرابر کنین! چون حالا ریشه‌ی مشکل اینه که مدیریت عادت داره تخمین‌هاتونو کاهش بده.
خوبه که مرزهاتون رو مشخص کنین و استدلال و سند بیارین که چرا ممکنه کار شما این قدر طول بکشه و اگه از این کمتر بشه مشکلات و باگ‌های مختلفی ممکنه برای نرم‌افزار پیش بیاد که صرفاً به این دلیل بوده که زمان کافی برای تست کردن چیزی که نوشتین بهتون داده نشده. با این وجود، به طور معمول، هرچقدر هم که قبلش استدلال آورده باشین و گوشزد کرده باشین، ته قصه شما به درستی، مسئول تمام مشکلات کدی هستین که نوشتین. پس خوبه که از ابتدا زیر بار تخمینی نرین که منجر بشه از کیفیت کار بزنین.
آخرش اگه بازم نشد چی؟
در کل اگر این استراتژی‌ها جواب ندادن می‌تونه نشانه‌ی این باشه که مدیریت، ظرفیت لازم رو برای تعامل سازنده در جهت پیشبرد کار به شکل اصولی نداره و همیشه این گزینه جلوی روی شما بازه که اگر نمی‌تونین سازمانتون رو عوض کنین، تیمی که توش کار می‌کنین یا محل کارتون رو عوض کنین. سازمان هم متقابلاً این گزینه رو داره که وقتی ببینه شما طبق انتظاراتش عمل نمی‌کنید، شما رو با یه نیروی تازه‌نفس جایگزین کنه.
در هر صورت بهتره فراموش نکنیم که تحمیل تخمین‌ها به دیگران به‌عنوان یک دستور، فاجعه‌آفرینه و مجازات به‌خاطر تخمین اشتباه، مثل تنبیه کودک به‌خاطر چیزیه که هنوز نمی‌دونه یا نمی‌تونه درک کنه.
بد نیست توجه داشته باشیم که تخمین‌ها از سمت توسعه‌دهنده‌ها میان و ددلاین‌ها از سمت مارکتینگ و مشکلات وقتی پیش میان که ددلاین‌ها کوتاه‌تر از تخمین‌ها باشن. در چنین حالتی سه گزینه بیشتر نداریم:
- توسعه‌دهنده‌ها اضافه‌کاری کنند.
- نیازمندی‌های ددلاین کمتر بشن.
- ددلاین از دست بره.
که معمولاً گزینه‌ی اول ترجیح اصلی و رایج سازمان‌هاست که هزینه‌اش هم برن‌اوت شدن نیروها و هر سال نیروهای جدید عوض کردنه.
برای مطالعه‌ی بیشتر می‌تونین به این منابع رجوع کنین:
- How to estimate a programming task if you have no experience in it
- How do you deal with continuous work pressure
- How do you handle scheduling/deadlines around programmers
- How can I avoid team burnout
- The NoEstimates Movement
- Evidence Based Scheduling
- 5 Practical Ways to Manage Expectations on Your Projects
- ۱۱ قانون تخمین نرم‌افزار برای کارهای پیچیده
- مدیریت زمان پروژه چیست ؟ فرمول محاسبه زمان
share
