رابطه تیم توسعه با بقیه سازمان

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

«مهندسی» اینجا یعنی چه

در این درس مت زیاد می‌گوید engineering به‌جای development. دلیلش ساده است: در این درگیری‌ها، بقیهٔ سازمان معمولاً IT و UAT و تست را هم با توسعه در یک جبهه می‌گذارند. پس وقتی می‌گوییم تیم مهندسی، منظور همان طرفِ میز است — نه فقط کسانی که روزانه کد می‌زنند.

مسائل بین مهندسی و بقیهٔ سازمان بعضی جاها در همهٔ شرکت‌ها تکرار می‌شوند؛ بعضی‌ها به نوع سازمان وابسته‌اند. گروه‌بندی مت کامل نیست؛ از تجربهٔ شخصی‌اش آمده. پنج گروه می‌بیند:

غیرانتفاعی: ابرقهرمان، عذاب وجدان، یا رؤیا

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

در غیرانتفاعی کوچک معمولاً ابرقهرمانی هستی که همه‌چیز را می‌کند: فرانت، بک، موبایل، و تعمیر پرینتر. اگر به تکنولوژی مربوط باشد، از تو انتظار دارند درستش کنی. نتیجه خیلی وقت‌ها burnout است، یا رفتن — چون برای این حجم کار به اندازهٔ کافی حقوق نمی‌گیری. گاهی ذهنیت «همه دست به کار» است. گاهی از روز اول انتظار غیرواقعی بوده. و گاهی اولین نفری که استخدام کردند jack-of-all-trades بود — کمی برنامه‌نویس، کمی همه‌چیز دیگر — و آن شخص رفت. بعد گفتند «یک برنامه‌نویس دیگر بگیریم» و یک دولوپر معمولی استخدام کردند با همان انتظار قبلی، بی‌آنکه بدانند چقدر بزرگ است.

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

و بعضی غیرانتفاعی‌ها رؤیا هستند: فشار تحویل غیرواقعی نیست، به رشد بلندمدت و سلامت آدم‌ها اهمیت می‌دهند. مت این را زیاد در نهادهای عمومی مثل دانشگاه دیده.

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

سه مسئله که تقریباً همه‌جا هست

مت برای همهٔ این‌ها جواب کامل ندارد. ولی دو منبع تکراری می‌بیند.

منبع اول: کاریکاتور ریش‌بلندِ نِرد

اعضای تیم مهندسی یک مشت neckbeard nerd دیده می‌شوند که نمی‌فهمند چه چیزی برای کاربر و شرکت مهم است؛ فقط می‌خواهند روی هوس نِردی براق کار کنند. مت آرزو می‌کند این کاریکاتور کاملاً بی‌پایه باشد. نیست. واقعاً اتفاق می‌افتد.

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

منبع دوم: توسعه به‌عنوان شغل فنیِ تکراری

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

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

درمان باید از رهبری مهندسی بیاید — یعنی از تو

اگر این‌ها در سازمانت قابل حل باشند — که همیشه نیستند — معمولاً باید رهبری مهندسی حلشان کند. امید مت این است که آن رهبری تو باشی.

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

وقتی کاریکاتور راست از آب درمی‌آید

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

مت تعارف ندارد: اگر دولوپرهایت — مخصوصاً اگر offshore و ارزان باشند — بدون مشخصات پیکسل‌به‌پیکسل کار را تمام نمی‌کنند، شاید این درد بخشی از معامله‌ای باشد که با استخدام butts-in-seats بسته‌ای؛ معمولاً با ارزان‌ترین نرخ ممکن.

همین منطق برای سمت دیگر هم هست. اگر تیمت را neckbeardهایی می‌بینند که دوست دارند قبل از هر کلاس `final` بگذارند به‌جای کار مفید، و واقعاً bike-shedding می‌کنند یا جونیورهای بی‌فایده‌اند، بقیهٔ شرکت شاید حق دارد آن‌ها را نیازمند میکرو ببیند — چون شاید هستند.

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

اگر دولوپرهای همدل و توانا داری: بقیه را درست کن

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

یک راه: تمایل کلی دولوپرها به چیزهایی مثل shiny object syndrome را بپذیر. نشان بده برای مهارش چه کرده‌ای. بعد همان پذیرش نقد را بچرخان: جنبه‌های دیگر درخواست‌تان مشروع است — مثلاً اجازهٔ پرداخت technical debt، یا بودجهٔ کنفرانس. ارزشش را به زبان غیرفنی بگو. از هزینهٔ شرکت بگو اگر بدهی فنی آن‌قدر بماند که نپرداختنش گران تمام شود. از سود رشد مداوم دولوپرها بگو. زبان آن‌ها را حرف بزن؛ در همان حرف، از تیمت دفاع کن.

نمونهٔ پیچ technical debt به مدیرعامل:

تو: می‌خواهم چیزی را روی میز بگذارم که شبیه فیچر نیست؛
    ولی اگر نگذاریم، سه ماه دیگر فیچر هم نداریم.

CEO: یعنی اسپرینت را به «کار داخلی» می‌دهی؟
     مشتری که technical debt نمی‌بیند.

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

CEO: پس این سرمایه‌گذاری است، نه تعطیلی فیچر؟

تو: دقیقاً. به زبان شما: هزینهٔ نپرداختن، و سود رشد.
    نه «بگذارید نردها بازی کنند».

