برنامهٔ پروژه را با سناریو بسازیم، نه تاریخ قطعی

Plan، forecast و commitment یک چیز نیستند

Plan توضیح می‌دهد برای رسیدن به یک هدف چه مسیر، کار، dependency و تصمیمی را فعلاً در نظر گرفته‌ایم. Forecast برآوردی است دربارهٔ اینکه با اطلاعات فعلی، یک outcome در چه بازه‌ای و با چه عدم‌قطعیتی ممکن است رخ دهد. Commitment تصمیمی است که یک فرد یا تیم پس از دیدن ظرفیت، ریسک و گزینه‌های جایگزین می‌پذیرد. این سه می‌توانند به هم مرتبط باشند، اما قابل‌جایگزین‌کردن نیستند.

وقتی یک forecast را مثل قول قطعی نمایش می‌دهیم، هر تغییر کوچک به «عقب‌افتادن تیم» تعبیر می‌شود؛ حتی اگر مسئله، تغییر داده یا آشکارشدن یک dependency پنهان بوده باشد. برعکس، اگر همه‌چیز را به uncertainty حواله کنیم و هیچ boundary یا decision date نداشته باشیم، تیم هم نمی‌داند چه کاری را باید جلو ببرد. سناریو باید هم عدم‌قطعیت را نشان دهد و هم تصمیم بعدی را قابل‌اجرا کند.

برای هر برنامه، من دست‌کم این چهار جمله را جدا می‌نویسم: هدف چیست؟ اکنون چه چیزی را می‌دانیم؟ چه فرضی باید درست باشد؟ اگر فرض تغییر کرد، کدام تصمیم را در چه زمانی بازبینی می‌کنیم؟ همین چهار سؤال از تبدیل roadmap به فهرست تاریخ‌ها جلوگیری می‌کند.

• Plan: مسیر فعلی، کارهای لازم، dependency و تصمیم‌های باز.
• Forecast: بازهٔ احتمالی بر اساس evidence، ظرفیت و فرض‌های فعلی.
• Commitment: انتخاب آگاهانهٔ تیم یا صاحب تصمیم برای یک scope و زمان مشخص.
• Review point: زمان یا رویدادی که باید forecast و scope دوباره بررسی شوند.

چرا تاریخ قطعی در پروژهٔ AI زود می‌شکند؟

در یک پروژهٔ نرم‌افزاری هم تاریخ قطعی بدون فرض خطرناک است؛ در پروژهٔ AI لایه‌های بیشتری از عدم‌قطعیت وجود دارد. ممکن است نمونهٔ اولیه با چند prompt خوب کار کند اما برای دادهٔ واقعی به cleaning، permission، retrieval، evaluation یا human review نیاز داشته باشد. تغییر مدل یا provider هم فقط یک تغییر فنی نیست؛ روی latency، هزینه، quality و رفتار workflow اثر می‌گذارد.

از طرف دیگر، dependencyهای AI همیشه در backlog فنی دیده نمی‌شوند. دسترسی به داده، تأیید حقوقی، مالک دانش، سیاست امنیتی، زمان متخصص domain و آمادگی کاربر می‌تواند critical path را تغییر دهد. AI می‌تواند از issueها و سندها رابطه‌های احتمالی را پیدا کند، اما نبودن یک dependency در متن به معنی نبودن آن در جهان واقعی نیست.

بنابراین مشکل تاریخ قطعی فقط خطای تخمین نیست. تاریخ قطعی اغلب گفت‌وگوی لازم دربارهٔ quality bar، scope و مسیر fallback را به بعد موکول می‌کند. وقتی deadline از ابتدا تبدیل به هدف اصلی شود، تیم ممکن است بخش‌هایی را که باید یاد بگیرد پنهان کند یا خروجی ظاهری را جایگزین outcome کند.

