فصل ۶ — ساخت تیم مناسب

Ocean's 11 یکی از آن فیلم‌های سرقت است که در فهرست علاقه‌مندی‌های همه جا می‌افتد. با آزادی Danny Ocean از زندان شروع می‌شود. با شریک و دوستش Rusty Ryan ملاقات می‌کند تا سرقتی پیشنهاد دهد. نقشه این است که ۱۵۰٬۰۰۰٬۰۰۰ دلار از سه کازینوی لاس‌وگاس — Bellagio، Mirage و MGM Grand — دزدیده شود. دو سارق می‌دانند تنها نمی‌توانند سرقت را انجام دهند، پس شروع به جمع‌کردن گروهی از مجرمین می‌کنند: صاحب سابق کازینو، جیب‌بر، کلاهبردار، متخصص الکترونیک و نظارت، متخصص مواد منفجره و آکروبات.

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

Ocean و Ryan هرگز نمی‌توانستند تنها Bellagio را سرقت کنند. نه‌تنها ماه‌ها برای جمع منابع مالی لازم نیاز داشتند، بعید بود با تنها دو نفر نقشهٔ معقولی برای دور زدن اقدامات دفاعی کازینو بکشند. با جمع‌آوری تیمی با اندازه و مهارت دقیقاً مناسب، زمان اجرا را کم و شانس موفقیت را زیاد کردند.

برای اجرای موفق تلاش بازآرایی در مقیاس بزرگ، به Ocean's 11 خودمان نیاز داریم. Danny ماه‌ها در زندان New Jersey روی سرقت iterate کرد؛ از blueprint فهرست مهارت‌ها و تخصص لازم را استخراج کرد، همراه با نام‌های کاندیدهای بالقوه. در این فصل یاد می‌گیریم چطور بسته به تخصص لازم برای اجرای مؤثر بازآرایی، انواع مختلف تیم‌ها را بسازیم. به‌عنوان technical lead یاد می‌گیریم فهرست هم‌تیمی‌های بالقوه را محدود و آن‌ها را قانع کنیم در سفر همراه ما شوند. در پایان دربارهٔ بهترین استفاده از وضعیت نامساعد — نیاز به اجرای پروژه تنها — بحث می‌کنیم.

شناسایی انواع مختلف متخصصان

در فصل ۴ یاد گرفتیم چطور طرح اقدام مؤثر بنویسیم. یاد گرفتیم پیچیدگی مهم تلاش بازآرایی را در چند نقطه عطف سطح بالای مختصر با زیروظایف حیاتی خلاصه کنیم.

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

با خواندن مجدد طرح شروع می‌کنیم. در هر گام سعی می‌کنیم کدی که باید با آن تعامل کنیم را visualize کنیم. آیا راحت می‌توانیم آن را ببینیم؟ آیا با اطمینان تغییرات لازم و اثر یا اثرات downstream را استدلال می‌کنیم؟ آیا گودال‌های احتمالی آن بخش کدبیس را می‌فهمیم؟ آیا اثرات محصولی تغییرات را می‌فهمیم؟ آیا با فناوری‌هایی که مستقیم یا غیرمستقیم با آن‌ها کار می‌کنیم آشنا هستیم؟ اگر بله، عالی! احتمالاً می‌توانیم خودمان تغییرات را انجام دهیم. اگر نه، به کمک کس دیگری نیاز داریم. می‌توانیم کسی را به یکی از دو روش کمک بگیریم: contributor فعال یا subject matter expert.

contributor فعال به‌شدت درگیر پروژه است، ایده‌آل از روز اول. با نوشتن کد کنار شما فعالانه مشارکت می‌کند. contributorهای فعال باید زود و در هر بازنگری طرح اجرا برای نظر مشورت شوند.

subject matter expertها، یا به اختصار SME، contributor فعال تلاش شما نیستند. موافقت کرده‌اند برای بحث راه‌حل، پاسخ سؤال و شاید code review در دسترس باشند. اگرچه مشارکتشان می‌تواند بسیار معنادار باشد، تعهد زمانی به پروژه کم است. تمرکز اصلی‌شان روی پروژه‌های دیگر است.

