فصل ۷ — ارتباطات

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

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

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

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

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

درون تیم شما

امیدوارم ارتباط درون تیم شما از قبل کم‌اصطکاک و پرتکرار باشد. اگر چنین است، احتمالاً تیم در طول روز کاری معمولی در تبادلات زیادی شرکت می‌کند. جفت‌برنامه‌نویسی می‌کنید، کد یکدیگر را بازبینی می‌کنید و با هم دیباگ می‌کنید. شاید تیم همچنین جلسات روزانهٔ stand-up و همگام‌سازی هفتگی داشته باشد. بسیاری از ما هنگام این تعاملات به نحوهٔ ارتباطمان فکر نمی‌کنیم. آن‌ها بخشی روتین از کار به نظر می‌رسند — و باید هم چنین باشند. با این حال، بعضی از این تعاملات را می‌توان کمی آگاهانه‌تر کرد تا پروژه‌های فنی پیچیده و بلندمدت (مثل بازآرایی در مقیاس بزرگ) را بهتر پشتیبانی کنند.

یادداشتی دربارهٔ ارتباط منظم

اگر تیم شما از قبل مؤثر و مکرر ارتباط برقرار نمی‌کند، شاید بهتر باشد پروژهٔ بازآرایی بزرگ را تا بعد از رفع مشکلات ارتباطی به تأخیر بیندازید. تیم ممکن است دچار مشکلاتی باشد: شاید با تیمی با خودپسندی‌های متضاد کار می‌کنید، یا هم‌تیمی‌هایی که بیشتر حرف می‌زنند تا گوش دهند. هر چه باشد، بدون رفع مشکلات ارتباطی، تیم نمی‌تواند پروژهٔ حیاتی را خوب (یا اصلاً) اجرا کند. منابع زیادی برای بهبود ارتباط تیمی وجود دارد، اما توصیه می‌کنم کتاب Nonviolent Communication اثر مارشال رزنبرگ را بخوانید.

اگر تیم نسبتاً تازه است یا صرفاً برای اجرای بازآرایی تشکیل شده (مثل بیشتر تیم‌های ببر)، ابتدا یک یا دو تمرین team-building انجام دهید. مهم است تیم قبل از چنین پروژه‌ای با یکدیگر راحت باشد. اول، همه احتمالاً یک یا دو باگ منتشر می‌کنند. می‌خواهید تیم حمایتگر باشد و سریع به اصلاح اشتباه کمک کند، نه اینکه به خاطر آن انتقاد کند. دوم، باید بتوانید مشکلات دشوار را با هم حل کنید؛ رها کردن خودپسندی کمک می‌کند سریع‌تر به راه‌حل خوب برسید. سوم، بازآرایی‌های بزرگ ممکن است طولانی شوند. باید بتوانید در طول پروژه بازخورد صادقانه به هم‌مهندسان بدهید. هیچ‌کس نمی‌خواهد از هم‌تیمی‌اش بی‌زار شود تا جایی که دیگر نتواند با او کار کند. باور کنید، من آن اشتباه را کرده‌ام.

برای پیشبرد تیم بدون سوءتفاهم و حوادث دیگر، از همان ابتدا چند عادت ارتباطی را در نظر بگیرید. بعضی از این مفاهیم برای کسانی که حتی به‌حداقل Agile عمل می‌کنند آشناست. عادت‌های پرتکرار (روزانه یا هفتگی) و کم‌تکرار (ماهانه یا فصلی) را می‌بینیم که برای نگاه انتقادی به آنچه تا امروز انجام شده و آنچه پیش روست مهم‌اند.

اگر ممکن است، سیاست «بدون لپ‌تاپ» و استفادهٔ حداقلی از تلفن در جلسات را برقرار کنید. ایده‌آل این است که فقط کسانی لپ‌تاپ داشته باشند که فعالانه یادداشت می‌گیرند یا محتوا روی صفحه به اشتراک می‌گذارند. اگر شرکت‌کننده on-call است یا در رفع incident فعال است، داشتن لپ‌تاپ کاملاً قابل قبول است. این سیاست شاید کمی سخت به نظر برسد، اما باور دارم به همه سود می‌رساند. بدون کامپیوتر در جلسات تمرکز بهتری دارم؛ بیشتر گوش می‌دهم، ایده‌های بهتری می‌دهم و اغلب احساس می‌کنم جلسه مفید بوده. اگر کنجکاوید، فقط برای یک یا دو جلسه امتحان کنید. شاید مفیدتر شوند و گاهی زودتر تمام شوند!

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