• کیفیت و تازگی داده هنوز با prototype ثابت نشده است.
• رفتار مدل و هزینهٔ provider ممکن است با الگوی اولیه فرق کند.
• integration، permission یا approval بیرونی در مسیر بحرانی قرار می‌گیرد.
• تعریف Done برای خروجی احتمالی هنوز شفاف نیست.
• کاربر یا تیم عملیاتی برای اعتماد و استفاده آماده نیست.

AI در سناریوپردازی چه کمکی می‌کند؟

نقطهٔ قوت AI در این کار، جمع‌کردن context و تولید گزینه‌های اولیه است. می‌تواند تاریخچهٔ cycle time، وضعیت issueها، تغییرات scope، dependencyهای ثبت‌شده، blockerها و تصمیم‌های قبلی را کنار هم بگذارد و نشان دهد کدام فرض‌ها بیشترین اثر را روی برنامه دارند. این کار زمان آماده‌شدن برای برنامه‌ریزی را کم می‌کند، به شرطی که source و تازگی اطلاعات معلوم باشد.

AI همچنین می‌تواند برای یک outcome چند مسیر پیشنهاد دهد: مسیر سریع با scope کوچک، مسیر متعادل با review کامل، و مسیر محافظه‌کارانه با کاهش ریسک یا dependency. برای هر مسیر باید توضیح دهد چه چیزی ثابت فرض شده، چه ظرفیت یا اقدام بیرونی لازم است و اگر یک trigger رخ داد، کدام بخش باید بازتنظیم شود.

اما AI نباید از روی task count یک احتمال دقیق جعل کند. اگر داده کم، غیرهم‌جنس یا stale است، خروجی درست می‌تواند یک بازهٔ وسیع‌تر، confidence پایین‌تر و چند سؤال باز باشد. این خروجی شاید کمتر چشمگیر به نظر برسد، ولی برای تصمیم‌گیری صادقانه‌تر است. کیفیت سناریو با تمیزی timeline سنجیده نمی‌شود؛ با توانایی آن برای آماده‌کردن تصمیم بعدی سنجیده می‌شود.

• Context synthesis: جمع‌کردن evidence از backlog، issue، تصمیم و delivery history.
• Assumption mapping: برجسته‌کردن فرض‌هایی که بیشترین اثر را بر زمان و scope دارند.
• Option generation: ارائهٔ چند مسیر با trade-off، dependency و هزینهٔ فرصت.
• Change detection: پیدا کردن triggerهایی که forecast را نیازمند بازبینی می‌کنند.
• Draft communication: تبدیل سناریو به زبان قابل‌فهم برای تیم و stakeholder.

سه سناریوی پایه چگونه ساخته می‌شوند؟

سه سناریو قانون طبیعی پروژه نیستند؛ یک ابزار گفت‌وگو هستند. سناریوی سریع یا optimistic نشان می‌دهد اگر dependencyهای اصلی به‌موقع حل شوند، scope کنترل‌شده بماند و quality gate بدون rework عبور کند، چه outcomeای ممکن است. سناریوی محتمل، بر اساس وضعیت فعلی و محدودیت‌های شناخته‌شده ساخته می‌شود. سناریوی محدودشده یا constrained نشان می‌دهد اگر یک ریسک مهم رخ دهد، چه چیزی را باید حذف، عقب‌انداخت یا به fallback سپرد.

در هر سناریو به جای فقط یک تاریخ، چهار چیز را بنویسید: بازهٔ زمانی، scope قابل‌تحویل، فرض‌های بحرانی و trigger بازبینی. اگر سناریوی سریع فقط با اضافه‌کردن آدم یا حذف review ممکن است، آن trade-off باید آشکار باشد. اگر سناریوی محتمل به تأیید یک سازمان بیرونی وابسته است، owner و زمان پیگیری آن dependency باید در برنامه دیده شود.

