پست

Debugging Teams

Better Productivity through Collaboration

Preview Image
Debugging Teams

توضیحات

نظر

نظر

  • امتیاز : 00/10
  • به دیگران توصیه می‌کنم :
  • دوباره می‌خوانم :
  • ایده برجسته :
  • تاثیر در من :
  • نکات مثبت :
  • نکات منفی :

مشخصات

  • نویسنده :
  • انتشارات :
  • صفحه مشخصات : goodreads

بخش‌هایی از کتاب

در این بلوک می‌رویم سراغ فصل ۱ تا جایی که سه ستون HRT و «HRT in Practice» شروع می‌شود.

۱. مسئله از «خودت» شروع می‌شود

فصل ۱ با این ایده شروع می‌کند که وقتی بحثِ ریسک‌های اجتماعی توسعه‌ی خلاق است، تنها متغیری که واقعاً رویش کنترل کامل داری «خودت» هستی.

  • انسان‌ها ذاتاً پر از باگ‌اند؛ قبل از این‌که باگ‌های هم‌تیمی‌هایت را ببینی، باید باگ‌های خودت را ببینی.
  • هدف فصل: کمک کند واکنش‌ها، رفتارها و نگرش‌های خودت را ببینی و اصلاح کنی تا انرژی کم‌تری صرف درگیری‌های انسانی و انرژی بیش‌تری صرف نوشتن کد خوب شود.

ایده‌ی کلیدی فصل: توسعه‌ی نرم‌افزار یک «Team Sport» است؛ برای موفقیت، باید رفتار خودت را حول سه اصل «تواضع، احترام، و اعتماد» بازتنظیم کنی.

۲. Help Me Hide My Code – ناامنیِ رایج برنامه‌نویس‌ها

نویسنده‌ها یک الگوی تکرارشونده از کارشان روی Google Project Hosting دیدند:

  • «می‌شود شاخه‌های خاص Subversion را روی Google Code مخفی کنیم؟»
  • «می‌شود پروژه‌ی متن‌باز اول private باشد بعد public شود؟»
  • «من می‌خواهم همه‌ی history پاک شود که انگار کد از اول این‌شکلی بوده.»

تم مشترک: ناامنی.

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

نویسنده‌ها این را نه فقط یک واکنش انسانی طبیعی، بلکه «علامتِ یک مشکل عمیق‌تر» در فرهنگ توسعه می‌دانند.

۳. افسانه‌ی «برنامه‌نویس نابغه»

۳.۱. قهرمان‌سازی فردی

کتاب مثال مایکل جردن و Chicago Bulls را می‌زند: رسانه‌ها تیم را نادیده می‌گیرند و تمام فوکوس را روی «ستاره» می‌گذارند.

در دنیای نرم‌افزار هم همین است:

  • Linus Torvalds، Richard Stallman، Bill Gates، Steve Jobs… به‌عنوان قهرمانان تک‌نفره دیده می‌شوند.
  • روایت رایج: «لینوس به تنهایی Linux را نوشت.» درحالی‌که او فقط یک هسته‌ی اولیه نوشت و اصل کار، کار صدها نفر بود؛ هنر واقعی او «رهبری و هماهنگی» بود.
  • Unix هم محصول یک تیم در Bell Labs بود نه فقط Thompson و Ritchie.
  • Stallman Emacs اولیه را نوشت، اما بقیه‌ی ecosystem را صدها نفر دیگر ساخته‌اند.

در بسکتبال هم جردن بدون تیم و بدون مربی‌ای مثل Phil Jackson قهرمان نمی‌شد؛ Jackson عمداً یک «dream team» ساخت و سیستم را حول آن چید.

۳.۲. فانتزی Batcave

نویسنده‌ها فانتزی رایجِ توسعه‌دهنده را این‌طور توصیف می‌کنند:

  • ایده‌ی ناب به‌سراغت می‌آید؛
  • در Batcave خودت برای هفته‌ها/ماه‌ها disappear می‌کنی و implementation بی‌نقص را می‌نویسی؛
  • بعد، محصول را «Release» می‌کنی و همه از نبوغت شگفت‌زده می‌شوند؛ شهرت و ثروت می‌آید.

این فانتزی، همان «Genius Programmer» myth است.

واقعیت:

  • اولاً «نابغه» بسیار نادر است.
  • ثانیاً حتی نوابغ هم باگ دارند؛ ایده و مهارت کافی نیست؛ outcome محصول به شدت به «چقدر خوب با دیگران کار می‌کنی» وابسته است.

۳.۳. ناامنی به‌عنوان ریشه‌ی افسانه

ترس از این‌که «اگر کار نیمه‌کاره‌ام را ببینند می‌فهمند نابغه نیستم» باعث می‌شود توسعه‌دهنده‌ها:

  • از نمایشِ زودهنگام کد فرار کنند؛
  • هر نقدی را تهدید به «افشا شدن احمق بودن» تلقی کنند.

نقل قول وبلاگی که می‌آورند دقیقاً همین را می‌گوید: «حس می‌کنم اگر قبل از تمام شدن کسی کد را ببیند فکر می‌کند احمقم.»

نویسنده‌ها صریح می‌گویند:
در این مورد «هر جور دوست داری کار کن» جواب نیست؛ پنهان‌کاریِ سیستماتیک، اشتباه استراتژیک است.

۴. «پنهان‌کاری مضر است» – چرا کار در غار خطرناک است؟

۴.۱. ریسک فنی و یادگیری

داستان دوچرخه و تغییر دنده:

  • یک نفر در گاراژ، ماه‌ها روی مکانیزم جدید کار می‌کند، هیچ‌کس را در جریان نمی‌گذارد.
  • همسایه‌اش، با کمک بچه‌های مغازه‌ی دوچرخه، در همان زمان یک مکانیزم مشابه اما بهتر می‌سازد و لانچ می‌کند.
  • وقتی prototype مخفی خودش را نشان می‌دهد، معلوم می‌شود اشکال‌های ابتدایی‌ای دارد که اگر از هفته‌ی اول کسی دیده بود، به‌سرعت fix می‌شد.

نتیجه‌ها:

  • تا وقتی ایده را در «حالت خام» با دیگران تست نکرده‌ای، نمی‌دانی:
    • ایده قبلاً حل شده یا نه؛
    • مسیرت غلط است یا درست؛
    • implementation اولیه‌ات کجاهای بنیادی ایراد دارد.
  • هرچه زودتر بازخورد بگیری، ریسک ماشین‌زدن به دیوار پایین‌تر می‌آید (با این caveat که «Feedback زیادِ خیلی زود» هم می‌تواند مضر باشد که در فصل‌های بعدی به آن می‌پردازند).

۴.۲. Bus Factor

آن‌ها «Bus Factor» را این‌طور تعریف می‌کنند:

تعداد افرادی که باید زیر اتوبوس بروند تا پروژه کاملاً نابود شود.

اگر تنها کسی هستی که کد و طراحی را می‌فهمد:

  • Bus Factor = ۱؛ پروژه با غیبت تو (ازدواج، مهاجرت، مریضی، شرکت عوض کردن) زمین می‌خورد.
  • اگر دو نفر درک عمیق دارند، Bus Factor = ۲ و قوی‌تر است؛ یک تیم کوچک آن را بالا می‌برد.

پنهان‌کاری آگاهانه، Bus Factor را پایین نگه می‌دارد و پروژه را شکننده می‌کند.

۴.۳. سرعت و Feedback Loop

کار انفرادی معمولاً کندتر از چیزی است که دوست داری اعتراف کنی؛ وقتی گیر می‌کنی، ساعت‌ها/روزها در باتلاق می‌مانی؛ درحالی‌که یک هم‌تیمی باتجربه در ۳۰ ثانیه ممکن است بگوید: «ببین، این‌جا فلان چیز را جا انداختی.»

نویسنده‌ها analogy کامپایلر را می‌آورند:

  • هیچ‌کس ۱۰هزار خط کد نمی‌نویسد و بعد برای اولین‌بار Compile بزند.
  • ما در حلقه‌های خیلی کوتاه کار می‌کنیم: تابع جدید → Compile → Test → Refactor → Compile.

مغز ما برای feedback سریع تنظیم شده است. در سطح پروژه هم همین‌طور:

  • Requirements عوض می‌شوند؛
  • موانع سیاسی یا طراحی پیدا می‌شوند؛
  • محیط تغییر می‌کند و چیزی که یک سال پیش relevant بود ممکن است امروز بی‌اهمیت باشد.

«چند جفت چشم بیش‌تر» نه فقط Bug را کم‌عمق می‌کند، بلکه کمک می‌کند پروژه روی ریل بماند و با محیط update شود؛ کسانی که در غار کار می‌کنند ممکن است بعد از مدت‌ها با محصولی بیرون بیایند که بازار و جهان مدت‌هاست از آن عبور کرده است.

۴.۴. بحث Office و Open Space

یک اینسرت جالب هم دارند درباره‌ی فضای فیزیکی تیم:

  • افسانه‌ی قدیمی: برای بهره‌وری بالا، حتماً باید «دفتر دربسته‌ی شخصی» داشته باشی تا در سکوت کد بزنی.
  • دیدگاه نویسنده‌ها: برای اکثر مهندس‌ها، این نه لازم است نه لزوماً مفید؛ چون نرم‌افزار را تیم می‌نویسد و «کانال پرظرفیت و کم‌اصطکاک به بقیه‌ی تیم» تقریباً به‌اندازه‌ی خود اینترنت مهم است. اگر ساعت‌ها بدون تعامل، روی چیز اشتباه کار کنی، آن سکوت به ضررت است.
  • اما Open Space افراطی (۵۰–۱۰۰ نفر در یک سالن) هم مزخرف است؛ باعث می‌شود همه از ترسِ اذیت کردن بقیه، سکوت کنند. نتیجه: نه تمرکز داری، نه ارتباط درست.

پیشنهاد آن‌ها:

  • تیم‌های ۶ تا ۱۲نفره در اتاق‌های کوچک/بزرگ مجزا، که مکالمه‌ی خودجوش ساده و غیرخجالت‌آور باشد.
  • Protocolهای ساده برای «interrupt»: مثلاً call کردنِ «breakpoint Mary» و گرفتن ack/NACK؛ یا استفاده از هدفون، توکن روی مانیتور و … برای سیگنال‌دادن.

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

۵. همه‌چیز درباره‌ی تیم است

نویسنده‌ها نتیجه می‌گیرند:

  • قهرمان‌های تک‌نفره‌ی واقعی خیلی نایاب‌اند؛ و همان‌ها هم دستاوردهایشان را «در خلأ» به‌دست نیاورده‌اند؛ همیشه یک جرقه بوده و بعد یک تلاش تیمی قهرمانانه.
  • هدف اصلی، ساختنِ «تیم سوپراستار» است، نه تبدیل شدن به قهرمان تنها.

فرمول‌شان را این‌طور خلاصه می‌کنند:

توسعه‌ی نرم‌افزار یک ورزشِ تیمی است.

این جمله را عمداً تبدیل به مانترا می‌کنند، چون دقیقاً با فانتزی درونیِ «Genius Programmer» در تعارض است.

اگر در «لانه‌ی هکر»ت نابغه باشی ولی نتوانی با دیگران ویژن را توزیع و مهندسی را تقسیم کنی، نمی‌توانی دنیا را عوض کنی یا میلیون‌ها کاربر را خوشحال کنی.

۶. سه ستون (Three Pillars): HRT

برای این‌که از «درک تیمی بودن کار» برسیم به «ساختن تیم عالی»، نویسنده‌ها سه اصل را به‌عنوان زیرساخت تمام تعامل‌های سالم معرفی می‌کنند: Humility, Respect, Trust = HRT.

  • Humility (تواضع):
    • مرکز عالم نیستی؛ نه همه‌چیز را می‌دانی، نه خطاناپذیری.
    • برای رشد و بهبود خودت باز هستی.
  • Respect (احترام):
    • به همکارانت به‌عنوان «انسان» اهمیت می‌دهی، نه صرفاً «منبع تولید کد».
    • توانایی‌ها و دستاوردهایشان را جدی می‌گیری.
  • Trust (اعتماد):
    • باور داری دیگران competent‌اند و معمولاً کار درست را می‌کنند.
    • می‌توانی در زمان مناسب «فرمان را بدهی دست آن‌ها» و واقعاً ول کنی.

تز قوی‌شان:

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

ساختار کتاب هم حول همین است:

  • فصل ۱: کار کردن روی خودت و جا انداختن HRT در رفتار شخصی‌ات.
  • فصل ۲: ساخت فرهنگ تیمی بر پایه‌ی HRT.
  • فصل ۳ و بعد: کار با آدم‌های بیرون تیم، سازمان، و نهایتاً کاربران، باز هم با همین سه ستون.

در این بلوک می‌رویم سراغ بخش «HRT in Practice» از فصل ۱؛ یعنی جایی که نویسنده‌ها تواضع، احترام و اعتماد را به رفتارهای کاملاً عملی ترجمه می‌کنند.

۱. «Ego» را کم کن

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

چند نشانه‌ی Ego بالا:

  • همیشه می‌خواهی «اولین» یا «آخرین» نفر باشی که در هر بحثی حرف می‌زند.
  • روی هر جزئیات ریز باید کامنت بدهی و نظر داشته باشی.

نویسنده‌ها بین «اعتماد به نفس» و «خودبزرگ‌بینی» تمایز می‌گذارند:

  • اعتماد به نفس لازم است؛ بدونش مسئولیت نمی‌گیری.
  • اما راه درست، ساختن یک غرور جمعی تیمی است، نه غرور فردی؛ چیزی شبیه فرهنگ Apache که به‌شدت به «هویت جمعی پروژه» بها می‌دهد و آدم‌هایی را که صرفاً دنبال self‑promotion هستند پس می‌زند.