بیایید با یک پروژهٔ نمونه ملموس‌تر کنیم. تیم monitoring و observability شرکت از یک سیستم جمع‌آوری metrics به دیگری مهاجرت می‌کند (شاید StatsD به Prometheus). زیرساخت را ساخته، چند node provision کرده و آمادهٔ پذیرش ترافیک از اپلیکیشن شماست. تیم به یکی دو توسعه‌دهنده نیاز دارد که با نحوهٔ استفادهٔ اپلیکیشن از StatsD آشنا باشند تا در گذار کمک کنند. شما یکی از آن‌ها هستید و تصمیم گرفته‌اید با نوشتن کتابخانهٔ داخلی جدید برای رابط با راه‌حل جدید و در نهایت جایگزینی کتابخانهٔ فعلی کمک کنید. باید مطمئن شوید کتابخانهٔ Prometheus feature parity با فعلی و API تمیز و intuitive دارد. وظیفهٔ نهایی شما ایجاد best practice برای استفاده از کتابخانهٔ جدید و تشویق پذیرش در سازمان مهندسی است.

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

هنگام ممیزی استفاده‌های کتابخانهٔ StatsD می‌بینید تیم توسعهٔ محصول دیگری آن را به شکلی متفاوت از بیشتر تیم‌ها استفاده می‌کند. می‌خواهید بفهمید چرا و آیا این رفتار حتماً باید در سیستم جدید تکرار شود. اگر لازم است، باید مطمئن شوید Prometheus آن را پشتیبانی می‌کند. به چند نفر در آن تیم مراجعه می‌کنید. یکی — فرض کنیم Frankie — مشتاقانه موافقت می‌کند ملاقات کند. پس از گفت‌وگوی کوتاه نتیجه می‌گیرید رفتار باید در کتابخانهٔ Prometheus جدید پشتیبانی شود و Frankie موافقت کرده هنگام ساخت قابلیت کد شما را review کند. Frankie در این سناریو SME است.

ممکن است برای اجرای موفق بازآرایی به انواع مختلف تخصص نیاز داشته باشید. در مثال جمع‌آوری metrics به تخصص فناوری تیم monitoring با StatsD و Prometheus، تخصص محصول Frankie با use caseهای مشخص، و تخصص خودتان در نحوهٔ استفادهٔ کدبیس از کتابخانه‌های جمع‌آوری metrics نیاز داشتیم. شاید بخواهیم با کسی از تیم امنیت مشورت کنیم که هیچ دادهٔ حساس مشتری از سیستم جدید عبور نکند (و اگر عبور کرد، اقدامات مهار سریع داشته باشیم).

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

هم‌سنجی (Matchmaking)

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

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

در پایان باید هر تخصص را با یک یا چند نفر match کنیم. از ابتدای فهرست شروع کنید و برای هر مورد اولین چند نام افراد یا تیم‌هایی که به ذهن می‌رسد بنویسید.

اگر در شرکت بزرگ کار می‌کنید یا با افراد تیم‌های مهندسی مختلف آشنا نشده‌اید، شاید برای هر تخصص سخت باشد متخصص پیدا کنید. اشکالی ندارد! می‌توانید با شناسایی یک دپارتمان شروع کنید. اگر به org chart به‌روز دسترسی دارید، بهترین تیم در دپارتمان را پیدا کنید. از مدیر برای تولید و سپس کاهش فهرست متخصصان نترسید. بخشی از کارشان اطمینان از داشتن همهٔ منابع لازم برای اجرای مؤثر پروژه‌هاست و احتمالاً بینش بهتری دارد کدام تیم‌های سازمان برای کمک مناسب‌اند.

یافتن متخصص از طریق on-call

اگر به org chart به‌روز دسترسی ندارید اما تیم مهندسی rotation on-call دارد و از سرویسی مثل PagerDuty برای هشدار حوادث استفاده می‌کند، شاید بتوانید متخصص درست را از این rotationها پیدا کنید. قابلیت یا جزء زیرساختی که متخصص می‌خواهید را پیدا کنید و تیمی با rotation on-call متناظر را بیابید. Voila!

