وظایف یک CTO در تیم‌های کوچیک

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

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

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

دومین نقش و به نظر من اصلی ترین نقشی که میتونه به عهده بگیره اینه که برای تیم فنی پلن رشد داشته باشه. چه پلن رشد برای اعضای تیم فنی، چه پلن رشد برای محصولات فنی.

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

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

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

حالا سوال پیش میاد چطور به این دید برسه؟

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

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

اسکرام رو با مشارکت پیش ببریم.

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

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

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

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

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

و سوم اینکه بچه ها تخمین story-point رو خودشون با همکاریِ هم انجام بدن. به این صورت که همه تخمین‌شون رو اعلام کنن و روی این تخمین گفتگو انجام بشه و نهایتا تیم به یک جمع‌بندی روی تخمین برسه.