راهنمای جامع همکاری در تیم نرم‌افزاری: جلسهٔ کمتر، شفافیت بیشتر

الگویی که در تیم‌های نرم‌افزاری بارها دیده‌ام این است: تقویم‌ها پر از جلسه است و با این حال هر روز کسی می‌پرسد «این کار دست کیست؟» یا «آخرش قرار شد کدام طرح را پیاده کنیم؟». جلسه کم نیست؛ مشکل این است که آنچه در جلسه گفته می‌شود جایی نوشته نمی‌شود، و هر جلسهٔ تازه برای جبران نبودِ همان نوشته برگزار می‌شود.

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

ریشهٔ مشکل: اطلاعاتی که فقط در ذهن آدم‌ها و پیام‌رسان است

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

نشانه‌هایش آشناست:

• پرسش‌های تکراری. «این باگ درست شد؟» «نسخه کی می‌رود؟» هر کدام چند بار در هفته، از آدم‌های مختلف.
• تصمیم‌هایی که دوباره باز می‌شوند. چون کسی نمی‌داند قبلاً چه بحثی شده و چرا آن نتیجه گرفته شد.
• وابستگی به یک نفر. اگر فلانی نباشد، هیچ‌کس نمی‌داند وضعیت پروژه چیست. در ادبیات نرم‌افزار به این «عامل اتوبوس» (Bus Factor) می‌گویند: چند نفر از تیم باید غیبت کنند تا کار متوقف شود.
• جلسه‌های گزارش وضعیت. که تنها هدف‌شان این است که هر کس بگوید روی چه کاری است، چون این اطلاعات جای دیگری پیدا نمی‌شود.

هیچ‌کدام از این‌ها با «ارتباط بیشتر» حل نمی‌شود. با ارتباطی حل می‌شود که جای ثابتی دارد.

یک منبع حقیقت برای وضعیت کار

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

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

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

ناهمگام به‌عنوان پیش‌فرض، هم‌زمان برای استثنا

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

دو نمونهٔ مستند و در دسترس از این رویکرد، راهنمای ارتباطات داخلی شرکت 37signals (سازندهٔ Basecamp) و بخش ارتباطات در دفترچهٔ عمومی شرکت GitLab است. هر دو در فهرست منابع آمده‌اند. اولی از نوشتن سنجیده به‌جای گفت‌وگوی لحظه‌ای دفاع می‌کند؛ دومی تأکید می‌کند که هر موضوع یک منبع حقیقت داشته باشد و تصمیم‌ها کتبی ثبت شوند. لازم نیست همهٔ آن قواعد را بپذیرید؛ ولی دیدن اینکه تیم‌هایی در مقیاس واقعی این‌طور کار می‌کنند، مفید است.

چه وقت هم‌زمان؟

• بعد از دو رفت‌وبرگشت بی‌نتیجه. اگر دو بار کامنت رد و بدل شده و هنوز همدیگر را نمی‌فهمید، ده دقیقه تماس بگیرید و بعد نتیجه را در کارت بنویسید.
• اختلاف نظر یا موضوع احساسی. نوشته لحن را منتقل نمی‌کند و سوءتفاهم را بزرگ‌تر می‌کند.
• حادثهٔ فوری. سرور اصلی پایین است؛ کسی منتظر کامنت نمی‌ماند.
• شروع یک موضوع تازه و مبهم. وقتی هنوز نمی‌دانید سؤال درست چیست، گفت‌وگوی کوتاه سریع‌تر است.

در همهٔ این موارد، یک چیز ثابت است: آنچه هم‌زمان تصمیم گرفته شد، ناهمگام ثبت می‌شود. جلسه‌ای که خروجی نوشتنی ندارد، برای هر کسی که در آن نبود، هرگز برگزار نشده است.

گفت‌وگو کنار کار، نه در پیام‌رسان

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

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

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

نوشتن برای خوانندهٔ غایب

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

قالب کامنت وضعیت

