یک تیم ۵ نفره داشت یک Feature را توسعه می‌داد. Project Manager گفت:
«کار را تقسیم کنیم که سریع‌تر پیش بره.»
پس Feature را کردند ۱۰ تا Task:
Developer A → 2 Tasks
Developer B → 2 Tasks
Developer C → 2 Tasks
Developer D → 2 Tasks
Developer E → 2 Tasks
روی کاغذ عالی بود.
همه مشغول بودند.
اما سه روز بعد...
ءDeveloper A منتظر API بود.
ءDeveloper B منتظر Database Migration بود.
ءDeveloper C منتظر تصمیم Backend بود.
ءDeveloper D کار خودش را تمام کرده بود، اما نمی‌توانست Merge کند.
و Developer E داشت روی چیزی کار می‌کرد که بعداً مشخص شد دیگر لازم نیست.
همه Busy بودند.
اما Feature جلو نمی‌رفت.
مشکل کجا بود؟
تیم کار را بر اساس تعداد Task تقسیم کرده بود،
نه بر اساس Dependency.
در واقع جریان کار این شکلی بود:
Database
↓
Backend
↓
API Contract
↓
Frontend
↓
Integration
ولی ما وانمود کرده بودیم همه این کارها مستقل‌اند.
یکی از خطرناک‌ترین اشتباهات در مدیریت Engineering همین است:
ءBusy بودن را با Progress اشتباه بگیریم.
ممکن است ۱۰ نفر همزمان روی ۱۰ Task کار کنند،
اما اگر ۹ تای آن‌ها منتظر یک Task باشند،
سرعت واقعی تیم همان سرعت آن یک Task است.
گاهی برای سریع‌تر شدن پروژه،
نباید کار بیشتری بین افراد پخش کنیم.
باید Dependencyهای اصلی را پیدا کنیم.
چون در Software Engineering،
تعداد Taskهای انجام‌شده مهم نیست.
مهم این است که:
چه مقدار از مسیر رسیدن به یک نتیجه واقعی طی شده است.