تا تمام شدن موارد ادامه دهید و نام بنویسید. جدول ۶-۱ فهرست نمونه برای مهاجرت جمع‌آوری metrics است.

جدول ۶-۱. فهرست انواع تخصص و متخصصان بالقوه

حوزهٔ دانش	نقطه عطف	نقش	متخصص
درک نحوهٔ استفادهٔ کد تکمیل سفارش از StatsD (متفاوت از بیشتر قابلیت‌های محصول)	۱	SME	Frankie، Mackenzie، تیم Order Processing
تست end-to-end خودکار بین کتابخانه و Prometheus	۲	contributor فعال	Jesse، تیم Automated Testing
پایش ترافیک اپلیکیشن به Prometheus هنگام پذیرش توسط تیم‌ها	۳	SME	تیم Monitoring
اثر pipeline deploy اپلیکیشن روی nodeهای Prometheus	۱	SME	Jesse، تیم Release & Deploy
اثرات امنیتی جمع metrics دربارهٔ مشتریان؛ مشتریان امنیت‌محور که باید مراقب monitoring آن‌ها باشیم	۱	SME	تیم Product Security

متخصصان چندرشته‌ای

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

اول، می‌تواند تعداد کل افرادی که باید با آن‌ها هماهنگ کنید را کم کند. هماهنگی پروژهٔ بزرگ با یک تیم سخت است، چه برسد به پروژهٔ بزرگ با چند توسعه‌دهنده در تیم‌های مختلف. هر contributor نه‌تنها باید به تلاش pitch شود و به‌روز شود، بلکه باید با فرایند توسعهٔ تیم شما (stand-up هفتگی یا روزانه، retrospective ماهانه و غیره) سازگار شود. ممکن است زمان و تلاش قابل‌توجهی طول بکشد تا همه هم‌راستا و با سرعت خوب کار کنند.

دوم، متخصصانی که درک عمیق از چند جنبهٔ مهم پروژه دارند احتمالاً دید قوی از نحوهٔ کار این قطعات با هم دارند. بینشی است که مهندسین کمی در شرکت به اشتراک می‌گذارند. با توجه به فهرست نمونه در جدول ۶-۱، Jesse احتمالاً یکی از آن افراد است. از گفت‌وگوهایمان می‌دانیم چند ماه با تیم release & deploy نزدیک کار کرده تا سیستم release درصدی برای دو سرویس مهم شرکت بسازد. همچنین می‌دانیم پس از آن پروژه به تیم internal tools رفته و در دسترس‌تر کردن محیط‌های تست خودکار کار کرده. Jesse یکی از آن مهندسینی است که مدت‌ها در شرکت بوده، روی فهرست طولانی پروژه‌ها کار کرده و بینش تیز از نحوهٔ کار این قطعات با هم دارد.

متأسفانه افرادی مثل Jesse می‌توانند خیلی مشغول باشند (احتمالاً چون به‌عنوان SME به چند پروژه نظر می‌دهند و چند پروژهٔ خودش را رهبری می‌کند). اگر برای مشارکت منظم در دسترس نیستند اما باور دارید دانش منحصربه‌فردشان برای بازآرایی حیاتی است، پیشنهاد دهید طرح اجرای شما را review کنند. ورودی آن‌ها به‌ویژه در تأیید کم‌اطمینان‌ترین تخمین‌های زمانی من مفید بوده. اگر به دنبال متخصصی برای مشارکت فعال هستید، می‌تواند یکی دو متخصص جایگزین پیشنهاد دهد.

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

بازنگری contributorهای فعال

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

اگر فهرست contributorهای فعال خیلی طولانی به نظر می‌رسد، فهرست را مرور کنید و ببینید آیا تخصصی هست که به‌جای آن SME بجویید. هماهنگی با SME هزینهٔ هماهنگی بسیار کمتری دارد چون فقط به‌صورت ad hoc مشورت می‌شوند. راهبردهای ارتباط مؤثر با SMEها را در فصل ۷ پوشش می‌دهیم.

سوگیری‌ها در فهرست متخصصان ما

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

