حالت تاریک
فصل ۵ — جلب تأیید
در سال سوم دبیرستان تصمیم گرفتم به گوشی موبایل نیاز دارم. نهتنها تقریباً همهٔ دوستانم یکی داشتند، دیگر علاقهای نداشتند هر بار برای اطلاع والدینم از جایی که هستم گوشیشان را به من بدهند. با هزینهٔ تقریباً ۱۰ سنت برای هر پیامک و دقیقههای گران تماس، ماهها به نزدیک نیمدوازده دوست سکه و پول خرد میدادم. حمل مشتی پول خرد هر جا که میرفتم و امید به قرض گرفتن گوشی دیگران دیگر به دلم نمینشست.
چون والدینم طرفدار داشتن گوشی برای دخترشان نبودند، قانع کردنشان نبرد سختی بود. «همه دارند» کافی نبود. باید مجموعهای قوی از استدلالهای مبتنی بر شواهد ارائه میدادم. پس چند تا جمع کردم. استدلالی حول داشتن گوشی برای امنیت ساختم. تازه گواهینامه گرفته بودم و در موارد اضطراری باید میتوانستم تماس بگیرم. تخمین تقریبی ساعات رانندگی در هفته را محاسبه کردم تا استدلال وزن بیشتری بگیرد. بعد هزینهٔ دستگاه و طرح را با پولی که شش ماه گذشته به دوستان داده بودم مقایسه کردم. اخیراً شروع به ساخت وبسایت برای درآمد جانبی کرده بودم و میدانستم میتوانم یک گوشی ساده و قبض ماهانه را بپردازم.
در پاسخ به استدلالها، والدین گفتند فکر نمیکنند ضرورت باشد. میتوانستم هنگام خروج از خانه گوشی مادرم را قرض بگیرم. وقتی اشاره کردم هفتهای سه تا چهار ساعت هم خودم و هم برادر کوچکترم را میرانم، تصمیم گرفتند شاید دیگر تجمل نباشد. بهاندازهٔ کافی متقاعد شدند که راحتی داشتن گوشی از هزینهاش بیشتر است. چند روز بعد یک گوشی سادهٔ دستدوم با شمارهٔ خودم گرفتم.
امروز این تجربه وقتی باید دیگران را از منافع شروع پروژهٔ بازآرایی قانع کنم به دردم میخورد. یکی از شکایات رایج همتیمیهایم این است که تمایل قوی به بازآرایی چیزی دارند اما نمیدانند چطور کسی را قانع کنند اجازه دهد. زمان گذاشتهاند شرایطی را که مسئله در آن رخ داده شناسایی کنند، شواهد و معیارها برای توصیف مسئله جمع کردهاند و طرحی دقیق برای حل آن نوشتهاند. مطمئناند مسئله باید حل شود و از راهحلشان هیجانزدهاند، اما هنگام ارائه به مدیر یا tech lead با تردید روبهرو میشوند.
این فصل با توضیح چرا مدیر شما موافق نیست شروع میکند و به فهم دیدگاهشان کمک میکند تا استدلال قانعکننده بسازید. سپس چند رویکرد مختلف برای جلب حمایت تیم مدیریت را پوشش میدهیم، با راهبردهای مشخص برای وادار کردنشان به همراهی. در پایان، اشکال مختلف تأیید و اثرشان روی طرح اجرا و تیمی که سرانجام میسازید را میبینیم.
چرا مدیر شما موافق نیست
مدیر شما ممکن است به دلایل متمایزی نسبت به بازآرایی بزرگ مردد (یا مخالف صریح) باشد. اول، معمولاً از کد دور است و دردها را بهخوبی نمیفهمد. دوم، بر توانایی تیم در ship کردن قابلیتهای مؤثر محصول بهموقع ارزیابی میشود. سوم، بدترین نتایج بازآرایی بزرگ معمولاً جدیتر از بدترین نتایج قابلیت محصول جدید است. در نهایت، بازآراییهای در مقیاس بزرگ هماهنگی بیشتری با ذینفعان خارج از تیم فوری میخواهند.
مدیران کد نمینویسند
بیشتر مدیران مهندسی بهندرت کد مینویسند و تقریباً در code review شرکت نمیکنند. در واقع کسی که مستقیم به مدیریت استخدام شده باشد ممکن است هرگز کدی که تیمش روی آن کار میکند نبیند. چون مدیر با مشکلاتی که شما و تیم مرتب encounter میکنید آشنا نیست، نباید تعجب کند از پیشنهاد شما تردید کند. تصور کنید به مهمان شام توضیح دهید چرا میخواهید همهٔ دستگیرههای لرزان خانه را عوض کنید؛ شاید منطقی بفهمد، اما نمیداند روزانه چقدر آزاردهندهاند. شاید مدیر دشواریهایی که بازآرایی میخواهد بهبود دهد را بفهمد، اما نمیبیند چرا باید الان درست شوند. اگر این مشکلات جدید نیستند، شرکت تا الان (و همچنان) با آنها کنار آمده. مدیر upside ساخت چیز جدید را در برابر رفع مشکلات ماندگار میسنجد.
مدیران متفاوت ارزیابی میشوند
مدیران معمولاً بر توانایی تیم در رسیدن به deadlineها و کمک به اهداف کسبوکار ارزیابی میشوند. اینها شامل ساخت قابلیتهایی برای نگهداشتن و جذب کاربر بیشتر یا باز کردن جریان درآمد جدید است. بهخاطر این انگیزهها، احتمال بیشتری دارند کار با نسبت اثر به تلاش بالا — یعنی نسبتاً کمتلاش اما پراثر — را اولویت دهند. همچنین deadlineهای تهاجمیتر برای رساندن زودتر تغییرات به مشتری تعیین میکنند.
این اهداف گاه با اهداف مهندسین تیم در تضاد است. مهندسین معمولاً پروژههایی را میجویند که مسئلهٔ جالب حل کنند و اغلب راهحل مقاومتر را بر ship سریع ترجیح میدهند. (همه در این قالب نیستند، اما در تجربهٔ من خلاصهٔ خیلیهاست.) بازآرایی بزرگ، اگرچه برای شما و همتیمیها معنادار و ارزشمند است، در پایین فهرست پروژههای احتمالی مدیر است. بازآراییهای در مقیاس بزرگ معمولاً طولانیاند و چون عمداً برای کاربر نامرئیاند، اثر مثبت فوری کمی برای کسبوکار دارند. اگر مدیر به دنبال ارتقا (یا نگران review پیشرو) باشد، احتمالاً کمتر از طرح شما حمایت میکند.
ریسک برای مدیر
حتی اگر مدیر متقاعد شود بازآرایی ارزشمند است، ممکن است با go-ahead به موقعیت خوب خود ریسک کند. همانطور که مدیر بر توانایی تیم در ساخت و تحویل بهموقع ارزیابی میشود، مدیر خودش هم بر اثر سازمانش روی کسبوکار ارزیابی میشود. برای مدیر سخت است مدیر خودش را قانع کند بازآرایی سرمایهگذاری ارزشمند زمان و منابع مهندسی است.
مدیران ریسک را میبینند
چند راه وجود دارد توسعهٔ قابلیت خراب شود. تیم به مانع میخورد و کمی دیرتر ship میکند، یا قابلیت به دست کاربر میرسد و باگهای زیادی آشکار میشود. اما احتمال outage فاجعهبار در توسعهٔ قابلیت جدید نسبتاً کم است چون قابلیتهای جدید معمولاً محدودهٔ مشخص و مرزهای نسبتاً روشنی دارند.
اهمیت هنگام اجرای بازآرایی در مقیاس بزرگ بسیار بیشتر است. تیم ریسک regression در سطح وسیع دارد و احتمال outage فاجعهبار بهمراتب ناچیز نیست. هنگام باز کردن کد قدیمی و کهنه، شانس بیشتری دارید باگهای غیرمنتظره پیدا کنید؛ ریسک کشیده شدن به سوراخ خرگوش برای رفع آنها میتواند deadlineها را بهطور قابلتوجهی به تأخیر بیندازد.
هر یک از ریسکهایی که در فصل ۱ برجسته کردیم برای مدیر شما آشکاراً نگرانکننده است.
مدیران باید هماهنگ کنند
بیشتر شرکتها تیمهای مهندسی را حول بخشهایی از محصول (یا محصولات) سازماندهی میکنند. فرض کنید برای اپلیکیشن پخش موسیقی به نام RadTunes کار میکنید. RadTunes ممکن است تیمی برای ساخت playlist و تیمی برای مدیریت جستجو داشته باشد. وقتی تیمی قابلیت جدید میسازد، معمولاً در بخشی از کدبیس که مالک آن است کار میکند. عجیب است تیم Search قابلیت playlist مشارکتی بسازد؛ انتخاب واضحتر تیم Playlist است.
حالا فرض کنید در تیم Playlist هستید و با مدل شیء song مشکل دارید. طرحی برای بهبود دارید، اما شامل تغییر کدی است که تقریباً همهٔ تیمهای شرکت مرتب با آن کار میکنند. شما و مدیر باید از ابتدا با همهٔ این تیمها هماهنگ کنید تا حمایت بگیرید و در طول بازآرایی هماهنگ بمانید تا همه همراستا باشند. وقتی بازآرایی را به مدیر pitch میکنید، مقدار عظیم کار لازم برای سازماندهی همه در کل مدت پروژه را میبیند. طبیعی است مردد از حمایت باشد.
تأیید در عمل چگونه است
قبل از پرش به راهبردهای متقاعدسازی، باید بفهمیم تأیید در عمل چگونه است. تأیید روی طیفی است. مدیریت میتواند کاملاً موافق، کاملاً مخالف، یا هر چیزی بین این دو باشد. بیشتر وقتها جایی در میانه تمام میشود. تصمیم برای پیشروی با بازآرایی در مقیاس بزرگ اغلب به دو سؤال برمیگردد:
آیا زمان مناسبی برای بازآرایی است؟ بازآراییهای در مقیاس بزرگ میتوانند سرمایهگذاری گرانی از نظر زمان توسعه باشند. چون پرهزینهاند (و میخواهیم مطمئن باشیم زمان کافی برای تکمیل پروژه budget شده)، باید مطمئن باشیم در زمان مناسب برای شرکت kick-off میکنیم. یعنی در نظر گرفتن زمان تکمیل پروژههای جاری و پروژههایی که شرکت (بهویژه تیم شما) قصد ship در فصلهای آینده دارد.
قبل از pitch به مدیر، مشخص کنید چه زمانی فکر میکنید تیم باید کار روی بازآرایی را آغاز کند و دقیقاً چرا آن زمان بهینه است. مثلاً آیا زمان مناسب است چون مشکلاتی که بازآرایی میخواهد حل کند هنوز به نقطهٔ بحرانی نرسیدهاند و زمان کافی برای راهحل ایدهآل دارید؟ یا شاید چون اجرای بازآرایی اکنون میتواند به تیم در پروژههای آینده کمک قابلتوجهی کند. هر کدام از این ملاحظات برای مدیر هنگام جلب حمایت مفید است.
چند منبع (اغلب بهصورت مهندس) باید اختصاص یابد؟ بازآرایی میتواند سرمایهگذاری گرانی از نظر منابع هم باشد. بسته به سطح تأییدی که از مدیر میگیرید، شاید نتوانید تیم ایدهآل را بسازید — فصل ۶ نگاه طولانیتری دارد. توجه کنید منابع میتواند مستقیماً تحتتأثیر زمان شروع پیشبینیشدهٔ بازآرایی باشد و بالعکس.
این فصل فرض میکند مدیر شما در همهٔ جنبههای بازآرایی مخالف است. اما اگر مدیر تا حدی موافق است و حمایت بیشتر میخواهید، میتوانید از هر یک از تکنیکهای توضیحدادهشده برای هل دادن مدیر در جهت درست استفاده کنید.
راهبردهای ساخت استدلال قانعکننده
حالا که میدانیم چرا مدیر موافق نیست، میتوانیم روی چند راهبرد مفید برای آرام کردن ترسها و ساخت پروندهٔ محکم برای قانع کردنشان به ارزش بازآرایی تمرکز کنیم. این بخش فرض میکند قبلاً گفتوگوی اولیهٔ اکتشافی با مدیر دربارهٔ پروژه داشتهاید. اگر هنوز نداشتهاید، «گفتوگوی اولیه» نقطهٔ شروع خوبی است. این گفتوگو به دو دلیل مهم است: اول، کمک میکند بفهمید کدام عوامل بیشترین وزن را برای مدیر دارند. دوم، حس میدهد آیا مدیر با استدلال احساسی یا منطقی راحتتر متقاعد میشود. این گفتوگو زمینهٔ اولیه برای انتخاب مؤثرترین راهبردها میدهد.
گفتوگوی اولیه
بهجای اینکه مدیر را با همهٔ اطلاعات جمعآوریشده تا الان له کنید، اول نظرش را بپرسید. میتواند به سادگی شروع گفتوگو در one-on-one با «فکر میکنم X روی توانایی ما برای انجام Y اثر میگذارد و میخواستم بدانم نظری دارید یا نه» باشد. با خواستن نظرشان نشان میدهید به دیدگاهشان ارزش میدهید و فرصت مهمی برای صادق بودن به شما میدهید.
اگر مدیر با مسئله آشناست، میتوانید زود بفهمید آیا از بازآرایی حمایت میکند. اگر مردد به نظر میرسد، از آنچه دربارهٔ دیدگاهشان بهعنوان مدیر یاد گرفتید برای pinpoint کردن بیشترین نگرانی استفاده کنید.
اگر مدیر با مسئله ناآشناست، نمای کلی ساده و بیطرف بدهید. مدیر خوب میخواهد بفهمد چرا نگرانید و سؤالهایی میپرسد که مسئله را برای خودش درست توصیف کند.
گوش دادن در این گفتوگو حیاتی است. خیلی از ما وقت را صرف فکر کردن به آنچه میخواهیم بعد بگوییم میکنیم نه پردازش واقعی حرف طرف. یادداشت بردارید — ذهنی یا نوشته؛ هر روشی که برایتان کار میکند. (من گفتوگوهای حضوری را سریع فراموش میکنم، پس نوشتن برایم مهم است.)
بهجای counterpoint، سؤال بپرسید. مثلاً بهجای «بهخاطر X کار نمیکند» بپرسید «به X فکر کردهاید؟» یا «برنامهتان برای X چیست؟» این نشان میدهد بیشتر به دیدگاه مدیر اهمیت میدهید تا درست بودن، و فرصت پاسخ به آنها میدهد.
توصیه میکنم این گفتوگو را حضوری یا ویدئو کنفرانس برگزار کنید، نه ایمیل یا چت. حالت چهره و لحن مدیر هنگام سنجش نگرش نسبت به بازآرایی احتمالی واقعاً مهم است.
پس از گفتوگوی اولیه با مدیر، میتوانید روی تکنیکهای متقاعدسازی تمرکز کنید. چهار تکنیک ساده و متمایز را اینجا outline میکنیم، اما فهرست کامل نیست. راهبردهای مختلف با مدیران مختلف بهتر کار میکنند، بسته به آنچه بیشتر انگیزه میدهد (مثلاً مسیر رشد در شرکت) یا میزان مخالفت (مثلاً موافق با وجود مسئله اما متقاعد نشده که فوری باید حل شود). در نهایت مؤثرترین راه هل دادن مدیر به go-ahead ترکیب تکنیکهاست: آنهایی که بیشترین اثر را دارند و راحتتر استفاده میکنید. اگر با اطمینان و آمادگی خوب پیش بروید، شاید همان «بله»ای را که میخواستید بگیرید.
استفاده از ابزارهای گفتگویی
بعضی همکاران میتوانند در جلسهای پر از مهندسین سرسخت در نیم ساعت همه را به نظرشان قانع کنند. متأسفانه من یکی از آنها نیستم. اگر شما هم نیستید، نگران نباشید! چند ترفند گفتگویی آسان (و صادقانه) داریم تا قانعکنندهتر بیان کنیم.
تعریف از فرایند فکری آنها خیلی کماند کسانی که در برابر تعریف مصوناند، مدیر شما هم نه. اگر در هر نقطهای از گفتوگو موافقید، با تعریف برجسته کنید. مثلاً موافقید بازآرایی مفید است، اما مدیر ترجیح میدهد شش ماه بعد دوباره ارزیابی شود. میتوانید با گفتن «نکات خیلی خوبی دربارهٔ منافع بالقوهٔ بازآرایی گفتید. واضح است درک nuanced از مشکلاتی که داشتهایم دارید» تمرکز را به منافع برگردانید. مدیر به منافعی که خودش شناسایی کرده یادآوری میشود و تمایل دارد آنها را در برابر معایب سنگینتر بسنجد.
ارائهٔ counter-argument نهتنها باید برای counter-argumentهای مدیر آماده باشید، شاید حتی خودتان آنها را مطرح کنید. عجیب به نظر میرسد، اما مطالعات روانشناسی نشان داده استدلالهای دوطرفه قانعکنندهتر از یکطرفهاند. مزایای مطرح مستقیم counter-argumentها:
- با نشان دادن اینکه جدی به معایب بازآرایی در مقیاس بزرگ فکر کردهاید، thoughtfulness و دقت بیشتری در تلاش نشان میدهید.
- نگرانیهای مدیر را تأیید میکنید؛ شاید مستقیم تعریف نکنید، اما تأیید میکنید تردیدشان مشروع است. مدیر برای شنیدن ایدههای شما بازتر است اگر احساس کند ایدههای خودش خوب فهمیده شدهاند.
نکتهٔ استفاده از counter-argument به نفع خودتان، refute دقیق آنهاست. به مثال RadTunes در «مدیران باید هماهنگ کنند» برگردیم. مدیر برنامهریزی کرده تیم Playlist بیشتر فصل آینده روی playlistهای مشارکتی کار کند. شما پیشنهاد میدهید تیم قبل از توسعهٔ قابلیت جدید وقت حیاتی صرف بازنویسی نمایش song در اپلیکیشن کند.
میتوانید بگویید «اگر فصل بعد بازآرایی song را شروع کنیم، باید کار روی playlistهای مشارکتی را چند ماه به تأخیر بیندازیم. برای مشتریانی که سالها این قابلیت را خواستهاند قطعاً ناامیدکننده است.» فوراً با rebuttal جواب دهید: «با این حال مطمئنم اگر پیادهسازی song را بازنویسی کنیم، چند هفته از توسعهٔ playlist مشارکتی کم میکند و تیم Search را برای نتایج بهتر بر اساس genre unblock میکند.»
حتی counter-argumentی که مدیر هنوز نگفته یا بعید است بگوید معرفی کنید. counter-productive به نظر میرسد، اما اگر موفق refute کنید اعتماد و موضع شما را تقویت میکند.
کتاب پیشنهادی
این کتابی نیست که معمولاً روی قفسهٔ برنامهنویس ببینید، اما شدیداً توصیه میکنم نسخهای از How to Win Friends and Influence People اثر Dale Carnegie بگیرید. بیش از ۸۰ سال پیش منتشر شد، اما بیشتر درسهایش امروز هم برقرار است. مهارتهایی که میآموزد نهتنها برای جلب تأیید پروژهها، بلکه در همهٔ جنبههای زندگی مفید است!
ساختن ساندویچ همراستایی
اگر علاقهای به بازی سیاسی دفتر ندارید، کاملاً قابلقبول است و میتوانید به بخش «تکیه بر شواهد» بروید. اگر میخواهید از چشمانداز سازمانی به نفع خود استفاده کنید، اهرمهای زیادی برای وادار کردن مؤثر مدیر به go-ahead بازآرایی در مقیاس بزرگ دارید. میتوانید ساندویچ همراستایی بسازید: حمایت همتیمیها را با حمایت مدیریت ارشد بگیرید و مدیر را بین این دو قرار دهید.
این رویکرد فقط وقتی کار میکند که از هر دو طرف ساندویچ حمایت کافی داشته باشید. اگر مدیر فقط فشار از تیم شما را حس کند، هنوز پای محکمی برای رد بازآرایی دارد، با دانستن اینکه از بالادستیها فشار کمی (یا اصلاً) نمیآید. اگر فقط فشار از بالا باشد و تیم شما آوازهدار حمایت نباشد (یا بدتر، مخالف باشد)، با دانستن ریسک آسیب به روحیهٔ تیم بهسختی پیش میرود.
مراقب باشید این راهبرد میتواند backfire کند. با توجه به گفتوگوی قبلی، مدیر میداند به بازآرایی علاقهمندید. اگر از مدیریت ارشد یا افراد تأثیرگذار دربارهٔ پیشروی با بازآرایی approached شود، ممکن است دو و دو را جمع کند و بفهمد دنبال نفوذ خارجی بودهاید. اگر رابطهٔ شکننده با مدیر دارید، ممکن است backlash بیاید. صرفنظر از قدرت رابطه، سعی کنید صریح بگویید نظرات خارجی را خواستهاید؛ سپس بهجای اینکه این متحدان مستقیم به مدیر مراجعه کنند، جلسهٔ سهنفره برای بحث دیدگاهها تنظیم کنید.
جمع کردن همتیمیها
قبل از مراجعه به مدیریت ارشد، وقت بگذارید همتیمیها را همصفحه کنید. احتمالاً در مراحل اکتشافی قبلی (جمع معیارها، نوشتن طرح اجرا) با بعضی دربارهٔ جنبههای بازآرایی صحبت کردهاید. برای کسانی که هنوز از فرایند فکری شما خبر ندارند، وقت بگذارید توضیح دهید. لازم نیست رسمی باشد؛ پیام بفرستید یا برای قهوه بخواهید.
هدف نهایی این است که برای بازآرایی در جایی که مدیر حضور دارد (جلسه، چت عمومی، ایمیل) یا در one-on-one خودشان با مدیر vouch کنند. شاید بخواهید هماهنگ کنید همه در همان هفته در one-on-one مطرح نکنند؛ نکته این است که علاقهٔ همه organic به نظر برسد، نه از پیش آماده. وقتی حمایت کافی از همتیمیها گرفتید، لایهٔ پایین ساندویچ را ساختهاید.
skip-level
اگر مدیر به بازآرایی در مقیاس بزرگ علاقه ندارد، شاید مدیر مدیر (skip-level) علاقه داشته باشد. مدیریت ارشد معمولاً دید گستردهای از اهداف سازمان و پروژههای فعلی و آینده دارد. با این دید گستردهتر، skip-level ممکن است نسبت به مدیر مستقیمتر به بازآرایی در سطح وسیع همدردتر باشد چون دامنهٔ منافع را بهتر visualize میکند.
سلسلهمراتب سختگیر
بعضی شرکتها سلسلهمراتب سخت دارند که رفتن مستقیم به skip-level faux-pas بزرگی است. قبل از رزرو وقت با مدیر مدیر، مراقب باشید چگونه دیده میشود. حداقل مواظب باشید مدیر مستقیم را سرزنش نکنید؛ روی ایجاد علاقه و همراستایی در بازآرایی تمرکز کنید.
اگر رابطهٔ از قبل با skip-level دارید و دلیل دارید از تلاش حمایت میکند، جلسه تنظیم کنید. گفتوگوی اولیه باید شبیه گفتوگو با مدیر باشد (بخش «گفتوگوی اولیه»). این تبادل کمک میکند بفهمید skip-level احتمالاً از بازآرایی پیشنهادی حمایت میکند. اگر حامی قوی نیست، حمایت افراد تأثیرگذار دیگر را برای لایهٔ بالای ساندویچ بجویید. اگر حمایتگر به نظر میرسد، جلسهٔ دوم تنظیم کنید: جزئیات طرح اجرا، همراستایی روی منابع لازم، و چگونگی کمک برای تأیید مدیر.
رابطه با skip-level
رابطهٔ قوی با skip-level صرفنظر از اهداف بازآرایی مفید است. در واقع اگر ممکن است توصیه میکنم one-on-one فصلی (یا حتی ماهانه) با skip-level داشته باشید. مدیریت ارشد منبع ارزشمندی اگر بخواهید دامنهٔ کارتان بهعنوان مهندس گسترش یابد؛ اگر برای رشد مهارتها به رهبری پروژهٔ مؤثر در بخش سازمان نیاز دارید، پروژهٔ مناسب را شناسایی میکنند. اگر mentorship میخواهید، شما را به مهندسین ارشد شرکت وصل میکنند. رابطهٔ برقرار با skip-level هم در دشواریهای رابطه با مدیر مستقیم، اگر پیش آید، کمک میکند.
دپارتمانها
در هر شرکت معمولاً چند دپارتمانی هستند که اختیار قابلتوجهی روی کسبوکار دارند. وقتی نظرشان لازم است، تصمیم نهایی است — چه در طراحی قابلیت جدید، فرایند جدید، یا رفع باگ. در بسیاری از صنایع (خدمات مالی، بهداشت، منابع انسانی) این دپارتمان legal و compliance است. اگر چند ماه در شرکت هستید، احتمالاً حدس میزنید کدام دپارتمان است. اگر مطمئن نیستید، از همسالها بپرسید؛ شاید داستانی از دخالت دپارتمان امنیت در حادثه یا نظر تیم فروش در قابلیت جدید داشته باشند.
در بعضی موارد (نه همه)، این دپارتمانها به بازآرایی شما علاقهمندند. مثلاً تیم compliance در Smart DNA، شرکت بیوتکنولوژی از بخش «در محل کار» در فصل ۴. بالاتر از همه، مسئول اطمینان از ایمنی DNA توالیشدهٔ مشتریان در همهٔ اوقات است. داشتن بیشتر سیستمهای شرکت روی نسخهٔ منسوخ Python برایشان نگرانکننده است چون دیگر patch امنیتی اعمال نمیشود. اگر تیم پژوهش از بهروزرسانی وابستگیهای Python حمایت نمیکرد، تیم نرمافزار میتوانست به compliance مراجعه کند و راههای زیادی که اجرای نسخهٔ پشتیبانینشدهٔ Python آسیبپذیری است را فهرست کند. تیم compliance سپس روی مدیران مهندسی لازم فشار میگذارد تا مهاجرت را اولویت دهند و لایهٔ بالای ساندویچ تکمیل میشود.
جذب مهندسین تأثیرگذار
هر شرکت چند (یا دو) مهندس بسیار تأثیرگذار دارد؛ ترکیبی از اعضای بسیار ارشد فنی (principal و distinguished engineers)، مدت زیاد در شرکت، یا در بعضی موارد هر دو. بسیاری از آنها، اگر نه بیشتر، هنوز عمیق در کدند. اگر با سطحی که میخواهید بهبود دهید آشنا باشند، نهتنها فوراً مشکلاتی که بازآرایی حل میکند را میفهمند، بلکه بینش ارزشمندی به طرح تا امروز میدهند. حمایت آنها میتواند در مشروعیتبخشی تلاش برای مدیر حیاتی باشد. در بعضی شرکتها هیچ تأییدی بزرگتر از thumbs-up مهندس ارشد نیست. اگر thumbs-up بگیرید، لایهٔ بالای ساندویچ محکم است.
اگر حمایت چند تأثیر ارشد (skip-level، دپارتمانهای حیاتی کسبوکار، مهندسین بسیار تأثیرگذار) را جمع کنید، بهتر است! ساندویچ همراستایی لازم نیست کاملاً متعادل باشد؛ کمی سنگینتر از بالا رویکرد را قویتر میکند.
پاداش دادن به بازآرایی
اگر با مدیریت (میانی و ارشد) رابطهٔ سالم دارید و میخواهید بازآرایی و نگهداری نرمافزار در شرکت اولویت یابد، میتوانید از این روابط برای ساخت سیستمهایی که آن را پاداش میدهند استفاده کنید. در سطح individual contributor، هیچ مهندسی نباید بشنود بازآرایی معادل خودکشی شغلی است؛ با کمیتههای ارتقای مهندسی و منابع انسانی کار کنید تا نگهداری کد را شامل و تشویق کنید. در سطح مدیریتی، هیچ مدیری، صرفنظر از جایگاه در سلسلهمراتب، نباید فرهنگ تولید بدهی فنی ایجاد کند. بعضی شرکتها با الزام مدیران به گنجاندن تلاشهای نگهداری در برنامهریزی فصلی، حتی برجستهکردن کیفیت کد و نگهداری در نردبان شغلی مدیریت، موفق شدهاند بدهی فنی را کم کنند. مدیریت فقط اطمینان از کارآمد، خوشحال و ship بهموقع قابلیتهای باکیفیت نیست؛ کار غیرجذاب نگهداری و بهبود کد موجود هم هست تا با شرایط متغیر مقیاس بگیرد.
تکیه بر شواهد
اگر مدیر به استدلالهای منطقی علاقه دارد، از شواهدی که در فصل ۳ جمع کردید برای تقویت موضع استفاده کنید. زمانی با مدیر برای ادامهٔ گفتوگوی اولیه تنظیم کنید. بگویید بیشتر فکر کردهاید و وقت گذاشتهاید مسئله را توصیف کنید تا ارزش (و امیدوارانه فوریت) آن را بهتر درک کند.
قبل از جلسه، شواهد را آماده کنید. اگر شواهد زیاد جمع کردهاید، روی دو یا سه مورد تکاندهندهترین تمرکز کنید. بعضی معیارها در قالب بصری بهتر منتقل میشوند؛ نمودار یا دو برای تأکید نقاط بسازید. زمان صرف سنتز این اطلاعات در رسانهای که مصرف برای مدیر آسان است به چند دلیل مفید است: اول، سندی جامع برای circulation به افراد علاقهمند در شرکت میدهد — مفید هنگام جلب حمایت بینعملکردی یا جذب همتیمی (فصل ۶). دوم، چیزی دارید که در جلسه به آن ارجاع دهید. برای کسانی که در متقاعدسازی مطمئن نیستند، مجموعهٔ روشن نکات در طول بحث میتواند همهچیز را عوض کند.
استدلال معیارها برای مهندسین خجالتی
برای مهندسینی که کمی خجالتیترند و هنوز سرمایهٔ اجتماعی لازم برای تکیه به همکاران تأثیرگذار یا بازی سخت با مدیر را نساختهاند، توصیه میکنم شدیداً روی استدلال معیارها تکیه کنند. حقایق آمادهسازی، حفظ و refute آسان دارند.
بازی سخت
اگر بهشدت مطمئنید بازآرایی برای کسبوکار حیاتی است و مدیر حاضر به انعطاف نیست، چند گزینهٔ شدیدتر دارید. ارائهٔ این گزینهها اغلب playing hardball نامیده میشود. هشدار: هر کدام میتواند جدی رابطه با مدیر و همکاران را به خطر بیندازد. وقتی موفق باشد، میتواند واقعاً مؤثر باشد و اگر بازآرایی موفق شود (که با خواندن این کتاب حتماً میشود)، میتواند حرفه را جلو بیندازد.
همه در موقعیت قوی کافی (در نقش فعلی یا مالی) برای playing hardball با مدیر نیستند و اشکالی ندارد! باید clout قابلتوجهی و سابقهٔ طولانی عملکرد خوب در نقش فعلی ساخته باشید تا این کار را بکشید.
نکتهٔ نهایی قبل از ورود: در هر دو تاکتیک باید حاضر به follow-through باشید. اگر مدیر bluff شما را صدا زد و متقاعد نشد، نهتنها رابطه را فرسایش میدهد، بلکه توانایی استفادهٔ موفق از رویکرد مشابه در پروژهٔ مهم بعدی را کم میکند.
توقف کار نگهداری پاداشنشده
وقتی نیاز جدی به بازآرایی در مقیاس بزرگ است، معمولاً مقدار غیربدیهی کار پشت صحنه برای نگهداشتن سیستمها عملیاتی در جریان است. مدیریت معمولاً از این کار بیخبر است، یا اگر هست، اهمیتش را نمیشناسد. اگر فعال و مرتب راهی برای کاهش مسئلهای که بازآرایی میخواهد حل کند پیدا میکنید، میتوانید به مدیر هشدار دهید دیگر این کار را نمیکنید. ایده توقف هر کار نامرئی است که مانع دیدن مدیریت مسئلهای میشود که بازآرایی میخواهد حل کند.
مثلاً مهاجرت Python در SmartDNA: قبل از rollout Python 2.7 به همهٔ محیطها، هر بار patch امنیتی منتشر میشد، تیم باید وقت ارزشمند صرف port کردن patch به سیستمهای منسوخ Python 2.6 میکرد. چون patchهای امنیتی قابل پیشبینی نیستند، هر بار آسیبپذیری جدید کشف میشد، تیم باید همهٔ کار قابلیت را متوقف و انرژی را به port کردن patch هدایت میکرد. این نگهداری بسیار وقتبر و پرریسک بود، اما در شرایط لازم. متأسفانه مدیریت حاضر نبود این هزینهٔ عملیاتی اجرای نرمافزار منسوخ را بشناسد.
در این سناریو میتوانید با پیشنهاد اینکه تیم دیگر patch امنیتی جدید را port نمیکند به مدیر فشار بیاورید تا ارتقای Python را اولویت دهد. بگویید میخواهید مرز مناسب برای تیم تعیین کنید؛ با تمرکز اصلی تیم روی توسعهٔ قابلیت، میتوانید assert کنید پشتیبانی نرمافزار legacy که تیم پژوهش اجرا میکند بهطور صریح مسئولیت نیست. اگر در برنامهریزی فصلی یا سالانه مدیر بهدرستی کار port منظم patch را در نظر نگرفت، تأکید کنید.
بله، خط سخت میکشید. شاید گناهکار باشید که دیگر نگهداری مهم نمیکنید (که بیشتر توسعهدهندگان باور دارند بخش حیاتی کارشان است). کاملاً طبیعی است. من قبلاً این استدلال را کردهام و نگران بیمسئولیتی و ناامید کردن شرکت بودم. فهمیدم با ایستادن روی موضع دقیقاً برعکس عمل میکردم؛ به کسبوکار نشان میدادم کجا blindspot مهم دارد و اهمیت آن blindspot چقدر است. با بازتعریف انتظارات با مدیر، گستردگی کار لازم برای عملیاتی نگهداشتن سیستمها بدون بازآرایی قابلتوجه را روشن میکنید.
دادن اولتیماتوم
اگر همهٔ راهها شکست خورد، میتوانید به مدیر بگویید اگر همچنان مخالف بماند، یا به تیم دیگر منتقل میشوید یا از شرکت استعفا میدهید. اگر میخواهید در همان شرکت بمانید و میتوانید تیم عوض کنید، قبل از مطرح کردن با مدیر تیمی را که میخواهید بپیوندید شناسایی کنید؛ بهتر است مدیر حامی بازآرایی در جای دیگر شرکت را پیدا کنید که علاقهمند است شما به تیمش بپیوندید. اگر عوض کردن تیم ممکن نیست، شاید تهدید به استعفا. این تصمیم را با فکر بگیرید و جدی بررسی کنید آیا ثبات مالی لازم را دارید قبل از صحبت با مدیر.
این گفتوگو با مدیر آسان نیست. اول بگویید نگرانید شرکت مشکلاتی که شناسایی کردهاید جدیتر نمیگیرد. اگر مدیر مشتاق است شما را در تیم نگه دارد، شاید دوباره ارزیابی کند و اجازه دهد بازآرایی پیش برود.
تأیید شکل بازآرایی را میدهد
اگرچه جلب تأیید خیلی قبل از نوشتن یک خط کد اتفاق میافتد، میتواند یکی از سختترین جنبههای بازآرایی در مقیاس بزرگ باشد. مدیران میتوانند با دلایل خوب نسبت به kick-off تلاش طولانی و مهندسیمحور مردد باشند؛ محدودیتها و انگیزههای خودشان در سازمان مهندسی را دارند. با این حال هر کدام از ما میتوانیم تکنیکهای متقاعدسازی را یاد بگیریم و برتری کنیم تا با وجود تردیدها تلاش را ارزشمند نشان دهیم. میتوانیم یاد بگیریم چطور مؤثر روی همتیمیها و همکاران در سازمان گستردهتر تکیه کنیم تا حمایت اضافی بگیریم.
پس از فروکش گرد و غبار، بسته به میزان تأییدی که گرفتهاید، شاید بتوانید بازآرایی را اجرا کنید یا نه. اگر مدیر همچنان تردید دارد، پروژه را فعلاً کنار بگذارید. میتوانید به جمع شواهد حمایتی ادامه دهید و منتظر لحظهٔ مناسبتر برای مطرح مجدد موضوع بمانید. مثلاً اگر شرکت از حادثهای رنج ببرد که مسئلهای که بازآرایی میخواهد حل کند علتش بود، زمان خوبی برای زنده کردن گفتوگو با مدیر است. دفعهٔ بعد که تیم وارد فاز برنامهریزی بلندمدت شد، بازآرایی را دوباره پیشنهاد دهید. چشم و گوش باز برای فرصتهایی که نور تازهای روی بازآرایی میتاباند.
اگر تأیید گرفتهاید — چه بلهٔ پرشور چه تأیید ولرم — باید از آن حمایت برای جمع منابع پروژه استفاده کنید. باید مشخص کنید کدام مهندسین برای بیشترین شانس موفقیت لازماند و در کدام مراحل تخصصشان نیاز است. همهٔ آنچه برای این تصمیمها لازم است در فصل ۶ بحث میکنیم.