سناریوی محدودشده شکست پروژه نیست. یک گزینهٔ آماده برای حفظ outcome است. ممکن است به جای launch کامل، یک pilot محدود، workflow دستی، feature flag یا release تدریجی انتخاب شود. ارزش این سناریو در این است که تیم هنگام رخ‌دادن ریسک از صفر تصمیم نمی‌گیرد.

• سریع: چه چیزی با کمترین scope و کمترین dependency برای یادگیری زودتر عرضه می‌شود؟
• محتمل: با ظرفیت و ریسک فعلی، چه بازه و چه quality bar واقع‌بینانه است؟
• محدودشده: اگر ریسک اصلی رخ دهد، کوچک‌ترین outcome قابل‌حفظ چیست؟
• برای هر سه: صاحب تصمیم، source، فرض، trigger، review date و مسیر بازگشت.

Critical path فقط فهرست dependencyهای فنی نیست

در برنامه‌ریزی کلاسیک، critical path معمولاً با کارهایی شناخته می‌شود که تأخیرشان پایان پروژه را جابه‌جا می‌کند. در محصول AI، بهتر است یک critical path socio-technical داشته باشیم: داده، مدل، integration، approval، دانش domain، آمادگی کاربر و توان پشتیبانی. اگر یکی از این nodeها برای outcome ضروری باشد، نبودن آن در plan، ریسک را حذف نمی‌کند؛ فقط آن را نامرئی می‌کند.

AI می‌تواند از متن پروژه graph یا فهرست dependency بسازد، اما هر رابطهٔ استنباط‌شده باید با source و confidence نمایش داده شود. همچنین باید بپرسیم آیا owner واقعی دارد، آخرین بار چه زمانی بررسی شده و در صورت شکست چه fallbackی وجود دارد. یک dependency که owner ندارد، در سناریو باید ریسک باز تلقی شود؛ حتی اگر در ابزار مدیریت پروژه سبز باشد.

برای هر dependency مهم، یک سؤال ساده بپرسید: اگر این مورد یک هفته دیر شود، کدام outcome، quality gate یا تصمیم تغییر می‌کند؟ پاسخ، dependencyهای تزئینی را از موارد بحرانی جدا می‌کند و کمک می‌کند سناریوها بر اساس اثر واقعی ساخته شوند.

• فنی: سرویس، مدل، API، repository، داده و deployment.
• سازمانی: approval، قرارداد، compliance، budget و availability افراد.
• انسانی: owner، review capacity، دانش domain، اعتماد و آمادگی کاربر.
• تصمیمی: فرض حل‌نشده، quality bar، scope boundary و انتخاب fallback.

در Agile، سناریو جای Sprint Goal را نمی‌گیرد

Scrum به جای ادعای پیش‌بینی کامل آینده، روی empiricism و سه ستون transparency، inspection و adaptation بنا شده است. Sprint Goal یک objective برای Sprint است و Developers برنامهٔ Sprint را می‌سازند و هر روز آن را با واقعیت تطبیق می‌دهند. این منطق با سناریوپردازی سازگار است: برنامهٔ فعلی داریم، اما اطلاعات تازه می‌تواند مسیر اجرای آن را تغییر دهد.

در این مدل، roadmap یا forecast سطح بالا نباید Sprint را با فهرست تاریخ‌های غیرقابل‌تغییر خفه کند. Product Owner باید value و Product Backlog را با شواهد بازتنظیم کند؛ تیم باید کیفیت و توان تحویل را ببیند؛ Scrum Master باید کمک کند impediment و الگوی شکست پنهان نماند. AI می‌تواند برای هر نقش evidence آماده کند، اما inspect و adapt همچنان یک رفتار تیمی و تصمیم انسانی است.

اگر سناریوها فقط در سند مدیریت پروژه بمانند، اثرشان کم است. در شروع هر چرخه باید بدانیم اکنون در کدام سناریو هستیم، چه triggerهایی ما را به سناریوی دیگر می‌برند و کدام تصمیم در جلسهٔ بعدی باید گرفته شود. این کار برنامه را زنده نگه می‌دارد، بدون اینکه هر روز از صفر شروع کنیم.