Stand-upها

Stand-upها عادت خوبی برای هم‌راستا نگه داشتن تیم در فواصل منظم‌اند. می‌توانند نیروی اجباری باشند تا شما و هم‌تیمی‌ها وضعیت کارها را در ابزار برنامه‌ریزی پروژه به‌روز کنید. فرصتی هم هست برای بازتاب ۲۴ ساعت گذشته: پیشرفت کافی داشتید یا باید از هم‌تیمی کمک بگیرید؟ با توجه به آنچه دیروز یاد گرفتید، امروز چه برنامه‌ای دارید؟

هر تیم رویکرد متفاوتی به stand-up دارد. بعضی جلسهٔ حضوری را ترجیح می‌دهند که همه دور میز جمع می‌شوند و پیشرفت روز قبل را می‌گویند. الزام حضور همه در زمان ثابت روزانه مزایایی دارد: نقطهٔ لنگر روزانه برای برنامه‌ریزی کار.

در پروژه‌های نرم‌افزاری بزرگ، داشتن زمان مشخص برای ارزیابی پیشرفت — هرچند کوچک — حیاتی است. گاهی دامنهٔ کار طاقت‌فرسا به نظر می‌رسد و تمرکز روی گام‌های تدریجی آن را قابل‌دسترس‌تر می‌کند. Stand-upهای روزانه و حضوری هم فرصتی برای face time مهم با یکدیگر فراهم می‌کنند. اگر بیشتر تیم مستقل برنامه‌نویسی می‌کند، stand-up روزانه شاید یکی از معدود تعاملات رو در رو باشد.

وقتی می‌گویم «حضوری» (in-person)، هر رسانهٔ رو در رو را می‌خواهم بگویم: در یک دفتر یا در ویدئوکنفرانس در سراسر جهان. مهم این است که همه وقت بگذارند یکدیگر را ببینند و بشنوند، دور از حواس‌پرتی.

تیم‌های دیگر روش ناهمگام را ترجیح می‌دهند و در پلتفرم همکاری (Slack، Discord و مانند آن) خلاصهٔ روز قبل را می‌نویسند. یک ایراد stand-up حضوری این است که همه باید دقیقاً هم‌زمان در دسترس باشند. برای تیم‌های پراکنده، stand-up حضوری ناراحت‌کننده یا تقریباً غیرممکن است. همچنین صبح یا بعدازظهر را قطع می‌کند و زمان تمرکز عمیق را کم می‌کند.

بازآرایی مؤثر کد تمرکز حاد می‌خواهد: فهم پیاده‌سازی فعلی (با خواندن کد یا اجرای تست‌های واحد)، تعیین بهترین بهبود، و سپس پیاده‌سازی دقیق با تکرار رفتار اولیه. بیشتر برنامه‌نویسان برای پیشرفت در کار دشوار به چند ساعت پیوسته بدون وقفه نیاز دارند. اگر مهندس ساعت ۹ می‌آید و ساعت ۱۰:۳۰ stand-up دارد، شاید اصلاً شروع نکند چون می‌داند پیشرفت چندانی نخواهد کرد.

برای شبیه‌سازی بهتر stand-up، معمولاً شرکت‌کنندگان باید تا زمان مشخصی به‌روزرسانی بدهند. مثلاً تیم تا ۱۰:۳۰ صبح هر روز کاری به‌روزرسانی ناهمگام می‌دهد. اگر زود می‌آیید، می‌توانید فوراً به‌روزرسانی کنید و سراغ کار بعدی بروید. هم‌تیمی‌ها هنگام شروع کار می‌نویسند. تا ۱۰:۳۰، اگر کسی چیزی ننوشته، مدیر یادآوری ملایم می‌کند تا همه به‌روزرسانی دهند.

