تبدیل شدن به یک رهبر فنی

مطلبی که می‌خوانید ترجمه‌ی قسمت ۲۶۵ از رادیو مهندسی نرم‌افزار است. رادیو مهندسی نرم‌افزار هر یکی دو هفته یک بار مصاحبه‌ای درباره‌ی یکی از موضوعات حوزه‌ی مهندسی نرم‌افزار با افراد خبره و با تجربه در موضوع مورد بحث ترتیب می‌دهد.

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

به یک برنامه‌ی دیگر از رادیوی مهندسی نرم‌افزار خوش آمدید. امروز با پاتریک کوا هستم. به رادیوی مهندسی نرم‌افزار خوش آمد پاتریک! خوشحالیم که با ما هستی.

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

پاتریک کوا یک مشاور ارشد و یک رهبر فنی در Thoughtworks است. معمولاً در لندن زندگی می‌کند، هرچند در حال حاضر در برلین کار می‌کند. او در زمینه‌ی توسعه‌ی نرم‌افزار بیش از یک دهه تجربه دارد و تمرکزش بر افراد، کسب و کار و فناوری است. ممکن است او را به واسطه‌ی کتاب «دفترچه راهنمای گذشته‌نگر» (The Retrospective Handbook) و یا کتاب جدیدترش «گفتگو با رهبران فنی» (Talking with Tech Leads) بشناسید. پاتریک همچنین در زمینه‌ی آموزش رهبری فنی، هم به صورت داخلی در Thoughtworks و هم در خارج از آن فعالیت داشته است. من در یکی از این آموزش‌های او بوده‌ام. موضوع این برنامه چگونگی تبدیل شدن به یک رهبر فنی است که کاملاً منطبق [با تجربیات او] است.
پاتریک آیا چیز دیگری هست که بخواهی در مورد خودت بگویی؟

نه، خیلی خوب خلاصه‌اش کردی.

برای این‌که جای ابهامی باقی نماند، هم من و هم پاتریک در Thoughtworks کار می‌کنیم. برای همین من در یکی از آموزش‌های او شرکت کردم. اولین سؤالی که هنگام صحبت کردن در مورد رهبری فنی به ذهن می‌رسد این است که نقش رهبر فنی چیست؟ وقتی من یک رهبر فنی می‌شوم چه مسئولیت‌هایی دارم؟

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

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

آنچه که به نظر من رهبر فنی نیست، چیزی است که افراد اغلب به آن مدیر فنی می‌گویند. کسی که بیشتر مسئولِ پیشرفت افراد و گزارش‌هاست اما لزوماً درگیر معماری نیست. حتی اگر پیش‌زمینه‌ی فنی داشته باشد لزوماً بر سیستم متمرکز نیست. انتظار دارم که مدیران فنی با رهبر فنی در تعامل باشند.

در بسیاری شرکت‌های دیگر استاد اسکرام (Scrum Master) نقش خیلی محبوبی است و به نظر من، این نقش خیلی متفاوت [از رهبر فنی] است، هر چند یک رهبر فنی می‌تواند استاد اسکرام هم باشد. استاد اسکرام بودن، لزوماً به صورت خودکار از شما یک رهبر فنی نمی‌سازد.

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

درست است.

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

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

من نوعی از تقسیم [وظایف] را [در نقش رهبر فنی] می‌بینم؛ یک جنبه‌ی فنی که مربوط به معماری و مسیر سیستم است، و جنبه‌ی مدیریت افراد و پروژه که ممکن است بیشتر مربوط به مدیر فنی باشد. این یک الگوی متداول است که می‌بینم. اما تأکید می‌کنم که این یک نقش است و به این معنی است که مجموعه‌ای از مسئولیت‌ها را شامل می‌شود.

پیش از آن‌که در این موضوع عمیق‌تر شویم آیا ممکن است توضیح دهید که دقیقاً چرا به رهبر فنی نیاز داریم؟

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

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

به خاطر دارم که یک توئیت را در ارائه‌تان به اشتراک گذاشته بودید: «در آخرین پروژه‌ام ده نفر بودند که همه‌شان عقایدی سرسختانه داشتند که در کد نشان داده شده بود.» آیا به همین مسئله اشاره دارید؟

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

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

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