• Sprint Goal را به یک outcome روشن، نه تعداد task، وصل کنید.
• هر روز تغییر context و blocker را نسبت به هدف بررسی کنید.
• در review، evidence جدید را به forecast و scope برگردانید.
• برای تغییر سناریو، owner و شرط تصمیم مشخص داشته باشید.
• تعهد تیم را به scope قابل‌فهم و quality bar واقعی گره بزنید.

مدل احتمال را با دقت نمایشی اشتباه نگیریم

تیم‌ها گاهی از AI می‌خواهند احتمال تحویل را با یک عدد دقیق بگوید؛ مثلاً ۸۷ درصد تا یک تاریخ مشخص. اگر دادهٔ گذشته، تعریف completion، اندازهٔ نمونه و شرایط پروژه روشن نباشد، این عدد بیشتر ظاهر علمی دارد تا معنای تصمیمی. بهتر است به جای confidence تزئینی، دامنهٔ فرض، کیفیت evidence و دلیل تغییر احتمال را نشان دهیم.

Forecast می‌تواند با بازه و سطح اطمینان بیان شود، اما باید مشخص باشد این بازه چگونه ساخته شده است. آیا بر مبنای cycle time همان سرویس است یا از پروژهٔ دیگری آمده؟ آیا کارهای review، incident و dependency بیرونی داخل داده هستند یا فقط زمان coding دیده شده؟ آیا پروژهٔ فعلی مشابه همان context است؟ مقایسهٔ بی‌زمینه می‌تواند تصمیم را بدتر کند.

DORA هم در راهنمای metricهای delivery بر context و پرهیز از تک‌معیاری‌کردن تأکید می‌کند. برای برنامه‌ریزی، throughput یا lead time به‌تنهایی کافی نیست؛ stability، rework، failure و زمان recovery هم تصویر را کامل می‌کنند. هدف measurement باید بهبود تصمیم و سیستم باشد، نه بازی‌دادن عدد برای دفاع از یک تاریخ.

• بازه را همراه با source، تعریف done و شرایط مقایسه نشان دهید.
• عدد confidence را بدون توضیح روش و محدودیت، حقیقت معرفی نکنید.
• throughput را کنار stability، rework و recovery ببینید.
• تغییر forecast را به trigger و evidence وصل کنید، نه به سلیقهٔ فردی.

اثر AI بر فرایند برنامه‌ریزی چیست؟

AI بخش‌های تکراری فرایند را فشرده می‌کند: جمع‌آوری وضعیت، استخراج dependency، دسته‌بندی ریسک و آماده‌کردن چند draft. در نتیجه تیم می‌تواند زمان بیشتری را روی trade-off، گفت‌وگوی با stakeholder و طراحی آزمایش بگذارد. این اثر از جنس augmentation است، نه حذف قضاوت. اگر AI فقط timeline را سریع‌تر بسازد، ممکن است سرعت تولید برنامه بالا برود اما کیفیت تصمیم تغییری نکند.

ریسک تازه، automation bias است: چون خروجی منظم و زبان آن مطمئن است، انسان ممکن است فرض‌هایش را بدون بررسی بپذیرد. ریسک دوم، کاهش یادگیری تیم است؛ اگر همهٔ برنامه‌ها از روی history تولید شوند، تغییر context یا failure mode جدید ممکن است دیده نشود. ریسک سوم، هزینهٔ هماهنگی است: سناریوهای زیاد بدون trigger و owner، به جای انعطاف، سردرگمی ایجاد می‌کنند.

به همین دلیل معیار موفقیت AI در برنامه‌ریزی باید این نباشد که چند plan ساخته است. باید ببینیم آیا تیم زودتر dependency بحرانی را دیده، تصمیم برگشت‌پذیر را سریع‌تر گرفته، rework را کم کرده یا در زمان تغییر، recovery بهتری داشته است.