با این حال درخواست مستقیم از همکار معایبی دارد. مهندسین نرم‌افزار در تخمین زمان و تلاش کار به‌طرز بدنامانه‌ای ضعیف‌اند. اغلب پیامد خوش‌بینی بی‌وقفه‌ای است که مهندس بودن می‌طلبد. وقتی چیزی درخواست کوچک به نظر می‌رسد، گاهی همکاران خیلی زود «بله» می‌گویند بدون scoping درست تعهد. شاید خیلی بعد از kick-off پروژه بفهمند به چند چیز زیاد «بله» گفته‌اند و جuggling سخت شده. (من آن شخص بوده‌ام و باور کنید گفتن بله به چیزهای زیاد به اندازهٔ گفتن نه به همه چیز بی‌فایده است.)

مشکل دیگر درخواست مستقیم از همکار این است که ممکن است افراد مناسب‌تر را نادیده بگیرید. همه از سوگیری‌هایی رنج می‌بریم که باید آگاهانه مقابله کنیم. یکی recency bias است — چیزهایی که اخیراً دیده‌ایم سریع‌تر به ذهن می‌آیند. اگر اخیراً نام همکاری را شنیده یا با او صحبت کرده‌ایم، احتمال بیشتری دارد در فهرست متخصص بالقوه بیاید. قبل از نهایی کردن فهرست متخصصان باید به این سوگیری توجه کنیم و لحظه‌ای بپرسیم آیا هر expert واقعاً بهترین است یا فقط چند روز پیش نامش را در ایمیل دیدیم. اگر کاندیدای واجدتر فکر می‌کنیم موجود است، تحقیق کنیم و شاید به تیم به‌جای فرد مراجعه کنیم. مدیران تیم‌های expert می‌توانند درخواست کمک را به توسعه‌دهندگان vet کنند و علاقه را بسنجند. مدیران خوب کسانی را شناسایی می‌کنند که می‌توانند معنادار مشارکت کنند و بیشترین سود را از visibility و رشد شغلی مشارکت در بازآرایی شما ببرند.

همچنین مهم است تخصص را با ارشدیت اشتباه نگیریم. Frankie شاید بیشترین تجربهٔ صنعتی یا بیشترین سابقه در شرکت را نداشته باشد، اما چند ماه گذشته مشارکت‌های قابل‌توجهی داشته و مطمئنید می‌تواند سؤالات را جواب دهد و در code review بینش ارزشمند بدهد. گاهی ارشدترین شخص بهترین همکار نیست؛ اغلب این توسعه‌دهندگان خیلی مشغول رهبری پروژه‌های پرتقاضای خودشان‌اند و زمانشان جای دیگر ارزشمندتر است. پروژهٔ شما هم می‌تواند فرصت عالی exposure و visibility فراتر از تیم فوری برای کسی باشد. بازآرایی (به‌ویژه در مقیاس بزرگ) می‌تواند پیچیده باشد، اما کاری نیست که مهندس با یک سال (یا حتی چند ماه) تجربه نتواند معنادار به آن کمک کند و از آن یاد بگیرد.

صحبت با مدیر تیم

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

انواع تیم‌های بازآرایی

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

مالکان (Owners)

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

فرض کنید در شرکتی با سه گروه مهندسی گسترده کار می‌کنید: developer productivity، infrastructure و product engineering. شما در تیمی هستید که مسئول کتابخانه‌ها و ابزارهای تست اپلیکیشن در گروه developer productivity است. همیشه خوب است مهندسین در سازمان unit test بیشتری می‌نویسند، اما نگرانید زمان لازم برای اجرای همه شروع به hinder کردن توانایی ship سریع کد کرده. با تمرکز بر کارایی، زمان اجرای unit testهای فردی را track می‌کنید و metrics روی مدت عملیاتی‌هایی مثل setup mock state پیچیده جمع می‌کنید. تیم تصمیم می‌گیرد بازآرایی را kick-off کند و روی تسریع فرایند mock setup تمرکز کند. اگرچه benchmark نسخهٔ جدید بهبود چشمگیر نشان می‌دهد، unit testهای موجود باید به منطق setup جدید migrate شوند تا از سرعت بهره ببرند. دو راه اصلی برای migration:

گزینهٔ ۱: یک تیم همهٔ تست‌ها را migrate می‌کند

اولین گزینه این است که تیم شما همهٔ تست‌ها را برای همه migrate کند. مزایای مشخصی دارد. تیم شما با بهترین روش migrate تست از منطق mocking قدیم به جدید آشناست؛ می‌داند کدام تست‌ها migrate آسان دارند، گودال‌های تست‌های سخت را می‌شناسد و چطور از سیستم mocking جدید بیشترین بهبود کارایی را بگیرد. تیم شما هم احتمالاً انگیزهٔ بیشتری برای اجرای migration دارد. به‌عنوان مالک فریم‌ورک تست، این را اولویت بالا دانسته‌اید. احتمالاً objective فصلی برای کاهش زمان اجرای suite کامل تعیین کرده‌اید. دانستن ارزیابی بر اساس دستیابی به آن هدف بسیار انگیزه‌بخش است (به‌ویژه نزدیک پایان فصل).

از سوی دیگر، هزاران تست برای migrate هست. تیم شما شاید راه هوشمندانه‌ای برای استفاده از ابزارهای code modification برای migrate خودکار بعضی ساده‌ترین‌ها پیدا کند، اما فقط درصد کوچکی از مسیر را می‌پوشاند. اگر callsiteهای باقی‌مانده را به‌طور مساوی بین تیم تقسیم کنید، شاید هنوز هفته‌ها کار دستی تکراری برای انتقال همه به سیستم جدید طول بکشد. تیم شما هم با آنچه هر تست واقعاً تست می‌کند آشنا نیست. هرچند دوست داریم فرض کنیم تست‌ها mocking فعلی را black box می‌بینند، همیشه نمی‌توان پیش‌بینی کرد تست‌ها چقدر به رفتار پیاده‌سازی فعلی وابسته‌اند. احتمال قوی دارد در نهایت به context نیاز داشته باشیم که تست چه چیزی و چگونه تست می‌کند تا درست به سیستم mocking جدید adapt شود.

گزینهٔ ۲: تیم‌ها تست‌های خود را به‌روز می‌کنند

گزینهٔ دوم این است که تیم‌های product engineering تست‌های مربوط به قابلیت‌هایی که مالک آن‌ها هستند خودشان migrate کنند. با این رویکرد تیم شما دیگر نیازی ندارد تنها هزاران تست را tackle کند. با توزیع کار در سازمان مهندسی، احتمال قوی اثر مثبت migration زودتر احساس شود. مهندسین تیم شما هم نگران decode کردن تست‌های سخت‌تر نیستند. با وظیفهٔ به‌روزرسانی تست‌های خود به هر تیم، کار مؤثرتری در حفظ رفتار موردنظر تست انجام می‌دهد. (به‌عنوان bonus، تیم‌های مشارکت‌کننده فرصت عالی برای بررسی بحرانی پوشش تست فعلی و شاید بهبود فراتر از چند ثانیه runtime دارند.)

این رویکرد معایب خودش را دارد. باید مستندسازی برای بهترین روش upgrade تست تولید کنید، صرف‌نظر از گزینه‌ای که انتخاب می‌کنید، اما کیفیت اولیه (و به‌روزرسانی به‌موقع) مستندات با این رویکرد بسیار مهم‌تر است. مهندسینی که فعالانه تست‌هایشان را migrate می‌کنند به‌شدت به تیم شما برای پاسخ سؤال و code review وابسته‌اند. حتی اگر سند FAQ بسیار کامل دارید، احتمالاً باز هم باید همان دسته سؤال‌ها را بیش از یک بار جواب دهید.

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

تعادل برقرار کردن

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

رویکرد پیشنهادی

