Pre-Mortem پروژه چیست؟ شکست را قبل از وقوع شبیه‌سازی کنید

بیشتر تیم‌ها فقط وقتی شکست را می‌بینند که دیر شده است: بودجه تمام شده، ددلاین رد شده و مشتری ناراضی است. در آن لحظه تحلیل «چه اشتباهی کردیم؟» فقط درس گرفتن از گذشته را ممکن می‌کند، نه نجات پروژه. اما تکنیکی وجود دارد که همین تحلیل را قبل از شروع پروژه اجرا می‌کند: Pre-Mortem پروژه.

در این مقاله می‌بینید Pre-Mortem دقیقاً چیست، چه تفاوتی با جلسهٔ ریسک‌سنجی معمولی و Post-Mortem دارد، چطور آن را گام‌به‌گام اجرا کنید، چه خروجی مشخصی باید بدهد و در چه شرایطی به آن نیاز ندارید. هدف این است که بعد از خواندن، بتوانید یک جلسهٔ Pre-Mortem واقعی را در تیم خود برگزار کنید و از دل آن، فهرست اقدامات پیشگیرانه بیرون بیاورید.

Pre-Mortem پروژه چیست؟ (پاسخ سریع)

Pre-Mortem پروژه تکنیکی مدیریتی است که در آن تیم، پیش از شروع یا در میانهٔ پروژه، فرض می‌کند پروژه شکست خورده و سپس علت‌های احتمالی آن شکست را فهرست می‌کند. معادل فارسی نزدیک به آن «پیش‌مرگ‌نگاری» یا «پیش‌کالبدشکافی» است. این روش بر پایهٔ «پس‌نگری پیش‌نگر» (prospective hindsight) کار می‌کند؛ یعنی مغز وقتی رویدادی را «اتفاق‌افتاده» فرض کند، راحت‌تر دلایلش را پیدا می‌کند تا وقتی از او بپرسند «چه چیزی ممکن است اتفاق بیفتد؟».

چرا Pre-Mortem با جلسهٔ ریسک‌سنجی معمولی فرق دارد؟

جلسهٔ ریسک معمولی یک مشکل قدیمی دارد: کسی نمی‌خواهد نقش «خبر بد» را بازی کند. وقتی از تیم می‌پرسیم «چه ریسک‌هایی می‌بینید؟»، معمولاً جواب‌ها کوتاه، عمومی و محافظه‌کارانه‌اند. خوش‌بینی گروهی و فشار جمعی باعث می‌شود ریسک‌ها روی کاغذ بیایند ولی در واقعیت باور نشوند.

Pre-Mortem این قید را برمی‌دارد. وقتی می‌گوییم «پروژه شکست خورد، چرا؟»، دیگر لازم نیست کسی نگران «بدبین به‌نظر رسیدن» باشد؛ چون شکست بخشی از فرضیه است، نه پیش‌بینی. تفاوت‌ها را در جدول زیر ببینید:

نکتهٔ کلیدی: Pre-Mortem جای ثبت ریسک را نمی‌گیرد؛ آن را با سناریوهای عینی و انسانی‌تر تغذیه می‌کند.

Pre-Mortem پروژه چگونه کار می‌کند؟ گام‌به‌گام

اجرای درست Pre-Mortem یک ساعت تا ۹۰ دقیقه زمان می‌برد و به یک تسهیل‌کننده نیاز دارد. مراحل به این ترتیب است:

1. چارچوب را روشن کنید: دامنه دقیق پروژه یا فاز، هدف نهایی، ددلاین و معیار موفقیت را روی تخته بنویسید. اگر «موفقیت» تعریف نشده باشد، «شکست» هم معنا ندارد.
2. شکست را قطعی اعلام کنید: جملهٔ اصلی جلسه این است: «فرض کنید یک سال از امروز گذشته و این پروژه کاملاً شکست خورده است.» همه باید این فرض را بپذیرند.
3. نوشتن خاموش (Silent Brainwriting): هر عضو چند دقیقه بی‌صدا دلایل شکست را می‌نویسد. این کار از چسبیدن به نظرات افراد پرنفوذ جلوگیری می‌کند.
4. اشتراک و خوشه‌بندی: دلایل جمع می‌شوند و در دسته‌های مشترک مثل «مردم»، «فرایند»، «فناوری»، «بودجه و زمان»، «عوامل بیرونی» گروه‌بندی می‌شوند.
5. رأی‌گیری اهمیت: هر نفر چند رأی به خطرناک‌ترین دلایل می‌دهد. قرار نیست همهٔ دلایل دنبال شوند؛ فقط آن‌هایی که بیشترین احتمال و شدت را دارند.
6. تبدیل به اقدام: برای هر دلیل برتر، یک اقدام پیشگیرانه یا کاهش‌دهنده با مسئول و ددلاین تعریف کنید.
7. ثبت و پایش: خروجی در همان ابزاری ثبت شود که کار پروژه در آن مدیریت می‌شود؛ در غیر این صورت فراموش می‌شود.

چه کسانی باید در جلسه باشند؟

نه همهٔ ذی‌نفعان و نه فقط مدیران. ترکیب مؤثر حدود ۵ تا ۹ نفر است و باید این نقش‌ها را پوشش دهد: مالک محصول یا کارفرما، مجری فنی، کسی که با مشتری در تماس است، و در صورت امکان یک نفر از بیرون تیم که پروژه را نمی‌شناسد. حضور «نفر تازه‌وارد» طلایی است، چون او سؤال‌هایی می‌پرسد که تیم دیگر نمی‌بیند.

چه خروجی دقیقی باید داشته باشد؟

خروجی یک جلسهٔ درست، یک متن پرحجم نیست؛ یک فهرست کوتاه و عملیاتی است. برای هر سناریوی شکست برتر باید مشخص شود: علت، علائم هشدار زودهنگام، اقدام پیشگیرانه، مالک اقدام و ددلاین بازبینی. اگر خروجی این پنج قلم را ندارد، جلسه ناقص مانده است.

مثال‌های واقعی و عددی از Pre-Mortem

• پروژهٔ مهاجرت نرم‌افزار، تیم ۱۴ نفره: در Pre-Mortem تیم فرض کرد مهاجرت شکست خورده. یکی از دلایل برتر «وابستگی به یک مهندس خاص که فقط او سیستم قدیم را می‌شناسد» بود. اقدام پیشگیرانه: مستندسازی و آموزش دو نفر جانشین. اگر این ریسک پیش از شروع دیده نمی‌شد، احتمال توقف پروژه در صورت غیبت آن فرد بالای ۲ هفته بود.
• پروژهٔ بازاریابی محصول جدید، تیم ۶ نفره: جلسه دو ساعت طول کشید و ۲۳ دلیل شکست تولید شد که پس از رأی‌گیری به ۵ دلیل برتر رسید. سه اقدام از این پنج مورد در همان هفتهٔ اول اجرا شد. مهم‌ترین یافته این بود که «پیام محصول برای سه بخش مشتری متفاوت، ضد و نقیض است» — موضوعی که در جلسات ریسک قبلی هرگز مطرح نشده بود.
• پروژهٔ ساخت یک شعبهٔ فروشگاه: Pre-Mortem نشان داد تأخیر مجوز شهرداری می‌تواند کل افتتاحیه را ۶ هفته عقب بیندازد. تیم پیش از عقد قرارداد اجاره، یک بند تمدید و یک برنامهٔ افتتاح موقت در فضای جایگزین را آماده کرد. این یک اقدام، احتمال از دست دادن فصل فروش را به‌شکل محسوسی کاهش داد.
• تیم نرم‌افزاری ۹ نفره با اسپرینت‌های دو هفته‌ای: Pre-Mortem برای هر اسپرینت، ۱۵ دقیقه اجرا می‌شد. نتیجه این بود که «تسک‌های مبهم بدون معیار پذیرش» به‌عنوان پرتکرارترین دلیل شکست اسپرینت شناسایی شد و از هفته سوم، هر تسک یک تعریف «انجام‌شده» گرفت.

چه زمانی Pre-Mortem جواب می‌دهد و چه زمانی نه؟