وقتی کاری را متوقف می‌کنید، به کس دیگری می‌سپارید، یا تصمیمی گرفته شده، کامنتی با این چهار بخش بنویسید:

وضعیت: صفحهٔ خروجی اکسل کار می‌کند، ولی ستون تاریخ هنوز میلادی است.

چه چیزی عوض شد: با مالی هماهنگ شد که فیلتر شعبه فعلاً لازم نیست؛ از معیار پذیرش حذفش کردم.

سؤال باز: فرمت تاریخ ۱۴۰۵/۰۷/۰۵ باشد یا ۵ مهر ۱۴۰۵؟ منتظر جواب واحد مالی.

قدم بعد: بعد از جواب، تبدیل تاریخ را می‌زنم و کارت را به بازبینی می‌برم.

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

صریح بگویید از چه کسی چه می‌خواهید

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

همین منطق برای خود کارت‌ها هم برقرار است: کارتی که عنوان روشن، معیار پذیرش و مسئول دارد، نصف سؤال‌های تیم را پیش از پرسیده شدن جواب می‌دهد. نوشتن چنین کارتی موضوع مقالهٔ کارت خوب چه شکلی است است.

جلسه‌هایی که می‌مانند و جلسه‌هایی که حذف می‌شوند

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

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

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

سه سؤال پیش از هر جلسهٔ تازه

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

شفافیت با مرز: همه نباید همه‌چیز را ببینند

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

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

امنیت روانی: شفافیت بدون ترس

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

امی ادموندسون، پژوهشگر مدرسهٔ کسب‌وکار هاروارد، «امنیت روانی تیم» را این‌طور تعریف می‌کند: باور مشترک اعضای تیم به اینکه ریسک کردن میان‌فردی، مثل پرسیدن، اعتراف به اشتباه یا مخالفت، در این تیم امن است. پروژهٔ پژوهشی گوگل دربارهٔ اثربخشی تیم‌ها، که با نام Project Aristotle شناخته می‌شود، هم امنیت روانی را از مهم‌ترین عوامل تیم‌های موفق یافت. خلاصه و منابع هر دو در صفحهٔ ویکی‌پدیای این مفهوم آمده است.

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

• دربارهٔ کارت حرف بزنید، نه دربارهٔ آدم. «این کارت سه روز است مانده؛ چه چیزی جلویش را گرفته؟» نه «چرا هنوز تمامش نکردی؟».
• از کسی که زود خبر بد می‌دهد تشکر کنید. کسی که روز سوم می‌گوید «به UAT نمی‌رسیم»، تیم را نجات داده است.
• مدیر اول تأخیرهای خودش را نشان دهد. اگر برآورد مدیر غلط بود، همین را در بازنگری بگوید.
• بازنگری دربارهٔ سیستم است. سؤال «چه چیزی در روش کار ما باعث این شد؟» است، نه «تقصیر چه کسی بود؟».
• داده‌های تابلو را برای سنجیدن افراد به کار نبرید. وقتی تعداد کارت‌های هر نفر معیار ارزیابی شود، کارت‌ها بی‌معنی می‌شوند و تابلو دیگر حقیقت را نشان نمی‌دهد.

توافق‌نامهٔ کاری تیم: قواعد را یک بار بنویسید

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

1. وضعیت هر کار روی تابلو است. کسی که کاری را شروع یا تمام می‌کند، همان موقع کارت را جابه‌جا می‌کند.
2. بحث دربارهٔ یک کار، روی کارت همان کار است. اگر در پیام‌رسان یا تماس تصمیمی گرفته شد، خلاصه‌اش در کارت ثبت می‌شود.
3. به کامنت‌هایی که نام شما در آن‌هاست، تا پایان همان روز کاری جواب می‌دهیم، حتی اگر جواب «فردا نگاه می‌کنم» باشد.
4. برای کار فوری تماس می‌گیریم، نه پیام. فوری یعنی «اگر تا یک ساعت دیگر انجام نشود، مشکل جدی پیش می‌آید».
5. ساعت‌های تمرکز را محترم می‌شماریم؛ مثلاً صبح‌ها تا ساعت ۱۱ جلسهٔ غیرضروری نمی‌گذاریم.
6. هر جلسه دستور کار و یک مسئول نوشتن خروجی دارد.
7. کارتی که مسدود است، همان روز علامت می‌خورد و دلیلش نوشته می‌شود.
8. این توافق‌نامه را هر سه ماه در بازنگری مرور و اصلاح می‌کنیم.

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