۱. تیم شما چند تست ساده را که بیشترین سود را از migration می‌برند شناسایی کند. به تیم‌های product engineering برای context بیشتر دربارهٔ تست‌های با بیشترین اثر مراجعه کند. ۲. با گزینهٔ ۱ (بخش «گزینهٔ ۱: یک تیم همهٔ تست‌ها را migrate می‌کند») شروع کند. migrate دستی تست‌ها را آغاز و فرایند را کامل مستند کند. (اگر فایل‌های تست clearly متعلق به تیم مشخص است، به آن تیم heads up بدهید یا با آن تکمیل migration را انجام دهید.) ۳. برای فایل‌های تست migrate‌شده benchmark اجرا کند تا اثر کارایی را واضح نشان دهد. آن‌ها را هم مستند کند. ۴. ابزار code modification برای migrate خودکار چند مورد ساده توسعه دهد. ابزار را روی زیرمجموعه‌های کوچک و منطقی suite اجرا کند تا همهٔ تست‌های کاندید migrate شوند. ۵. گزینهٔ ۲ (بخش «گزینهٔ ۲: تیم‌ها تست‌های خود را به‌روز می‌کنند») را kick-off کند. سیستم mocking جدید را با برجسته‌کردن منافع و اشاره به migrationهای نمونه تبلیغ کند. office hour برای پاسخ سؤال و troubleshooting حضوری راه بیندازد. jam sessionهای منظم در نظر بگیرد که مهندسین در سازمان با تیم شما برای چند migration بپیوندند. ۶. با تیم‌ها objective فصلی برای بهبود کارایی تست‌هایشان تنظیم کند؛ اگر متعهد شده‌اند بر اساس مشارکت ارزیابی شوند، احتمال انجام تست‌ها بیشتر است.

تیم‌های پاک‌سازی (Cleanup Crews)

بعضی سازمان‌های مهندسی بزرگ تیم‌هایی دارند که به بهبود بهره‌وری توسعه‌دهنده اختصاص یافته‌اند. دامنهٔ کار این تیم‌ها می‌تواند بسیار گسترده باشد: provision و مدیریت محیط‌های توسعه؛ نوشتن افزونهٔ ویرایشگر و اسکریپت برای اتوماسیون کارهای تکراری؛ ساخت ابزار برای درک بهتر اثر کارایی تغییرات پیشنهادی کد؛ نگهداری و گسترش کتابخانه‌های هسته‌ای که همهٔ مهندسین محصول به آن وابسته‌اند (شامل logging، monitoring، feature flag و غیره). بیشتر اوقات، تیم‌های developer productivity که در مرزهای اپلیکیشن کنار توسعه‌دهندگان محصول کار می‌کنند نقش cleanup crew را بر عهده می‌گیرند.

Cleanup crewها کار مهم (اما اغلب بی‌تشکر) شناسایی و ریختن cruft و antipattern از کدبیس و جایگزینی الگوهای بهتر و پایدارتر را بر عهده دارند. این تیم‌ها معمولاً از مهندسینی هستند که عمیقاً به سلامت کد اهمیت می‌دهند و می‌خواهند مهندسین محصول توسعه، تست و در نهایت ship قابلیت جدید را آسان داشته باشند. بزرگ‌ترین رضایتشان وقتی است که توسعه‌دهندگان دیگر در شرکت از (و قدردانی کنند از) کتابخانه‌ها و ابزارهایشان.

معمولاً این تیم‌ها بازآرایی‌های سنگین را به دو دلیل بر عهده می‌گیرند. اول، دامنهٔ دانششان از کدبیس بی‌رقیب است. چون مالک کتابخانه‌های هسته‌ای و کاربردی‌اند، معمولاً حداقل exposure به تقریباً هر گوشه‌ای از اپلیکیشن دارند. این به‌ویژه برای تیم‌هایی در monorepoهای بزرگ درست است. دوم، تیم‌ها به توسعهٔ راه‌حل‌های ergonomic که برای همه قابل‌دسترس است ارزش می‌دهند؛ تجربهٔ ارزشمندی در نوع interfaceهایی دارند که تعادل درست بین extensible و practical برقرار می‌کنند. اگر انگیزهٔ اصلی پروژه تقویت بهره‌وری توسعه‌دهنده (و نگه‌داشتن آن) است، این تیم عالی است. دلیل سوم ضمنی این است که با map و اجرای بازآرایی توسط cleanup crew، تیم‌های توسعهٔ محصول می‌توانند نسبتاً بدون اختلال روی توسعهٔ قابلیت تمرکز کنند.