آژانس بازاریابی: توسعه، مرحلهٔ آخرِ کارِ دیگران

اینجا معمولاً یک مسئلهٔ نسبتاً ثابت و نسبتاً خاص هست: این شرکت‌ها را بیشتر آدم‌هایی می‌گردانند که پس‌زمینهٔ توسعه ندارند. اغلب طراح‌اند — نه همیشه — و غالباً مشاوره یا کار آژانسی بلدند، ولی دولوپر نیستند.

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

منبع فرق دارد — رهبری طراح است — درمان همان است. به تیمت نگاه کن. کار خلاق می‌کنید؟ اگر بله، برای رهبری روشن کن؛ داستان بگو که کار شما هم همان‌قدر خلاق است. اگر نه، یا رویکرد را عوض کن و همدلی خلاق بساز، یا اگر نمی‌توانی و نمی‌خواهی، سرنوشتت را بپذیر: همیشه پیاده‌ساز دیده می‌شوی. حداقل در این شرکت، سهم تو همین است.

آژانس توسعه: ترس مت

مت Tighten را می‌گرداند، پس احتمالاً به کوری خودش هم معترف است. ولی اگر باید حدس بزند، بدترین تمایل آژانس‌هایی مثل مال او این است که فروشنده‌ها قولی بدهند که دولوپرها باید نگه دارند. واقعاً می‌ترسد یک روز بفهمد دولوپرهای Tighten نشسته‌اند و دربارهٔ انتظار غیرواقعی مت از مشتری غر می‌زنند.

درمان:

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

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

بازنگری فروش → توسعه — ۹۰ دقیقه — بعد از تحویل

۱. فروش (۱۰ دقیقه)
   چه قولی دادیم؟ اسکوپ، تاریخ، بودجه. عین عبارت مشتری.

۲. توسعه (۲۰ دقیقه)
   آن قول از داخل چه حسی داشت؟ کجا فشار آمد؟
   کجا کار واقعی با چیزی که فروخته شد فرق داشت؟

۳. نقطهٔ کور (۱۵ دقیقه)
   کجا فروش بدون چشمِ کسی که روزانه کد می‌زند تعهد بست؟

۴. صدای «نه» (۱۵ دقیقه)
   اگر کسی حس overcommit داشت، حرف زد؟ شنیده شد؟
   اگر نه، چه چیزی جلوی حرف را گرفت؟

۵. تماس بعدی (۱۵ دقیقه)
   کدام دولوپرِ روزانه-کدزن روی فروش بعدی می‌آید؟
   یک قانون: قول تازه بدون تأیید لید فنی وارد SOW نمی‌شود.

۶. یک تغییر مشخص (۱۵ دقیقه)
   فقط یک تصمیم قابل اجرا برای پروژهٔ بعد — نه ده شعار.

استارتاپ: اعتیاد بنیان‌گذار به تازگی

مت می‌گوید از استارتاپ فنی آن‌قدر چیز غلط درمی‌آید که نمی‌داند از کجا شروع کند. ولی در رابطهٔ مهندسی با بقیه، رایج‌ترین مسئله از کشش بنیان‌گذارها به امر نو می‌آید. فکر می‌کنی دولوپرها shiny object syndrome دارند؟ با بنیان‌گذار استارتاپ حرف بزن.

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

حلش کمی leading up می‌خواهد؛ فرض مت این است که تو بنیان‌گذار نیستی. اگر هستی و این مشکل را داری، بهتر عمل کن. بنیان‌گذارها را گاهی آدم‌هایی کاریکاتور می‌کنند که همه‌چیز را می‌دانند و حاضر نیستند یاد بگیرند. خیلی‌وقت‌ها به رهبری مورد اعتمادشان برای یک مکالمهٔ سخت بازند: باید swoop and poop را متوقف کنند — همان آمدن ناگهانی و عوض کردن همه‌چیز — به نفع شیوه‌ای از ارتباط و تسک‌دادن که خروجی واقعی از دولوپرها بگیرد. باز هم: به زبان آن‌ها بگو.

تو: وقتی پنج‌شنبه می‌آیی و اسکوپ دوشنبه را عوض می‌کنی،
    تیم دو روز کار را دور می‌ریزد. اسمش را می‌گذاریم swoop and poop.

بنیان‌گذار: من دارم محصول را با بازار هم‌تراز می‌کنم.

تو: بازار را می‌فهمم. چیزی که نمی‌خری این است که هر چرخش،
    یک هزینهٔ پنهان دارد: context از بین می‌رود، کیفیت می‌افتد،
    و همان سرعتی که می‌خواهی دیرتر می‌رسد. اگر تازگی لازم است،
    بگذارید در صف اولویت بیاید — نه اینکه از بالای سرِ کانبان
    فرود بیاید. تو خروجی می‌خواهی؛ این شکلِ تسک‌دادن ضد خروجی است.

یا قدرت در رأس مهندسی، یا ارتباطی که باورنکردنی است

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

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

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

به زبان ساده

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

مثال واقعی

در آژانس بازاریابی توسعه را «پیاده‌سازی آخر کار» می‌بینند؛ در استارتاپ بنیان‌گذار swoop and poop می‌کند؛ در آژانس توسعه خطر این است که فروش قولی بدهد که دولوپر باید نگه دارد — مت می‌ترسد خودش همان آدم باشد.