Pre-Mortem برای پروژه‌های با عدم‌قطعیت بالا، وابستگی بین تیم‌ها، ددلاین سخت یا پیامد شکست سنگین بیشترین ارزش را دارد. در مقابل، برای کارهای کوچک، تکراری و کم‌ریسک، برگزاری آن فقط هزینهٔ زمانی است.

نشانه‌های اینکه به Pre-Mortem نیاز دارید

• پروژه جدید است و تیم تجربهٔ قبلی مشابه ندارد.
• چند تیم یا سازمان درگیرند و هماهنگی سخت است.
• ددلاین بیرونی و برگشت‌ناپذیر دارید (رونمایی، قرارداد، رویداد).
• در گذشته پروژه‌های مشابه شکست خورده‌اند ولی علت دقیقش روشن نیست.
• جلسات ریسک شما هر بار به همان چند ریسک کلیشه‌ای می‌رسد.

نشانه‌های اینکه نیاز ندارید

• کار تکراری با مسیر شناخته‌شده (مثل انتشار محتوای روتین).
• پروژهٔ بسیار کوچک با پیامد شکست ناچیز.
• تیم در بحران فوری است و باید همین حالا تصمیم اجرایی بگیرد؛ در آن لحظه بازبینی کوتاه کافی است.

چطور خروجی Pre-Mortem را به برنامهٔ پایش تبدیل کنیم؟

جلسهٔ Pre-Mortem بدون برنامهٔ پایش، به‌سرعت فراموش می‌شود. برای ماندگارکردن آن، هر دلیل شکست برتر را به یک «کارت پایش» تبدیل کنید که پنج قلم دارد: شاخص قابل‌مشاهده، آستانهٔ هشدار، اقدام پیشگیرانه، مسئول و ددلاین بازبینی. سپس این کارت‌ها را در جریان کار هفتگی تیم بگنجانید، نه در یک فایل جداگانه.

برای اینکه این برنامه زنده بماند، در هر جلسهٔ هفتگی فقط کارت‌هایی را مرور کنید که شاخصشان از آستانه گذشته است. این کار هم وقت کمی می‌گیرد و هم باعث می‌شود Pre-Mortem از یک رویداد یک‌باره به یک مکانیزم دائمی تبدیل شود. همچنین در پایان هر فاز، درصد تحقق اقدامات را بسنجید؛ اگر اقدامی چند دوره اجرا نشده باشد، یا مالک ندارد یا اولویتش واقعی نبوده است.

مزایا، معایب و Trade-off

Trade-off اصلی: Pre-Mortem سرعت شروع را کمی کم می‌کند تا احتمال شکست را کاهش دهد. سرمایه‌گذاری روی آن وقتی منطقی است که هزینهٔ شکست از هزینهٔ یک جلسه بسیار بیشتر باشد. برای پروژه‌ای که شکست آن چند ساعت عقب‌افتادن است، این معاوضه به‌صرفه نیست.

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

1. اجرای تشریفاتی: برگزاری جلسه فقط برای تیک‌زدن «مدیریت ریسک» بدون پیگیری خروجی.
2. تعریف مبهم شکست: اگر معیار موفقیت روشن نباشد، «شکست» هم مبهم می‌شود و جلسه به گلایهٔ عمومی می‌رسد.
3. غفلت از عوامل انسانی: تمرکز فقط روی فناوری و بودجه و نادیده‌گرفتن تنش‌های تیمی، تغییر مدیر یا بیانگیزگی.
4. فهرست بی‌اولویت: تلاش برای حل هر ۳۰ دلیل شکست، تیم را فلج می‌کند.
5. نبود مسئول برای اقدام: اقدام بدون مالک، فقط یک آرزو است.
6. یک‌بار‌وهمیشه: Pre-Mortem فقط در شروع کافی نیست؛ در نقاط عطف باید تکرار شود.
7. تبدیل به جلسهٔ سرزنش: اگر به گذشتهٔ افراد اشاره کند، اعتماد از بین می‌رود.

نکات کاربردی

