در دنیای توسعه محصول، یکی از رایجترین سؤالاتی که تیمها با آن روبهرو میشن اینه که:
«این تسک چقدر زمان میبره؟»
در ظاهر، سؤال بیخطری به نظر میرسه. اما پاسخدادن سریع و بدون زمینه، معمولاً ما را وارد چرخهای از توقعات اشتباه، استرس، و بازنگریهای پرهزینه میکنه.
مشکل از جایی شروع میشه که ما به جای درک واقعی از مسئله، بهسرعت وارد فاز برنامهریزی میشویم. در حالی که اغلب، هنوز دقیق نمیدونیم چی میخوایم:
چه چیزی قرار است ساخته شود؟
با چه موانعی روبهرو هستیم؟
و اصلاً این تسک، در کجای مسیر رشد محصول قرار میگیرد؟
ما نیاز داریم پیش از برنامهریزی، ابتدا «سطح درک تیم» از مسئله را بسنجیم. آیا تیم آمادهٔ تخمینزدن هست؟ یا هنوز باید کشف یا بررسی بیشتری انجام بشه؟
در تجربهٔ ما، اغلب تسکها در یکی از این سه دسته قرار میگیرند:
1. تسکهایی که میتوان دقیق تخمین زد:
مشکل و راهحل روشن است.
تیم با دامنه آشناست.
وابستگیها و ریسکها کم است.
مثال: اصلاح یک باگ در سیستم شناختهشده.
2. تسکهایی که نمیتوان فعلاً تخمین زد:
هنوز هدف مبهم است.
تکنولوژی جدید است.
نیاز به هماهنگی بیرونی دارد.
مثال: طراحی یک سیستم قیمتگذاری جدید برای فروش محصول تازه لانچ شده.
3. تسکهایی که فاز اول آنها، فقط برای تخمینزدن است:
نیاز به Discovery دارد.
قرار است ابتدا نمونهسازی یا تحلیل اولیه انجام شود.
مثال: بررسی امکان پشتیبانی از یک نوع جدید پرداخت با تأمینکنندهٔ خارجی.
درک، پایهٔ اعتماد است
وقتی بهجای فشار برای عدد دادن، به تیم کمک کنیم که «درک» خود را از مسئله بسنجند، دو اتفاق خوب میفته:
تصمیمگیریها دقیقتر میشود، چون دید ما واقعیتر است.
تیم احساس امنیت و مشارکت بیشتری میکند، چون از او توقع حدسزدن بیپشتوانه نداریم.
مثال واقعی
فرض کنیم تیم قراره ویژگی «پشتیبانی از پلن پرداخت اقساطی» رو به پلتفرم اضافه کنه. در ظاهر، این فقط اضافهکردن یک گزینه جدید در فرم پرداخت به نظر میرسه. اما وقتی با دید درک عمیقتر جلو بریم، متوجه میشیم:
وضوح هدف پایین: هنوز دقیق نمیدونیم اقساط قراره چطور محاسبه بشن. آیا سود داره؟ بازههاش چطوریه؟
وابستگی فنی بالا: نیاز به اتصال به درگاه بانکی جدید یا شرکت اعتبارسنجی هست.
نیاز به هماهنگی بیرونی: تیم حقوقی باید قوانین جدید قراردادها رو بررسی کنه.
آشنایی پایین: تیم قبلاً روی چنین قابلیتی کار نکرده.
هماهنگی بینتیمی: تیمهای مالی، مارکتینگ و پشتیبانی هم باید در جریان تغییرات باشن.
نتیجه؟
این تسک در ابتدا قابل تخمین نیست. ما نیاز به یک فاز کشف (Discovery) داریم:
جمعآوری نیازمندیها از تیم حقوقی و مالی
بررسی محدودیتهای فنی در اتصال به API جدید
طراحی اولیه تجربه کاربری
سنجش پیچیدگی اجرا با کمک مهندسی فنی
بعد از این مرحله، تازه میتونیم بفهمیم واقعاً چقدر کار داریم، و آیا تخمین دقیق ممکنه یا نه.
ما معمولاً میدونیم که هر تسکی یکی از سه حالت زیر را داره:
قابل تخمین دقیق
غیرقابل تخمین (در حال حاضر)
نیازمند فاز اولیه برای کشف و سپس تخمین
اگر تیم به این طبقهبندی فکر کنه، همکاریهای واقعیتری شکل میگیره، توقعات بهتر مدیریت میشود و خروجی نهایی باکیفیتتر خواهد بود.
پرسیدن این سؤال ساده در شروع هر پروژه میتواند نقطهٔ تفاوت باشه:
«آیا میدانیم قراره چی بسازیم؟ یا هنوز باید بفهمیم؟»