آن ها در مورد نقش رهبری فنی چه گفتند؟

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

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

آیا در اولین تجربه‌ی رهبری فنی، مناقشه داشتید؟

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

ممکن است با یک مثال این را توضیح دهید؟

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

پیش از آن تعطیلات مهم، پیش از آن تماس، با چنین شرایطی چطور عکس‌العمل نشان می‌دادید؟ به عنوان یک رهبر فنی چطور؟

فکر می‌کنم قبل از تعطیلات احتمالاً می‌گفتم این مسئله به من مربوط نیست. مسئولیت رهبر فنی یا مدیر پروژه است که به آن رسیدگی کند.

بنابراین حداکثر کاری که می‌کردید صحبت کردن با رهبر فنی یا مدیر پروژه بود؟

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

در نهایت آن‌ها روی یک سبک‌ کاری به توافق رسیدند؟

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

داستان خوبی است. با این داستان خیلی سطحی در مورد وظایف رهبر فنی صحبت کردیم. بنابراین باید چشم‌انداز پروژه و معماری کلی آن را در ذهن داشته باشید. یک برنامه‌ی خوب در مورد طرح‌های معماری نرم‌افزار داریم که توسط سایمون براون ارائه شده است که ممکن است ارزش شنیدن را داشته باشد. او نویسنده‌ی کتاب «معماری نرم‌افزار برای توسعه‌دهندگان» ( Software Architecture for Developers) است (اشاره به قسمت ۲۲۸ است-مترجم).
این در مورد کار کردن با افراد بود که در مثالی که درباره مناقشه داشتید به آن اشاره کردید. چه کارهای دیگری را به عنوان مسئولیت‌های یک رهبر فنی می‌بینید؟

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

حوزه‌ای مربوط به رهبری عمومی هم وجود دارد. منظور از آن مثلاً رسیدگی به مناقشات است. اما به نظرم چیزهای زیادی درباره‌ی رهبری وجود دارد که یک رهبری فنی کارآمد از آن بهره می‌گیرد. بخشی از آن این است که افرادِ در حوزه‌ی کسب و کار را متقاعد کند که باید به صورت تیمی به مسائل فنی بپردازند. چون باید این زمان را صرف کرده باشید تا بتوانید در برخورد با مسائل فنی عمیق و یا مسائل زیرساختی به صورت کارآمدتری عمل کنید. مثل یک خیابان دوطرفه است. باید توسعه‌دهندگان را هم متقاعد کنید که فقط روی مسائل فنی کار نکنند تا اطمینان داشته باشند میان چیزی که روی آن کار می‌کنند و کمک به کسب و کار، ارتباطی وجود داشته باشد. چون به این ترتیب می‌خواهید میان افراد فنی و کسب و کار اعتمادسازی کنید. بنابراین رهبر فنی به نوعی نقش یک پل را ایفا می‌کند. کمی در مورد مدیریت مخاطرات (Risk) صحبت کردم. به نظرم این یک مسئله‌ی خیلی بزرگ است که یک رهبری فنی باید به آن بیاندیشد. در بیشتر سازمان‌ها این نقش معمولاً مرتبط با افراد دیگری خارج از تیم است. این افراد ممکن است افراد تیم عملیات (Operations) یا پشتیبانی باشند که باید نرم‌افزار ساخته شده را اجرا کنند. همچنین ممکن است افراد حوزه‌ی بازاریابی و مالی باشند که در با پیامدها و ویژگی‌های نرم‌افزار [سروکار دارند]. در واقع هدف این است که یک نفر به طور کلی نگرانی‌های مخاطرات را در نظر دارد؛ برخی تیم‌ها ممکن است مدیر پروژه داشته باشند یا نه. رهبر فنی باید در مورد مخاطرات فنی هم بیاندیشد. مثلاً آیا وقتی نرم‌افزار در محیط محصول قرار می‌گیرد به اندازه‌ی کافی زیرساخت برای لاگ وجود دارد تا اگر چیزی خراب شد بتوان از آن پشتیبانی کرد؟ آیا تصمیمات فنی درستی گرفته‌ایم تا به نقشه‌ی راه یک فروشنده‌ی خاص وابسته نشویم و اگر آن فروشنده از بین برود نرم‌افزار ما هم دچار مشکل شود. آیا به اندازه‌ی کافی وقت صرف تمیز نگه داشتن کد و بازسازی (Refactor) آن می‌کنیم؟ چون در نهایت این منجر به کاهش اثرگذاری تیم می‌شود. فکر می‌کنم این‌ها مسئولیت‌های رهبری عمومی هستند.