مثال Hamming: John Tukey فوق‌العاده بود، ولی عمداً خیلی راحت و ساده لباس می‌پوشید؛ این یعنی حاضر بود «قیمتِ کمی‌جدی‌گرفتن در نگاه اول» را بدهد، تا در عوض در بلندمدت راحت‌تر با سیستم کار کند و با Ego نجنگد.

۲. یاد بگیر انتقاد بدهی و انتقاد بگیری

۲.۱. انتقاد دادن

داستان Joe: توسعه‌دهنده‌ای که در تیم جدید، شروع می‌کند برای کد بقیه ایمیلی Code Review فرستادن؛ با لحن محترم، اما چون تیم فرهنگ HRT نداشت و ناامن بود، چند هفته بعد مدیر به او می‌گوید «خیلی خشن و انتقادی رفتار می‌کنی، همه ناراحت شده‌اند.»

نکته‌ی نویسنده‌ها:

  • در یک فرهنگ سالمِ HRT، این رفتار Joe باید «هدیه» محسوب شود، نه تهدید.
  • ولی وقتی اطرافیان ناامن‌اند، باید نسبت به context حساس باشی و در introduce کردن Code Review محتاط‌تر عمل کنی.

تفاوتِ انتقاد مخرب شخصیتی و انتقاد سازنده روی خروجی:

  • انتقاد شخصیتی: «تو همیشه design رو خراب می‌کنی، چرا مثل بقیه نمی‌فهمی…»
  • انتقاد سازنده: مشخص، action‑able، و روی Artifact (کد، طراحی، داک) متمرکز است، نه روی ارزش آدم.

مثالِ بدی که خودشان می‌زنند:

«من کاملاً flow این متد را اشتباه می‌دانم، باید الگوی xyzzy را مثل همه استفاده می‌کردی.»

ایرادها:

  • دوتایی کردن دنیا به «درست/غلط».
  • رفرنس دادن به «همه» برای شرمنده کردن طرف.
  • دستور دادن، نه پیشنهاد دادن.

فرم بهتر همان حرف:

«من این‌جا کمی در فهم flow مشکل داشتم؛ شاید اگر الگوی xyzzy را استفاده کنیم، فهم و نگه‌داری‌اش در درازمدت ساده‌تر شود؟»

در این نسخه:

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

۲.۲. انتقاد گرفتن

برای گرفتن انتقاد باید دو لایه را از هم جدا کنی:

  • قیمت‌گذاری روی خودت
  • قیمت‌گذاری روی خرو‌جی‌ات (کد، داک، دیزاین)

تز کلیدی‌شان:

«تو، کدت نیستی.»

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

به‌صورت عملی:

  • انتقاد = «هدیه‌ای که می‌توانی بپذیری یا رد کنی».
  • لازم نیست روی تک‌تک نکته‌هایی که می‌شنوی حتماً action بگذاری؛ مثل مثالی که می‌زنند: دوستت می‌گوید «اسفناج دندانت گیر کرده و من از این کت و شلوارت خوشم نمی‌آید»؛ لازم است فقط اسفناج را برداری، نه این‌که لزوماً لباس عوض کنی.

۳. Fail Fast and Iterate – شکستِ زود، یادگیریِ سریع

اینجا دو ایده را کنار هم می‌گذارند:

  • افسانه‌ای که می‌گوید مدیرِ ارشدی ۱۰ میلیون دلار اشتباه می‌کند، استعفا می‌نویسد، و CEO جواب می‌دهد: «من تازه ۱۰ میلیون دلار خرج آموزش تو کرده‌ام، چرا باید اخراجت کنم؟»
  • شعار Google: «Failure is an option»؛ اگر هیچ‌وقت fail نمی‌کنی، یعنی کافی‌قدر risk و innovation نداری.

نمونه‌ی Google X:

  • در moonshotها (ماشین خودران، Glass و …) افراد تشویق می‌شوند ایده‌های دیوانه‌وار بدهند.
  • هم‌تیمی‌ها تشویق می‌شوند این ایده‌ها را هرچه سریع‌تر بترکانند؛ reward می‌گیری اگر بتوانی یک ایده را با reasoning خوب kill کنی.
  • تنها ایده‌هایی جلو می‌روند که نتوانی در whiteboard با کمک بقیه آن‌ها را جدی debunk کنی.

Postmortem به‌عنوان ابزار یادگیری از شکست:

  • هدفش «لیست عذرخواهی و بهانه» نیست؛ باید دقیقاً بگوید چه یاد گرفتیم و چه تغییری اعمال می‌شود.
  • اصولاً باید public و discoverable باشد تا نسل بعدی دوباره همان اشتباه را تکرار نکند.

المان‌های یک Postmortem خوب:

  • خلاصه‌ی کوتاه
  • Timeline از کشف تا resolution
  • علت ریشه‌ای
  • تخمین اثر و خسارت
  • Action itemهای فوری برای حل مشکل
  • Action itemهای پیشگیرانه برای آینده
  • Lessons Learned

۴. برای یادگیری جا باز کن

داستان Cindy: مهندس سوپراستاری که در حوزه‌ی خودش به «کمال» رسیده و بعد:

  • Technical Lead می‌شود، چند تیم را می‌گیرد، mentor بقیه می‌شود، کنفرانس می‌رود، expert می‌شود.
  • کم‌کم می‌فهمد دیگر چیز تازه‌ای یاد نمی‌گیرد؛ مدام در نقش «معلم» است.
  • یک روز می‌بیند حوزه‌ای که روی آن expert شده، اساساً دیگر مرکز توجه صنعت نیست.

نویسنده‌ها این را نوعی local maximum trap می‌بینند:

  • خیلی خوب است که در یک نقطه از landscape مهارت به قله برسی، اما اگر فقط همان‌جا بمانی، یادگیری‌ات متوقف می‌شود و از بازار جا می‌مانی.
  • Ego به‌راحتی تو را قفل می‌کند: addicted می‌شوی به این‌که «همیشه باسوادترین آدم اتاق» باشی.

راه‌حل مبتنی بر تواضع:

  • بعضی وقت‌ها آگاهانه خودت را در موقعیتی قرار بده که از بقیه ضعیف‌تر باشی؛ تیمی که در آن «بزرگ‌ترها» از تو جلوترند.
  • uncomfortable بودن و یاد گرفتن از آن‌ها، در بلندمدت خیلی بیش‌تر از «همیشه لیدر بودن» تو را رشد می‌دهد.

۵. یاد گرفتن صبر (وقتی سبک‌ها با هم نمی‌خوانند)

داستان Fitz و Karl روی converter CVS → Subversion/Git:

  • Fitz «bottom‑up» کار می‌کرد: شیرجه در کد، patch سریع، آزمون و خطا.
  • Karl «top‑down» بود: می‌خواست قبل از هر تغییری، call stack و معماری را کامل بفهمد.

وقتی pair programming کردند:

  • برخورد سبک‌ها تبدیل شد به دعوای جدی؛
  • فهمیدند به این شکل نمی‌توانند کنار هم پشت یک کیبورد بنشینند.

اما چون:

  • تاریخ مشترک طولانی داشتند،
  • به همدیگر اعتماد و احترام داشتند،

با صبر و انعطاف مدل جدیدی تعریف کردند:

  • با هم bug را isolate می‌کردند؛
  • بعد جدا می‌شدند، Fitz از پایین، Karl از بالا جلو می‌رفت و بعد وسط راه دوباره meet می‌کردند.

نتیجه: هم دوستی حفظ شد، هم کار پروژه جلو رفت.

پیام عملی: اگر HRT پشت صحنه باشد، اختلاف سبک را می‌شود با کمی صبر تبدیل به Complementarity کرد، نه میدان جنگ.

۶. Open to Influence بودن (و Vulnerability به‌عنوان قدرت)

دو پارادوکس ظاهری:

  • «هرچه بیش‌تر بازِ تأثیر گرفتن باشی، تأثیرگذارتر می‌شوی.»
  • «هرچه آسیب‌پذیرتر به‌نظر برسی، قوی‌تر دیده می‌شوی.»

۶.۱. آدم لجباز چه می‌شود؟

همه یک نفر را می‌شناسیم که:

  • در هیچ بحثی کوتاه نمی‌آید؛
  • هرچه بیش‌تر سعی کنی نظرش را عوض کنی، بیش‌تر در موضعش فرو می‌رود.

در بلندمدت:

  • تیم کم‌کم او را route around می‌کند؛
  • حرفش دیگر جدی گرفته نمی‌شود؛
  • حتی اگر نکته‌ی خوبی هم بگوید، کسی حوصله‌ی دوباره درگیر شدن با او را ندارد.

پس اگر می‌خواهی حرفت جدی گرفته شود:

  • باید نشان بدهی قابلیت تغییر نظر داری؛
  • باید قبل از این‌که public موضع قطعی بگیری، خوب گوش کنی؛ وگرنه اگر مدام عقب بنشینی، به‌عنوان «متزلزل» دیده می‌شوی. بنابراین تعادل: late commitment + real openness.

۶.۲. آسیب‌پذیری و اعتراف به ندانستن

سؤال: اگر بگویی «نمی‌دانم» یا «اشتباه کردم»، آیا اعتبارت از بین می‌رود؟

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

در تیم مهندسی سالم:

  • اعتراف به اشتباه یا ندانستن = نمایشِ تواضع + مسئولیت‌پذیری + اعتماد به قضاوت بقیه.
  • در عوض، دیگران برای صداقتت احترام بیش‌تری قائل می‌شوند و در درازمدت «بیش‌تر به تو گوش می‌دهند».

نکته‌ی کلیدی آن‌ها:

  • در یک تیم نرم‌افزاری، طرف مقابل تو «رقیب سیاسی» نیست؛ هم‌تیمی است. نیازی نیست دائم در حالت دفاعی باشی.

در این بلوک، انتهای فصل ۱ را جمع‌بندی می‌کنیم؛ همان جایی که نویسنده‌ها HRT را از سطح «اصل» به سطح «Next Steps» می‌برند.

۱. چرا اصلاً باید وارد این دردسرها شد؟

نویسنده‌ها می‌پذیرند که «آدم‌ها messy و خسته‌کننده‌اند» و برای خیلی از مهندس‌ها جذاب‌تر است همیشه با کامپایلر سر و کله بزنند تا با انسان. اما نقل‌قولی از Richard Hamming می‌آورند:

  • او تعریف می‌کند که با شوخ‌طبعی و رفاقت با منشی‌ها، سطح کمک‌هایی که از آن‌ها می‌گرفت فوق‌العاده بالا بود؛ تا حدی که یک‌بار برای گرفتن یک کار چاپی، شخصاً از Murray Hill به Holmdel رفتند و برگشتند.
  • نکته: چون روی رابطه سرمایه‌گذاری کرده بود (جوک گفتن، حال‌پرسیدن، آدم حساب کردنشان)، بعداً در نقطه‌ی حساس، سیستم (سازمان) به نفع او خم شد.

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

۲. HRT در بافت کلی کتاب

نویسنده‌ها تأکید می‌کنند که HRT فقط یک شعار اخلاقی نیست، اسکلت‌بندی کل کتاب است:

  • این فصل (۱): اول از همه باید خودت را زیر ذره‌بین بگذاری؛ رفتارهای شخصی را با HRT align کنی؛ Ego را کم کنی، یاد بگیری انتقاد بدهی و بگیری، سریع fail کنی و از آن درس دربیاوری، برای یادگیری وقت بگذاری، صبور باشی و تأثیرپذیر.
  • فصل ۲: HRT را از سطح فرد تعمیم می‌دهند به سطح فرهنگ تیم؛ این‌که چطور «تیم رؤیایی» بسازی که در آن تواضع، احترام و اعتماد default است.
  • فصل‌های بعد:
    • کار با آدم‌هایی که هر روز با تیم در تماس‌اند ولی جزو core culture نیستند (دیگر تیم‌ها، contributors بیرونی، آدم‌های سمی).
    • ناوبری سازمانی؛ جایی که سیاست، ساختار و بوروکراسی می‌تواند همان‌قدر خطرناک باشد که یک آدم سمی.
    • و نهایتاً رابطه با کاربران؛ کسانی که گاهی فراموش می‌کنیم وجود دارند، ولی بدون آن‌ها نرم‌افزار ما هیچ معنایی ندارد. HRT باید در تعامل با کاربران هم حاضر باشد.

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

۳. Next Steps – قدم بعدی از نگاه نویسنده‌ها

فصل با این پیام تمام می‌شود:

  • اگر تا این‌جا آمده‌ای، در مسیر درست برای یاد گرفتن «خوب با بقیه بازی کردن» هستی.
  • نقطه‌ی شروع، خودت هستی: باید روی الگوهای رفتاری خودت مکث کنی، آن‌ها را ببینی و عمداً عوضشان کنی.
  • وقتی HRT را internalize کردی، همکاری برایت طبیعی‌تر می‌شود و بهره‌وری مهندسی‌ات به‌شکل محسوسی بالا می‌رود؛ نه با کدنویسی بیش‌تر، بلکه با هدررفت کمتر روی درگیری‌ها و سوءتفاهم‌ها.

ساختار رشد هم از «داخل به بیرون» است:

  1. Self: تو و عاداتت.
  2. Team: ساختن culture بر پایه‌ی HRT.
  3. Organization & Others: برخورد با آدم‌های بیرون تیم، آدم‌های سمی، و ساختن خوشه‌های HRT در یک محیط بزرگ‌تر.
  4. Users: تعمیم همین نگاه به کاربران، و طراحی محصول/تعامل‌ات با آن‌ها بر این اساس.

در این بلوک، ابتدای فصل ۲ را تا پایان دو بخش «What Is Culture?» و «Why Should You Care?» باز می‌کنیم.

