جلسه رتروسپکتیو چیست؟ راهنمای کامل مرور دوره‌ای تیم

رتروسپکتیو (Retrospective) جلسه‌ی مرور پایان هر دوره‌ی کاری است — هر اسپرینت، هر ماه، هر فصل — با سه پرسش ساده: چه چیزی خوب پیش رفت و ادامه پیدا کند؟ چه چیزی خوب نبود و متوقف شود؟ و دوره‌ی بعد دقیقاً چه چیزی را متفاوت انجام می‌دهیم؟ پشتوانه‌اش جدی است: متاآنالیز تننبام و چرازولی (۲۰۱۳، مجله Human Factors) نشان داد مرورهای ساختاریافته، عملکرد تیم و فرد را به‌طور میانگین حدود ۲۰ تا ۲۵ درصد بهتر می‌کنند.

اگر تیمت ماه‌هاست با همان روش همیشگی کار می‌کند و همان اصطکاک‌های همیشگی — جلسه‌های کش‌دار، دوباره‌کاری، سوءتفاهم بین فروش و اجرا — هر دوره عیناً تکرار می‌شوند، این مقاله برای توست.

رتروسپکتیو دقیقاً چیست و با جلسه مرور پروژه چه فرقی دارد؟

تفاوت اصلی در موضوع جلسه است: رتروسپکتیو درباره‌ی «روش کار کردنِ» تیم است، نه درباره‌ی یک پروژه یا اتفاق خاص. جلسه‌ی مرور یک لانچ می‌پرسد «آن لانچ چطور پیش رفت؟» (این کارِ AAR است)؛ رتروسپکتیو می‌پرسد «ما به‌عنوان تیم، این دوره چطور کار کردیم — و کجای روشمان را عوض کنیم؟»

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

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

رتروسپکتیو از کجا آمد؟

واژه و سنت مدرنش از مهندسی نرم‌افزار می‌آید. نورم کرث، مشاور نرم‌افزار، در کتاب «رتروسپکتیوهای پروژه» (۲۰۰۱) این جلسه را رسمی کرد و «دستور اولیه‌ی» معروفش را نوشت — قاعده‌ای که هنوز اول بسیاری از رتروها خوانده می‌شود و مضمونش این است: می‌پذیریم که همه، با دانسته‌ها و امکانات همان لحظه، بهترین کاری را که می‌توانستند کرده‌اند. این جمله تعارف نیست؛ همان شرطی است که باعث می‌شود آدم‌ها واقعیت را بگویند نه دفاعیه.

همان سال ۲۰۰۱، مانیفست توسعه‌ی چابک منتشر شد و اصل دوازدهمش دقیقاً همین جلسه بود: تیم در فواصل منظم درباره‌ی مؤثرتر شدنش تأمل می‌کند و رفتارش را تنظیم می‌کند. اسکرام — پرکاربردترین چارچوب چابک — رترو را به رویداد رسمی پایان هر اسپرینت تبدیل کرد؛ راهنمای رسمی اسکرام برای اسپرینت یک‌ماهه حداکثر سه ساعت برایش وقت می‌گذارد و برای اسپرینت‌های کوتاه‌تر، کمتر.

کتاب دربی و لارسن، «رتروسپکتیوهای چابک» (۲۰۰۶)، ساختار پنج‌مرحله‌ای استانداردش را جا انداخت: زمینه‌سازی، جمع‌آوری داده، استخراج بینش، تصمیم، جمع‌بندی. و شواهد کمّی هم رسید: همان متاآنالیز ۲۰۱۳ که در مقاله‌ی AAR مفصل آورده‌ایم، نشان داد اثر مثبت مالِ مرورهای «ساختاریافته» است — دورهمی گلایه، این اثر را ندارد.

چهار گام رتروسپکتیو — با یک مثال واقعی

فرض کن تیم پنج‌نفره‌ای داری که اپ سفارش آنلاین می‌سازد و هر دو هفته رترو می‌گیرید. جلسه این‌طور پیش می‌رود:

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

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

۳. چه چیزی را باید شروع کنیم؟ پیشنهادها جمع می‌شوند، بی‌قضاوت: کدریویوی اجباری؟ جلسه‌ی کوتاه هم‌ترازی قبل از شروع هر فیچر؟ چک‌لیست تست قبل از ریلیز؟