حوزه‌ی سوم مربوط به معماری است. یعنی تلاش برای این‌که افراد بیشتر به ساختن یک سیستم فکر کنند تا به نوشتن نرم‌افزار. یعنی فقط به ویژگی‌هایی که می‌نویسند فکر نکنند بلکه به زیست‌بومی (Ecosystem) که نرم‌افزار در آن زندگی خواهد کرد هم فکر کنند.

یعنی فکر کردن به این‌که آیا باید با یک محفظه‌ی داکِر در فضای ابری (Cloud) مستقر شود یا چنین چیزهایی؟

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

عنوان نوشته‌ی بلاگی که به آن اشاره کردید «رهبر فنی-حوزه‌های مسئولیت» است. می‌خواهم کمی در مورد برخی چیزهایی که مطرح شد عمیق‌تر صحبت کنیم. چیزهایی مثل رهبری و همین‌طور امور مربوط به توسعه از جمله شئ‌گرایی، ‌کدنویسی، معماری تکاملی، و … . به نظرم تا حدی شبیه به مدیریت فرهنگ تیم است. آیا شما این را هم مسئولیت خود می‌بینید؟

بله، قطعاً. فکر می‌کنم فرهنگ تیم یک بخش مهم است. در یکی از سخنرانی‌هایی که داشتم که عنوانش «راهنمای رهبری یک تیم برای یک خوره‌ی نرم‌افزار» (The geek's guide to leading a team) است در این مورد صحبت کردم که یک رهبر فنی باید بر چه چیزهایی از جنبه‌ی فرهنگ تیمی تمرکز کند. من آن را با رهبر تیم مقایسه می‌کنم، که روی نحوه‌ی تعامل اعضای تیم با یکدیگر کار می‌کند. در نقش رهبر فنی یک مسأله فرهنگی این است که افراد چه رویکردی نسبت به کدی که می‌نویسند دارند؟ مثلاً این‌که به دنبال ترویج چه نوعی از فرهنگ توسعه هستید؟ چون توانایی تأثیرگذاری بر آن را دارید.

یک مثال از آن این است که اگر یکپارچه‌سازی مستمر (Continuous Integration) دارید، [ممکن است] یک بیلد (Build) خراب شود. من در تیم‌هایی کار کرده‌ام که در آن این خرابی ادامه پیدا می‌کرد چون نگاه این بود که مشکل کسِ دیگری است. این نشان از نوعی از [مشکل] فرهنگ تیمی بود که رهبر فنی روی آن تمرکز نکرده بود. این در مقابل تیمی است که به محض این‌که یک بیلد خراب شود، یک نفر به سوی آن می‌شتابد و پرچمی افراشته می‌شود که مشخص می‌کند چه کسی در حال درست کردن آن است.

برای ایجاد و حمایت از این فرهنگ تیمی معمولاً چه می‌کنید؟

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

یک راه دیگر برای یک‌سو شدن این است که یک توسعه‌دهنده، بخشی از سیستم را توضیح دهد (شاید در مورد تعامل با واسط‌های برنامه‌نویسی (API) خارجی یا سایر وابستگی‌های خارجی باشد) و سپس ببینیم آیا یک رویکرد عمومیِ سازگار در آن وجود دارد یا خیر. حتی در یک تیم هشت نفره ممکن است با سه راهبرد برای تعامل با سیستم‌های خارجی مواجه شوید و افراد می‌توانند از این یاد بگیرند.

آن‌چه متوجه شدم این است که آن‌چه شما می‌گویید کمی شبیه به اجتماعات فنی (Tech Huddle) است که در آن تیم گرد هم آمده و در مورد فناوری‌ها صحبت می‌کنند. آیا منظور همین است؟

بله، قطعاً. اجتماع فنی یک نام آن و یک راه برای رسیدن به آن است. برخی تیم‌ها یک بازبینی کد (Code Review) کاملاً گروهی انجام می‌دهند. شرکتی به نام Unruly در انگلیس هست که به خاطر فراتر بردن XP، (مخفف Extreme Programming) شناخته شده است. آن‌ها برنامه‌نویسی گروهی (Mob Programming) را اتخاذ کرده‌اند که در آن تمام تیم در یک زمان در حال برنامه‌نویسی است.

اجازه بدهید از فرهنگ تیم به موضوع رشد توسعه‌دهنده و رشد افراد، برویم. فکر می‌کنم این به کار رهبر فنی مربوط باشد. رویکرد شما به آن چطور است؟

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

می‌شود مثالی از انجام این کار با یک شخص بزنید؟

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

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

راهبرد رهبر ویژگی اساساً به این معنی است که به افراد صراحتاً مسئولیت‌هایی در تیم سپرده شود و از کسانی که به تنهایی از پسِ آن بر نمی‌آیند حمایت شود.

بله، دقیقاً.

چطور از من حمایت می‌کنید؟ اگر من رهبر ویژگی احراز هویت باشم و ندانم چطور شروع کنم به من چه می‌گویید؟

کمی در مورد آن‌چه از یک رهبر ویژگی انتظار دارم صحبت می‌کنم. این‌که اطمینان حاصل کنیم تمام نیازمندی‌های کسب و کار برآورده شده است و تمامی مخاطراتِ موارد کاربرد مربوط به احراز هویت که نیاز داریم ارزیابی می‌شود. بخشی از آن احتمالاً این است که باید با چنین افرادی صحبت کنی تا بفهمی چطور می‌خواهند با سیستم تعامل می‌کنند. سپس او به این کار می‌پردازد و سپس در مورد رویکرد فنی به این مسئله صحبت می‌کند. یک عادت خوب رهبر فنی این است که جواب کامل را بلافاصله ندهد و اجازه دهد افراد خود به آن دست یابند. من سؤالات زیادی می‌پرسم تا بفهمم افراد چه علاقه‌مندی‌هایی دارند و چه دانشی دارند. در مثالی که زدید اگر اصلاً ندانند از کجا باید شروع کرد، کمی واضح‌تر می‌گویم: «آیا OAuth و کتابخانه‌های مربوط به این زمینه را دیده‌ای؟ آیا به احراز هویت دوگانه (Two Factor Authentication) نیاز داریم؟» سپس افراد آن را بررسی کرده و راه‌حل مناسب را با توجه به پشته‌ی فناوری‌ای که داریم پیدا می‌کنند. حتی ممکن است بگویم «برو و یک Spike اجرا کن.» که یک تحقیق فنی با زمان محدود است که در آن فرد، یک نمونه‌ی اولیه‌ی کوچک ارائه می‌کند و از آن یاد می‌گیریم.

وقتی من در این شرایط هستم معمولاً می‌گویم: «این‌ها عباراتی است که در گوگل جستجو می‌کنم.» شما هم این کار را می‌کنید؟

بله، قطعاً این هم یک گزینه است.

بسیار خوب. به رهبر ویژگی اشاره کردیم که به این معنی است که بخشی از وظایف یک رهبر فنی را به شخص دیگری می‌سپارید تا رشد کند. آیا نکته‌ای در انتخاب فرد مناسب برای این کار وجود دارد؟

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

آیا تا به حال در شرایطی بوده‌اید که یک نفر، زیادی داوطلب شود؟

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

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

این مربوط به شناخت افراد است. ابزاری که می‌توانید از آن استفاده کنید گفتگوهای دو نفره است. از افراد بپرسید به چه چیزی علاقه‌مند هستند؟ چه کار می‌خواهند انجام دهند؟ وقتی این را از افراد بپرسید، بسیاری از افراد معمولاً جوابی ندارند چون در واقع به آن فکر نمی‌کنند. برخی هم اهداف واضحی دارند. بنابراین بخشی از آن این است که بفهمید افراد به چه علاقه‌مند هستند، اهداف واقعی آن‌ها چیست و به کدام سو می‌روند. من به عنوان یک رهبر فنی به دنبال این هستم که در محیطی که در آن هستیم کارهای در دسترسِ قابل انجام را با فرصت‌هایی که افراد دوست دارند و شاید هنوز نمی‌دانند، همسو کنم. برای مثال، توسعه‌دهندگانی داشته‌ام که می‌خواستند وارد فضای ذهنی توسعه-عملیات (DevOps) و کار با زیرساخت شوند و روی خودکارسازی، با مثلاً Puppet یا Chef و چنین چیزهایی کار کنند. در حالی که سایر توسعه‌دهندگان اصلاً نمی‌خواستند با آن سر و کار داشته باشند. بیشتر می‌خواستند بر جلوی‌کار (Frontend) و واسط کاربری متمرکز باشند. یا گروه دیگری که نمی‌خواهند حتی به واسط کاربری نگاه کنند :-) و می‌خواهند در توسعه‌ی سرویس‌های سرسخت پشتِ‌کار (Backend) و واسط‌های برنامه‌نویسی، رشد کنند. اگر از افراد نپرسید این‌ها را نخواهید فهمید. این‌جاست که صَرف وقت برای هر توسعه‌دهنده مفید است. شاید حتی به صورت گروهی هم بتوانید آن را انجام دهید.

