مدیریت زمان پروژههای گروهی یعنی تیم بداند چه خروجیای، با چه معیار پذیرشی، توسط چه مالک و تا چه تاریخ تحویل میشود؛ ورودی آن از کجا میآید، به چه کاری وابسته است و اگر عقب افتاد چه کسی تصمیم میگیرد. تقویم مشترک یا فهرست بلند وظایف بدون این قراردادها فقط ظاهر هماهنگی را میسازد.
این راهنما برای پروژههای تیمی کوچک و متوسط، از پروژه دانشگاهی و کمپین محتوا تا توسعه محصول، نوشته شده است. هدف آن طراحی یک سیستم سبک برای تحویل است: قرارداد خروجی، نقشه وابستگی، حد کار همزمان، ریتم مرور، forecast و escalation. انتخاب نرمافزار، برنامهریزی پروژه پیچیده، اولویتبندی backlog و بازیابی تأخیر صفحات مالک جدا دارند و اینجا فقط به نقطه اتصالشان با اجرای تیم پرداخته میشود.
نسخه کوتاه: هر کار تیمی باید هفت پاسخ داشته باشد
پیش از شروع هر بسته کار، این هفت فیلد را در یک محل مشترک تکمیل کنید:
- خروجی: چه چیز قابلتحویلی ساخته میشود؟
- معیار پذیرش: چه کسی با چه شاهدی آن را میپذیرد؟
- مالک پاسخگو: چه کسی وضعیت و عبور از مانع را پیگیری میکند؟
- تاریخ و منبع آن: موعد تعهد بیرونی است، forecast داخلی یا فقط هدف آزمایشی؟
- ورودی و وابستگی: شروع یا پایان کار منتظر چه فرد، تصمیم، داده یا تأمینکنندهای است؟
- ظرفیت و WIP: چه مقدار کار همزمان پذیرفته میشود و چه چیزی فعلاً شروع نمیشود؟
- نقطه کنترل: تیم چه زمانی forecast، مانع و تصمیم لازم را مرور میکند؟
اگر یکی از این پاسخها نامعلوم است، «شروع» احتمالاً فقط انتقال ابهام به مرحله اجراست. نمونه عبارت بهتر این است: «نسخه قابلکلیک صفحه پرداخت، مطابق پنج سناریوی پذیرش، با مالکیت سارا، تا پایان ۲۵ شهریور؛ پس از دریافت متن حقوقی در ۲۰ شهریور؛ مرور forecast دوشنبه و پنجشنبه.»
چرا زمان در پروژه تیمی با برنامه شخصی فرق دارد؟
در برنامه شخصی، تأخیر یک کار عمدتاً تقویم همان فرد را جابهجا میکند. در پروژه گروهی، تأخیر میتواند زمان انتظار چند نفر، رزرو یک منبع مشترک، موعد مشتری یا زنجیره تحویل را تغییر دهد. بنابراین مسئله فقط مجموع ساعتها نیست؛ منطق میان کارها و کیفیت handoff مهم است.
| منبع اتلاف | نشانه قابلمشاهده | کنترل مناسب | کنترل نامناسب |
|---|---|---|---|
| خروجی مبهم | بازکاری و اختلاف بر سر «تمامشدن» | معیار پذیرش پیش از شروع | فشار برای سریعتر کارکردن |
| وابستگی پنهان | کار شروع شده اما منتظر ورودی است | مالک، موعد نیاز و fallback | افزودن نفر به کار مسدود |
| کار همزمان زیاد | آیتمهای نیمهتمام و جابهجایی مکرر | حد WIP و سیاست pull | شروع همه اولویتها |
| تصمیم بیمالک | جلسه تکراری بدون انتخاب | صاحب تصمیم و deadline | رأیگیری بیقاعده |
| گزارش دیرهنگام | «۹۰٪ تمام» تا روز تحویل | remaining work و forecast | درصد پیشرفت شهودی |
مرز این صفحه با راهنماهای دیگر چیست؟
اگر پرسش اصلی شما «کدام کار تیم جلوتر باشد؟» است، راهنمای اولویتبندی کارهای تیمی درباره MoSCoW، RICE، ظرفیت و حق تصمیم صفحه مالک است. این مقاله از لحظهای شروع میشود که کار وارد تعهد اجرا شده است.
اگر پروژه شبکه بزرگ، عدمقطعیت زیاد، چند پیمانکار، WBS رسمی یا تحلیل مسیر بحرانی لازم دارد، از راهنمای برنامهریزی پروژه پیچیده استفاده کنید. اینجا یک مدل سبک برای تیم معمولی میسازیم و محاسبه CPM را دوباره آموزش نمیدهیم.
اگر مسئله انتخاب Trello، Asana، Jira، Planner یا ابزار self-hosted است، مقایسه در صفحه ابزارهای مدیریت پروژه انجام شده است. ابزار باید سیستم توافقشده را پشتیبانی کند؛ feature زیاد جای قرارداد خروجی و handoff را نمیگیرد.
از شواهد و استانداردها چه استفادهای میکنیم؟
NASA مدیریت زمانبندی را به پنج حوزه برنامهریزی، توسعه، ارزیابی و تحلیل، نگهداری و کنترل، و مستندسازی و ارتباط تقسیم میکند. در توضیح بهروزشده ۲۸ آوریل ۲۰۲۶، برنامه یکپارچه را چارچوب هماهنگی تلاشها و منبع داده تصمیمهای مدیریتی معرفی میکند. این راهنما برای برنامههای NASA نوشته شده و نسخه اجباری یک تیم کوچک نیست؛ ما اصل تفکیک «ساخت برنامه، بهروزرسانی، تحلیل و ارتباط» را از مرور مدیریت زمانبندی NASA میگیریم و سطح جزئیات را متناسب میکنیم.
گزارش GAO در ۲۰۲۶ درباره یک برنامه نوسازی فناوری، دوباره چهار ویژگی برنامه قابلاتکا را برجسته میکند: جامع، خوشساخت، معتبر و کنترلشده. گزارش توضیح میدهد برنامه یکپارچه باید زمان، مدت و رابطه فعالیتها را روشن کند تا پیشرفت، مشکل و پاسخگویی دیده شوند. این یک مطالعه موردی نظارتی است و موفقیت هر پروژه را پیشبینی نمیکند؛ برای مشاهده دامنه و یافتهها به گزارش فناوری اطلاعات GAO در ۲۰۲۶ مراجعه کنید.
استاندارد GovS ۰۰۲ دولت بریتانیا نیز نقشها و پاسخگویی، برنامهریزی و کنترل، منابع و ظرفیت، ریسک، تصمیم، ارتباطات و گزارش را اجزای مرتبط تحویل میداند. این استاندارد برای دستگاههای دولتی بریتانیاست، نه قانون یا certification برای تیم ایرانی؛ اما فهرست حوزههای آن کمک میکند زمان را جدا از حاکمیت و منابع نبینیم. نسخه و دامنه در استاندارد رسمی Project Delivery مشخص است.
جلسه شروع ۹۰دقیقهای: یک بسته اجرایی بسازید
زمان ۹۰ دقیقه پیشنهاد اولیه برای پروژه کوچک است، نه استاندارد جهانی. اگر ذینفعان متعدد یا داده پرخطر دارید، جلسهها و بازبینیهای بیشتری لازم است. خروجی جلسه باید یک بسته کمحجم باشد:
- یک جمله outcome و یک فهرست کوتاه out-of-scope؛
- سه تا هفت deliverable با معیار پذیرش؛
- milestoneهای تصمیم یا تحویل، نه فهرست همه فعالیتها؛
- مالک هر خروجی و صاحب تصمیمهای اصلی؛
- وابستگیهای بیرونی و موعد نیاز آنها؛
- تقویم واقعی ظرفیت، تعطیلات و محدودیت منابع مشترک؛
- ریتم update، review و escalation؛
- محل واحد وضعیت و decision log.
جلسه شروع زمانی تمام است که ابهامهای پراثر نامگذاری و برای هرکدام مالک کشف تعیین شده باشد؛ لازم نیست همه مجهولات با حدس پُر شوند.
| مصنوع اجرایی | حداقل محتوا | مالک نگهداری | زمان بهروزرسانی |
|---|---|---|---|
| نقشه خروجی | deliverable، پذیرش، مالک و milestone | مسئول پروژه/تیم | شروع و تغییر scope |
| تابلوی جریان | state، WIP، blocker و next action | مالک هر آیتم | با تغییر واقعی وضعیت |
| دفتر وابستگی | ورودی، تأمینکننده، موعد نیاز و fallback | مالک خروجی مصرفکننده | مرور جریان |
| Decision log | گزینه، تصمیم، صاحب، تاریخ و دلیل | صاحب تصمیم یا ثبتکننده جلسه | همان روز تصمیم |
| Forecast تحویل | تاریخ، سطح اطمینان، فرض و ریسک | مالک milestone | پس از داده یا تغییر پراثر |
این پنج مورد میتوانند در یک فایل یا ابزار واحد باشند. هدف تکثیر سند نیست؛ هر داده باید یک محل حقیقت، مالک و دلیل استفاده داشته باشد.
گام اول: خروجی را پیش از فعالیت تعریف کنید
«کار روی محتوا»، «طراحی صفحه» یا «تحقیق» فعالیتاند؛ پایان قابلپذیرش ندارند. خروجی باید یک شیء، تصمیم یا نتیجه قابلبررسی باشد: «نسخه نهایی سه ایمیل با تأیید حقوقی»، «گزارش مصاحبه با شش الگوی مشاهدهشده» یا «صفحه پرداخت عبورکرده از سناریوهای پذیرش».
برای هر خروجی این قرارداد را بنویسید:
- نام و هدف: چه تصمیم یا استفادهای را ممکن میکند؟
- معیار پذیرش: شاهد عینی کافی چیست و چه کسی میپذیرد؟
- قید: قالب، بودجه، امنیت، accessibility یا الزام قراردادی چیست؟
- نسخه: draft، قابلبررسی، پذیرفتهشده یا منتشرشده؟
معیار پذیرش، کنترل کیفیت را به آخر پروژه تبعید نمیکند. بازبین باید پیش از شروع بداند چه چیزی و در چه زمانی برای او میآید؛ وگرنه صف review به وابستگی پنهان تبدیل میشود.
گام دوم: مالکیت و اختیار را از انجام کار جدا کنید
چند نفر میتوانند روی یک خروجی کار کنند، اما وضعیت آن نباید بیمالک باشد. «مالک خروجی» لزوماً همه کارها را انجام نمیدهد؛ او مطمئن میشود تعریف، ورودی، هماهنگی، مانع، forecast و درخواست پذیرش روشناند.
| نقش | پرسش | خطای رایج | شاهد |
|---|---|---|---|
| مالک خروجی | چه کسی وضعیت و عبور از مانع را پیگیری میکند؟ | «همه مسئولاند» | یک نام برای هر خروجی |
| انجامدهنده | چه کسی کدام بخش را اجرا میکند؟ | مالک مساوی مجری انفرادی | بستههای کار محدود |
| پذیرنده | چه کسی معیار done را تأیید میکند؟ | بازبین ناشناخته در پایان | نام و پنجره review |
| صاحب تصمیم | در تعارض scope/time/quality چه کسی انتخاب میکند؟ | جلسه بدون حق تصمیم | decision log |
| جانشین | در غیبت نقش گلوگاهی چه میشود؟ | توقف تا بازگشت فرد | قاعده و سطح اختیار جانشین |
برای تفاوت مسئولیت، اختیار، delegation brief و accountability از راهنمای تفویض مؤثر و پاسخگویی استفاده کنید. ماتریس نقش وسیله روشنکردن کار است، نه راهی برای افزودن نامهای زیاد به هر ردیف.
گام سوم: وابستگی را به قرارداد handoff تبدیل کنید
نوشتن «وابسته به تیم فنی» کافی نیست. هر وابستگی باید یک خروجی ورودی، تأمینکننده، مصرفکننده، موعد نیاز، معیار پذیرش و fallback داشته باشد. موعد نیاز با موعد نهایی پروژه یکی نیست؛ ورودی باید پیش از زمان مصرف و با فرصت کنترل برسد.
قالب کوتاه وابستگی:
برای شروع [کار مصرفکننده] به [ورودی مشخص] از [مالک تأمین] تا [تاریخ/ساعت و منطقه زمانی] نیاز داریم. پذیرش یعنی [شاهد]. اگر تا نقطه کنترل نرسید، [گزینه جایگزین/تصمیم] توسط [صاحب تصمیم] فعال میشود.
وابستگی میتواند finish-to-start نباشد؛ گاهی draft پایدار برای شروع کافی است و همپوشانی کنترلشده ممکن میشود. اما interface، نسخه و هزینه دوبارهکاری باید روشن باشند. «همزمان شروع کنیم تا سریع شویم» بدون این قرارداد فقط ریسک را پنهان میکند.
گام چهارم: موعد، برآورد و forecast را یکی نگیرید
- موعد تعهدی: تاریخی که به مشتری، قرارداد یا رویداد بیرونی متصل است.
- تاریخ هدف: زمان مطلوب داخلی که میتواند برای ایجاد فاصله امن زودتر باشد.
- برآورد: قضاوت درباره تلاش یا مدت با داده و عدمقطعیت موجود.
- forecast: پیشبینی بهروز پایان براساس وضعیت واقعی، remaining work، جریان و ریسک.
- baseline: نسخه تأییدشده برنامه برای مقایسه؛ با تغییر forecast پاک نمیشود.
بهجای «۸۰٪ تمام»، مقدار باقیمانده و شاهد را گزارش کنید: «دو سناریو از پنج سناریوی پذیرش باقی است؛ محیط تست فردا در دسترس میشود؛ forecast پنجشنبه با اطمینان متوسط.» درصد شهودی ممکن است روزها ثابت بماند و تصمیمی نسازد.
برای کار تکرارشونده میتوانید از داده تاریخی cycle time یا نسبت estimate/actual استفاده کنید. ثبت ساعت باید هدف و سطح دقت مناسب داشته باشد؛ دستورالعمل منصفانه آن در راهنمای ردیابی زمان آمده است. ساعت بیشتر معادل ارزش یا عملکرد بهتر فرد نیست.
گام پنجم: ظرفیت را با حد کار همزمان محافظت کنید
ظرفیت اسمی حاصلضرب نفر و ساعت نیست. مرخصی، جلسه، پشتیبانی، کار نگهداری، onboarding، مهارت گلوگاهی و وقفههای معمول از آن کم میشوند. همچنین همه افراد قابلجایگزینی نیستند؛ پنج ساعت آزاد توسعهدهنده لزوماً کمبود دو ساعت بازبین حقوقی را حل نمیکند.
راهنمای کانبان مه ۲۰۲۵ چهار سنجه حداقلی WIP، throughput، work item age و cycle time را تعریف و SLE را forecast احتمالی مبتنی بر تاریخچه معرفی میکند. این تعاریف فقط وقتی معنا دارند که نقطه start/finish و Definition of Workflow تیم روشن باشد. Kanban نسخه یک برد یا قانون عمومی برای همه پروژهها نیست؛ تعریف و محدودیتها در Kanban Guide 2025 آمده است.
حد WIP را با مشاهده گلوگاه آزمایش کنید، نه با عدد جادویی. اگر review انباشته میشود، شروع کار تازه را محدود و ظرفیت را برای پایاندادن یا رفع مانع مصرف کنید. استثنای فوری باید مشخص کند کدام آیتم خارج میشود؛ افزودن کار بدون خروج، ظرفیت نمیسازد.
گام ششم: ریتم هماهنگی را براساس تصمیم طراحی کنید
هر cadence باید سؤال و خروجی داشته باشد. سه لایه سبک برای بسیاری از تیمها کافی است:
- update غیرهمزمان روزانه: تغییر وضعیت، کار بعدی، مانع و تصمیم لازم؛ بدون بازگویی تاریخچه.
- مرور جریان دو یا سه بار در هفته: آیتمهای پیر، WIP، صف review، وابستگی نزدیک و forecast milestone.
- مرور تحویل هفتگی: خروجی پذیرفتهشده، تغییر baseline/forecast، ریسک و تصمیم ذینفع.
Scrum Guide رسمی، Daily Scrum پانزدهدقیقهای را رویدادی برای Developers میداند که پیشرفت به Sprint Goal را بازرسی و برنامه آینده نزدیک را تطبیق میدهد. عدد ۱۵ دقیقه و شکل رویداد متعلق به Scrum است، نه قانون همه تیمها؛ خود راهنما نیز ساختار سؤالها را تحمیل نمیکند. اگر Scrum اجرا نمیکنید، فقط اصل «مرور برای تطبیق برنامه، نه گزارش به مدیر» را با احتیاط از Scrum Guide رسمی بگیرید.
جلسه وقتی لازم است که ابهام، تعارض یا تصمیم همزمان ارزش داشته باشد. جلسه status که میتوانست update مکتوب باشد حذف شود؛ طراحی agenda، نقش و صورتجلسه تصمیم در راهنمای جلسه مؤثر آمده است.
داشبورد اجرای تیم چه چیزهایی را نشان دهد؟
داشبورد خوب هر حرکت را ثبت نمیکند؛ تصمیم نزدیک را ممکن میسازد. حداقل نما میتواند شامل deliverable/milestone، owner، state، forecast، dependency، blocker age، next decision و last updated باشد. دادهای که مالک و cadence نگهداری ندارد سریعاً به تزئین تبدیل میشود.
| سنجه | تعریف عملی | سؤال تصمیم | هشدار تفسیر |
|---|---|---|---|
| Milestone forecast | تاریخ فعلی پیشبینیشده با سطح اطمینان | آیا تعهد یا scope باید بازبینی شود؟ | تضمین نیست |
| WIP | کار شروعشده و تمامنشده طبق تعریف تیم | آیا شروع تازه را متوقف کنیم؟ | میان جریانهای متفاوت مقایسه خام نشود |
| Work item age | زمان سپریشده آیتم باز از start | کدام آیتم نیازمند توجه است؟ | سن زیاد لزوماً تقصیر مالک نیست |
| Blocked age | زمان از ثبت مانع فعال | escalation یا fallback لازم است؟ | مانع باید تعریف مشترک داشته باشد |
| Handoff first-pass | درصد ورودی پذیرفتهشده بدون برگشت اساسی | قرارداد interface کجا ضعیف است؟ | برای تنبیه تأمینکننده استفاده نشود |
| Rework | زمان/آیتم ناشی از اصلاح معیار یا خطا | تعریف، کیفیت یا تغییر کجا مشکل دارد؟ | همه iteration دوبارهکاری نیست |
پروتکل مانع و escalation را قبل از گیرکردن بنویسید
مانع هر دشواری نیست؛ وضعیتی است که ادامه کار پذیرفتهشده را متوقف یا forecast را بهطور معنادار تهدید میکند و تیم در سطح فعلی اختیار یا ورودی رفع آن را ندارد. ثبت مانع باید شامل اثر، زمان شروع، اقدام انجامشده، مالک رفع، تصمیم لازم و deadline تصمیم باشد.
مسیر escalation نباید فقط «به مدیر بگو» باشد. مشخص کنید چه آستانهای، به کدام نقش، با چه گزینههایی و تا چه زمانی میرود. پیام خوب میگوید: «تأیید امنیت از سهشنبه مسدود است؛ اگر تا چهارشنبه ۱۲ نرسد، forecast تحویل دو روز جابهجا میشود. گزینهها: بازبین جانشین یا کاهش scope بخش غیراصلی؛ تصمیم با مدیر محصول تا ۱۱.»
تغییر را با trade-off وارد کنید
درخواست تازه نباید بیصدا کنار کارهای متعهدشده اضافه شود. هر تغییر حداقل باید اثر بر خروجی، زمان، ظرفیت، وابستگی، کیفیت و ریسک را نشان دهد. صاحب تصمیم یکی از چهار گزینه را انتخاب میکند: جایگزینی با کار موجود، تعویق، افزایش ظرفیت واقعی با هزینه و onboarding، یا تغییر موعد/scope.
baseline قبلی را نگه دارید و forecast را جدا بهروزرسانی کنید. اگر برنامه واقعاً شکسته است و گزینههای عادی دیگر کافی نیستند، وارد فرایند جبران تأخیر و ساخت Recovery Plan شوید؛ فشار همگانی، حذف QA یا تغییر صوری baseline بازیابی نیست.
سه سناریوی اجرایی
پروژه دانشگاهی چهار نفره
خروجیها به طرح پژوهش، جمعآوری داده، تحلیل، متن و ارائه تقسیم میشوند. «همه روی گزارش کار میکنند» با مالک هر خروجی و بازبین جایگزین میشود. وابستگی داده به رضایت و دسترسی پاسخدهنده موعد نیاز دارد. مرور دوبار در هفته بر شاهد خروجی و کار باقیمانده است، نه فقط اعلام «من انجام میدهم».
کمپین آژانس کوچک
تقویم انتشار مقصد نهایی نیست؛ متن، طراحی، تأیید برند و تنظیم انتشار handoffهای جدا هستند. هر ورودی نسخه و زمان پذیرش دارد. ظرفیت بازبین مشتری بهعنوان منبع بیرونی دیده میشود. درخواست فوری تازه فقط با خروج یا تعویق یک آیتم وارد WIP میشود.
تیم محصول توزیعشده
منطقه زمانی در deadline وابستگی ثبت میشود. update روزانه غیرهمزمان، صف review و decision log انتقال شیفت را ممکن میکنند. milestone نسخه با سناریوهای پذیرش تعریف میشود؛ وضعیت سبز پیامرسان شاهد ظرفیت یا پیشرفت نیست. جلسه مشترک فقط برای تصمیم interface یا ریسک نزدیک برگزار میشود.
آزمایش چهاردهروزه برای یک پروژه زنده
- روزهای ۱ و ۲: سه تا هفت خروجی، معیار پذیرش و مالک را بنویسید.
- روز ۳: وابستگیها، موعد نیاز، پذیرنده و صاحب تصمیم را ثبت کنید.
- روز ۴: ظرفیت واقعی و WIP اولیه را با یک فرض روشن تعیین کنید.
- روزهای ۵ تا ۷: update و مرور جریان را اجرا و زمان مانع/انتظار را ثبت کنید.
- روز ۸: یک گلوگاه را انتخاب کنید؛ همه فرایند را همزمان تغییر ندهید.
- روزهای ۹ تا ۱۳: یک اصلاح مانند معیار handoff، جانشین یا کاهش WIP را بیازمایید.
- روز ۱۴: forecast، خروجی پذیرفتهشده، آیتم پیر، مانع، دوبارهکاری و تجربه تیم را مرور کنید.
تصمیم پایانی باید مشخص باشد: ادامه، اصلاح یا حذف قاعده. این مرور میتواند به برنامه پایدار مرور هفتگی متصل شود تا پروژه با وضعیت کهنه اداره نشود.
خطاهای رایج
- تقویم بدون منطق: تاریخها ثبت شدهاند اما predecessor، ورودی یا منبع موعد معلوم نیست.
- مالکیت جمعی مبهم: چند نام روی کارت است و هیچکس وضعیت یا escalation را مالک نیست.
- شروع برابر پیشرفت: تعداد آیتم فعال زیاد میشود، اما خروجی پذیرفتهشده ثابت میماند.
- درصد ساختگی: ۸۰ یا ۹۰ درصد بدون remaining work، شاهد یا forecast گزارش میشود.
- جلسه برای جمعآوری status: وقت همزمان صرف اطلاعاتی میشود که میتوانست پیشخوانده شود.
- ابزار بهعنوان فرایند: نصب برد، automation یا گانت جای تعریف done و نقش را میگیرد.
- فوریت بدون خروج: کار تازه اضافه میشود، اما هیچ تعهدی از ظرفیت خارج نمیشود.
- پنهانکردن خبر بد: forecast تا روز موعد ثابت میماند تا «منفی» به نظر نرسد.
- سنجش تنبیهی: ساعت، age یا throughput برای رتبهبندی افراد با کارهای ناهمسان استفاده میشود.
پرسشهای متداول
بهترین ابزار برای مدیریت زمان پروژه گروهی چیست؟
بهترین مطلق وجود ندارد. ابتدا جریان، تعداد نقشها، نیاز dependency، permission، گزارش، دسترسی و بودجه را مشخص کنید. برای تیم کوچک ممکن است جدول مشترک کافی باشد؛ پروژه چندلایه شاید ابزار تخصصی بخواهد. ابزار را با سناریوی واقعی پایلوت کنید.
چطور کار را عادلانه میان اعضا تقسیم کنیم؟
تعداد کارت مساوی معیار عدالت نیست. اندازه، مهارت، پیچیدگی، کار نامرئی هماهنگی، ریسک و ظرفیت واقعی را ببینید. مالک خروجی را از مجری هر بسته جدا کنید و بار review و پشتیبانی را نیز ثبت کنید. سپس درباره trade-offها شفاف گفتوگو کنید.
جلسه روزانه برای هر پروژه لازم است؟
خیر. cadence تابع سرعت تغییر، هزینه هماهنگی، وابستگی و نیاز تصمیم است. update غیرهمزمان ممکن است کافی باشد. Daily Scrum یک رویداد مشخص در چارچوب Scrum است و نباید بدون هدف به همه تیمها کپی شود.
اگر یکی از اعضا کارش را دیر تحویل داد چه کنیم؟
ابتدا اثر و علت عملیاتی را جدا کنید: خروجی مبهم، وابستگی، ظرفیت، مهارت، تصمیم دیرهنگام یا برآورد اشتباه؟ remaining work و forecast تازه را ثبت کنید، مصرفکنندگان بعدی را مطلع و گزینه تصمیم را بالا ببرید. گفتوگوی عملکردی یا انضباطی بدون بررسی سیستم، مسئله زمانبندی را حل نمیکند.
پیشرفت پروژه را با ساعت بسنجیم یا درصد؟
هیچکدام بهتنهایی کافی نیست. خروجی پذیرفتهشده، remaining work، forecast milestone، WIP، age، مانع و کیفیت handoff را کنار زمان واقعی ببینید. ساعت ورودی است و درصد شهودی ممکن است گمراهکننده باشد؛ سنجه باید به تصمیم مشخص وصل شود.
جمعبندی
مدیریت زمان پروژههای گروهی از «بیشتر کارکردن» یا «پیگیری مداوم افراد» به دست نمیآید. سیستم قابلاتکا خروجی و پذیرش را تعریف میکند، مالک و صاحب تصمیم را جدا میسازد، وابستگی را قرارداد handoff میکند، ظرفیت و WIP را میپذیرد و forecast را با داده تازه اصلاح میکند.
برای شروع، نرمافزار یا مراسم تازه نخرید. یک پروژه زنده را انتخاب کنید، هفت فیلد ابتدای مقاله را برای سه خروجی تکمیل و یک نقطه مرور تعیین کنید. پس از چهارده روز ببینید آیا زمان انتظار، کار نیمهتمام و خبر دیرهنگام کمتر و خروجی پذیرفتهشده قابلپیشبینیتر شده است. اگر نه، همان داده نشان میدهد مشکل در تعریف، وابستگی، ظرفیت یا اختیار کجاست.