• نکته مهم: جملهٔ جلسه را حتماً با فعل گذشته بگویید: «پروژه شکست خورد»، نه «ممکن است شکست بخورد».
• ترفند کاربردی: یک «نفر بیرونی» دعوت کنید؛ او سؤال‌هایی می‌پرسد که تیم آن‌ها را بدیهی فرض کرده است.
• اشتباه رایج: جمع نکردن دلایل به‌صورت خاموش؛ در بحث آزاد، صدای بلندترین فرد برنده می‌شود.
• قبل از شروع این را بدانید: خروجی Pre-Mortem باید به تسک واقعی در ابزار کاری تیم تبدیل شود، وگرنه در فایل جلسه خاک می‌خورد.
• معیار سنجش: بعد از ۳۰ روز بررسی کنید چند درصد اقدامات پیشگیرانه واقعاً اجرا و اثرشان دیده شده است.

تفاوت Pre-Mortem با Post-Mortem و فهرست ریسک

• Post-Mortem (پس‌کالبدشکافی): بعد از پایان پروژه برگزار می‌شود و به دنبال درس گرفتن از رویدادهای واقعی است.
• فهرست ریسک (Risk Register): سندی زنده که ریسک‌ها، احتمال، شدت و پاسخ‌ها را ثبت می‌کند.
• Pre-Mortem پروژه: جلسهٔ خلاقانه و فرض‌محور پیش از وقوع که فهرست ریسک را با سناریوهای انسانی و پنهان غنی می‌کند.

به‌عبارت ساده: فهرست ریسک «چه چیزی؟» را می‌پرسد، Pre-Mortem «چرا شکست خورد؟» را، و Post-Mortem «چه شد؟» را.

دوایتفای و Pre-Mortem پروژه

ارزش Pre-Mortem وقتی ماندگار می‌شود که خروجی آن در همان محیطی ثبت شود که کار پروژه در آن جریان دارد. دوایتفای یک پلتفرم جامع مدیریت پروژه، مدیریت تیم و رسیدن به اهداف است و همین بستر را یکپارچه فراهم می‌کند. در دوایتفای می‌توان هر سناریوی شکست را به یک ریسک ثبت‌شده، یک تسک پیشگیرانهٔ دارای مسئول و ددلاین، و یک شاخص قابل‌پایش تبدیل کرد؛ همچنین بخش ریسک‌ها و محدودیت‌ها، وابستگی‌های WBS، گانت‌چارت و Workload تیم به شما نشان می‌دهد کدام اقدام کجا می‌تواند گلوگاه شود. Doitify Copilot و AI Coach هم می‌توانند در آماده‌سازی چارچوب جلسه، جمع‌بندی دلایل شکست و تبدیل آن‌ها به تسک‌های پیشگیرانه کمک کنند. دوایتفای محصول ماست و به همین دلیل امکاناتش را از نزدیک می‌شناسیم؛ با این حال برای تیم‌های کوچک با پروژه‌های ساده، حتی یک تختهٔ ساده و یک فهرست تسک هم می‌تواند Pre-Mortem را عملی کند.

جمع‌بندی

Pre-Mortem پروژه یک تغییر کوچک در جمله‌بندی با اثر بزرگ است: به‌جای پرسیدن «چه ممکن است اشتباه شود؟»، می‌گوییم «پروژه شکست خورد؛ چرا؟». این تکنیک ریسک‌های پنهان و انسانی را بیرون می‌کشد و از دل آن، اقدامات پیشگیرانهٔ دارای مسئول می‌سازد. برای اجرای درست، دامنه و معیار موفقیت را روشن کنید، جلسه را خاموش و فرض‌محور اداره کنید، دلایل را اولویت‌بندی کنید و خروجی را به تسک واقعی در ابزار کار تیم تبدیل کنید. ساده‌ترین راه برای مطمئن‌شدن از اینکه Pre-Mortem فقط یک گفت‌وگوی خوب نبوده، این است که بعد از یک ماه بررسی کنید کدام اقدام پیشگیرانه اجرا شده و اثرش در وضعیت واقعی پروژه دیده می‌شود.

اگر موضوع Pre-Mortem پروژه برایتان مفید بود، پیشنهاد می‌کنیم نرم افزار مدیریت منابع پروژه؛ تخصیص منابع و ظرفیت تیم و بهترین جایگزین Todoist برای مدیریت تسک و هدف را هم بخوانید.