می‌توانید در بازآرایی بزرگ هم stand-up روزانه داشته باشید، اما شاید بخواهید در طول اجرا فرکانس را بازبینی کنید. مثلاً اگر تیم وارد milestoneای با جریان‌های کاری موازی شده، به‌روزرسانی روزانهٔ این جریان‌های مجزا شاید وقت‌گیر نباشد. اگر به‌روزرسانی‌ها بسیار فنی و جزئی‌اند، بیشتر هم‌تیمی‌ها زمینهٔ لازم برای درک آن‌ها را ندارند. به‌جای stand-up روزانه، می‌توانید دو بار در هفته یا در همگام‌سازی هفتگی به‌روزرسانی جامع‌تر بدهید.

همگام‌سازی هفتگی

Stand-upهای روزانه برای تصویر سریع از پیشرفت همه‌اند؛ راه ارتباط منظم یک‌اندازه برای همه نیستند. اگر در stand-up نیم‌ساعته اعضا زیاد و عمیق دربارهٔ کار و مشکلات صحبت می‌کنند، دو گزینه دارید: اول، بخواهید بعد از stand-up ادامه دهند؛ اگر گفت‌وگو مربوط به بخش کوچکی از تیم است، کافی است. دوم، همگام‌سازی هفتگی برگزار کنید — فرصتی با زمان بیشتر برای موضوعات مهم.

در بازآرایی‌های بزرگ، چون سطح تأثیر گسترده است، مهندسان زیادی از سازمان درگیر می‌شوند. وقتی تیم بسیار بین‌رشته‌ای است و همه ۱۰۰٪ روی بازآرایی نیستند، همگام‌سازی هفتگی معمولاً بهتر از stand-up روزانه است. با جلسهٔ نیم‌ساعته یا یک‌ساعتهٔ هفتگی، فقط به‌روزرسانی‌های مرتبط با بازآرایی بحث می‌شود.

حدود یک ساعت برای همگام‌سازی هفتگی پیشنهاد می‌کنم. ساختار شبیه stand-up با چند تغییر: نیمهٔ اول — هر کس بگوید در هفتهٔ قبل در بازآرایی چه کرده. اگر پیشرفت کمتر از انتظار بود، چرا: مانع؟ کار غیرمرتبط با بازآرایی؟ دانستن آنچه پروژه را متوقف کرده به اندازهٔ دانستن کارهای جاری مهم است تا در صورت نیاز کار بازتوزیع شود. هنگام دور زدن اتاق، موضوعاتی که نیاز به بحث بیشتر دارند یادداشت کنید.

نیمهٔ دوم — بحث موضوعات مهم. موضوعات را در طول هفته جمع کنید و با دستور جلسهٔ کامل بیایید. مثلاً هم‌تیمی edge case تازه‌ای در تست پیدا کرده. شاید بخواهید در همگام‌سازی هفتگی بیشتر بحث کنید و رویکرد rollout را اصلاح کنید تا edge caseهای مشابه پوشش داده شوند.

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

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

بیشتر بازآرایی‌های بزرگ milestoneهای حجیم با کارهای خسته‌کننده و تکراری دارند. این مراحل معمولاً چالش‌برانگیز یا جذاب نیستند؛ کسل‌کننده اما لازم‌اند. پروژه انگار به خزیدن می‌افتد. هم‌تیمی‌ها در این مراحل بیشتر در معرض burnout‌اند، اما گروهی که بتوانید روی آن تکیه کنید و ناامیدی را با آن‌ها در میان بگذارید تفاوت بزرگی می‌سازد. اگر کسی انرژی ادامه ندارد، شاید کسی با ظرفیت بیشتر کمک کند.

حتماً در همگام‌سازی هفتگی یادداشت بردارید تا سابقهٔ بحث‌ها و نتیجه‌گیری‌ها را داشته باشید. این یادداشت‌ها، همراه با کارهای ردیابی‌شده در نرم‌افزار مدیریت پروژه، برای retrospective بعدی مفیدند.