۱. مقدمه‌ی فصل ۲: چرا درباره‌ی فرهنگ تیم حرف می‌زنیم؟

نویسنده‌ها از این‌جا به بعد تمرکز را از «فرد» به «تیم» می‌برند:

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

هدف فصل:

  • توضیح این‌که «فرهنگ» چیست؛
  • تمرکز ویژه روی الگوهای ارتباطی (communication) که به موفقیت کمک می‌کنند؛
  • و این‌که چطور با همین الگوها می‌شود هر محصولی را با یک تیم انسانی، کم‌هزینه‌تر و مؤثرتر ساخت.

۲. «Culture» یعنی چه؟ – استعاره‌ی نان خمیرترش

وقتی کلمه‌ی Culture را می‌شنویم، یا یاد اپرا و هنر می‌افتیم، یا یاد پتری‌دیش بیولوژی؛ نویسنده‌ها عمداً از همانی دومی استفاده می‌کنند.

۲.۱. داستان نان خمیرترش (Sourdough)

اگر یک نان خمیرترش واقعاً عالی خورده باشی و دنبال نانوا بگردی، به این می‌رسی که:

  • کلید طعم و کیفیت نان، یک Starter است: مخلوطی از خمیر و آب که داخلش مخمر (yeast) و باکتری Lactobacillus زندگی می‌کند.
  • مخمر نان را پف می‌دهد، باکتری طعم ترش و خاص می‌سازد.
  • همه‌ی لکتوباسیل‌ها یکسان نیستند؛ بعضی سوش‌ها طعم خیلی بهتری می‌دهند. اگر نانوا یک Starter با طعم عالی پیدا کند، با دقت از آن نگه‌داری و آن را تغذیه می‌کند، و هر بار مقدار کمی از آن را به خمیر جدید «تزریق» می‌کند.

این Starter یک کار دیگر هم می‌کند:

  • آن‌قدر قوی است که وقتی وارد خمیر جدید می‌شود، «سوش‌های وحشی و ناخواسته» مخمر/باکتری محیط را عقب می‌زند و خودش غالب می‌شود؛ نتیجه: خروجیِ نهایی نان، همان طعم و هویت مشخص.

۲.۲. قیاس با فرهنگ تیم

فرهنگ یک تیم مهندسی دقیقاً شبیه همین استارتر خمیرترش است:

  • Starter Culture = بنیان‌گذاران و اعضای اولیه‌ی تیم
  • خمیر تازه = نیروهای جدیدی که به تیم اضافه می‌شوند
  • مخمر و باکتری = خود اعضای تیم و رفتارهایشان

اگر Starter قوی باشد:

  • می‌تواند «سوش‌های فرهنگی ناشناخته» که نیروهای جدید می‌آورند را مهار و هضم کند؛
  • و newcomers را آرام‌آرام به همان هویت، ارزش‌ها و رفتارها آغشته می‌کند.

اگر Starter ضعیف باشد:

  • هر newcomer عملاً می‌تواند بخش‌هایی از فرهنگ قبلی خودش را «تزریق» کند؛
  • چون هیچ چیز قوی‌ای برای شکل دادن رفتار وجود ندارد، تیم به‌راحتی توسط ارزش‌ها و الگوهای تصادفی تازه‌واردها re‑shape می‌شود؛
  • خروجی نهایی (نان / تیم) غیرقابل پیش‌بینی و غالباً ناامن می‌شود.

نکته‌ی مهم: فرهنگ فقط این نیست که «چطور کد می‌زنیم». فرهنگ ترکیبی است از:

  • شیوه‌ی کار (code review، TDD، design doc و …)
  • ارزش‌ها و اهداف مشترک
  • و حتی Ritualهای اجتماعی و شوخی‌های داخلی تیم (ناهار پنج‌شنبه، نوشیدنی جمعه، یا جنگ Nerf Gun در دفتر Pittsburgh گوگل هر وقت قطار رد می‌شد).

بنیان‌گذاران و اعضای اولیه بیشترین اثر را روی شکل‌دهیِ اولیه دارند، اما فرهنگ یک چیز ایستا نیست؛ همراه رشد و تغییر تیم، خودِ فرهنگ هم evolve می‌کند.

۳. چرا باید برای فرهنگ وقت بگذاری؟

بخش بعدی می‌پرسد: «خب، چرا باید این‌قدر به فرهنگ اهمیت بدهم؟ چه می‌شود اگر ندم؟»

۳.۱. اگر فرهنگ را رها کنی، دیگران برایت می‌سازند

اگر خود تیم روی ساختن و نگه‌داشت culture سرمایه‌گذاری نکند:

  • به‌مرور شخصیت‌های قوی (لزوماً نه سالم) وارد می‌شوند و شروع می‌کنند فرهنگ خودشان را تحمیل کردن.
  • ممکن است خوش‌شانس باشی و اتفاقاً فرهنگِ آن‌ها خوب از آب دربیاید، ولی در اکثر موارد، نتیجه ترکیبی است از:
    • دعوا و کشمکش
    • حواس‌پرتی دائمی از کار اصلی
    • و هدر رفتن انرژی‌ای که باید صرف design و shipping می‌شد.

داشتن یک فرهنگ «قابل دفاع» مهم است:

  • اگر خودِ اعضای تیم فرهنگ را ارزشمند ندانند، انگیزه‌ای هم برای دفاع از آن در مقابل newcomerها نخواهند داشت.
  • آن وقت یک نفر جدید با style بد یا ارزش‌های ناسازگار می‌تواند به‌راحتی کل جو تیم را عوض کند.

۳.2. فرهنگ، مسئولیت همه است، نه فقط لید

اشتباه رایج:

  • «Culture» را مسئولیت Lead یا Manager فرض می‌کنند؛ انگار فقط اوست که نگهبان فرهنگ است.

نویسنده‌ها صریح می‌گویند:

  • بنیان‌گذاران و لیدها نقش پررنگی دارند، اما هر عضو تیم هم در تعریف، هم در نگه‌داری، و هم در دفاع از فرهنگ مسئول است.
  • وقتی کسی تازه وارد تیم می‌شود، فرهنگ را فقط از Lead نمی‌گیرد؛ از تمام رفتارهایی که از نزدیکانش می‌بیند می‌آموزد:
    • چطور کار همدیگر را review می‌کنید؛
    • چطور conflict حل می‌کنید؛
    • چقدر روی کیفیت حساس هستید؛
    • چه چیزی در تیم تشویق یا تحمل می‌شود.

۳.۳. «فرهنگ قوی» یعنی چه؟

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

  • فرهنگ قوی = باز است به تغییراتی که آن را بهتر می‌کند، اما در برابر تغییراتی که آن را بدتر می‌کند، مقاومت دارد.

در تیم‌های موفق:

  • فکوس اصلی فرهنگ، «Ship کردنِ نرم‌افزار خوب» است.
  • اگر تمرکز اصلی فرهنگ چیزهای دیگری مثل:
    • مهمانی دائم،
    • جلسه برای جلسه،
    • بازی قدرت و one‑upmanship،
      باشد، تیم شاید «با هم حال کند»، ولی خروجی خیلی کمی خواهد داشت.

برای کسی مثل تو که از ساختن و shipping لذت می‌برد:

  • حیاتی است در تیمی باشی که محصول‌محور است؛ و بعد فعالانه کمک کنی همین فضا حفظ و تقویت شود.

۳.۴. فرهنگِ Self‑Selecting

یک Insight مهم: فرهنگ مثل یک فیلتر خودانتخاب‌گر عمل می‌کند.

  • در پروژه‌های متن‌باز Apache، تیم‌هایی که روی HRT و کد تمیز و maintainable تأکید دارند، دقیقاً همین مدل آدم‌ها را جذب می‌کنند.
  • اگر فضای mailing list آن‌ها پر از توهین و حمله‌ی شخصی باشد، همان جنس آدم را هم جمع می‌کند؛ آدم‌های introvert و سازنده به‌مرور کنار می‌روند.

در سازمان‌های شرکتی، این Self‑Selection به‌وضوح در فرآیند استخدام دیده می‌شود:

  • مثلاً گوگل «Culture fit» را صریحاً به‌عنوان یکی از معیارهای interview دارد؛ اگر کسی از نظر تکنیکی عالی باشد اما نتواند در team‑based environment کار کند، یا محیط ساختار-پذیر افراطی بخواهد، رد می‌شود.
  • اگر به culture‑fit در استخدام توجه نکنی، بعداً انرژی عظیمی باید صرف «جا انداختن» یا «بیرون کردن» آن فرد کنی؛ هر دو هزینه‌بر و فرساینده‌اند.

در این بلوک، بخش «Culture and People» از فصل ۲ را باز می‌کنیم؛ یعنی جایی که کتاب تفاوت کار خلاق (مثل توسعه‌ی نرم‌افزار) با کار خط تولید را توضیح می‌دهد و اثر فرهنگ را روی نوع آدم‌هایی که جذب می‌کنی نشان می‌دهد.

۱. چرا نرم‌افزار مثل خط تولید نیست؟

نویسنده‌ها تأکید می‌کنند که کار خلاق مثل نرم‌افزار را نباید با مونتاژکار خط تولید قاطی کرد:

  • در بعضی کارها، چند روز آموزش و یک‌سری ابزار ساده کافی است و اگر یکی از کارگرها برود، نفر بعدی را راحت جایگزین می‌کنی؛ خروجی هم با تکرار یک سری حرکت روتین تولید می‌شود.
  • در مهندسی نرم‌افزار (و هر کار خلاق مشابه)، خروجی به تفکر، حل مسئله و تصمیم‌گیری وابسته است؛ اگر نیروی خوب از دست بدهی، با یک ramp‑up چندروزه جبران نمی‌شود.

اگر می‌خواهی محصول خوب بسازی، به مهندسان خوب نیاز داری، و برای این‌که مهندسان خوب بتوانند best workشان را انجام بدهند و بمانند، باید فرهنگی داشته باشی که:

  • برای ایده‌ها و نظرهایشان safe باشد؛
  • بتوانند واقعاً روی محصول اثر بگذارند؛
  • و در تصمیم‌گیری مشارکت کنند.

۲. چه کسانی را جذب می‌کنی؟

خیلی از مهندسان قوی دو چیز را می‌خواهند:

  • هم‌تیمی‌های قوی‌تر یا هم‌سطح، تا از آن‌ها یاد بگیرند؛
  • و نقشی واقعی در تصمیم‌گیری محصول؛ نه صرفاً «پیاده‌ساز دستورات بالا».

نویسنده‌ها دو مدل مدیریت/فرهنگ را مقابل هم می‌گذارند:

  1. Top‑down / alpha‑engineer
    • یک «alpha engineer» لید است و بقیه باید فقط دستورات او را اجرا کنند.
    • معمولاً آدم‌هایی را می‌آورد که ارزان‌تر و مطیع‌ترند؛ outcome: تیمی پُر از «follower» که خودش باید برای همه تصمیم بگیرد، و مهندسانی که می‌توانستند در جای دیگر driver باشند، اصلاً جذب این تیم نمی‌شوند.
  2. Consensus‑driven / مشارکتی
    • همه حس «مالکیت و مسئولیت» نسبت به محصول دارند.
    • لید واقعاً گوش می‌دهد، و احترام (R از HRT) در مرکز است.
    • گاهی، برای سرعت، تیم خودخواسته بخشی از تصمیم‌ها را به TL/Tech Committee تفویض می‌کند، اما این delegation نتیجه‌ی همان consensus است، نه دیکتاتوری.

بسیاری وقتی کلمه‌ی «Consensus» را می‌شنوند یاد جلسات بی‌پایان هیپی‌ها و «Kumbaya» می‌افتند، اما نویسنده‌ها می‌گویند اگر چنین شود، مشکل از team dysfunction است، نه از خودِ consensus.

۳. رفتارِ آدم‌ها با هم: از «قلدری» تا HRT

اگر فرهنگ تیم این باشد که:

  • «سینه‌کوبی»، داد و بیداد، تحقیر و حمله‌ی شخصی normal است،

در عمل:

  • فقط آدم‌های تهاجمی و ego‑driven جذب می‌شوند یا دوام می‌آورند؛
  • مخصوصاً بسیاری از زنان (به تجربه‌ی نویسنده‌ها) این فضا را به‌شدت repel‑کننده می‌یابند؛
  • تیم شاید از بیرون «پر سروصدا و بااعتمادبه‌نفس» به‌نظر برسد، اما درونش انرژی عظیمی صرف جنگ قدرت می‌شود.

اگر فرهنگ را روی HRT بنا کنی:

  • مهندسانی را جذب می‌کنی که هم به کیفیت و هم به احترام اهمیت می‌دهند؛
  • و به‌جای جنگ، وقتشان را صرف نوشتن کد تمیز و طراحی خوب می‌کنند.

نویسنده‌ها بین Ego تیمی و Ego فردی فرق می‌گذارند:

  • غرور تیمی (Team Pride) خوب است؛ این‌که تیم به محصولش افتخار کند.
  • اما وقتی افراد با Egoهای شخصی‌شان تیم را زیر سایه می‌برند، فرمول شکست است؛ در فصل ۴ مفصل‌تر به این می‌پردازند.

۴. نقش انتقاد سازنده در فرهنگ

انتقاد سازنده برای رشد فرد و تیم حیاتی است، ولی خیلی‌ها از آن فرار می‌کنند. دلایل:

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

درحالی‌که:

  • انتقاد «هدیه» است؛ بخشی را که مفید و align با ارزش‌هاست برمی‌داری، بقیه را می‌گذاری کنار.
  • بدون انتقاد، احتمال این‌که سال‌ها همان اشتباهات را تکرار کنی، بالاست؛ چون self‑awareness و introspection به‌تنهایی معمولاً کافی نیستند که همه‌ی blind spotهایت را ببینی.