تیم دورکار و ترکیبی

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

چند نکتهٔ عملی:

• ساعت‌های هم‌پوشانی را تعیین کنید. چند ساعت در روز که همه در دسترس‌اند و جلسه‌های لازم در همان بازه گذاشته می‌شود.
• در تیم ترکیبی، جلسه را برای حاضران غایب طراحی کنید. اگر حتی یک نفر از راه دور وصل است، همه از راه دور وصل شوند، وگرنه بحث اصلی در اتاق می‌ماند.
• تغییرات باید فوری دیده شوند. تابلویی که فقط با رفرش به‌روز می‌شود، باعث می‌شود دو نفر هم‌زمان یک کار را بردارند یا کسی روی اطلاعات کهنه تصمیم بگیرد.
• به دسترس‌پذیری ابزار فکر کنید. ابزاری که سرورش داخل کشور است یا روی شبکهٔ خودتان نصب شده، در روزهای اختلال اینترنت بین‌الملل هم در دسترس می‌ماند. این ملاحظه را، کنار مسئلهٔ محل نگهداری داده‌ها، در مقالهٔ نصب روی سرور خودتان یا ابری بررسی کرده‌ام.

دو هفتهٔ اول: برنامهٔ اجرا

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

1. روز اول: با تیم یک ساعت بنشینید و فهرست کنید اطلاعات کار الان کجاها پخش است. همین فهرست معمولاً همه را قانع می‌کند که چیزی باید عوض شود.
2. روز دوم و سوم: همهٔ کارهای باز را روی تابلو بیاورید و برای هر کدام مسئول تعیین کنید. از این به بعد، سؤال «این کار کجاست؟» با «تابلو را ببین» جواب داده می‌شود.
3. روز چهارم: قاعدهٔ «بحث کار روی کارت» را شروع کنید. هر بار که کسی در پیام‌رسان دربارهٔ یک کار مشخص سؤال کرد، با مهربانی خواهش کنید همان را در کارت بپرسد.
4. هفتهٔ اول: جلسهٔ گزارش وضعیت را برای یک هفته آزمایشی حذف کنید و جلسهٔ روزانه را پای تابلو برگزار کنید.
5. هفتهٔ دوم: پیش‌نویس توافق‌نامهٔ کاری را با تیم بنویسید. هر بندی که کسی با آن مخالف است، یا اصلاح شود یا کنار برود.
6. پایان هفتهٔ دوم: بازنگری کوتاه: چه چیزی بهتر شد، چه چیزی دست‌وپاگیر بود، کدام قاعده را نگه می‌داریم؟

جمع‌بندی

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

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

منابع و مطالعهٔ بیشتر

• The 37signals Guide to Internal Communication — اصول ارتباطات داخلی سازندگان Basecamp، با تأکید بر نوشتن و ارتباط ناهمگام.
• GitLab Communication — The GitLab Handbook — راهنمای عمومی ارتباطات در GitLab: منبع حقیقت واحد، ثبت کتبی تصمیم‌ها و کار ناهمگام.
• Remote versus Co-located Work — Martin Fowler — مقایسهٔ کار دورکار و کار در یک مکان و آنچه هر کدام از تیم می‌طلبد.
• Psychological safety — Wikipedia — تعریف امنیت روانی، پژوهش‌های ادموندسون و یافته‌های پروژهٔ Aristotle گوگل.