باز هم موضوع را کمی عوض کنیم. در ابتدا اشاره کردید که به عنوان یک رهبر فنی باید خودتان هم کد بنویسید. چرا؟

فکر می‌کنم یک مسئله‌ی کلیدی است. برای من به این معنی است که بتوانید کد سیستم را بنویسید. مقاله‌ای در ComputerWorld یا InfoWorld هم هست که به آن ارجاع می‌کنم. نویسنده در آن در مورد این صحبت می‌کند که توسعه‌دهندگان به این خاطر به سایر توسعه‌دهندگان احترام می‌گذارند که کدِ آن‌ها را می‌بینند. یک مثال از اوایل فعالیت حرفه‌ایم دارم. در شرکتی کار می‌کردم که چند مدیر فنی داشت. یکی از مدیران فنی می‌خواست در ارتباط با اتمام یک ابزار جلسه داشته باشیم که در آن زمان سیستم کنترل نسخه‌ها (CVS) را به سیستم داخلی کنترل کدهای منبع‌شان (Source Control) متصل می‌کرد. این ابزار وابستگی‌هایی به Perl و ... داشت و ساعات آخر روز جمعه بود. مدیر آمد و گفت «خیلی مهم است که این کار قبل از پایان روز به اتمام برسد.» صحبت از ساعت ۳ بعد از ظهر روز جمعه است :-) و من تقریباً مطمئن هستم که نمی‌توانیم آن را تمام کنیم. گفتم بیایید بنشینیم و با هم روی آن کار کنیم و کیبورد را به مدیر فنی دادم. چهره‌اش طوری بود که می‌گفت چه کنم؟ برای من واضح بود که او نمی‌تواند کد Perl بنویسد و نمی‌دانستم با کنار من نشستن می‌خواست به چه چیزی دست یابد. من در ابتدای فعالیت حرفه‌ایم متوجه شدم که «بسیار خوب، این فرد را در زمره‌ی افراد غیر فنی قرار می‌دهم» و در این نقطه، دیدگاه‌تان تغییر خواهد کرد.

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

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