نویسنده‌ها می‌گویند همین کتاب را حداقل دوازده نفر به‌طور جدی review کردند و انتقادهای خیلی دقیق دادند؛ بدون آن، کیفیت نهایی کتاب به‌مراتب پایین‌تر بود.

البته دادن feedback خوب کار راحتی نیست؛ ساده‌ترین کار «خراب کردن» و مسخره کردن است؛ ساختن feedback سازنده انرژی و مهارت می‌خواهد.

اگر colleagues و دوستانی داری که وقتی ازشان feedback می‌خواهی واقعاً نقد سازنده می‌دهند (نه فقط تعریف)، این‌ها را «مثل unobtainium» نگه‌دار؛ بسیار کمیاب‌اند.

۵. فرهنگ HRT و طیف شخصیت‌ها

نکته‌ی مهم برای طراحی culture:

  • آدم‌های تهاجمی معمولاً می‌توانند در محیط‌های آرام هم به‌صورت productive کار کنند.
  • اما آدم‌های آرام، introvert و متفکر تقریباً هرگز در محیط‌های aggressive شکوفا نمی‌شوند؛ صدایشان گم می‌شود و کم‌کم کنار می‌کشند.

اگر به‌دنبال فرهنگی هستی که بیشترین طیف آدم‌ها بتوانند در آن خوب کار کنند، آن فرهنگ باید روی تواضع، احترام و اعتماد ساخته شود.

هشدار: فرهنگ‌های آرام و محترم نسبت به disruption توسط آدم‌های تهاجمی آسیب‌پذیرترند؛ به‌همین خاطر:

  • باید آگاهانه اجازه ندهی newcomer تهاجمی، tone تیم را تصاحب کند؛
  • معمولاً با engage نکردن در لحن aggressive شروع می‌شود؛
  • و گاهی لازم است یکی از اعضای ارشد، مستقیم و قاطع با آن شخص صحبت کند تا از فرهنگ محافظت کند (فصل ۴، «Poisonous People»، این را باز می‌کند).

در این بلوک، از ابتدای بخش «Communication Patterns of Successful Cultures» تا انتهای سه زیر‌بخش اولش می‌رویم: High‑Level Synchronization، Mission Statement، Efficient Meetings، و بعد هم بخش «Working in a Geographically Challenged Team».

۱. الگوهای ارتباطی در فرهنگ‌های موفق

مشکل کلاسیک مهندسان: ترجیح می‌دهند با کامپایلرِ منطقی و قابل پیش‌بینی سر و کله بزنند تا با انسانِ احساسی و غیرخطی، و ارتباط را مانعِ راه نوشتن کد می‌بینند.

اما اگر:

  • تیم روی جهت و اولویت‌ها sync نباشد،
  • و اطلاعات شفاف در دسترس نباشد،

اصلاً نمی‌فهمی «در حال نوشتن کد روی مسأله‌ی درست» هستی یا نه.

در هر فرهنگ موفق و کارآمد، روی کانال‌های ارتباطی مختلف سرمایه‌گذاری می‌شود:

  • mailing list
  • design doc
  • chat room
  • mission statement
  • کامنت‌های کد
  • how‑toهای عملیاتی و …

برقراری هم‌فهمی روی جهت تیم، effort می‌خواهد، اما این effort مثل سرمایه‌گذاری است که بازدهش را در بهره‌وری و رضایت تیم می‌بینی.

یک قاعده‌ی کلی:

  • ارتباط هم‌زمان (synchronous) (جلسه، تماس تلفنی) را تا حد ممکن با «کم‌ترین تعداد آدم لازم» انجام بده.
  • ارتباط ناهم‌زمان (asynchronous) (ایمیل، issue tracker، کامنت روی doc) را تا حد امکان برای «گروه بزرگ‌تر» بفرست تا همه بتوانند در زمان مناسب خودش ببینند.

هر بار کسی را وسط کارش قطع می‌کنی، باید هزینه‌ی context switching را در نظر بگیری.

۲. هم‌ترازی سطح بالا (High‑Level Synchronization)

در سطح بالا، دو چیز حیاتی است:

  • توافق روی اهداف مشترک
  • و توافق روی روش‌های کار (best practices)

ابزارهایی که در ادامه مطرح می‌شود، همه به همین خدمت می‌کنند: mission statement، design doc، typeهای خاص جلسه و …

۳. Mission Statement – نه از جنس شعارهای بازاری

اول ماموریت را از نوعی که اکثر شرکت‌ها دارند، مسخره می‌کند؛ مثال دو mission statement مبهم که می‌توانستند برای هر چیزی از کارواش تا فروشگاه پوشاک به کار بروند.

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

۳.۱. Mission خوب برای تیم مهندسی چیست؟

برای یک تیم تولید نرم‌افزار، mission statement ابزاری است برای:

  • تعریف جهت (Direction)
  • محدود کردن حوزه (Scope)

یک مثال خوب: mission تیم Google Web Toolkit (GWT). وقتی GWT متن‌باز شد، Fitz و Ben به تیم گفتند باید یک mission statement شفاف بنویسند. تیم اول مقاومت داشت («وقت تلف کردن است»)، اما وقتی نشستند، بحث‌های جدی در گرفت، چون مشخص شد خودِ لیدهای ارشد روی جهت محصول اتفاق‌نظر ندارند.

در نهایت، Mission این شد:

GWT’s mission is to radically improve the web experience for users by enabling developers to use existing Java tools to build no‑compromise AJAX for any modern browser.

این جمله کوتاه، دو چیز را دقیق مشخص می‌کند:

  • جهت: بهبود رادیکال تجربه‌ی وب برای کاربر، از طریق توانمندسازی توسعه‌دهنده.
  • محدودیت دامنه: تمرکز روی ابزارهای Java.

تیم علاوه بر جمله‌ی Mission، یک سند مفصل «Making GWT Better» هم نوشت که تک‌تک عبارت‌های mission و non‑goals پروژه را توضیح می‌داد.

نتیجه‌های عملی:

  • لید تیم بعدها اعتراف کرد: فکر می‌کرد این تمرین وقت‌تلف‌کردن است، اما همین پروسه باعث شد لیدها تفاوت دیدگاهشان را کشف و resolve کنند؛ چیزی که می‌توانست بعداً سرعت محصول را بکشد.
  • وقتی mission روی وب منتشر شد، newcomers را به آن ارجاع می‌دادند و بخش بزرگی از بحث‌های تکراری «جهت محصول چیست؟» حذف شد.
  • هر وقت محیط یا بیزنس pivot می‌کرد، باید صادقانه می‌دیدند آیا mission هنوز معنا دارد یا باید به‌سختی آن را update کنند؛ مثل اصلاح قانون اساسی، سخت ولی ممکن.

۴. جلسات کارآمد (Efficient Meetings)

نویسنده‌ها صریحاً می‌گویند بیشتر آدم‌ها از جلسه متنفرند؛ اگر بد اداره شود، waste محض است.

۴.۱. جلسات دوره‌ای (standing meetings)

جلسات هفتگی تیم باید:

  • فقط برای اعلان‌های مهم، معرفی‌ها و هماهنگی خیلی سطح بالا باشد.
  • دور زدن اتاق و شنیدن status از هر نفر، حتی وقتی چیزی ندارند، فرمولی است برای اتلاف وقت و self‑harm.

راه بهتر:

  • هر موضوعی که نیاز به بحث عمیق دارد، در لیست «sidebar» نوشته شود؛ بعد از اتمام بخش اصلی، فقط کسانی که به آن topic ربط دارند می‌مانند و بقیه با خیال راحت می‌روند.
  • وقتی این عادت جا بیفتد، هر کس هر جا دید بحث دارد منحرف می‌شود، می‌تواند بگوید «sidebar؟» و بحث را ذخیره کند بدون این‌که کسی احساس کند خاموش شده است.
  • اگر در آن هفته agenda مهمی ندارید، بدون عذاب وجدان جلسه را لغو کنید.
  • اگر فرهنگ سازمان جوری است که «پر بودن کلندر» نشانه‌ی status است، این را صریحاً «دیوانگی» می‌نامند.

Daily Standup (Agile):

  • اگر واقعاً «۱۵ دقیقه‌ای، ایستاده و on‑point» بماند، قابل دفاع است.
  • اما بدون مراقبت دائمی، به‌سرعت تبدیل می‌شود به جلسات ۳۰ دقیقه‌ای با بحث‌های عمیق و therapy group.
  • کسی باید با authority آن را time‑box و track نگه دارد.

۴.۲. جلسات طراحی / تصمیم‌گیری

اگر می‌خواهی چیز جدیدی design کنی یا تصمیم سخت بگیری:

  • به‌صورت تجربی، بیش از ۵ نفر در اتاق، تصمیم‌گیری واقعی را فلج می‌کند؛ مگر این‌که یک نفر decision‑maker از پیش تعیین‌شده وجود داشته باشد.
  • مثال‌شان: اگر ۶ نفر را در یک تور شهری بدون لیدر بگذاری و بخواهی با consensus تصمیم بگیرند که کجا بروند، بیشتر روز در گوشه‌ی خیابان مشغول بحث خواهند بود.

۴.۳. Maker’s Schedule و زمان «Make»

جلسات با «Make Time» سازگار نیستند.

  • اشاره به مقاله‌ی Paul Graham: مهندس نیاز به blocks ۳–۴ ساعته‌ی بدون interruption دارد.
  • توصیه: این blocks را در کلندر خودت explicit رزرو کن (Busy / Make Time).

بهتر است جلسات را:

  • تا حد امکان نزدیک breakهای طبیعی بگذاری (ناهار، آخر روز).
  • در گوگل، سنت «No Meeting Thursday» وجود داشت تا حداقل یک روز را تا جای ممکن خالی بگذارند؛ کار می‌کرد، اما نیاز به policing مداوم داشت.

پنج قانون ساده‌ی آن‌ها برای جلسه‌ی خوب:

  1. فقط کسانی را دعوت کن که واقعاً لازم‌اند.
  2. حتماً agenda داشته باش و قبل از جلسه بفرست.
  3. وقتی اهداف جلسه محقق شد، جلسه را تمام کن (حتی اگر زودتر از زمان رزرو شده باشد).
  4. بحث را روی agenda نگه‌دار و اجازه‌ی drift بی‌پایان نده.
  5. زمان جلسه را تا حد امکان با دیگر نقاط وقفه در روز align کن.

۵. کار در تیم‌های «Geographically Challenged»

وقتی تیم distributed است یا خودت remote کار می‌کنی، دومسئله داری:

  • هم نیاز به ابزارهای دیگر برای ارتباط داری؛
  • هم به‌طور کلی باید بیش‌تر روی ارتباط سرمایه‌گذاری کنی، نه کم‌تر.

۵.۱. مستندسازی تصمیم‌ها

وقتی اعضای تیم در یک مکان نیستند:

  • تصمیم‌های مهم را باید کتبی و share کنی (معمولاً ایمیل).
  • chat، پیام فوری و صحبتِ راهرو مفید است، اما نتیجه‌های مهمشان باید در کانالی که همه می‌بینند (مثلاً mailing list) ثبت شود.
  • مزیت جانبی: archive برای بعداً، و شفافیت برای newcomers.

در پروژه‌ی Subversion، شعارشان این بود:

«اگر بحثی در لیست ایمیل رخ نداده، انگار هرگز رخ نداده است.»

یعنی:

  • می‌توانی در chat brainstorm کنی، ولی وقتی به تصمیم رسیدید، باید آن را روی لیست ایمیل replay کنید، تا یک:
    • log قابل جست‌وجو از reasoning داشته باشید؛
    • و امکان مشارکت برای کسانی که حاضر نبودند فراهم شود.

این برای فرهنگ consensus حیاتی است.

۵.۲. Over‑Communication از راه دور

اگر remote کار می‌کنی:

  • باید بیش از حد نرمال با تیم communicate کنی؛
  • از تمام مدیاها استفاده کن: chat، ایمیل، video call، تلفن؛
  • مطمئن شو همه هم می‌دانند که «هستی» و هم می‌دانند روی چه کار می‌کنی.

و مهم‌تر از همه:

  • قدرت و نقش «face‑to‑face» را دست‌کم نگیر؛ هیچ چیز از نظر bandwidth و اعتمادسازی به آن نزدیک نمی‌شود.

۵.۳. مثال‌های سفر حضوری

دو مثال واقعی:

  1. مهندسی که با تیمی در کلرادو کار می‌کرد و نمی‌توانست momentum بگیرد. Fitz به او گفت یک هفته برو آن‌جا مستقر شو. بعد از یک روز، ایمیل زد که:
    • اوضاع حرکت کرده،
    • و با هم ناهار و بعد از کار بیرون رفتن، رابطه‌ای ساخته که روی ریتم کار اثر گذاشته است.
  2. Corey که با تیمی در یک دفتر دیگر پروژه جدیدی را شروع کرده بود. traction نمی‌گرفت، Ben گفت برو دو روز همان‌جا کنارشان بشین. Corey نگران هزینه‌ی سفر بود، اما وقتی رفت دید:
    • فقط همان دو روز bandwidth گفتگو و context مشترک ایجاد کرد که بعداً تمام تعامل‌های remote را نرم و مؤثر کرد.

نکته‌ی زیرخط:

  • سفر کاری ممکن است گران به‌نظر برسد، ولی هزینه‌ی نرفتن، از نظر friction، سوءتفاهم و کند شدن کار، معمولاً بیش‌تر است.
  • اگر بودجه داری و پروژه مهم است، برای جلسات شروع پروژه یا تصمیم‌های کلیدی، حضور فیزیکی تقریباً همیشه ارزشش را دارد.