همگام‌سازی هفتگی می‌تواند با stand-up ترکیب شود یا جایگزینش شود. حتی با stand-up روزانه یا دو بار در هفته، همگام‌سازی هفتگی بسیار مفید است چون فرصت بحث عمیق‌تر دربارهٔ مهم‌ترین موضوعات هفته را می‌دهد. اگر stand-up ناهمگام دارید، به‌ویژه همگام‌سازی هفتگی را توصیه می‌کنم تا همه به‌طور منظم رو در رو تعامل داشته باشند. ترکیب‌های مختلف stand-up (ناهمگام یا حضوری، روزانه یا یک روز در میان) را با همگام‌سازی هفتگی امتحان کنید و ببینید چه چیزی برای تیم شما بهتر است.

Retrospectiveها

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

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

اگر در اجرای retrospective خوب مطمئن نیستید، منابع عمومی زیادی وجود دارد. Atlassian مقالات و پست‌های وبلاگی دربارهٔ بهترین شیوه‌ها دارد.

خارج از تیم شما

مثل هر پروژهٔ نرم‌افزاری بزرگ، افراد زیادی خارج از تیم به پیشرفت شما علاقه‌مندند: مدیریت ارشد، مهندسان تیم‌های متأثر، رهبران فنی ارشد. مدیریت ارشد می‌خواهد مطمئن شود بازآرایی با سرعت و نتایج مورد انتظار پیش می‌رود. از دید آن‌ها، بازآرایی‌های بزرگ به راحتی به گودال پول تبدیل می‌شوند: زمان مهندسی گران‌بها صرف بازنویسی قابلیت موجود می‌شود و اگر پروژه منحرف شود، سرمایه‌گذاری بیشتر می‌شود. هزینهٔ فرصت هم مطرح است (فصل ۵). مدیریت ارشد می‌خواهد مرتب مطمئن شود تصمیم سرمایه‌گذاری درست بوده؛ در غیر این صورت شاید برنامهٔ توقف یا مکث بچیند. با تقویت مهارت ارتباطی در به‌روزرسانی‌های بیرونی می‌توانید حمایت را حفظ کنید.

مدیران و مهندسان تیم‌های متأثر می‌خواهند هر مرحله را دنبال کنند تا بدانند کی تحت تأثیر قرار می‌گیرند: زمان rollout و مدت آن. رهبران فنی ارشد به دنبال موانع به‌عنوان فرصت هدایت پروژه به مسیر درست‌اند. این افراد معمولاً در شکل‌دادن چشم‌انداز فنی شرکت نقش دارند و موفقیت تلاش‌های فنی پیچیده — از جمله بازآرایی‌های بزرگ — بر عهدهٔ آن‌هاست.

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

هنگام آغاز پروژه

چند تصمیم مهم اولیه دربارهٔ ارتباط با ذی‌نفعان بیرونی هنگام kick-off لازم است. با تصمیم زودهنگام، زمان هماهنگی با همکاران خارج از تیم صرفه‌جویی و احتمال سوءتفاهم کمتر می‌شود.

انتخاب یک منبع واحد حقیقت

حتی کوچک‌ترین شرکت‌ها برای یک مجموعه کار از ابزارهای متعدد استفاده می‌کنند. شاید هم GSuite و هم Office 365 داشته باشید. حتی در سازمان مهندسی، اسناد پراکنده در GSuite، GitHub و ویکی داخلی است. جستجو در نیم‌تنه پلتفرم برای اطلاعات پراکنده آزاردهنده است؛ وقتی اطلاع در چند جا هست و با هم نمی‌خواند، بدتر است.

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

در پلتفرم انتخاب‌شده، دایرکتوری برای همهٔ مستندات مرتبط بسازید — منبع واحد حقیقت (single source of truth). مستندات می‌تواند شامل مشخصات طراحی فنی، برنامهٔ اجرا (فصل ۴)، یادداشت جلسات، postmortem و غیره باشد. هر جا مهندسان دنبال مستندات می‌گردند، به این دایرکتوری یا بهتر به سند مشخص در آن لینک دهید. اگر همکاران در GitHub جستجو می‌کنند و شما Notion ترجیح می‌دهید، ورودی در GitHub بسازید و مستقیم به Notion لینک دهید. هم پیدا کردن آسان می‌شود، هم مطمئن می‌شوید نسخهٔ کهنهٔ پراکنده ندارید.

