۱۵ مسئله‌ی مهم برای مدیران فنی شرکت های نرم افزاری

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

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

مثال اول (طراحی زیرساخت بدون مد نظر گرفتن پایداری)

از طریق یکی از دوستان به یه شرکتی معرفی شدم تا به دوستان اون شرکت در حوزه ی مسائل زیرساختی کمک کنم. وقتی شروع به بررسی و گفت و گو کردیم،‌ تیم فنی اون شرکت دیزاینی از زیرساختشون رو به من نشون دادن که می خواستن با استفاده از اون دیزاین سیستمشون رو هم از نظر پویا بودن (سریع بشه تغییر ایجاد کرد در زیرساخت) و هم از نظر رشد پذیری تضمین کنن. در نگاه اول دیزاین ساده و جذابی بود اما یک مسئله ی ساده ای رو در این راستا در نظر نگرفته بودن... اون هم داستان دسترس پذیری بالا (HA - High Availability)
این مسئله باعث شده بود وابستگی‌های زیادی به تک تک پازل‌های دیزاین زیرساختشون وجود داشته باشه که از نظر پایداری تهدیدی به حساب میومد. برای حل این مسئله در این مثال،‌ من طرح جایگزینی بهشون دادم و با طرح جدید مشکلاتی که فکر می کردم وجود داره رو حل کردم و با همکاری اون تیم تونستیم به راحتی از پس مشکل بربیایم.

مثال دوم (طراحی ساختار تیمی بدون در نظر گرفتن پایداری)

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

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

اول اینکه تیم فنی شرکت محصول شرکت رو به صورت مایکروسرویس طراحی و پیاده سازی کرده بودند.

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

دوم اینکه در پیاده سازی مایکروسرویس، هر نفر یک مایکروسرویس رو توسعه داده بود (مهمه که بدونید تیم فنی شرکت ۱۳ نفره بود و توی بک اند ۵ نفر در حال کد زدن بودن)

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

در راستای حل مشکلات، نمیشد مایکروسرویس‌ها رو عوض کرد (به خاطر هزینه‌ی بالای تغییر) اما در حوزه‌ی ساختار تیمی میشد یه سری کارها کرد. کاری که پیشنهاد دادم این بود که بر روی هر مایکروسرویس حداقل ۲ نفر و حداکثر ۴ نفر (در بهترین حالت ۳ نفر هستش از دید من) کار باید بکنه. برای پیاده سازی این مسئله مشکل نیروی انسانی خواهیم خورد چون به ۱۰ نفر نیروی توسعه دهنده‌ی بک‌اند نیاز می‌داشتیم. برای حل کمبود نیروی انسانی پیشنهاد ما این بود که هر نفر روی ۲ مایکروسرویس کار کنه، یعنی در نهایت به این شکل شد که تیم فعلی رو به گروه های ۲ نفره تبدیل کردیم (یک نفر استخدام شد) و به ۳ تیم ۲ نفره رسیدیم،‌ و به هر تیم ۲ مایکروسرویس اختصاص داده شد و توافق شد که تسک ها حتما بین ۲ نفر پخش باشه. این تغییر باعث میشد که اگه یه نفر از توسعه دهندگان دچار مشکلی می‌شد،‌ حداقل یک نفر برای ادامه کار اون فرد قبلی در مجموعه وجود داشته باشه تا در طی مراحل استخدام و آموزش نیروی جدید مشکلی نداشته باشیم. در کل شرکت بعد از پیاده سازی این مسئله، تمامی تیم ها رو به تیم های ۳ نفره افزایش داد و از دید تیم مدیریتی ساختاری پایدار در اون حوزه رو درست کرده بودیم.

چه چیزی برای شما جلب توجه میکرد؟

هر دو مثال‌ شامل یک مشکل یکسان بودند اما در حوزه‌ی متفاوت (زیرساخت، ساختار نیروی انسانی) که نشون دهنده‌ی این مسئله هستش که چه در تیم فنی و چه در تیم مدیریتی، مسئله ی پایداری مورد توجه قرار نگرفته بود.

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

چیزی که برام جذاب بود بعد از گذشت چند ماه مشکل قبلی دیگه در هیچ جای سیستم وجود نداشت. انگار مسئله رو درک کرده بودند و خودشون تیکه‌هایی از سازمان که دچار اون مشکل بود رو تغییر داده بودند. این برام خیلی جذاب و دوست داشتنی بود. برداشتی که من کرده بودم این بود که تیم بسیار قوی ای دارن که اگه راه درست مسائل رو یاد بگیرند خودشون می‌تونن مشکلات رو حل کنن. برای اثبات این مسئله به جای اینکه این دفعه وارد داستان بشم و سعی کنم راه حل بدم، ‌سعی کردم مشکل رو درک کنم و به صورت کلی در مورد تئوری‌هاش حل مشکل باهاشون صحبت کنم (در مثال فوق در مورد نحوه‌ی مدیریت منابع باهاشون صحبت کردم نه این که الان چقدر منبع به کجا اختصاص بدید مشکل حل میشه). نتیجه ی صحبت‌هام بعد از یک ماه این بود که تیم بعد از یادگیری نحوه ی مدیریت منابع خودش راه حلی داده بود برای نحوه ی حل مشکلشون و نسبتا هم بدون نقص بود.

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

به جای گرفتن ماهی برای کسی،‌ ماهی گیری یادش بدیم!!

از اون به بعد تلاش کردم همیشه به این شکل به تیم‌ها کمک کنم و برای اینکه بتونم سریع تر و راحت‌تر این کارو بکنم، ۱۵ تا از بزرگ ترین عناوینی رو که به نظرم به تیم های نرم افزاری کمک خواهد کرد، در پست های بعدی به اشتراک بذارم ... باشد که به کار آید.