در این بلوک، بقیه‌ی فصل ۲ را تا انتهای «It Really Is About Your Product, After All» پوشش می‌دهم.

۱. Design Doc؛ چرا قبل از کد باید بنویسی؟

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

ویژگی‌های یک Design Doc سالم:

  • معمولاً یک owner دارد، ۲–۳ نفر مشارکت‌کننده‌ی اصلی، و تعداد بیش‌تری reviewer.
  • نقش‌اش:
    • blueprint سطح‌بالای پروژه‌ی آینده؛
    • کانال ارزان برای sync کردن تیم روی این‌که «چه می‌خواهیم بسازیم و چطور».
  • چون هنوز ماه‌ها کد نزده‌ای، پذیرش Feedback و تغییر مسیر، ارزان‌تر و راحت‌تر است؛ هم کیفیت design و هم implementation بالاتر می‌رود.
  • بعداً راهنمای برنامه‌ریزی و تقسیم کار می‌شود.

اما نباید «دین طراحی» بگیری:

  • اگر پروژه‌ای را می‌توانی چندبار از صفر در همان زمانی که برای نوشتن یک Design Doc طولانی لازم است بازنویسی کنی، Doc احتمالاً overkill است.
  • judgement لازم است: برای سیستم توزیع‌شده با stateful service و SLA بالا، Design Doc ضروری است؛ برای اسکریپت ۱۰۰ خطی، نه.

Doc باید سند زنده باشد، نه سنگ قبر:

  • باید همراه با تکامل پروژه update شود، نه این‌که فقط در لحظه‌ی «before coding» نوشته و بعد رها شود؛ البته اغلب تیم‌ها دقیقاً همین اشتباه را می‌کنند.

۲. روزمره‌ی ارتباط: Mailing List، Chat، Issue Tracker

وقتی هدف و mission مشخص شد، می‌رسی به ابزارهایی که ارتباط روزمره را حمل می‌کنند. این کانال‌ها bandwidth و context محدودی دارند و خطر سوء‌تفاهم و آسیب به HRT بالاست، ولی اگر درست استفاده شوند، بهره‌وری را بالا می‌برند.

۲.۱. Mailing List

تقریباً هیچ تیمی نیست که لااقل یک لیست ایمیل نداشته باشد؛ مسئله این است چطور از آن استفاده کنی.

  • پروژه‌های بزرگ معمولاً چند لیست دارند: dev، code‑review، users، announce، و …
  • اما پروژه‌ی کوچک با ۳ مهندس و ۲ کاربر اگر ۶ لیست بسازد، مثل این است که برای ۵ نفر ۶ اتاق جلسه درست کرده باشی: پراکندگی، echo، و اتاق‌های خالی.
    • توصیه: با یک لیست شروع کن، فقط وقتی واقعاً traffic بالا شد و آدم‌ها رحم خواستند، آن را بشکن.
    • استثنا: ایمیل‌های خودکار و botها بهتر است در لیست جدا یا حداقل با prefix قابل فیلتر شدن باشند.

نکته‌های عملی:

  • etiquette مشخص برای بحث ایمیلی تعریف کن:
    • لحن مؤدب،
    • جلوگیری از «noisy minority» که روی هر thread سوار می‌شوند و فضا را انحصار می‌دهند.
  • برای هر چیز مهمی (agenda جلسات، minutes، تصمیم‌ها، design docها) یک copy روی لیست بفرست تا:
    • یک «system of record» قابل جست‌وجو داشته باشی،
    • newcomers وقتی می‌پرسند «چرا این تصمیم را گرفتید؟»، بتوانی آن‌ها را به آرشیو ارجاع دهی، نه این‌که دوباره از صفر دفاع کنی.

اگر این آرشیو را نسازی، محکوم به تکرار همه‌ی بحث‌ها برای هر نسل جدیدی از نیروها هستی.

۲.۲. Online Chat

Chat یک ابزار عالی برای پرسش‌های سریع و تعامل سبک‌وزن است، مشروط به این‌که kill‑switch مزاحمت را در دست خود مهندس بگذاری.

نویسنده‌ها تأکید می‌کنند: group chat عمداً بهتر از ۱:۱ است:

  • قبلاً تیم‌ها غالباً در IRC کانال مشترک داشتند؛ امروز معادل‌اش Slack است.
  • افراد می‌توانند:
    • در بحث‌ها شرکت کنند،
    • صرفاً از دور دنبال کنند (lurk)،
    • یا بعداً log را بخوانند.
  • این باعث می‌شود lore پروژه collect شود، نه این‌که در DMها گم بشود.

مشکل مدرن: با IM، default تبدیل شد به ۱:۱ private chat، که insecurities را تغذیه می‌کند:

  • کسی که از «پرسیدن سؤال احمقانه» جلوی بقیه می‌ترسد، همه‌چیز را private می‌پرسد؛ نتیجه:
    • بار تکرار پاسخ روی seniorها می‌افتد،
    • دانش shared نمی‌شود.

با تولد Slack موج جدید group chat برگشت:

  • Slack integrationهای زیادی دارد؛ owner گزارش هفتگی از نسبت DM به پیام‌های کانال می‌گیرد و می‌تواند تیم را gently هل بدهد به‌سمت بحث‌های public.

قانون مفید:

  • سوال/بحثی که «ارزش یک بار جواب درست» دارد، باید در کانال گروهی مطرح شود؛ DM برای چیزهایی که ذاتاً شخصی‌اند.

۲.۳. Issue Tracker

اگر issue tracker داری (و باید داشته باشی)، فقط داشتن ابزار کافی نیست؛ باید فرآیندی برای triage و رسیدگی داشته باشی.

اگر:

  • tracker neglected باشد،
  • اولویت‌گذاری نداشته باشی،

رخ می‌دهد که:

  • مردم filing را رها می‌کنند و یا مستقیماً غر می‌زنند،
  • و وقتی تیم برمی‌گردد سراغ tracker، کلی وقت را روی باگ‌های بی‌اهمیت می‌گذارد، درحالی‌که مهم‌ها پشت backlog گم شده‌اند.

Issue tracker عملاً یک فروم تخصصی است، با همان قواعد mailing list:

  • بحث‌های راهرو و شفاهی درباره‌ی یک باگ را حتماً به‌صورت کامنت در issue ثبت کن؛ این تصمیم‌ها فقط وقتی «واقعی» هستند که جایی ثبت شده باشند.
  • لحن باید مؤدبانه بماند؛ رفتارهای troll‑like را تحمل نکن.
  • اگر thread در issue طولانی و پیچیده شد، بحث conceptual را موقتاً روی لیست ایمیل ببرید؛ email client ابزار بهتری برای managing threadهای عمیق است.

۳. ارتباط به‌عنوان بخشی از مهندسی

در این قسمت، چند نقطه‌ی حساس در خود فرآیند توسعه را از زاویه‌ی ارتباط بررسی می‌کند.

۳.۱. Code Comments – نه زیاد، نه کم، و روی «چرا»

استایل کامنت‌گذاری بحث‌برانگیز است، اما چند اصل عملی:

  • کامنت‌های خیلی verbose ممکن است intent و reasoning را خوب بیان کنند، اما اگر update نشوند تبدیل به noise خطرناک می‌شوند.
  • کامنت‌های صفر یا خیلی کم هم باعث می‌شود آینده‌ای‌ها وقت‌شان را صرف reverse‑engineering intent تو کنند.

اشتباه رایج:

  • کامنتی که فقط ساختار بد و نام‌گذاری بد را پنهان می‌کند؛ در اصل دارد همان‌چیزی را تکرار می‌کند که کد already می‌گوید.

نویسنده‌ها می‌گویند:

  • تمرکز کامنت باید روی چرا باشد، نه «چه کار می‌کند»؛
  • مفیدترین سطح برای کامنت، سطح method / function و API است.

قانون‌شان: اصل یونانی «μηδέν άγαν» – «هیچ چیز بیش از حد لازم».

نکته مهم‌تر از خود سبک: یک style guide مشترک و ثبات.

دلیل Style Guide را هم باید شفاف بگویی (مثل intro راهنمای C++ گوگل):

  • هدف، manage complexity، enforce consistency، و جلوگیری از feature‑bloat است؛
  • نه necessarily «بهترین» یا «سریع‌ترین» possible C++؛ مهم این است که هر مهندس بتواند سریع کد بقیه را pattern‑match کند.

۳.۲. اسم گذاشتن روی فایل‌ها – چرا «امضای نویسنده» بد است؟

سنت قدیمی این است که بالای فایل بنویسی:

1

# Created: October 1998 by Brian W. Fitzpatrick <...>

مشکل این رویکرد برای codebaseهای امروزی:

  • نرم‌افزار امروز را «افراد متعدد»، در بازه‌های زمانی طولانی، مدام تغییر می‌دهند.
  • سوال حل‌نشدنی: از چه نقطه‌ای نام نفر دوم، سوم، چهارم را باید اضافه کرد؟ چند خط تغییر؟ یک تابع؟ چند باگ‌فیکس؟
  • اگر تابعی را کسی نوشته، بعداً دیگری refactor کرده، و سومی rewrite، چه اسمی باید بماند / حذف شود؟

نتیجه‌ی واقعی:

  • انرژی عظیمی صرف بحث‌های بی‌حاصل روی attribution می‌شود؛
  • Ownership ذهنی روی فایل ایجاد می‌کند و Bus Factor را پایین می‌آورد؛
  • دیگران برای تغییر فایل «با اسم دیگری روی آن»، تردید می‌کنند.

راه‌حل پیشنهادی:

  • attribution را از سطح فایل بردار؛
  • در عوض:
    • یک فایل top‑level AUTHORS یا CONTRIBUTORS داشته باش؛
    • از history سیستم Version Control برای جزئیات دقیق‌تر استفاده کن.

۳.۳. Code Review برای هر Commit

اگر استاندارد کدنویسی داری، بدون review این استاندارد روی کد enforce نمی‌شود.

اصل‌شان:

  • هر خطی که وارد repo می‌شود، باید حداقل یک جفت چشم دوم رویش را دیده باشد؛ قبل یا بعد از commit، ولی حتماً دیده شده باشد.
  • Changeset باید کوچک و reviewable باشد؛ patch هزاران خطی عملاً فقط برای پیدا کردن indentation‑nit مرور می‌شود، نه برای کیفیت واقعی.

اثرات:

  • کیفیت کد بالا می‌رود؛
  • sense of group‑ownership و غرور جمعی روی codebase تقویت می‌شود؛
  • حلقه‌ی Feedback سریع‌تر می‌شود (همان چیزی که در «Hiding Is Considered Harmful» گفتند).

۳.۴. فرآیند تست و Release واقعی

مهم نیست TDD کار می‌کنی یا فقط regression test ساده داری؛ اصل:

  • هرچه تست‌های خودکار بیش‌تر، اطمینان‌ات در زمان refactor و feature‑addition بالاتر.
  • نقش تست باید بخشی رسمی از «چرخه‌ی کدنویسی و review» باشد، نه یک چیز optional.

Release:

  • فرآیند باید آن‌قدر سبک باشد که release مکرر (مثلاً هفتگی) ممکن شود.
  • ولی آن‌قدر هم شُل نباشد که buildهای شکسته و regressionها سر از دست کاربر دربیاورند.

بدون فرآیند Release سالم، یا در تله‌ی «لانچِ هر ۶ ماه یک بار با ریسک بالا» می‌افتی، یا در تله‌ی «لانچِ سریعِ پر از خطا»؛ هر دو برای اعتماد کاربر و morale تیم سمی‌اند.

۴. چرا همه‌ی این‌ها باز هم به «محصول» برمی‌گردد؟

فصل ۲ با این نکته تمام می‌شود:

  • شاید بخشی از این توصیه‌ها بازتاب سلیقه‌ی نویسنده‌ها در شیوه‌ی کار باشد، اما observation تجربی آن‌ها در پروژه‌ها و شرکت‌های متعدد این است که:
    • تیم‌هایی که روی فرهنگ قوی و ارتباط خوب کار کرده‌اند، واقعاً وقت بیش‌تری را صرف نوشتن و Ship کردن محصول می‌کنند و کم‌تر درگیر این می‌شوند که «اصلاً چه چیزی را باید بسازیم».
  • تیم قوی «تصادفی» ساخته نمی‌شود؛ حاصل seed و cultivation آگاهانه‌ی لیدها و بنیان‌گذاران است که هزینه‌ی بالای کار کردن با تیم dysfunctional را می‌فهمند.

اگر این کار را در ابتدا بکنی:

  • فرهنگ self‑selecting به‌وجود می‌آوری که:
    • آدم‌های هم‌خوان با ارزش‌ها را جذب می‌کند،
    • و به newcomers کمک می‌کند سریع onboard شوند.
  • بدون این‌ها، تازه‌وارد یا:
    • مدت‌ها وقتش در فهم «چگونه کار این تیم پیش می‌رود» می‌سوزد،
    • یا سعی می‌کند تیم را وادار کند مثل تیم قبلی خودش کار کند (که می‌تواند خوب یا فاجعه‌بار باشد).

نقطه‌ی پایانی‌شان تیز است:

  • بیش‌ترِ «هزینه‌ی فرهنگ» در عمل هزینه‌ی ارتباط است: mission statement، جلسات، mailing list، chat، کامنت کد، داکیومنت‌ها و فرآیندهای تصمیم‌گیری.
  • خیلی‌ها تعجب می‌کنند که چرا برای تیمی که فقط قرار است «محصول بسازد»، این‌همه ارتباط (و انرژی عاطفی) لازم است؛ اما واقعیت همین است: محصول تو نهایتاً درباره‌ی «ارتباط با انسان‌ها» است، نه فقط با ماشین.