در طول پروژه مطمئن شوید همهٔ مستندات در دایرکتوری پروژه می‌نشیند (با به‌روزرسانی لینک‌های خارجی از منابع پرکاربرد دیگر).

تعیین انتظارات

بعد، انتظارات را با ذی‌نفعان بیرونی مشخص کنید. بسیاری مرتب سراغ شما می‌آیند و اطلاع می‌خواهند. این مدل با زیاد شدن ذی‌نفعان آزاردهنده می‌شود: اگر هر بار مدیریت ارشد سؤال دارد ایمیل یا پیام بیاید، زمان زیادی صرف پاسخ می‌شود. از طرف دیگر، گاهی کسانی هستند که می‌خواهید مرتب سر بزنند اما نمی‌زنند — آن وقت تیم باید اطلاع را فعالانه push کند. push مداوم به ذی‌نفعان زیاد، به‌ویژه وقتی طرف مقابل تأیید نمی‌کند که خوانده، آزاردهنده است.

به‌جای پاسخ به هر درخواست یا تماس با هر ذی‌نفع، مشخص کنید چگونه پیشرفت را اعلام می‌کنید و از همان ابتدا انتظار بگذارید کجا و با چه فرکانسی به‌روزرسانی می‌گیرند. وقتی ذی‌نفع از الگو خارج شد (مثلاً پیام از skip-level)، به‌جای پاسخ مستقیم، یادآوری ملایم بدهید کجا اطلاع را پیدا کند.

هنگام kick-off، طرح ارتباطی تقریبی بنویسید شامل:

کجا اطلاع مرحلهٔ فعلی بازآرایی را پیدا کنند

• در Slack: کانال مرتبط، topic کانال = توضیح کوتاه مرحلهٔ فعلی؛ پایان هفته پیام خلاصهٔ هفتگی (بعد از همگام‌سازی هفتگی می‌توانید فوراً بنویسید و به یادداشت جلسه لینک دهید).
• در JIRA: لینک به برد پروژه؛ برای به‌روزرسانی‌های سطح بالا، فیلد خلاصهٔ هفتگی در سطح پروژه.

کجا جدول زمانی سطح بالا را پیدا کنند

• در ریشهٔ دایرکتوری مستندات، در خود طرح ارتباطی، یا زیربخشی از برنامهٔ اجرا. اگر تاریخ‌ها جابه‌جا شد، به‌روز نگه دارید.

کجا اطلاعات فنی بازآرایی را پیدا کنند

• لینک به دایرکتوری مستندات؛ خلاصهٔ کوتاه از انواع اسنادی که جمع می‌کنید.

کجا سؤال بپرسند

• Discord: کانال پروژه یا کانال مخصوص سؤال.
• ایمیل: به گروه تیم بفرستند نه فرد.
• تیم بین‌رشته‌ای: گروه ایمیل برای همهٔ درگیران.

کی تیم‌های متأثر از شما بشنوند

• شفافیت بالا با تیم‌هایی که ممکن است تحت تأثیر باشند.
• فهرست راهنمایی برای تعامل با کد تیم‌های دیگر: tag برای code review، حضور در stand-up آن‌ها وقتی مرتبط است.

در طول اجرای پروژه

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

اعلان‌های پیشرفت

اعلان پیشرفت فقط برای اطلاع از تکمیل milestone (و مزایای آن) مهم نیست — برای احساس بهره‌وری و روحیهٔ تیم هم حیاتی است. بازآرایی بزرگ حتی برای تیم‌های پروژهٔ طولانی هم سنگین به نظر می‌رسد. جشن گرفتن هر milestone حس دستاورد می‌دهد.