متأسفانه cleanup crewها پایدار نیستند. وقتی این گروه‌ها productive هستند، تیم‌های مهندسی دیگر، معمولاً تیم‌های توسعهٔ قابلیت، احساس مسئولیت کمتری برای تعهد به نگهداری مهم می‌کنند. با گذشت زمان، cleanup crewها کار غیرقابل‌تحملی انباشته و آهسته اعضای تیم را burnout می‌کند. در نتیجه این تیم‌ها معمولاً کوتاه‌عمرند یا turnover بالا دارند. علاوه بر این، تیم‌هایی که از نگهداری شانه خالی می‌کنند به‌تدریج حافظهٔ عضلانی پشتیبانی بلندمدت قابلیت را از دست می‌دهند. انداختن بازآرایی در مقیاس بزرگ دیگر به سمت آن‌ها شاید گزینهٔ عملی نباشد.

تیم ببر (Tiger Team)

tiger team به تیمی از متخصصان فنی اشاره دارد که برای تجربه و انرژی انتخاب شده‌اند تا هدف مشخصی را محقق کنند. (درست مثل Ocean's 11!) این اصطلاح اولین بار در مقالهٔ ۱۹۶۴ Program Management in Design and Development ابداع شد که tiger teamها را روش مؤثر بهبود قابلیت اطمینان سیستم‌های هوافضا و فضایی پیشنهاد کرد. یکی از tiger teamهای مشهور پس از نقص و انفجار ماژول سرویس Apollo 13 برای بازگرداندن ایمن فضانوردان به زمین تشکیل شد. گروه بعداً مدال آزادی ریاست‌جمهوری را برای تلاش‌هایش در مأموریت دریافت کرد.

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

pitch (متقاعدسازی)

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

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

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

متقاعد کردن مهندس تجربه‌ای متفاوت از متقاعد کردن مدیر تیم است. مهندس‌ها به کد نزدیک‌ترند؛ دردهایی که بازآرایی می‌خواهد برطرف کند را ملموس‌تر، حادتر و مکررتر حس می‌کنند. در تجربهٔ من به‌ندرت وقت قابل‌توجهی صرف قانع کردن مهندس می‌کنید که مسئله‌ای که می‌بینید واقعی است؛ اغلب دقیقاً می‌دانند چرا دردهایی که می‌خواهید رفع کنید مهم‌اند چون خودشان چند بار همان درد را تجربه کرده‌اند. با مهندس‌ها احتمالاً می‌توانید بیشتر تکنیک‌های pitch بخش‌های بعد را با موفقیت (شاید ترکیبی) استفاده کنید.

مدیران از دید ثانویه درد را حس می‌کنند؛ مثلاً افزایش تدریجی تخمین زمان در sprint planning به‌خاطر افزایش پیچیدگی کد. در one-on-one بعضی مهندسین ناامیدی از حوادث مکرر به‌خاطر کد شکننده و ضعیف تست را بیان می‌کنند. مدیران هم اغلب انگیزه‌ای برای اولویت بازآرایی بر توسعهٔ قابلیت ندارند، چون معمولاً بر بهره‌وری تیم در ship نوآوری‌های محصول جدید با cadence منظم اندازه‌گیری می‌شوند. صرف یک یا دو فصل برای بهبود کدی که تیم مسئول آن است تا در فصل‌های بعد سرعت توسعه را بالا ببرد برای مدیریت ارشد فروش سخت است، پس مدیران مگر نیاز فوری به پاک‌سازی کد جدال نمی‌کنند. از تکنیک‌های پیشنهادی بعد، توصیه می‌کنم شدیداً روی معیارها و مبادله (bartering) تکیه کنید.

انگیزهٔ مدیران برای سلامت کد

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

معیارها

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

معمولاً این pitchها با expertهای تردیددارتر و داده‌محورتر مؤثرترند. مهندسانی که همیشه سؤال می‌پرسند؛ p95 زمان پاسخ APIهایی که تیم نگه می‌دارد را فعالانه پایش می‌کنند؛ اولین کسانی‌اند که افزایش میانگین عملیات پایگاه داده روی shard مشخص را می‌بینند. با معیارهای خودتان به جنبهٔ تحلیلی‌شان appeal کنید و شاید expert جدید بگیرید.

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

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

سخاوتمندی (Generosity)

ناسازگاری شناختی عجیبی به نام اثر Benjamin Franklin وجود دارد: شانس بیشتری دارید کسی شما را دوست بدارد اگر از او خواهش کنید تا اینکه برایش لطفی بکنید. مثلاً Charlie از Dakota خواهش می‌کند. Dakota خوشحال انجام می‌دهد. پدیده می‌گوید Dakota احتمال بیشتری دارد لطف دیگری برای Charlie بکند تا اگر Charlie برایش لطفی کرده بود. ایده این است که مردم به‌خاطر دوست داشتن کمک می‌کنند، حتی اگر واقعاً دوست ندارند، چون ذهن‌شان با حفظ سازگاری منطقی بین اعمال و برداشت‌ها مشکل دارد.

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

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

فرصت (Opportunity)

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

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

مبادله (Bartering)

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

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

مبادله بین مهندسین

وقتی مبادله بین دو مهندس است، معمولاً تبادل تخصص subject matter است؛ یعنی expertی که به‌عنوان SME جذب می‌کنید می‌خواهد شما در پروژهٔ جاری یا آینده به‌عنوان SME مشارکت کنید. دیده‌ام مهندسین موافقت کنند code review مبادله کنند، shift on-call اضافی اگر rotation مشترک دارند، یا تعداد مشخصی post-mortem را مستند و تسهیل کنند به‌جای expert.

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

تکرار (Repeat)

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

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

چند نتیجه

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

سناریوی واقع‌بینانه

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

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

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

بدترین حالت مطلق این است که نتوانید کمک اضافی بگیرید و باید پروژه را تنها اجرا کنید. قبل از بررسی بهترین استفاده از این وضعیت، می‌خواهم لحظه‌ای تأیید کنم: اگر تنها گزینه‌تان اجرای بازآرایی بزرگ cross-functional به‌تنهایی است، شاید اصلاً انجام ندهید. اگر سازمان مهندسی به‌اندازهٔ کافی با پیشنهاد شما متقاعد نشده staffing را درست تخصیص دهد و expertهایی که مراجعه کردید هم متقاعد نشده‌اند، شاید وقت بازگشت به تختهٔ طراحی و تقویت پرونده است. وگرنه شاید وقت آن باشد بپذیرید شاید اکنون زمان اجرای این پروژه نیست.

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

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

یکی دو حادثه هنگام تغییرات گسترده در کدبیس تقریباً اجتناب‌ناپذیر است. اگرچه post-mortemها باید blameless باشند، وقتی فقط یک فرد مسئول پروژه است، می‌تواند احساس شود بار مسئولیت و remediation بعدی تنها روی شماست نه گروهی از افراد.

فرایند post-mortem در Etsy

شدیداً توصیه می‌کنم اگر هنوز نکرده‌اید به فرایند post-mortem Etsy توسعه‌یافته توسط John Allspaw نگاه کنید. رویکردشان به پاسخ حادثه کامل است و رشد عمدی و متمرکز در سازمان مهندسی را ترویج می‌کند و در عین حال ایمنی روانی مهندسین فردی را حفظ می‌کند.

توصیه می‌کنم buddy پیدا کنید، شاید کسی که او هم تنها مالک پروژهٔ قابل‌توجهی شده. این شخص برای accountable و motivated نگه داشتن شماست، شبیه ملاقات منظم با دوست برای یوگا: می‌دانید آنجا خواهد بود چون شما هم آنجا خواهید بود و بالعکس. cadence منظم برای ملاقات و مرور پیشرفت در پروژه‌های respectiveتان تنظیم کنید. می‌توانید به هم در brainstorm راه‌حل مشکلات سخت کمک کنید و گاهی code یکدیگر را review کنید. در هر صورت داشتن کسی برای همراهی در جادهٔ سخت برای ماندن در مسیر حیاتی است.

پرورش تیم‌های قوی

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

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

---

بخش سوم

اجرا