در فصل بعد (۳)، این مبنا را روی «نقش لید» می‌گذارند: این‌که leader واقعاً چه‌کار می‌کند و چرا تقریباً هر تیم مؤثر، یک «کاپیتان» نیاز دارد.

حالا وارد فصل ۳ می‌شویم: «Every Boat Needs a Captain» – هر قایقی به کاپیتان نیاز دارد. این فصل مستقیماً درباره‌ی leadership است و برای هر کسی (نه فقط مدیرها) مفید است، چون درک بهتر رهبریت را به تو می‌دهد یا درک بهتری از رفتار لید خودت.

مقدمه فصل: کدام الگوی لیدری؟ Servant Leadership

نویسنده‌ها با یک نقل‌قول آغاز می‌کنند:

“Managers serve the team, while the team builds the product. Managers don’t serve the product unless they also happen to be on the team.”
— Brian Fitzpatrick, in a Google internal mailing list

این جمله خلاصه‌ی فلسفه‌شان است: manager واقعاً در خدمت تیم است، نه برعکس.

۱. Servant Leadership چیست؟

اصطلاح Servant Leadership را Robert Greenleaf در دهه‌ی ۱۹۷۰ مطرح کرد:

  • Leader یک «خدمتگزار» است؛
  • هدفش remove کردن موانع، حمایت از تیم، و ایجاد فضایی است که تیم بتواند مؤثرترین کارش را انجام دهد.
  • برعکس الگوی traditional top‑down که لید فرمان می‌دهد و تیم اجرا می‌کند، Servant Leader فیلسوفه‌اش «خدمت به تیم تا تیم محصول را بسازد» است.

اما در واقعیت، خیلی از مهندسان با این مفهوم آشنا نیستند، چون:

  • دانشگاه‌ها اصلاً درس «همکاری» نمی‌دهند؛
  • بیشتر دانشجویان یک‌بار تجربه‌ی گروهی را از روی اجبار داشته‌اند و نتیجه‌اش بد بوده، نه آموزش واقعی مهارت تیم‌سازی. همین‌طور، خیلی از مهندسان فکر می‌کنند «manager = مزاحم» و کارش را «دخالت و چک کردن» می‌دانند. اما leadership خوب آن‌قدر نامرئی است که تیم حس می‌کند «خودمان همه چیز را درست کردیم».

    ۲. Manager، Tech Lead و Engineering Manager

در این فصل، تمرکز اصلی روی دو نقش است:

  • Engineering Manager (people manager): کسی که مسئولیت عملکرد، رشد و حقوق اعضای تیم را دارد؛ اغلب خودش کد نمی‌نویسد یا خیلی کم می‌نویسد.
  • Tech Lead (TL): کسی که همچنان یک مهندس contributing است (کد می‌نویسد)، اما مسئولیت فنی پروژه را هم به عهده دارد: design، architecture، تقسیم کار، اولویت‌بندی فنی و …

در بسیاری شرکت‌ها این دو نقش overlap هستند یا یک نفر هر دو را برعهده می‌گیرد (Manager/TL)، اما می‌توانند جدا باشند. چرا بعضی شرکت‌ها این تقسیم را دارند؟

  • ممکن است یک Senior Engineer قدرت فنی بالایی داشته باشد اما اصلاً توانایی (یا علاقه‌ای) به people management نداشته باشد؛
  • در عوض، ممکن است یک Engineering Manager از نظر فنی متوسط باشد، اما توانایی بالایی در گوش دادن، حل تعارض، career development و … دارد.

نویسنده‌ها تأکید می‌کنند:

  • اجبار کردن یک مهندس فوق‌العاده برای این‌که مدیر شود، می‌تواند یک مهندس عالی را از دست بدهد و یک مدیر افتضاح به‌دست آورد (اشاره به «Peter Principle»).
  • بهتر است مسیر شغلی تخصصی و مسیر مدیریتی را جدا نگه داشت، اگر فرد علاقه‌ای به people‑management نداشته باشد.

۳. The Engineering Lead

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

۳.۱. تصور اشتباه: «تیم خودران» بدون لید

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

  • در عمل دیده‌اند که اگر تیمی لید (یا مدیر) نداشته باشد، یکی از چند اتفاق می‌افتد:
    1. افراد سرشان را پایین می‌گذارند و روی کار تکنیکال می‌روند، اما هماهنگی بلندمدت ضعیف می‌شود و ممکن است در جهت‌های متفاوت حرکت کنند.
    2. یا یکی از اعضای تیم (معمولاً senior) به‌طور طبیعی رهبری را می‌گیرد؛ اما چون رسماً لیدر نیست، ممکن است انرژی زیادی صرف این شود که «چطور دیگران را به این کار متقاعد کنم؟»

چرا؟ چون تیم نیاز به تصمیم‌گیری دارد و شخصی باید آخرین کلمه را بزند؛ مخصوصاً در تصمیم‌های مهم. اگر این نقش واضح نباشد، یا سردرگمی پیش می‌آید یا نوعی «shadow leadership» پدید می‌آید که ناکارآمد است.

۳.۲. تعریف نقش

لید مهندسی واقعاً چه می‌کند؟ نه دیکتاتور که همه را زیر فرمان می‌برد، نه صرفاً یک ستاره‌ی تکنیکال که بقیه باید دنبالش کنند. در paradigm Servant Leadership:

  • Remove کردن موانع: اگر تیم نیاز به resource، اطلاعات، یا تصمیم سازمانی دارد، لید باید آن را تأمین کند.
  • Facilitation: اطمینان از این‌که تیم روی اهداف sync است و ارتباط شفاف دارد.
  • تصمیم‌گیری نهایی: در مواقعی که consensus نمی‌شود یا زمان محدود است، لید قاطعانه تصمیم می‌گیرد (ولی بر اساس مشورت با تیم).
  • Accountability: لید در برابر سازمان، نتایج و عملکرد تیم را به عهده می‌گیرد.

چیزهایی که لید نباید باشد:

  • شخصیت alpha که همه را تحت فرمان دارد: این تیم را به dependence می‌کشاند.
  • خودش کل کد را بنویسد: اگر لید همه‌ی کار را بکند، bus factor پایین می‌شود و رشد تیم متوقف می‌شود.

    ۴. تمایز Leadership از Management

یک نکته‌ی ظریف در فصل:

  • Manager: به معنای دقیق، کسی که اختیارات اداری روی افراد دارد (hiring، firing، performance review، حقوق و …).
  • Leader: کسی که تیم را هدایت می‌کند، اما لزوماً اختیارات اداری ندارد (مثل یک Tech Lead که مدیر نیست، اما lead می‌کند).

در فصل ۳، نویسنده‌ها اغلب از «lead» صحبت می‌کنند تا شامل هر دو گروه شود (Manager و TL)، اما وقتی لازم است، تمایز را مشخص می‌کنند.

۵. چرا لیدری برای تو مهم است؟

حتی اگر هرگز قصد نداری مدیر یا TL شوی، فهمیدن این مفاهیم:

  • کمک می‌کند رفتار لید خودت را بهتر بفهمی؛
  • اگر روزی به اجبار به سمت lead سوق داده شدی (یا خودت خواستی)، این ابزارها را داری؛
  • و می‌توانی روی رفتار رهبر تیم خودت تأثیر بگذاری یا feedback بدهی، چون می‌فهمی کدام رفتار productive و کدام antipattern است.

نکته‌ی پایانی این بخش

فصل ۳ به دو قسمت تقسیم می‌شود:

  1. Antipatterns – رفتارهایی که لیدها معمولاً (حتی بدون قصد بد) مرتکب می‌شوند و تیم را فلج می‌کنند.
  2. Patterns – رفتارهای مثبتی که لید خوب را می‌سازند و تیم را قدرت می‌بخشند.

در بلوک بعدی، وارد بخش Antipatterns می‌شویم: Hire Lowering Standards، Ignore Low Performers، Treat Team Like Children، Be Everyone’s Friend، Compromise Hiring Bar، و چند مورد دیگر.

حالا وارد Antipatterns فصل ۳ می‌شویم؛ یعنی رفتارهای اشتباهی که لیدها معمولاً (حتی با نیت خوب) مرتکب می‌شوند و تیم را فلج می‌کنند.

Antipattern #1: نادیده گرفتن Low Performers

یکی از سخت‌ترین چالش‌های لیدری، مدیریت کسی است که performance پایین دارد.

مثال واقعی

Fitz اوایل مدیریت‌اش وقتی می‌خواست پاداش‌ها را توزیع کند، به مدیرش گفت: «عاشق مدیر بودن هستم!» مدیر بلافاصله پاسخ داد:

«گاهی تو پری دندونی (Tooth Fairy) هستی، گاهی باید دندان‌پزشک باشی.»

یعنی گاهی باید کار ناخوشایند «کشیدن دندان» را انجام دهی.

چرا نادیده گرفتن مشکل دارد؟

اکثر لیدها امیدوارند low performer به‌طور جادویی یا خودش بهتر شود یا برود، اما:

  • این تقریباً هرگز اتفاق نمی‌افتد.
  • «Hope is not a strategy.» (یکی از شعارهای تیم SRE گوگل)

در این بین:

  • High performers وقت و انرژیشان را صرف کشاندن low performer می‌کنند؛
  • Morale تیم آب می‌رود؛
  • بقیه خیلی خوب می‌دانند کی low performer است، چون آن‌ها دارند بارش را بر دوش می‌کشند.

نتیجه‌ی نادیده گرفتن

  • جذب high performers جدید سخت می‌شود (کسی نمی‌خواهد عضو تیمی شود که low performer دارد).
  • High performers فعلی تیم را ترک می‌کنند.
  • در نهایت، فقط low performers باقی می‌مانند، چون فقط آن‌ها نمی‌توانند جای دیگری شغل پیدا کنند.

همچنین، تو حتی به low performer هم لطف نمی‌کنی؛ چون ممکن است در تیمی دیگر واقعاً موفق باشد.

چگونه مدیریت کنی؟

نویسنده‌ها طی تجربه‌ی دردناک، این متد را یاد گرفته‌اند (تشبیهشان: کمک به کسی که لنگ می‌زند تا دوباره راه برود، بعد دوید):

  1. بازه‌ی زمانی مشخص: مثلاً ۲–۳ ماه برای بهبود.
  2. اهداف بسیار خاص و کوچک: incremental milestones تا موفقیت‌های کوچک احتمالی زیاد باشد.
  3. جلسه‌ی هفتگی: چک کردن progress، انتظارات explicit را برای هر هفته مشخص کن.
  4. نتیجه‌ی شفاف: اگر نتواند follow کند، خیلی زود واضح می‌شود (هم برای تو، هم برای او).

معمولاً یکی از دو چیز اتفاق می‌افتد:

  • خودش متوجه می‌شود که نمی‌تواند و استعفا می‌دهد (راه‌حل بدون درگیری).
  • یا عزم خودش را جمع می‌کند و واقعاً بهتر می‌شود.

در هر حال، تو سریع حرکت کردی و یا او را کمک کردی «up» شود یا «out».

اگر خیلی دیر عمل کنی، رابطه‌ی او با تیم و تو آن‌قدر خراب می‌شود که دیگر نمی‌توانی کمک‌اش کنی.

Antipattern #2: نادیده گرفتن Human Issues

لیدری به دو بخش اصلی نیاز دارد: تکنیکال و social. خیلی از لیدها (که از نقش فنی ترفیع گرفته‌اند) فقط روی تکنیکال تمرکز می‌کنند و مشکلات انسانی را ignore می‌کنند.

مثال واقعی: Jake و Pablo

دوست نزدیک Fitz (Jake) تازه بچه‌دار شده بود و چند هفته از خانه کار می‌کرد؛ برای Fitz (که قبلاً هم remote با Jake کار کرده بود) مشکلی نبود و Jake هم مثل همیشه productive بود.

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

«Dude, people have kids all the time. You need to go into the office.»

Jake که فردی خونسرد بود، وحشی شد و احترامش به Pablo به‌طور جدی آسیب دید.

تحلیل

Pablo می‌توانست:

  • کمی empathy نشان بدهد؛
  • بگوید «چند هفته remote مشکلی ندارد»؛
  • یا شرایطی Negotiate کند (مثلاً ۱–۲ روز هفته بیا دفتر).

هرکدام از این‌ها بهتر از آن لحن سرد و بی‌احساس بود.

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

Antipattern #3: دوست همه بودن (Be Everyone’s Friend)

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

مشکل

وقتی تو قدرت career کسی را داری، او ممکن است فشار احساس کند که باید به‌صورت مصنوعی به اشاره‌های دوستانه‌ی تو پاسخ دهد؛ یعنی چیزی که به‌نظر «دوستی» است، واقعاً معصومانه نیست.

نکته‌ی مهم:

  • «دوست بودن» و «soft touch leadership» یکی نیست؛ می‌توانی consensus بسازی و تیم را lead کنی، بدون این‌که peer بقیه باشی.
  • همین‌طور می‌توانی لید سختگیر باشی، بدون این‌که دوستی‌های قبلی را به باد بدهی.

توصیه:

  • یک راه: Lunch با تیم – فضای غیررسمی برای ارتباط اجتماعی، بدون این‌که احساس ناراحتی به وجود بیاید.
  • اگر کسی که باید مدیرش باشی دوست خیلی خوب (و هم‌سطح) تو بوده و خودش self‑managing نباشد و سخت‌کوش نباشد، موقعیت برای هر دو استرس‌زا خواهد بود. نویسنده‌ها توصیه می‌کنند تا حد امکان از این وضعیت دوری کنی.

Antipattern #4: پایین آوردن استانداردهای استخدام (Compromise Hiring Bar)

استیو جابز گفته:

«A people hire other A people; B people hire C people.»

