پرش به مطلب اصلی

جلسه جای شروع فکر کردن نیست

· ۱ دقیقه مطالعه
مهدی مالوردی
مهندس نرم‌افزار و نویسندهٔ این سایت

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

اما وقتی از جلسه بیرون می‌آیی، هنوز دقیق نمی‌دانی تصمیم چه شد، چه چیزی قرار است عوض شود، چه کسی مالک جلو بردن آن است و کی دوباره بررسی می‌کنیم که بهتر شده یا نه.

به نظرم مشکل این نیست که حرف‌ها غلط بوده‌اند. مشکل این است که نقدها قبل از جلسه به مسئله‌ی قابل حل تبدیل نشده‌اند. وقتی مسئله صورت‌بندی نشده باشد، جلسه خیلی زود تبدیل می‌شود به جایی برای گفتن حس‌ها و نارضایتی‌ها؛ نه جایی برای ساختن تصمیم.

حرف اصلی

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

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

وقتی رترو تبدیل به نق زدن می‌شود

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

مشکل از جایی شروع می‌شود که رترو فقط ظرف گفتن نارضایتی می‌شود. هرکس چیزی می‌گوید که آزارش داده، چند نفر هم تأیید یا مخالفت می‌کنند، اما آخرش روشن نمی‌شود مسئله دقیقاً چیست، از کجا فهمیده‌ایم، اثرش چقدر جدی است و چه چیزی باید تغییر کند.

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

نقطه خطر

رترو وقتی بی‌اثر می‌شود که نقد را جمع می‌کند، اما آن را به تصمیم و اقدام قابل پیگیری تبدیل نمی‌کند.

این فقط مشکل رترو نیست

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

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

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

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

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

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

اول بنویسیم، بعد ریویو کنیم، بعد جلسه بگذاریم

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

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

یک قالب ساده می‌تواند این باشد:

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

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

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

چرخه پیشنهادی: نوشتن مسئله، ریویوی تیمی، جلسه تصمیم، مالک اقدام و پیگیری

اصل پیشنهادی

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

خروجی جلسه باید صاحب و سنجه داشته باشد

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

بعد از هر بحث مهم باید روشن باشد:

  • چه چیزی قرار است تغییر کند؟
  • چه کسی مالک جلو بردن تغییر است؟
  • تا کی باید انجام شود؟
  • کی دوباره بررسی می‌کنیم؟
  • با چه سنجه‌ای می‌فهمیم بهتر شده؟

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

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

مالک اقدام، نه مسئول مشکل

هدف این نیست که برای مشکل مقصر پیدا کنیم. مالک اقدام یعنی کسی که کمک می‌کند تغییر گم نشود؛ نه کسی که تقصیر مشکل به گردنش افتاده باشد.

پس جلسه کی لازم است؟

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

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

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

معیار ساده

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

جلسه وقتی ارزشمندتر می‌شود که آدم‌ها با ذهن آماده واردش شوند؛ نه با این انتظار که همان‌جا تازه مسئله را پیدا کنند.

جمع‌بندی

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

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

برای همین پیشنهاد من ساده است:

اول مسئله را بنویسیم، بعد ریویو کنیم، بعد اگر هنوز لازم بود جلسه بگذاریم.

جلسه جای شروع فکر کردن نیست؛ جای تصمیم گرفتن بعد از فکر کردن است.