بله، قطعاً. زیاد می‌بینم که رهبران فنی، به ویژه آن‌هایی که بی‌مقدمه در این نقش قرار گرفته‌اند، به تیم اعتماد می‌کنند. وقتی شش ماه بعد به سراغ کد می‌روند می‌گویند: «چرا کلاس‌های ما سیصد خط هستند؟ تست‌ها کجا هستند؟» و به دنبال تمامی انتظاراتشان از کد خوب می‌گردند که در واقع محقق نشده‌اند،‌ چون تیم این تصمیم‌ها را گرفته است. این برای من به منزله‌ی مدیریت مخاطرات فنی (Technical Risk Management) است. یعنی خیلی خوب است که به توسعه‌دهندگان اعتماد کنید و بخواهید به آن‌ها این حد از آزادی و درک را بدهید. اما در عین حال به یک حلقه‌ی بازخورد نیاز دارید تا آن‌چه که فکر می‌کنید در حال رخ دادن است محقق شود. این برای من یک مسئله‌ی کلیدی است. به عنوان یک رهبر فنی باید بدانید وضعیت فعلی سیستم چیست تا بتوانید موازنه برقرار کنید. موازنه‌ای میان سرعت اضافه کردن ویژگی‌ها و یا بازطراحی و رویکردهای معماری در یک بخش سیستم.