۴. یک تغییر مشخص برای دوره‌ی بعد — با مسئول و معیار. از فهرست، فقط یکی (حداکثر دو) انتخاب می‌شود: «هر تغییر قبل از ریلیز، یک بازبین دوم می‌گیرد؛ مسئول استقرار: سارا؛ معیار موفقیت: باگ برگشتی دوره‌ی بعد، نصف.» انتخابِ یک تغییر، ضعف نیست؛ راز اجراست — تیمی که هر رترو پنج قانون جدید می‌گذارد، عملاً هیچ‌کدام را اجرا نمی‌کند.

فرمت‌های محبوب رترو — کدام برای کی؟

ساختار چهارگامی بالا اسکلت است؛ روی همین اسکلت، فرمت‌های متنوعی ساخته‌اند که سوال‌ها را تازه نگه می‌دارند:

فرمت را عوض کن، اسکلت را نه: هر چهار فرمت باید به همان گام آخر برسند — یک تغییر مشخص، یک مسئول، یک معیار. رترویی که با «گفتگوی خوبی بود» تمام شود، جلسه نبوده؛ درمانگری گروهی بوده.

ضدالگوها: چه چیزی رترو را می‌کشد؟

• رتروی بی‌خروجی. جلسه حرف خوب زیاد دارد ولی هیچ تغییری ثبت نمی‌شود — بعد از سه دوره، همه می‌فهمند این جلسه «واقعی» نیست و سکوت می‌کنند.
• تغییرِ دوره‌ی قبل مرور نمی‌شود. اولین آیتم هر رترو باید سرنوشت تغییر رتروی قبل باشد؛ وگرنه تعهدها بی‌هزینه می‌شوند.
• تبدیل شدن به جلسه‌ی گلایه از بیرون. «مشتری‌ها بد قول می‌دهند» شاید درست باشد، ولی رترو درباره‌ی چیزی است که در کنترل تیم است: «در قرارداد، بند تغییر دامنه اضافه کنیم» خروجی است؛ غر زدن نه.
• حضور کسی که آدم‌ها جلویش حرف نمی‌زنند. اگر حضور مدیرعامل باعث سکوت می‌شود، یا فرهنگ باید درست شود یا ترکیب جلسه — یافته‌ی ادموندسون درباره‌ی امنیت روانی همین‌جا هم صادق است.
• رتروی قحطی‌زده. وقتی «وقت نیست»، اولین قربانی رتروست — و دقیقاً تیمی که وقت ندارد، بیشترین نشتی فرآیندی را دارد. جلسه‌ی کوتاهِ برگزارشده از جلسه‌ی کاملِ لغوشده باارزش‌تر است.

جلسه رتروسپکتیو در ریبین چطور اجرا می‌شود؟

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

تفاوتش با اجرای دستی، سه چیز است:

1. منتور جلسه را به خروجی می‌رساند — نمی‌گذارد جلسه در گام گلایه‌ها تمام شود و تا «یک تغییر مشخص با معیار» نرسیده، جمع‌بندی نمی‌کند. چون کسب‌وکارت را می‌شناسد (پروفایل، اسناد، جلسات قبلی)، الگوهای تکرارشونده‌ی دوره‌های قبل را هم جلویت می‌گذارد.
2. خروجی خودکار ثبت می‌شود — خلاصه، درس‌آموخته‌ها و تغییر انتخاب‌شده به شکل حداکثر ۵ تعهد زمان‌دار ذخیره می‌شوند و به حافظه‌ی جلسات بعدی می‌روند.
3. رتروی بعدی از همین‌جا شروع می‌شود — چک‌این هفتگی اجرای تغییر را در طول دوره پیگیری می‌کند و رتروی بعد، اول از همه سرنوشت همان تغییر را می‌پرسد؛ درمان همان ضدالگوی دوم.

یک جلسه‌ی کامل رتروسپکتیو در ریبین معمولاً ۱۵ تا ۲۵ دقیقه طول می‌کشد و در پلن رایگان — بدون کارت بانکی — قابل اجراست.