وقتی تیم نیاز به استخدام سریع دارد، ممکن است از میان ۴۰–۵۰ نفر مصاحبه شده «۵ نفر بهترین» را انتخاب کنی، حتی اگر هیچ‌کدام‌شان واقعاً hiring bar را pass نکرده باشند. این سریع‌ترین راه ساختن تیم متوسط است.

هزینه‌ی استخدام اشتباه

هزینه‌ی پیدا کردن فرد درست (کار recruiter، تبلیغات، رفرنس و …) بسیار کم‌تر از هزینه‌ی نگه‌داشتن کسی است که هرگز نباید استخدام می‌شد:

  • افت productivity تیم،
  • stress تیم،
  • زمان صرف‌شده برای managing او تا جایی که بالاخره اخراجش کنی،
  • اگر هم نگهش داری، هزینه‌اش از همه بیش‌تر است (تیم کاملاً فلج می‌شود).

اگر تو مدیر تیمی هستی که سازمان مدام نیروی بی‌کیفیت برایت می‌فرستد، تا آخر جنگ کن برای hiring quality؛ اگر هنوز بی‌فایده است، شاید وقت آن رسیده که دنبال شغل جدید بگردی. بدون مواد اولیه‌ی خوب، محکوم به شکست هستی.

Antipattern #5: رفتار مثل بچه با تیم (Treat Team Like Children)

بهترین راه برای نشان دادن «بی‌اعتمادی» به تیم، رفتار کردن مثل بچه یا زندانی با آن‌هاست. آدم‌ها معمولاً همان‌طور رفتار می‌کنند که با آن‌ها رفتار می‌شود.

مثال‌ها:

  • Micromanagement مداوم،
  • بی‌احترامی به توانایی‌هایشان،
  • هیچ فرصتی برای مسئولیت‌پذیری ندادن.

اگر تو باید دائماً micromanage کنی چون بهشان اعتماد نداری، پس اشتباه استخدامی داری. اگر افرادی استخدام کردی که لیاقت اعتماد دارند و اعتمادت را نشان بدهی، معمولاً خودشان را به ارتفاع آن بالا می‌کشند.

مثال کنفرانس Fitz

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

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

مثال Google

گوگل برای کارمندان:

  • کابینت‌های پر از لوازم‌التحریر دارد (مفت)،
  • Tech Stops: شبیه فروشگاه الکترونیک self‑service برای کابل، ماوس، USB و … بدون کنترل خاص.

خیلی از شرکت‌های معمولی با وحشت می‌گویند «مطمئناً دارند پول هدر می‌دهند، همه چیز را می‌دزدند!» اما:

  • هزینه‌ی داشتن workforce که مثل بچه رفتار می‌کنند بسیار بالاتر از هزینه‌ی چند خودکار و کابل USB است.

وقتی به مهندسان اعتماد کنی، خودشان احساس مسئولیت می‌کنند و «Do The Right Thing» را انجام می‌دهند.

حالا وارد Positive Patterns (الگوهای مثبت لیدری) می‌شویم.

Pattern #1: Lose the Ego (نه به Ego فردی، بله به Ego جمعی)

این ساده‌ترین راه گفتن این است که «تواضع را جایگزین غرور کن». هیچ‌کس نمی‌خواهد با کسی کار کند که مرتب طوری رفتار می‌کند انگار مهم‌ترین آدم اتاق است.

نشانه‌های Ego زیاد

  • همیشه باید اولین یا آخرین حرف را در هر موضوع بزنی؟
  • احساس می‌کنی باید روی هر جزئیات proposal یا بحثی نظر بدهی؟

تفاوت بین تواضع و ضعف

تواضع به معنای «پادری بودن» نیست. اعتماد‌به‌نفس هیچ مشکلی ندارد، فقط مثل Know-it-all رفتار نکن.

Collective Ego (ایگوی جمعی)

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

مثلاً Apache Software Foundation جوامعی با هویت قوی ساخته که افراد self-promotion را رد می‌کنند؛ اگر کسی بیاید که بیش‌تر به خودنمایی اهمیت می‌دهد تا محصول، تیم او را نمی‌پذیرد.

داستان واقعی: John Tukey

John Tukey (ریاضی‌دان بزرگ) تقریباً همیشه لباس casual می‌پوشید و وارد دفترهای مهم می‌شد؛ گاهی مدت‌ها طول می‌کشید تا طرف مقابل بفهمد این یک first-class man است.

Richard Hamming می‌گوید:

«ظاهر conforming بودن، تو را راه می‌برد. اگر بخواهی مدام ego خودت را در جاهای مختلف جا بزنی و بگویی “من به روش خودم انجامش می‌دهم”، قیمت جزئی ولی ثابتی در طول کل career خودت می‌پردازی، و در طول یک عمر، این تبدیل به یک مشکل عظیم می‌شود.»

Pattern #2: Be a Zen Master (مثل استاد ذن آرام باش)

وقتی لید هستی، همه وقت در معرض دید هستی. حتی وقتی پشت میزت داری ایمیل می‌زنی، همه تو را نگاه می‌کنند:

  • زبان بدن تو،
  • واکنش‌های تو به چت‌های کوچک،
  • سیگنال‌هایت سر ناهار.

همه دارند می‌خوانند: آیا تو اعتماد‌به‌نفس داری یا ترس؟

مثال واقعی: Bill (مدیر Fitz)

Bill هر موقع یک مشکل بزرگ پیش می‌آمد، هرگز panic نمی‌کرد.

  • یک بازویش را روی سینه‌اش می‌گذاشت،
  • چانه‌اش را روی دستش می‌گذاشت،
  • شروع به پرسیدن سوال درباره‌ی مشکل می‌کرد (معمولاً از کسی که دارد کاملاً panic می‌کند).

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

Fitz می‌گوید اگر کسی می‌آمد و می‌گفت ۱۹ دفتر شرکت توسط Alien حمله شده، Bill جواب می‌داد:

«ایده‌ای داری چرا نشدن ۲۰ دفتر؟»

Zen Trick: پرسیدن سوال

وقتی یکی از تیم از تو advice می‌خواهد، خیلی هیجان‌انگیز است چون بالاخره می‌توانی چیزی را Fix کنی! اما آخرین جایی که باید بروی solution mode است.

آن شخص معمولاً نمی‌خواهد تو مشکلش را حل کنی، بلکه می‌خواهد کمکش کنی که خودش حلش کند.

راه آسان: پرسیدن سوال.

این به معنای جایگزینی خودت با Magic 8 Ball نیست (که دیوانه‌کننده و بی‌فایده است)؛ بلکه کمک کنی مشکلش را refine و explore کند. معمولاً این کار، کارمند را به جواب هدایت می‌کند و جواب او خواهد بود، که به ownership و مسئولیت می‌انجامد.

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

Pattern #3: Be a Catalyst (کاتالیزگر باش)

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

این نقشی است که اغلب به‌عنوان لید باید بازی کنی.

Build Consensus (ایجاد اجماع)

یکی از رایج‌ترین کارهای team leader این است که consensus بسازد.

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

ساختن consensus یک مهارت لیدری است که حتی توسط unofficial leaders استفاده می‌شود، چون می‌توانی بدون هیچ authority واقعی، lead کنی.

Remove Roadblocks (برطرف کردن موانع)

گاهی تیم روی چیزی consensus دارد اما به roadblock می‌خورد.

خیلی از موانع برای تیم غیرممکن هستند، اما برای تو به‌عنوان لید آسان است که حلشان کنی:

مثال ۱: تیم Fitz چند هفته سعی کرد مشکلی را با Legal Department حل کنند؛ وقتی به Fitz آمدند، او در کم‌تر از ۲ ساعت حلش کرد چون می‌دانست باید با چه کسی صحبت کند.

مثال ۲: تیم Ben نیاز به server resources داشت و نمی‌توانستند allocated شود؛ Ben چون با تیم‌های دیگر در ارتباط بود، همان بعدازظهر منابع را برایشان فراهم کرد.

داستان “Know Where to Put the Chalk Mark”

یک استاد مکانیک بازنشسته شده؛ شرکت قدیمی‌اش مشکلی دارد که هیچ‌کس نمی‌تواند حل کند. استاد را صدا می‌کنند، او ماشین را بررسی می‌کند، گوش می‌دهد، و بالاخره یک X کوچک با گچ روی ماشین می‌زند و می‌گوید:

«دقیقاً اینجا یک سیم شل شده، تعمیرش کن.»

تعمیرکار باز می‌کند، سیم را محکم می‌کند، مشکل حل می‌شود. صورت‌حساب می‌رسد: ۱۰,۰۰۰ دلار. CEO عصبانی می‌شود و breakdown خرج را می‌خواهد.

استاد صورت‌حساب جدید می‌فرستد:

  • خودِ علامت گچ = ۱ دلار
  • دانستن اینکه کجا باید علامت بزنی = ۹,۹۹۹ دلار

این داستان درباره‌ی wisdom است: یک تنظیم کوچک ولی دقیق می‌تواند اثر عظیم داشته باشد.

Ben تیمش را مثل یک blimp تصور می‌کند که آرام در یک جهت حرکت می‌کند. بجای micromanage و اصلاحات مداوم، او یک هفته را فقط می‌بیند و گوش می‌دهد؛ آخر هفته یک علامت گچ کوچک در مکان دقیق روی blimp می‌زند و یک “tap” کوچک اما حیاتی می‌زند تا مسیر تنظیم شود.

Pattern #4: Remove Roadblocks (موانع را بردار)

یکی از مهم‌ترین کارهای لید این است که موانع را از سر راه تیم بردارد.

بعضی از موانع تقریباً برای اعضای تیم غیرممکن هستند، اما برای تو آسان. کمک کردن در این موارد بسیار ارزشمند است.

توضیح بیش‌تر در بخش Catalyst همین فصل بود؛ این یکی از انواع catalyst بودن است.

Pattern #5: Be a Teacher and Mentor (معلم و مربی باش)

کمک به رشد مهارت‌های تیم، یکی از بهترین سرمایه‌گذاری‌های بلندمدت است.

وقتی وقت می‌گذاری به افراد یاد بدهی، نه‌تنها مهارتشان بالا می‌رود، بلکه اعتماد و احترامشان به تو افزایش می‌یابد. این باز به HRT بازمی‌گردد.

حالا وارد الگوهای بعدی لیدری می‌شویم.

Pattern #6: Set Clear Goals (اهداف واضح تعیین کن)

یکی از بزرگ‌ترین چیزهایی که می‌توانی برای تیمت انجام دهی این است که اهداف را واضح کنی.

چرا مهم است؟

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

مثال: Mission Statement

گاهی شنیدن واژه‌ی Mission Statement باعث می‌شود فکر کنیم به چیزی مانند این برسیم:

«ما آرزو می‌کنیم محبوب‌ترین و باارزش‌ترین شرکت در جهان باشیم…»

این نوع بیانیه‌ها، marketing doublespeak هستند و هیچ معنای عملی ندارند.

Mission Statement واقعی

یک mission statement خوب، جهت را مشخص می‌کند و scope را محدود می‌کند. مثال واقعی از Google Web Toolkit (GWT):

«ماموریت GWT این است که تجربه‌ی وب را برای کاربران به‌شدت بهبود ببخشد، با این که توسعه‌دهندگان بتوانند با ابزارهای Java موجود، AJAX بدون سازش برای هر مرورگر مدرن بسازند.»

بعد از این، تیم GWT یک سند کامل با عنوان “Making GWT Better” نوشتند که جمله‌جمله‌ی mission statement را توضیح می‌داد و حتی یک بخش Nongoals (چیزهایی که پروژه نباید روی آن‌ها کار کند) هم داشت.

فایده

با داشتن mission statement واضح:

  • همه می‌دانند چه کاری باید انجام دهند؛
  • می‌توانی feature request های خارج از scope را به‌راحتی رد کنی؛
  • سال‌ها کار روی چیزهای نامرتبط را ذخیره می‌کنی.

Pattern #7: Be Honest (صادق باش)

صداقت در لیدری بسیار حیاتی است، چه در feedback دادن، چه در اعلام مشکلات واقعی.

مثال: Constructive Criticism

بسیاری از مردم از گرفتن criticism می‌ترسند چون فکر می‌کنند مجبورند روی تمام نقدهایی که دریافت می‌کنند action بگیرند، حتی اگر با آن موافق نباشند.

اما واقعیت این است: criticism یک هدیه است که می‌توانی قبول یا رد کنی.

مثلاً قبل از مصاحبه‌ی مهم، کت و شلوار مورد علاقه‌ات را پوشیدی و از دوستت پرسیدی: «چطور به‌نظر می‌رسم؟» او گفت:

«اسفناج بین دندان‌هات مانده، و راستش از کتت بدم می‌آد.»

تو می‌توانی اسفناج را پاک کنی، ولی لزومی ندارد لباسـت را عوض کنی.

چگونه نقد سازنده بدهیم؟

اشتباه: «دوست عزیز، کاملاً control flow اون متد رو اشتباه نوشتی. باید از pattern استاندارد xyzzy استفاده کنی مثل بقیه.»

این feedback پر از antipattern است:

  • به او می‌گویی «اشتباه است» (انگار دنیا سیاه و سفید است!).
  • demand می‌کنی چیزی را تغییر دهد.
  • به او می‌گویی کاری خلاف بقیه کرده (احساس احمق بودن).

درست: «هی، من کمی confused شدم از control flow اینجا. فکر می‌کنم pattern xyzzy ممکن است واضح‌تر و maintainable تر باشد؟»

توجه کن:

  • از humility استفاده کردی تا سوال را درباره‌ی خودت کنی، نه او.
  • او اشتباه نکرده؛ تو فقط مشکل در درک کد داری.
  • پیشنهاد را فقط offer می‌کنی، نه demand.
  • بحث در حوزه‌ی کد باقی می‌ماند، نه مهارت یا ارزش فردی.