وقتی به عنوان یک رهبر فنی کد می‌نویسید، آیا دو نفری (Pair) کد می‌زنید و یا به تنهایی و یا به شکل دیگری است؟

سؤال خوبی است. به شدت توصیه می‌کنم که از تبدیل شدن به یک تکاورِ تنها که روی ویژگی‌های بحرانی و حساس به زمان کار می‌کند، خودداری کنید. چون تبدیل به مسدودکننده کار می‌شوید. فکر می‌کنم یکی از دشواری‌هایی که بعداً در مورد آن صحبت خواهیم کرد مربوط به مدیریت زمان است. یعنی نمی‌توانید مداوم روی یک چیز کار کنید و باید از کار کردن روی چیزهایی که در مسیر بحرانی قرار دارند پرهیز کنید. به نظرم دو نفری کار کردن راه خیلی خوبی است. وقتی برای [پیاده‌سازی] یک ویژگی یا یک داستان (Story) گرد هم می‌آییم، در مورد رویکرد کلی و کاری که باید انجام دهیم صحبت می‌کنیم. صراحتاً در مورد کارهایی که می‌خواهیم انجام دهیم حرف می‌زنیم تا اگر من مجبور به ترک کار شدم یا باید به جلسه می‌رفتم آن شخص بتواند کار را ادامه دهد و امیدوار باشم تا وقتی برمی‌گردم کار از مسیر خارج نشده یا حداقل می‌شود درباره‌ی آن صحبت کرد. این کار، یکی دو مزیت دارد. شخصی که با او کار می‌کنید اطلاعاتی از یک دیدگاه دیگر دریافت می‌کند. شما هم نقطه‌ی تماسی با آن ویژگی پیدا می‌کنید و می‌فهمید در کد چه خبر است.

بنابراین وقتی دونفری کار می‌کنید مسیر پیاده‌سازی را طراحی می‌کنید تا در صورتی که لازم شد به جلسه بروید شخص دیگر بتواند به تنهایی کار را ادامه دهد؟

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

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

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

فارغ از این تنهایی، تبدیل شدن به یک رهبر فنی به چه معناست؟

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

یک بار در جلسه‌ای بودم، [پرسیدم] کدام یک از شما مدیر، کدام توسعه‌دهنده و کدام‌یک معمار است؟ او گفت مدیر کسی است که سرش مدام در ایمیل است. توسعه‌دهنده مدام در IDE و معمار در PowerPoint است :-) و من گفتم رهبر فنی همیشه سرش در تقویم‌اش است :-)

در این نهارها در این مورد هم صحبت می‌کنید؟ می‌توانید صحبت‌هایی که در این جلسات اتفاق می‌‌افتاد را به اشتراک بگذارید؟

بله. Thoughtworks یک شرکت مشاوره‌ای است و با مشتریان متفاوتی کار می‌کند. اما من این شانس را داشتم که نزدیک به تیم‌هایی باشم که با مشتریانی کار می‌کردند که در همسایگی ما هستند. وقت نهار گرد هم می‌آمدیم چون این راحت‌ترین راه بود که در جایی خنثی کنار هم باشیم. سپس روی یکی از موضوعات روز تمرکز می‌کردیم. لیستی از موضوعاتی که می‌خواستیم درباره‌ی آن صحبت کنیم داشتیم. یکی از این موضوعات مدیریت زمان بود: «چطور خود را از جلسات رها کنید؟» موضوع دیگر هم بود که درباره‌ی نحوه‌ی تعامل با مشکلات توسعه‌دهندگان بود. مثلاً شاید توسعه‌دهنده‌ای باشد که با سایر اعضای تیم وفق نمی‌شود. دیگران چه راهبردهایی در کمک به برطرف کردن این مسئله استفاده می‌کنند؟ این به یک‌سو کردن راهبردها در این نوع مسائل کمک می‌کند. گاهی اوقات صحبت از مسائل فنی بود. مثلاً بازبینی معماری‌مان و این‌که آیا مناسب است یا این‌که شما رویکردی دیگری به آن می‌داشتید؟ تلاش می‌کردیم روی چیزهایی که خیلی مربوط به توسعه‌دهنده هستند، تمرکز نکنیم. چون در این مسائل می‌توانید با تیم‌تان صحبت کنید: «الگوی طراحی درست برای این ویژگی چیست؟ و ...» بیشتر روی مسائلی تمرکز می‌کردیم که فکر می‌کردیم مناسبِ همکارانِ در آن سطح بود.