هر طور شرکت feature جدید را اعلام می‌کند (ایمیل دپارتمان یا Slack)، درخواست کنید به‌روزرسانی‌های مهم بازآرایی را هم اعلام کنید. تیم recognition می‌گیرد و نشان می‌دهد بازآرایی سرمایه‌گذاری ارزشمند مهندسی است.

برنامهٔ اجرا

در فصل ۴ یاد گرفتیم برنامهٔ اجرای مؤثر بنویسیم. فراتر از نقشهٔ راه، می‌توان آن را محل ثبت کار در طول پروژه کرد. از نسخهٔ اصلی کپی بگیرید. نسخهٔ اصل باید نسبتاً دست‌نخورده بماند جز به‌روزرسانی‌های سبک تخمین و معیار milestone. کپی نسخهٔ زنده است و پیشرفت را ثبت می‌کند. (تاریخچهٔ نسخه کمک می‌کند مقادیر اولیه را با به‌روزرسانی‌ها مقایسه کنید.) می‌تواند شامل باگ‌های عجیب، edge caseهای غیرمنتظره یا انحراف از طرح باشد. این نسخهٔ دوم دید ظریف‌تری به پیشرفت می‌دهد و ردیابی کار تا امروز را آسان‌تر می‌کند.

مثلاً در مثال فصل ۴، تیم Smart DNA باید همهٔ محیط‌های Python 2.6 را به 2.7 مهاجرت کند. milestone اول برنامهٔ اجرا:

• ایجاد یک فایل requirements.txt واحد.
  • معیار: تعداد فهرست‌های وابستگی متمایز؛ شروع: ۳؛ هدف: ۱
  • تخمین: ۲–۳ هفته
  • زیرکارها:
    • فهرست همهٔ بسته‌ها در هر مخزن.
    • ممیزی بسته‌ها و محدود کردن به بسته‌های لازم با نسخهٔ متناظر.
    • تعیین نسخهٔ ارتقا برای Python 2.7.

با پیشرفت، تیم کپی را با زمینهٔ یافته‌ها پر می‌کند:

• ایجاد یک فایل requirements.txt واحد.
  • معیار: تعداد فهرست‌های وابستگی متمایز؛ شروع: ۳؛ هدف: ۱
  • تخمین: ۲–۳ هفته
  • زیرکارها:
    • فهرست همهٔ بسته‌ها در هر مخزن. هنگام بررسی اولین مخزن، شگفت‌زده شدیم کد به شش وابستگی اضافی تکیه دارد که در requirements.txt صریح نبود. پژوهشگران فهرست به‌روز برای مخزن اول و ۱۰ وابستگی گم‌شده در دو مخزن دیگر را دادند.
    • ممیزی بسته‌ها. خوشبختانه ۸۰٪ بسته‌های سه مخزن یکسان بود. از آن مجموعه فقط هشت بسته نسخهٔ متفاوت داشت که باید هماهنگ می‌شد.
    • تعیین نسخهٔ ارتقا برای Python 2.7. برای هفت بسته در مجموعهٔ نهایی دشوار بود — نسخه‌های سازگار با 2.7 APIها و قابلیت‌هایی را که پژوهشگران در دو مخزن استفاده می‌کردند deprecated کرده بودند. با تیم پژوهش به‌تدریج از آن قابلیت‌ها فاصله گرفتیم قبل از ادامهٔ بازآرایی.

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

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

درخواست بازخورد از مهندسان ارشد

همه از هم‌تیمی‌ها و همکاران باتجربه مشورت می‌گیریم. بازخورد از رهبران مهندسی ارشد بسیار مفید است، اما گرفتن و نگه‌داشتن توجه آن‌ها سخت است. چه از روز اول SME باشند (فصل ۶) چه تازه در جریان شوند، به‌خاطر مسئولیت‌های زیاد در پروژه‌های متعدد کندتر پاسخ می‌دهند. با ارتباط درست انتظارات، نباید کسی bottleneck شود.