• Automation: جمع‌کردن داده، ساخت draft و به‌روزرسانی بر اساس event معتبر.
• Augmentation: پیشنهاد سناریو، آشکارکردن فرض و آماده‌سازی گفت‌وگوی تصمیم.
• Agent محدود: اجرای action کم‌ریسک پس از approval و ثبت audit trail.
• مالک انسانی: انتخاب outcome، پذیرش trade-off، تعهد و تغییر سناریو.

یک workflow چهارده‌روزه برای شروع

برای اجرای عملی، یک پروژهٔ کامل را از ابتدا با چند سناریوی بزرگ احاطه نکنید. یک outcome مشخص و یک بازهٔ کوتاه انتخاب کنید. در روزهای اول فقط evidence و baseline را جمع کنید: زمان cycle، waiting، rework، blockerهای باز، dependencyهای بیرونی و decisionهایی که عقب افتاده‌اند. اگر دادهٔ کافی ندارید، همین کمبود را به‌عنوان محدودیت برنامه ثبت کنید.

در مرحلهٔ بعد، AI سه سناریو را به‌صورت draft آماده کند. تیم باید فرض‌ها و scope هرکدام را اصلاح کند، نه اینکه فقط یکی را از بین پیشنهادهای مدل انتخاب کند. سپس یک سناریوی فعلی، یک trigger برای بازبینی و یک fallback قابل‌اجرا انتخاب کنید. در پایان چرخه، forecast را با واقعیت مقایسه کنید و دلیل اختلاف را ثبت کنید.

این ریتم باعث می‌شود برنامه‌ریزی به یک سند زنده تبدیل شود. همچنین معلوم می‌کند مشکل اصلی، نبود ابزار است یا نبود داده، owner، quality bar و تصمیم. اگر این پایه‌ها آماده نباشند، Agent قوی‌تر فقط ابهام را با سرعت بیشتری پخش می‌کند.

• روز ۱ و ۲: outcome، boundary، owner، baseline و dependencyهای اصلی را مشخص کنید.
• روز ۳ و ۴: AI evidence، فرض‌ها و سه سناریوی اولیه را آماده کند.
• روز ۵: تیم scope، quality bar، trigger و fallback هر سناریو را review کند.
• روز ۶ تا ۱۰: سناریوی انتخاب‌شده را اجرا و تغییر context را ثبت کنید.
• روز ۱۱: forecast را با شواهد تازه بازتنظیم کنید؛ تاریخ را بی‌دلیل ثابت نگه ندارید.
• روز ۱۲ تا ۱۴: outcome، rework، waiting و decision latency را با baseline مقایسه کنید.

خطاهای رایج در برنامه‌ریزی سناریومحور

خطای اول، ساختن سناریوهای زیاد است. اگر هر وضعیت یک timeline جدا داشته باشد، تیم دیگر نمی‌داند کدام تصمیم مهم است. سه سناریو فقط زمانی ارزش دارد که تفاوتشان در فرض، scope یا اقدام روشن باشد و trigger تغییر بینشان تعریف شود.

خطای دوم، پنهان‌کردن تعهد پشت واژهٔ forecast است. گاهی مدیر می‌خواهد همان تاریخ قطعی را نگه دارد و فقط نامش را forecast بگذارد. اگر consequence، owner و trade-off تاریخ مشخص نیست، هنوز تصمیم واقعی نگرفته‌ایم.

خطای سوم، آموزش‌ندادن به تیم برای خواندن خروجی AI است. هرکس باید بداند source کجاست، چه چیزی inferred شده، confidence به چه معناست و چگونه خطا را گزارش کند. خطای چهارم، بازنگرداندن یادگیری به سیستم است؛ اگر هر بار اختلاف forecast با واقعیت را فقط به «بدشانسی» نسبت دهیم، مدل و فرایند بهتر نمی‌شوند.

