تمرین تیم‌سازی در چارچوب Scrum

جادوی کاهش ریسک بدون مقصر جلوه‌دادن افراد – وقتی رهبری جلوی «پری‌مورتِم یا Pre-Mortem» شما را می‌گیرد

این مقاله در سازمان اسکرام توسط استفان وولپرس در (آلمان) در تاریخ ۲۳ نوامبر ۲۰۲۵ منتشر شده است.

خلاصه: «پری‌مورتِم» یا بازنگری پسنگرانه

مقاومت رهبری در برابر برگزاری یک «پری‌مورتِم» نشان می‌دهد مدل عملیاتی سازمان شما آیا واقعاً پیشگیری از شکست را جدی می‌گیرد یا فقط روایت‌های آرامش‌بخش را ترجیح می‌دهد. این مقاله به شما نشان می‌دهد چطور این اختلال فرهنگی را تشخیص دهید و بفهمید کدام نبردها ارزش جنگیدن دارند.


جادوی کاهش ریسک بدون مقصر جلوه‌دادن افراد

یک تکنیک مدیریت ریسک وجود دارد که فقط ۶۰ دقیقه زمان می‌برد، هیچ هزینه‌ای ندارد و مسائلی را آشکار می‌کند که روش‌های برنامه‌ریزی دیگر از قلم می‌اندازند. این تکنیک نزدیک به دو دهه در میدان عمل امتحان شده است. تیم‌هایی که از آن استفاده می‌کنند، مشکلات فاجعه‌آمیز را وقتی هنوز برای اقدام کردن وقت هست شناسایی می‌کنند.

بیشتر سازمان‌ها هرگز از این تکنیک استفاده نمی‌کنند. وقتی تلاش می‌کنید آن را معرفی کنید، همان کسانی که بلندترین ناله‌ها را درباره شکست پروژه‌ها سر می‌دهند، اغلب همان‌هایی هستند که در جلسه آن را خفه می‌کنند. این تکنیک «پری‌مورتِم» است، و مقاومتی که در برابرش می‌بینید درباره سازمان شما بیش از هر «ریسک رجیستر»‌ای (ثبت ریسک‌ها) به شما اطلاعات می‌دهد.


اصول پایه (اگر تا حالا پری‌مورتِم اجرا نکرده‌اید)

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

این جابه‌جایی از «ممکن است شکست بخورد» به «شکست خورده است» چیزی را باز می‌کند. آدم‌ها دست از تعارف برمی‌دارند. ریسک‌هایی که قبلاً به‌خاطر ملاحظات سیاسی (فضای دارای تضاد منافع) از گفتنشان در جلسات برنامه‌ریزی معمولی خودداری می‌کردند، ناگهان وارد اتاق می‌شوند: بدهی فنی‌ای که همه از آن خبر دارند اما کسی نمی‌خواهد مطرحش کند، ذینفعی که در ماه چهارم این کار را به‌کلی به باد خواهد داد، و آن فرض کلیدی که کل برنامه روی آن سوار است اما هنوز هیچ‌کس واقعاً آن را صحه‌گذاری نکرده است.

تکنیک پری‌مورتِم ساده است: در یک جلسه ۶۰ دقیقه‌ای، ابتدا هر کس فهرست خودش از دلایل شکست را می‌نویسد. بعد، آن‌ها را خوشه‌بندی می‌کنید، روی موارد بحرانی رأی می‌دهید و سپس عمیق‌تر می‌روید:

  • آن شکست دقیقاً چه شکلی دارد؟
  • چه علائم هشدار اولیه‌ای خواهیم دید؟
  • این هفته چه کاری می‌توانیم بکنیم تا جلویش را بگیریم؟ و برنامه پشتیبان چیست؟

از جلسه بیرون می‌آیید با یک درک مشترک از اینکه چه چیز می‌تواند این ابتکار عمل را بکشد و اقدام‌های مشخصی که می‌توانید فوراً انجام دهید. نه یک سند برای بایگانی. یک بینش واقعی.
نکته من: «ساختارهای رهایی‌بخش» (Liberating Structures) در این فضا خیلی خوب جواب می‌دهند؛ مثلاً به TRIZ فکر کنید.

اعتراض‌های سطح رهبری به پری‌مورتِم

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

سه اعتراض اصلی این‌ها هستند:

۱. «ما برای یک ورکشاپ دیگر وقت نداریم»

وقتی این جمله را می‌شنوید، دارید مشکل زمان‌بندی نمی‌شنوید؛ دارید یک اعتراف می‌شنوید.

آن‌چه می‌گویند: تقویم‌ها پر است، تحت فشار تحویل هستیم، و یک ساعت وقت گذاشتن برای تصور شکست، یعنی یک ساعت کمتر برای «ساختن».

آن‌چه در واقع اعتراف می‌کنند: برنامه‌ریزی در این سازمان یک تئاتر است. ما نمی‌توانیم تفاوت بین «مشغول به نظر رسیدن» و «اثربخش بودن» را تشخیص دهیم. برای جلسات رودمپ و استراتژی آف‌سایت که جز اسلاید دِک خروجی دیگری ندارند وقت داریم، اما برای ۶۰ دقیقه‌ای که ممکن است واقعاً جلوی شکست را بگیرد نه.