منظور از «مهندس ارشد» (senior engineer) در اینجا باتجربه‌ترین مشارکت‌کنندگان فردی در تیم، دپارتمان یا شرکت است — نه لزوماً عنوان شغلی Senior Engineer. معمولاً عنوان‌های بزرگ‌تر مثل Senior Staff، Principal یا Distinguished Engineer. گاهی کسانی‌اند که بیشترین مدت در شرکت مانده‌اند.

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

بعد تعیین کنید بازخوردشان برای مومنتوم پروژه چقدر حیاتی است — بدون نظرشان می‌توانید پیش بروید؟ اگر بله، صریح بگویید تا اولویت‌بندی درست کنند. اگر بدون نظرشان پیش نمی‌روید، بگویید blocker شده‌اند تا فوریت کافی باشد. در هر صورت، مهلت مشخص برای بازخورد بگذارید.

اگر به مهندس ارشد گفتید دیدگاهش blocker است، مهلت گذاشتید و هنوز پاسخی نیست، وقت قاطعیت است. اگر تقویمش پر نیست، وقت یک‌به‌یک رزرو کنید (توضیح جلسه کامل باشد!). اگر فقط چند دقیقه می‌خواهید، سر میز یا بعد از جلسه‌ای بگیرید. رو در رو به‌تأخیر انداختن سخت‌تر است.

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

مثال: روی نمونه‌اولیه کتابخانهٔ جدید در بازآرایی بزرگ کار می‌کنید. چند interface پایه با پیاده‌سازی‌های موقت ناقص. برای code review می‌گذارید با توضیح کوتاه و لینک سند طراحی. مهندس ارشد را tag می‌کنید اما فراموش می‌کنید بگویید بازخورد روی interfaceهاست (نه پیاده‌سازی‌ها) و می‌خواهید ظرف یک هفته merge کنید.

چند روز می‌گذرد — نظر هم‌تیمی‌ها هست، از مهندس ارشد نیست. پیام می‌زنید؛ می‌گوید دیده و تا آخر هفته می‌رسد. با هم‌تیمی‌ها تصمیم می‌گیرید merge کنید و در reviewهای بعدی ادامه دهید.

روز بعد مهندس ارشد review را باز می‌کند و روی جزئیات پیاده‌سازی نظر می‌دهد و نگران می‌شود که merge شده. همه ناراحت‌اند: شما از تأخیر و تمرکز روی بخش اشتباه؛ او از نظر روی کد موقت و merge بدون انتظار برای نظرش. با تعیین انتظارات درست از ابتدا همهٔ این سوءتفاهم‌ها قابل اجتناب بود.

کار کردن تنها

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

• اگر در stand-up روزانه با هم‌تیمی‌های غیرمرتبط شرکت می‌کنید، به‌روزرسانی‌ها را جایی بنویسید که ذی‌نفعان بیرونی ببینند. وگرنه stand-up ناهمگام خودتان: دیروز چه کردید، امروز چه می‌خواهید؛ اگر ابزار مدیریت پروژه مفید است، کارها را به‌روز کنید.
• اگر تیم همگام‌سازی هفتگی دارد و agenda می‌پذیرد، هر هفته حداقل یک موضوع اضافه کنید تا همه از کار شما باخبر بمانند و دیدگاه‌های متفاوت بگیرید. اگر همگام‌سازی ندارید، یک ساعت در هفته block کنید: مرور کار، به‌روزرسانی مستندات (وقت اختصاصی یادداشت‌ها را به‌روز نگه می‌دارد)، یا خلاصهٔ هفتگی برای دیگران.
• office hours برگزار کنید تا ذی‌نفعان بیرونی (از جمله مهندسان تیم‌های متأثر) سؤال بپرسند یا مشکل را با شما مرور کنند. فرکانس به بسامد تغییر در کد دیگران و میزان درگیری آن‌ها بستگی دارد؛ شاید دو بار در ماه شروع کنید و تنظیم کنید.

همیشه تکرار کنید

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

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

فصل بعد با موضوع الگوهای اجرای پربار ادامه می‌دهد. مجموعه‌ای از ایده‌ها (فنی و غیرفنی) که تیم می‌تواند در طول توسعهٔ بازآرایی امتحان کند.