• سناریوهای متعدد بدون تفاوت واقعی یا trigger بازبینی
• تاریخ قطعی با نام forecast و بدون گفت‌وگوی trade-off
• اعتماد به عدد AI بدون بررسی context و تعریف Done
• نادیده‌گرفتن کار review، data، approval و support
• ثبت‌نکردن دلیل اختلاف forecast و واقعیت
• استفاده از سناریو برای فرار از تصمیم به جای بهترکردن آن

جمع‌بندی از نگاه من

برنامهٔ خوب قرار نیست آینده را با دقت جادویی پیش‌گویی کند. قرار است وضعیت فعلی، فرض‌های مهم، گزینه‌های واقعی و تصمیم بعدی را روشن کند. در پروژه‌های AI، این نگاه از تبدیل prototype به وعدهٔ production جلوگیری می‌کند و به تیم اجازه می‌دهد scope را بر اساس evidence، نه فشار تقویم، تنظیم کند.

AI برای این فرایند ارزشمند است چون می‌تواند context را سریع‌تر جمع کند، dependency و تغییر را برجسته کند و چند draft سناریو بسازد. اما انتخاب outcome، تعیین quality bar، پذیرش ریسک، گفت‌وگو با stakeholder و تغییر commitment باید در اختیار انسان باقی بماند. همان‌طور که در مقالهٔ قبلی گفتم، Agent می‌تواند بخشی از task را انجام دهد؛ accountability را تحویل نمی‌گیرد.

پیشنهاد عملی حکیم این است: برای هر پروژه یک سناریوی فعلی، یک سناریوی سریع، یک سناریوی محدودشده، چند فرض بحرانی، یک trigger بازبینی و یک fallback بنویسید. بازه را با source و context توضیح دهید و بعد از هر چرخه، forecast را با outcome واقعی مقایسه کنید. اگر برنامه با تغییر یک فرض کاملاً می‌شکند، مشکل از نبود یک تاریخ دقیق نیست؛ مشکل از نداشتن گزینه و مسیر یادگیری است.

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

منابع اولیه برای بررسی

راهنمای رسمی Scrum دربارهٔ empiricism، شفافیت، inspect و adapt، Sprint Goal، Product Backlog و تطبیق روزانهٔ برنامه توسط Developers: https://scrumguides.org/scrum-guide.html — بررسی‌شده در 2026-09-15.

راهنمای رسمی DORA دربارهٔ metricهای throughput و instability، اهمیت context، ارتباط speed و stability و خطاهای تک‌معیاری‌کردن measurement: https://dora.dev/guides/dora-metrics/ — آخرین به‌روزرسانی صفحه 2026-01-05 و بررسی‌شده در 2026-09-15.

مستندات رسمی OpenAI دربارهٔ Agentهایی که می‌توانند taskهای چندمرحله‌ای را با ابزار، context و همکاری بین Agentها جلو ببرند و تفاوت محل orchestration و state در runtimeها: https://developers.openai.com/api/docs/guides/agents — بررسی‌شده در 2026-09-15.

مستندات رسمی GitHub دربارهٔ cloud agent برای research، plan، تغییر روی branch، review، iteration و pull request: https://docs.github.com/en/copilot/concepts/agents/cloud-agent — بررسی‌شده در 2026-09-15.

مرز شواهد و تحلیل

تعریف‌های Scrum، اصول metricهای DORA و capabilityهای اعلام‌شدهٔ OpenAI و GitHub از منابع اولیهٔ بالا گرفته شده‌اند. این منابع تضمین نمی‌کنند که سناریوپردازی یا Agent در هر پروژه forecast دقیق‌تری تولید کند. تفکیک plan، forecast و commitment، سه‌سناریوی سریع/محتمل/محدودشده، critical path socio-technical، ماتریس trigger و چارچوب pilot، تحلیل امین رضا سیدآبادی است و باید با context و دادهٔ واقعی همان تیم بازبینی شود.

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