به نظر می‌رسد ایجاد شبکه‌ی حمایتی راهبرد خوبی باشد. بیایید به فرایندِ تبدیل شدن به رهبر فنی نگاه کنیم. وقتی که از تعطیلات بر می‌گشتید در فرودگاه با شما تماس گرفتند و با این یک تماس شما از یک توسعه‌دهنده به یک رهبر فنی تبدیل شدید. آیا در این مسیر قدم برمی‌داشتید یا اتفاقی بود؟

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

بعد از این تجربه به دنبال کتاب‌هایی در این موضوع گشتم. قدیمی‌ترین کتابی که پیدا کردم «رهبر فنی شدن» (Becoming Technical Leader) نوشته‌ی جرالد واینبرگ بود. کتاب خیلی خوبی بود و ابزارهای خوبی در اختیار قرار می‌دهد اما فکر می‌کنم به درد هر کسی در هر محیط فنی بخورد و خاص رهبران فنی نیست. در کمک کردن به افراد برای این‌که معنی رهبر فنی موفق را درک کنند، یک جای خالی را حس می‌کردم. این یکی از دلایلی بود که نوشتن کتابم را شروع کردم که مجموعه‌ای از مصاحبه‌هاست با عنوان «گفتگو با رهبران فنی» (Talking with Tech Leads).

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

نه :-) فکر می‌کنم بخشی از دشواری این است که اولاً وقتی کسی این نقش را به شما می‌دهد، عدم قطعیت وجود دارد. اغلب میزان زیادی اضطراب دارید: «آیا کارم را به درستی انجام می‌دهم؟» خیلی دشوار است که فهرستی از مسئولیت‌ها یا زمینه‌هایی که باید بر آن تمرکز کنید، تهیه کرد. من از چیزهایی که نمی‌دانستم، آگاهی نداشتم و می‌دانستم که احتمالاً چیزهایی هستند که باید به دنبال آن باشم اما درباره‌شان نمی‌دانم. سعی می‌کردم با افراد درباره‌ی کارهایی که انجام نمی‌دهم ولی باید انجام دهم، صحبت کنم. در عین حال تلاش کردم به خودم بفهمانم: من از سطح مهارت‌های توسعه‌ی خودم راضی‌ام اما قطعاً مهارت‌های رهبری هم هست که در عنوان این نقش هست. این‌ها به چه معنی است؟ کجا می‌توانم آن‌ها را بهبود بخشم؟ درک نحوه ی ارتباط کارآمد، خصوصاً با ذی‌نفعان غیرفنی و فنی. چطور به مناقشات رسیدگی کنم؟ چطور بدون نوشتن کد، روی افراد تأثیر بگذرام؟ این مسائل مربوط به معماری رهبر فنی چه هستند؟ و تلاش کنم در این زمینه‌ها مهارت پیدا کنم.

آیا توسعه‌دهندگان تیم شما کاری انجام دادند که در این فرایند جابجایی به شما کمک کند؟ آیا به طور عمومی، توسعه‌دهندگان می‌توانند کاری در در حمایت از یک رهبر فنی تازه‌کار انجام دهند؟

بله. اگر به چند تا از تیم‌های قبلی‌ام فکر کنم، دریافت بازخورد از چند منبع به من کمک کرد. یکی از ابزارهای مورد علاقه‌ی من برای این‌کار، چرخه‌ی بازخورد ۳۶۰ درجه است، که در جلسات دو نفره یا سایر جلسات از آن استفاده می‌کردم. گاهی اوقات می‌توانیم کنار هم بنشینیم. دیده‌ام که سایر رهبران فنی فکر می‌کنند که کارشان عالی است، اما توسعه‌دهندگان نظر متفاوتی دارند. فکر می‌کنم یک رهبر فنی باید خود را مجبور به دریافت بازخورد از منظر توسعه‌دهندگان کند. اگر اعتمادسازی نکرده باشید، کار سختی است اما فکر می‌کنم واقعاً امر مهمی است و اگر این رفتار را با تیم‌تان داشته باشید اعتماد،‌ عمیق‌تر می‌شود.