از خودتان بپرسید: اگر نمی‌توانید ۶۰ دقیقه برای تست‌فشار (pressure test) یک ابتکار مهم قبل از تخصیص منابع صرف کنید، پس در تمام آن جلسات دیگر چه می‌کنید؟ اگر نمی‌توانید یک ساعت برای فکر کردن کنار بگذارید، در واقع برنامه‌ریزی نمی‌کنید؛ دارید «تئاتر برنامه‌ریزی» را برای یک تماشاگر اجرا می‌کنید.

شما همیشه برای چیزی که واقعاً برایتان ارزش دارد وقت پیدا می‌کنید. این اعتراض نشان می‌دهد سازمان «ظاهر پیشرفت» را بیش از «ماهیت پیشرفت» ارزش‌گذاری می‌کند.

۲. «این خیلی منفی است، تیم را دلسرد می‌کند»

این یکی محبوب من است، چون خالص‌ترین نوع «تفکر جادویی» است که در لباس «حکمت رهبری» ظاهر شده.

آن‌چه می‌گویند: باید اعتمادبه‌نفس را القا کنیم. تمرکز روی شکست، آن را خودمحقق‌کننده می‌کند. تیم‌ها به انرژی مثبت نیاز دارند.

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

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

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

باانگیزه‌ترین تیم‌هایی که دیده‌ام، آن‌هایی هستند که دقیقاً می‌دانند با چه چیزی طرف‌اند و برای مواجهه با آن برنامه دارند. و اگر آن برنامه جواب نداد، می‌توانند سریع به برنامه دیگری محور (pivot) کنند. اعتمادبه‌نفسی که پس از برخورد با واقعیت دوام می‌آورد، ابتدا نیاز دارد با واقعیت روبه‌رو شود.


۳. «ما همین حالا هم ریسک را مدیریت می‌کنیم»

این اعتراض افشاگرترین مورد است؛ چون یک خطای طبقه‌بندی (category error) در تفکر سازمان را برملا می‌کند.

آن‌چه می‌گویند: PMO (دفتر مدیریت پروژه) ریسک رجیسترها را نگه می‌دارد. ما فرایندهای حاکمیتی داریم. بازبینی پروژه انجام می‌شود. بنابراین، پری‌مورتِم کار تکراری به نظر می‌رسد.

آن‌چه از قلم می‌اندازند: آن‌ها «مُحَمل» (آرتیفکت) را با «فعالیت» اشتباه گرفته‌اند. داشتن یک ریسک رجیستر با داشتن «آگاهی از ریسک» یکسان نیست. این تفاوت بین «داشتن یک کپسول آتش‌نشانی» و «فهمیدن چگونگی شروع شدن آتش» است.

به ریسک رجیسترهای سازمان خود نگاه کنید. اغلب همان پنج مورد را روی همه پروژه‌ها می‌بینید: «گسترش دامنه» (scope creep)، «محدودیت منابع»، «هم‌راستایی ذی‌نفعان»، «پیچیدگی فنی» و «فشار زمان‌بندی». اشتباه نیستند، اما بی‌فایده‌اند: آن‌قدر کلی که نتوان بر اساس‌شان اقدام کرد، آن‌قدر بدیهی که بینش جدیدی نمی‌دهند، و آن‌قدر انتزاعی که جلوی هیچ چیز را واقعاً نمی‌گیرند.

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

جمع‌بندی — از رد شدن پری‌مورتِم چه می‌آموزید؟

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

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

هیچ روش تسهیلگری نمی‌تواند این را درست کند. اگر رهبری نمی‌تواند ۶۰ دقیقه برای تفکر انتقادی کنار بگذارد، یا باور دارد نام بردن از مشکلات باعث خلق آن‌ها می‌شود، یا فکر می‌کند مستندسازی معادل فهمیدن است، شما با یک اختلال فرهنگی روبه‌رو هستید که ریشه‌اش بسیار عمیق‌تر از پروفایل ریسک ابتکار عمل شماست.

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

گاهی ارزشمندترین چیزی که یک پری‌مورتِم به شما نشان می‌دهد این است که هیچ‌کس در موقعیت تصمیم‌گیری واقعاً نمی‌خواهد بداند چرا یک پروژه ممکن است شکست بخورد.

🗞 دوست دارید درباره مقاله‌هایی مثل این به شما خبر بدهم؟ عالی! می‌توانید اینجا برای خبرنامه «Food for Agile Thought» ثبت‌نام کنید و به بیش از ۴۰٬۰۰۰ مشترک بپیوندید.


منتورینگ رایگان مالکین محصول

«اگر در یک شرکت نرم‌افزاری مشغول به کارهای روزانه یک PO هستید و دوست دارید در مورد پیاده‌سازی اجایل، اسکرام و چالش‌های نقش PO در چهارچوب اسکرام یا تفکر استراتژیک در محصول، راهنمایی و مشاوره بگیرید، در خدمتتون هستم. یک وقت در adplist بگیرید.»


دیدگاه‌ها

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

error: اجازه کپی محتوا وجود ندارد