دو واحد، دو هدف — وقتی یکی را جای دیگری بگذارید چه می‌شود؟

در تیم‌های ایرانی که قرارداد دولتی یا سازمانی دارند، فشار «ساعت» از بالا می‌آید و «امتیاز» از تیم چابک. بدون سیاست مکتوب، هر جلسه هیئت‌مدیره به بحث واحد می‌رسد.

پوکر برنامه‌ریزی فقط وقتی معنا دارد که کسی بعداً ساعت واقعی ثبت کند. بدون log_time، سرعت (velocity) عددی روی کاغذ است.

علائم و هزینه

علامت هزینه
برنامه‌ریزی با امتیاز داستان، گزارش مالی با ساعت — بدون پل شفاف ذینفعان عدد متفاوت می‌شنوند؛ اعتماد کم می‌شود
سرعت بالا روی کاغذ، تحویل واقعی کم شک به کل فرآیند چابک
تیم امتیازها را برای محافظت از خود بالا می‌برد برنامه‌ریزی بعدی باز حدسی می‌شود
ثبت زمان کم یا صفر برآورد بعدی بدون یادگیری واقعی
هر اسپرینت سؤال «یک امتیاز چند ساعت است؟» جلسه برنامه‌ریزی به بحث واحد می‌رسد

چارچوب عملی

1. نوع کار و چارچوب تیم را مشخص کنید

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

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

2. یک واحد اصلی برای برنامه‌ریزی انتخاب کنید

در ویکی پروژه بنویسید: «برای تعهد اسپرینت از امتیاز داستان استفاده می‌کنیم؛ برای مالی از ساعت تجمیعی.» این خط یک‌بار نوشته می‌شود و هر تازه‌وارد بدون بحث هفتگی می‌فهمد.

3. برآورد و واقعیت را جدا نگه دارید

برآورد با estimate_task (برآورد تسک) ثبت می‌شود. تلاش واقعی با log_time (ثبت زمان). این دو فیلد هرگز یکی نشوند.

4. هر اسپرینت برآورد را با واقعیت مقایسه کنید

در بازبینی سه تسک نمونه را مقایسه کنید — نه برای سرزنش فرد، بلکه برای بهبود سیستم برآورد.

5. به ذینفع ساعت تجمیعی بدهید

مدیر مالی «چند ساعت این ماه صرف شد؟» می‌خواهد. گزارش از finance_summary (خلاصه مالی) تغذیه شود.

نکات تکمیلی برای اجرا

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

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

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

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

وقتی شاخص بهتر شد، آن را در decision_log (سابقه تصمیم) ثبت کنید تا فصل بعد بدانید چه کار کردید و چه اثر داشت. یادگیری سازمانی بدون ثبت، تکرار اشتباه است.

اشتباهات رایج

نقش WKFGo

estimate_task (برآورد تسک) — ثبت برآورد روی تسک — به ساعت، به امتیاز داستان، یا هر دو.

log_time (ثبت زمان) — ثبت ساعت واقعی روی تسک، تا برآورد با واقعیت مقایسه شود.

my_day (روز من) — خلاصه روز: رویدادهای تقویم و تسک‌های سررسیدشده یا عقب‌افتاده.

time_summary (خلاصه زمان) — گزارش زمان به تفکیک نفر و هزینه — پایه کالیبره کردن برآوردها.

finance_summary (خلاصه مالی) — جمع درآمد، هزینه و خالص پروژه؛ وقتی برآورد ساعت به بودجه وصل می‌شود.

decision_inbox (صف تصمیم) — در گردش روزانه تیم استفاده شود.

سناریوی عملی در تیم ایرانی

مدیر مالی ساعت می‌خواهد؛ تیم ۲۳ امتیاز تعهد می‌دهد. مدیر پروژه حدس «یازده روز» می‌زند — تحویل نوزده روز طول می‌کشد. واحدها جدا، بازبینی منظم، گزارش ساعت برای مالی.

هم‌ترازی با ذینفعان

نقش سؤال هفتگی اقدام در WKFGo
مدیر پروژه گلوگاه کجاست؟ برد + گزارش
لید فنی چه کسی مسدود است؟ my_queue (صف من)
مدیر اجرایی چه تصمیمی لازم است؟ decision_inbox (صف تصمیم)
مالی هزینه هم‌خوان است؟ finance_summary (خلاصه مالی)

سؤالات متداول

یک امتیاز داستان چند ساعت است؟

بعد از چند اسپرینت داده تاریخی دارید — فرمول جهانی وجود ندارد.

آیا ساعت ضدالگوی چابک است؟

خیر — ضدالگو قاطی کردن دو واحد در یک عدد است.

پیمانکار قیمت ثابت؟

قرارداد ساعتی؛ امتیاز فقط داخلی.

چطور مالی را راضی کنیم؟

نرخ مصرف و ساعت تجمیعی.

جمع‌بندی

امتیاز داستان و ساعت هدف متفاوت دارند. سیاست را در ویکی بنویسید و در ابزار جدا نگه دارید.