Pattern #8: Track Happiness (شادی تیم را رصد کن)

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

چگونه؟

بهترین لیدهایی که با آن‌ها کار کرده‌ایم، روانشناسان آماتور بودند: گاهی از وضعیت رفاهی اعضا خبر می‌گرفتند، مطمئن می‌شدند که برای کارشان recognition دریافت کنند، و سعی می‌کردند خوشحال باشند.

یکی از لیدها: یک spreadsheet از تمام کارهای کثیف و ناخوشایند ساخت و مطمئن می‌شد این کارها به‌صورت مساوی بین تیم تقسیم شوند.

لید دیگر: ساعات کاری تیمش را زیر نظر داشت و از comp time و تفریحات تیمی استفاده می‌کرد تا از burnout جلوگیری کند.

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

سوال طلایی

یکی از ارزشمندترین ابزارها در پایان هر one-on-one این سوال است:

«به چه چیزی نیاز داری؟»

این سوال ساده، یک راه عالی برای wrap up است و مطمئن می‌شوی هر نفر آن‌چه را برای productive و خوشحال بودن نیاز دارد، دریافت کند. اگر این را هر بار بپرسی، بالاخره تیمت یادش می‌ماند و گاهی با یک لیست از چیزهایی که نیاز دارند پیش تو می‌آیند.

Career Tracking

بخش بزرگی از tracking happiness، tracking career است. اگر بپرسی «۵ سال دیگر خودت را کجا می‌بینی؟» بیش‌تر اوقات یک shrug و نگاه خالی می‌گیری. ولی معمولاً چند چیز وجود دارد که همه می‌خواهند:

  • Promote شوند،
  • چیز جدیدی یاد بگیرند،
  • چیزی مهم launch کنند،
  • با آدم‌های باهوش کار کنند.

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

Pattern #9: Intrinsic Versus Extrinsic Motivation (انگیزه‌ی درونی در برابر بیرونی)

در TED Talk معروف Dan Pink درباره‌ی motivation، او توضیح می‌دهد که برای کارهای خلاقانه (مانند نوشتن نرم‌افزار)، Intrinsic Motivation بسیار مهم‌تر از Extrinsic Motivation است.

Extrinsic Motivation

پاداش‌های بیرونی مثل:

  • پول بیش‌تر،
  • عنوان (Title) بهتر،
  • امتیازات (Perks) بیش‌تر.

این‌ها برای کارهای مکانیکی کار می‌کنند، اما برای کار خلاقانه، اثر می‌توانند معکوس باشد.

Intrinsic Motivation

پاداش‌های درونی که واقعاً کارآیی را بالا می‌برند:

  1. Autonomy (استقلال): آزادی در تصمیم‌گیری درباره‌ی نحوه‌ی کار.
  2. Mastery (تسلط): فرصت برای یادگیری و بهتر شدن.
  3. Purpose (هدف): احساس کردن که کارت اهمیت دارد.

اگر این سه را برای تیمت فراهم کنی، حتی اگر حقوق خیلی بالا نباشد، مهندسانت بسیار productive و خوشحال خواهند بود.

Other Tips and Tricks (نکات و ترفندهای دیگر)

Delegate, But Get Your Hands Dirty (واگذار کن، اما دست‌هایت را کثیف کن)

وقتی از نقش individual contributor به leadership می‌روی، سخت‌ترین کار یافتن balance است:

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

راه درست:

  • اگر تازه وارد لیدری شدی، باید سخت کار کنی تا کارها را به مهندسان دیگر delegate کنی، حتی اگر برایشان خیلی طول بکشد. این یکی از راه‌های حفظ sanity تو و رشد تیم است.
  • اگر مدت‌هاست لیدی یا تیم جدیدی گرفتی، یکی از آسان‌ترین راه‌های کسب احترام تیم این است که دست‌هایت را کثیف کنی — معمولاً با برداشتن یک کار کثیف که هیچ‌کس نمی‌خواهد انجامش دهد.

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

Seek to Replace Yourself (به دنبال جایگزین خودت باش)

مگر این‌که بخواهی تا آخر عمرت دقیقاً همان شغل را داشته باشی، به دنبال جایگزین کردن خودت باش.

این از فرآیند hiring شروع می‌شود: اگر می‌خواهی یکی از اعضای تیم جایت را بگیرد، باید افرادی استخدام کنی که قادر باشند جایت را بگیرند — به‌عبارت دیگر: «افرادی باهوش‌تر از خودت استخدام کن.»

وقتی اعضای تیم داری که می‌توانند کارت را انجام دهند، باید به آن‌ها فرصت بدهی مسئولیت‌های بیش‌تری بگیرند یا گاهی تیم را lead کنند. اگر این کار را بکنی، سریع می‌بینی که چه کسی بیش‌ترین استعداد برای لیدری دارد و چه کسی می‌خواهد لید کند.

نکته: به یاد داشته باش بعضی افراد ترجیح می‌دهند فقط high-performing individual contributor باشند، و این هم OK است. ما همیشه از شرکت‌هایی تعجب کرده‌ایم که بهترین مهندسانشان را — بر خلاف میلشان — به نقش‌های مدیریتی می‌کشند. این معمولاً یک مهندس عالی از تیمت کم می‌کند و یک مدیر بد اضافه می‌کند.

Know When to Make Waves (بدان کی باید موج بزنی)

گاهی موقعیت‌های سخت پیش می‌آید که تمام سلول‌های بدنت به تو می‌گویند: «هیچ کاری نکن».

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

«کمی صبر کن، خودش درست می‌شود.»

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

با صبر کردن، فقط اجتناب‌ناپذیر را به تاخیر می‌اندازی و در این مسیر آسیب غیرقابل توصیفی وارد می‌کنی. پس عمل کن، و سریع عمل کن.

حالا وارد فصل ۴: Dealing with Poisonous People (برخورد با افراد سمی) می‌شویم. این فصل به‌شدت کاربردی و مهم است.

فصل ۴: برخورد با افراد سمی

همان‌طور که در ابتدای کتاب گفته شد: «مهندسی کار آسانی است، آدم‌ها سخت‌اند.»

تاکنون، تمرکز ما روی خود تو و تیمت بوده است. حالا می‌خواهیم به بیرون نگاه کنیم: چطور از فرهنگ تیمت در برابر افراد مخرب محافظت کنی؟

تعریف “Poisonous” (سمی)

وقتی برای اولین بار درباره‌ی این موضوع سخنرانی کردیم، اسمش را “How Projects Survive Poisonous People” گذاشتیم. عنوان جنجالی بود و همیشه سالن پر می‌شد — اما خطر دارد.

خطر برچسب‌زدن

اصطلاح “Poisonous Person” یک لیبل منفی است که خط تقسیم ایجاد می‌کند: ما (آدم‌های خوب) در برابر آن‌ها (آدم‌های بد). اما راه بهتر این است: بجای رد کردن افراد، باید رفتارهای غیرقابل تحمل را رد کنی.

افراد صرفاً خوب یا بد نیستند؛ رفتارها هستند که باید شناسایی و اصلاح شوند.

پس در این فصل، “Poisonous Person” فقط یک کوتاه‌نویسی برای «شخصی که رفتار خوبی ندارد» است، نه یک حکم اعدام!

Fortifying Your Team (تقویت دفاع‌های تیم)

به یاد داستان خمیرمایه (Yeast Starter) در فصل ۲ هستی؟

  • اگر starter culture تیمت قوی باشد، می‌تواند تأثیر منفی افراد جدید را خنثی کند.
  • اگر ضعیف باشد، فرهنگ جدید (معمولاً مخرب) تیم را تسخیر می‌کند.

نمونه‌های واقعی:

  • Subversion از همان اول با تیمی بسیار مؤدب و محترم شروع شد. ۱۵ سال گذشته، ولی فرهنگ همچنان همان است: افراد جدید یا با فرهنگ سازگار می‌شوند یا می‌روند.
  • برعکس، بعضی پروژه‌ها (مثل کامیونیتی Linux Kernel) از ابتدا پر از اشخاص aggressive بودند، و همچنان همان فرهنگ ادامه دارد.

بدترین دفاع: امیدواری که مشکلات خودشان حل شوند.
بهترین دفاع: تقویت فرهنگ تیم با best practice‌های محکم (Mission Statement، مستندسازی، Code Review، …).

Identifying the Threat (شناسایی تهدید)

بزرگ‌ترین خطر: از دست دادن Attention و Focus تیم.

این‌ها کمیاب‌ترین منابع تو هستند. افراد سمی می‌توانند تمام انرژی تیم را روی بحث‌های بی‌فایده، دفاع از خود، یا درگیری‌های احساسی بگذارند.

چطور رفتار سمی را تشخیص بدهی؟

نویسنده‌ها می‌گویند وقتی این نشانه‌ها را دیدند، ذهناً “Bozo Bit” فرد را می‌زنند — یعنی یک علامت ذهنی می‌گذارند که این شخص مدام رفتارهای مخرب دارد و باید خیلی مراقب باشند.

Signal #1: بی‌احترامی به وقت دیگران

کسانی که بجای خواندن documentation، پرسیدن سوالاتی که خودشان می‌توانند جوابش را پیدا کنند، یا دائماً با چیزهای غیرضروری وقت تیم را می‌گیرند.

مثال: Charlie در پروژه‌ی Subversion هر ۲–۳ ساعت یک ایمیل ارسال می‌کرد با ایده‌های تازه‌اش (بدون هیچ کد نوشتنی). سپس جواب سوالات کاربران را هم غلط می‌داد و تیم مجبور بود دوباره اصلاح کنند. مدت‌ها طول کشید تا بفهمیم او در واقع poisonous است.

Signal #2: Ego (غرور افراطی)

کسی که هرگز نمی‌تواند consensus را بپذیرد، نظر دیگران را گوش کند، یا به مصالحه برسد.

مثال: یک برنامه‌نویس باهوش آمد و اعلام کرد «طراحی کل Subversion اشتباه است و باید از صفر شروع شود!» یک هفته کامل صرف بحث با او شد. او حاضر به compromise نبود و پروژه‌ای که در beta بود قرار نبود از صفر شروع شود. بالاخره مجبور شدیم بحث را ول کنیم. جالب این‌که بعداً فهمیدیم بعضی از حرف‌هایش درست بود، اما Subversion با همان design موفق شد!

نکته: نه کسی ۱۰۰٪ حق داشت نه غلط؛ بلکه وقت تلف کردن در بحث‌هایی که هیچ وقت تمام نمی‌شوند مشکل بود.

Signal #3: Perfectionism (کمال‌گرایی افراطی)

ظاهرش خوب است: فردی فروتن، مؤدب، محترم، شنونده. اما تهدید فلج شدن را به همراه دارد.

مثال: Patrick یک مهندس عالی بود، اما هیچ وقت طراحیش کامل نمی‌شد. تیم منتظر ماند و ماند؛ هرگز شروع به کد نوشتن نکردند چون او هر بار می‌گفت «ممکن است مشکلی در آینده پیش بیاید». فلج شده بودیم.

Repelling the Poison (دفع کردن سم)

هدف ما Boot کردن Behavior است، نه شخص.

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

Strategy #1: Redirect Energy of Perfectionists (انرژی کمال‌گراها را هدایت کن)

وقتی یک راه‌حل “کافی” پیدا شد، کمال‌گرا را سمت یک مشکل دیگر هدایت کن.

مثال Patrick: بهش گفتیم «باشه، الان روی همین طراحی شروع می‌کنیم، امیدواریم تو کمکمون کنی اگر مشکلی پیش اومد.» او موافقت کرد و شروع به obsess شدن روی موضوع دیگری کرد!

این ترفند برای کسانی که مرتب شکایت می‌کنند هم کار می‌کند: بهشان بگو testing انجام دهند و regressionها را report کنند — همچنان complaint دارند ولی مفید است!

Strategy #2: Don’t Feed the Energy Creature (به تریبون دادن وقتت را تلف نکن)

شعار قدیمی Usenet: «Don’t feed the trolls».

  • اگر کسی عمداً trolling می‌کند (می‌خواهد تو را عصبانی کند)، سکوت کن.
  • هر چقدر جواب بدهی، بیشتر از انرژی تو تغذیه می‌کند.
  • معمولاً وقتی هیچ‌کس توجه نکند، خودش خسته می‌شود و می‌رود.

سخت است که جواب ندهی، ولی قوی باش!

Strategy #3: Don’t Get Overly Emotional (احساساتی نشو)

حتی اگر شخص عمداً troll نیست، آسان است که دفاعی شوی.

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

قانون: نبردهایت را با دقت انتخاب کن و آرام بمان.

Strategy #4: Look for Facts in the Bile (در بین تلخی، فکت را پیدا کن)

همیشه با دادن benefit of the doubt شروع کن.

  • اگر کسی شکایت می‌کند، با دقت گوش کن.
  • آیا نکته‌ی واقعی دارد؟ آیا چیزی برای یادگیری هست؟

مثال: یک روز یک ایمیل عصبانی از یک leader معروف‌ی در جامعه open source دریافت کردیم. پر از توهین و اغراق بود. اما یکی از تیم ما فقط چند سوال فنی درباره‌ی bug پرسید و تمام توهین‌ها را نادیده گرفت. فرستنده بازهم جواب داد (با سم بیشتر)، ولی تیم ما همچنان فقط روی bug تمرکز کرد و گفت:

«ممنون از bug report، می‌دونم چطور حلش کنم — به‌زودی patch منتشر می‌کنیم.»

تا پایان بحث، فرستنده‌ی اصلی تمام اعتبارش را از دست داد و دیگر اطرافش نماند.

کتاب مهندسی برنامه_نویسی