اگر بتوانید این سؤالات را مطرح کنید «من به عنوان یک رهبر فنی چه می‌کنم و تو چه انتظاراتی داری؟ آیا من آن‌ها را برآورده می‌کنم؟ فکر می‌کنی در کدام زمینه ضعیف‌تر هستم یا می‌توانم بهبود پیدا کنم؟ در کدام زمینه کارم را خوب انجام می‌دهم؟» در اینصورت دیدگاه بهتری نسبت به آن خواهید داشت و می‌توانید آن را در سطح تیم بررسی کنید.

بنابراین بازخورد گرفتن ابزار مهمی است. اگر مایل هستید بگویید خود شما چه بازخوردهایی دریافت کردید؟

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

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

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

این سؤال خیلی خوبی است :) واقعاً تا به حال به آن فکر نکرده‌ام. هر کس سبک رهبری فنی خودش را دارد. آن‌چه به نظر من خوب است این است که باید رویکردتان به مسائل را درک کنید و بشناسید. یک نشانه از کارامدی رهبر فنی این است که هر روز به او نیاز ندارید. اگر رهبری فنی مدام درگیر جلسات و جواب دادن به همه‌ی مسائل است، احتمالاً رهبر فنی کارآمدی نیست. به یکی از اولین سؤالات شما برگردیم «اصلاً چرا به رهبر فنی احتیاج داریم؟» اگر رهبر فنی کارآمدی باشید، به نقش توسعه‌دهنده برمی‌گردید و هنوز می‌توانید روی تصویر کلی تمرکز داشته باشید و مراقب ناهمسویی‌ها باشید. اگر کارتان را به خوبی انجام دهید، تیم باید [با تصویر کلی] همسو باشد و نباید مناقشات زیادی وجود داشته باشد، یا اگر هم هست خودشان باید بتوانند آن را برطرف کنند و این توافق عمومی باید وجود داشته باشد.

بسیار خوب. شما کتابی با عنوان «گفتگو با رهبران فنی» (Talking with Tech Leads) نوشته‌اید. در این کتاب با تعداد زیادی از رهبران فنی مصاحبه کرده‌اید و سؤالاتی یکسان را از آن‌ها پرسیده‌اید. در این کتاب چند دیدگاه در مورد نحوه‌ی رهبری فنی وجود دارد. آن‌چه من درباره‌ی این کتاب دوست دارم این است که نشان می‌دهد هر رهبر فنی سبک خاص خودش را دارد. حین انجام دادن این مصاحبه‌ها چه یاد گرفتید؟

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

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

با چند رهبر فنی صحبت کردید؟

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

رهبران فنی در مورد چه چیزی حرف می‌زدند؟ موضوعات اصلی چه بودند؟

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

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

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

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

این آخرین سؤال من بود. الان فرصت دارید که به هر سؤالی که باید می‌پرسیدم جواب دهید. آیا می‌خواهید چیزی بگویید؟ شاید آخرین دُرهای حکمت؟

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

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

من زیاد در مورد این موضوعات مربوط به رهبری فنی، بلاگ می‌نویسم. آدرس آن www.patkua.com است. در توئیتر هم خیلی فعال هستم و خیلی دوست دارم سؤالات، معماها و افکار شما در مورد رهبر فنی را بشنوم. من فکر می‌کنم از صحبت کردن با افراد و مشکلاتی که دارند خیلی یاد می‌گیرم و دوست دارم تجربه‌هایم را به اشتراک بگذارم. آدرس توئیتر من patkua@ است. سایت کتاب هم هست که می‌توانید آن را در leanpub پیدا کنید.

پاتریک، بابت این مصاحبه خیلی از شما متشکرم. فکر می‌کنم خیلی جالب بود.

متشکرم که من را دعوت کردید. سؤالات خوبی داشتید و من از بحث لذت بردم.