https://virgool.io/asdfadfadf/feed اینجا قصد دارم چیزهایی که به صورت روزمره در حوزه ی کارم بهش بر می خورم رو بنویسم fa 2026-06-16 23:51:04 https://files.virgool.io/ https://virgool.io/asdfadfadf https://virgool.io/asdfadfadf/%D8%B2%D9%85%D8%A7%D9%86-%D9%84%D8%A7%D9%86%DA%86-%DB%8C%D8%A7-%D8%B2%D9%85%D8%A7%D9%86-%D8%B1%DB%8C%D9%84%DB%8C%D8%B2%D8%9F-%D9%85%D8%B3%D8%A6%D9%84%D9%87-%D8%A7%DB%8C%D9%86-%D8%A7%D8%B3%D8%AA!-bfqkf9w8val0 خیلی وقته که تو بعضی از شرکت‌ها،‌ وقتی که یه فیچر جدید رو می‌خوان به دست کاربرهاشون (که می‌تونه کارمندای خود شرکت، بیزینس‌های دیگه و در نهایت کاربر نهایی باشه) برسونن،‌ بین تیم فنی و تیم مارکتینگ جنگی به پا میشه. چه جنگی؟ معلومه! تیم مارکتینگ از هفته‌ها قبل از رسیدن فیچر،‌ شروع به تبلیغات کرده و روز خاصی و یا حتی ساعت خاصی رو معین کرده و به همه اطلاع‌رسانی کرده، اما این وسط اون روز و اون ساعت تیم فنی ممکنه در انتشار نسخه‌ی جدید سرویس دچار مشکل بشه! این یعنی یه آبروریزی بزرگ به راه می‌افته و یا چیزی منتشر میشه که با قول‌های تیم مارکتینگ تطابق نداره. جدا از این مسئله، اکثر مواقع برای بهره‌مند شدن از اون قابلیت، کاربر می‌بایست اپلیکشن‌اش رو به روز رسانی کنه و در نهایت، ممکنه در اون زمان خاصی که تیم مارکتینگ براش برنامه‌ریزی کرده، به دستش نرسه. همه‌ی این مسائل به ما این رو میگه که‌ اتفاق بزرگی که تیم مارکتینگ براش یه عالمه برنامه چیده بود به خوبی اتفاق نیوفتاده. اگه این اتفاق تو شرکت شما هم پیش میاد شاید این نوشته به کارتون بیاد. در ابتدا داستان باید ۲ کلمه رو براتون تعریف کنم:زمان ریلیززمانی هستش که محصول شما،‌ تغییر می‌کنه و قابلیت‌های جدید بهش اضافه میشه.زمان لانچ زمانی هستش که کاربر باید به قابلیت‌ها و تغییرات جدید شما دسترسی داشته باشه.تا امروز همه‌ی ما این دو زمان رو یکسان میدیم. یعنی اگه می‌خواستیم یه قابلیت جدید رو لانچ کنیم، همون موقع نسخه‌ی نرم‌افزارمون رو هم ریلیز می‌کردیم. اما در واقعیت می‌تونه این دو زمان از هم جدا در نظر گرفته بشه و این جدا کردن می‌تونه یه عالمه مزیت برای شرکت‌هامون داشته باشه.بیاید با مثالی این اتفاق رو کمی شفاف‌تر کنیم.فرض کنید تیم مارکتینگ شما تصمیم به عوض کردن چند عکس در نرم‌افزار شما می‌گیره و قرار میشه ساعت ‍۱۲ در روز ۲۳ مرداد این نسخه‌ی جدید رو برای همگان منتشر کنه. از دید تیم مارکتینگ نکته‌ی مهم این تصمیم، انجام شدن در راس ساعت ۱۲ هستش که اتفاق رو برای تیم فنی ممکنه سخت‌تر کنه.در ادامه تیم فنی، بنا به این درخواست، تسکی ایجاد می‌کنه و تسک رو به نحو احسن انجام میده.روز موعود فرا میرسه و تیم فنی در ساعت ۱۱:۰۰ به خط میشه تا مراحل انتشار نسخه‌ی جدید برنامه رو بچینه و در ساعت مقرر،‌ همه چیز بدون مشکل انجام بشه.اما ... در زمان انتشار نسخه‌ی جدید مشکلاتی پیش میاد که خیلی هم جدی نیستند اما زمان انتشار رو از ساعت ۱۲ به ساعت ۱۲:۳۲ تغییر میده. این تغییر برای تیم مارکتینگ پذیرفته نیست و کلی سر و صدا به پا می‌کنه (جدا از هزینه‌های هدر رفته) اما با توضیحات مدیر فنی، اتفاق به فراموشی سپرده میشه.دفعه‌ی بعد که این درخواست از سمت تیم مارکتینگ تکرار میشه، مدیر فنی تدبیر جدیدی برای این اتفاق می‌اندیشه :). به‌جای اینکه با انتشار برنامه تغییرات اعمال بشه، در تسک به توسعه‌دهندگان توضیح میده که باید تغییرات در کد و با شرط‌هایی وابسته به زمان (یعنی مثلا اگه زمان فعلی از فلان موقع بیشتر بود، عکس دیگری رو نمایش بدن) این تسک پیاده بشه، و قبل از تاریخ مقرر کد منتشر بشه. با این استراتژی اگر مشکلی برای انتشار نسخه به وجود بیاد، برای حل مشکلات زمان وجود خواهد داشت.روز موعود فرا میرسه اما تیم فنی از قبل قابلیت مد نظر رو منتشر کرده بود و سر زمان همه چیز به خوبی و بدون نیاز به تغییری در چیزی، تغییر پیدا می‌کنه و مدیرفنی سربلند از این تسک بیرون میاد :)اگر دقت کرده باشید مدیرفنی با جدا کردن زمان انتشار با زمان لانچ، تونسته بود که نیاز‌های تیم فنی و مارکتینگ رو با یک تیر رفع کنه. اما این روش کار در تعداد زیادی اتفاق قابل پیاده سازی نیست! درسته؟کل صحبت ما همین بود! اما در اسکیل بزرگ و استاندارد!‌از این به بعد در مورد روشی صحبت می‌کنیم که باهاش میشه این کار رو در اسکیل بزرگ و به صورت استاندارد (یا به قول بچه‌های فنی، به صورت تمیز) پیاده کرد.خیلی قبل‌تر یکی از بزرگان علم کامپیوتر (مارتین فاولر) تئوری‌ای برای پیاده‌سازی قابلیت‌های جدید در سیستم‌های بزرگ ارائه داده بود. اسم اون تئوری Feature toggle یا Feature flag هستش. برای مطالعه‌ی بیشتر می تونید از این لینک استفاده کنید: https://www.martinfowler.com/articles/feature-toggles.htmlبرای اینکه مفهموم فیچر فلگ رو متوجه بشید، خیلی ساده سعی می‌کنم توضیح بدم که وقت زیادی ازتون گرفته‌نشه.وقتی که در تیم‌تون می‌خواید یه قابلیتی رو پیاده کنید که نیاز دارید زمان لانچ و ریلیز متفاوتی داشته باشه، ابتدا به اون فیچر یه نام یکتا‌ی انگلیسی بدید. مثلا test-feature که در سیستم بتونید این فیچر رو شناسایی کنید.بعدش در جایی از سیستم (مثلا دیتابیس) لیستی از فیچرها رو با وضعیتشون که شامل (public | private) هستش نگه دارید. بعد لیستی از کاربرانی رو که به اون فیچر در حالت private قراره دسترسی داشته باشن، در جای دیگه‌ای از سیستم نگه‌دارید (باز هم دیتابیس مکان خوبی هستش).نحوه‌ی چک کردن فعال بودن یک قابلیت برای هر کاربر به این صورت هستش: ۱- اگه اون قابلیت در حالت عمومی - public بود،‌ همه‌ی کاربرها به اون دسترسی دارن. ۲- اگه اون قابلیت در حالت خصوصی - private بود، فقط کاربرانی که از قبل اعلام شده‌اند به اون قابلیت دسترسی دارن.البته شما می‌تونید این مدل رو هر چقدر که دوست داشته باشید یا نیاز داشته باشید پیچیده‌تر و کامل‌تر کنید.در نهایت در زمان توسعه‌دادن اون قابلیت، با یک شرط ساده که توش چک میکنید که آیا اون کاربر به اون قابلیت دسترسی داره یا نه،‌ یا نسخه‌ی قبلی سیستم رو نشون میدید یا نسخه‌ی جدید رو نشون میدید. همین و بس‌!شاید براتون سوال باشه که مثلا سمت اپلیکیشن شما چه جوری باید این چک کردن‌ها رو انجام بده، و خب جوابش ساده است،‌ کافیه در درخواست لاگین یا گرفتن اطلاعات کاربر، لیست قابلیت‌های فعال برای اون کاربر رو به سمت اپلیکیشن برگردونیم.قابلیت‌هایی که زیرساخت فیچرفلگ به مجموعه‌ی شما میده، از دید من (که قطعا ناقص هستش)، این‌هاست:قابلیت انتشار نسخه، قبل از زمان لانچقابلیت مشاهده‌ی نسخه‌ی جدید برای بعضی از کاربران (مثلا تیم مارکتینگ یا تسترها و یا گروه تستی از کاربرها) در محیط پروداکشنقابلیت انتشار فیچری خاص برای گروه خاصی از کاربران (مثلا قابلیت ویژه‌ای برای شرکت خاصی که باهاش کار میکنید)بازگشت راحت به نسخه‌ی قبل برنامه در صورتی که باگ یا اروری در نسخه‌ی جدید وجود داشت باشهبرای مارکتینگ یکسری پیشنهاد و قانون برای درخواست قابلیت‌های جدید توی سال‌هایی که کار کردم تونستم در بیارم که شاید به درد شما هم بخوره و خلاصه اینهاست: قبل از اینکه قابلیتی که می‌خواید،‌ ریلیز نشده و توسط شما دیده نشده،‌ هیچ وقت به لانچ کردن اون قابلیت به صورت کورکورانه فکر نکنیدبرای لانچ کردن یک قابلیت،‌ زمانی که با تیم فنی ددلاین‌هاتون رو می‌بندید، همه‌ی کارهایی که داخلی هستش و توسط تیم‌های شرکت انجام میشه رو ببرید جلو، اما هیچ ارتباط بیرونی یا تبلیغات بیرونی‌ای انجام ندید و منتظر باشید که قابلیت ریلیز بشه و بعد از اون، ابتدا با تعداد محدودی از مشتریاتون اون قابلیت رو تست کنید، و در نهایت اگه فیچر درخواست شده،‌ از دید شما قابلیت لانچ شدن داشت، پلن لانچ بریزید و روز لانچ صرفا فیچرفلگ مد نظر رو public کنید!هیچ وقت و هیچ وقت به ددلاین‌های تیم فنی، اعتماد نکنید! و هیچ قولی به هیچ مشتری‌‌ای پیروی قول تیم فنی ندید! این قول دادن‌ها ممکن هستش جز آبروریزی و از دست دادن قرارداد، براتون هیچ آورده‌ای نداشته باشه.امیدوارم این مقاله به شما در خلق ارزش‌های بزرگ‌تر کمکی کرده باشه :) روزمره ی یک مدیرفنی مهدی یوسف تبار Thu, 31 Dec 2020 23:00:58 +0330 https://virgool.io/asdfadfadf/%D8%A7%D9%88%D9%84%DB%8C%D9%86-%D8%A7%D8%B2-%D9%BE%D8%A7%D9%86%D8%B2%D8%AF%D9%87%D9%85%DB%8C%D9%86-single-point-of-failure-vs-single-point-of-truth-d4jo83ce559f قبل از هرچیزی بهتره این ۲ مفهوم رو تعریف کنیم برای هم:Single Point of Failureبه قسمتی از سیستم که اگه اون قسمت درست کار نکنه به صورت کلی سیستم کار نمی کنه یا درست کار نمی کنه گفته میشه که به اختصار از این به بعد بهش میگیم SPOF.Single Point of Truthبه قسمتی از سیستم که اطلاعات یا لاجیک‌ها همگی از اون قسمت گذر می‌کنن و در صورتی که نیاز به تغییر یا بررسی دارند،‌ صرفا در همون قسمت این کارها روشون انجام میشه. که از این به بعد به اختصار بهش میگیم SPOTاز اونجایی که هردوی اون مفاهیم، در دیزاین سیستم‌های نرم افزاری و حتی مدیریتی مهم هستند،‌ خیلی از جاهایی که کار می‌کنیم یا کار کردیم باهاشون سرکار داشتیم.اما اینکه دقیقا هر کدوم چه کاربردی دارن رو شاید خوب متوجه نشده باشیم. پیروی این مسئله سعی می‌کنم چندین مثال براتون بیارم از کاربرد هرکدوم.در تمامی پروژه‌هایی که نیاز به یک بک‌اند دارن ما نیاز به یک برنامه برای ارائه‌ی فایل‌ها و درخواست‌ها داریم. اکثرا در پروژه‌های بزرگ ما با وبسرورهایی مثل nginx یا HA proxy سر کله می‌زنیم تا از بیشترین سرعت و قدرت در پردازش بیشترین درخواست‌های ممکن برخوردار باشیم. حالا بیاید فکر کنیم که به صورت ناگهانی وبسرور ها دچار اختلال میشه و نمی‌تونه درخواست‌هایی که سمتش میاد رو جواب بده. تو این شرایط تمامی سرویس ما دچار اختلال میشه و تا زمانی که مشکل وبسرورمون رو حل نکنیم هیچ تیکه‌ای از محصول ما کار نمی‌کنه!قطعا این خبر تیم شرکتمون رو ناراحت می‌کنه مخصوصا زمانی که مدت زمان حل کردن این مشکل طولانی بشه. برای این مسئله هممون میدونیم که پیشنهاد میشه از ساختارهایی که High Availability دارن استفاده کنیم. کاری که این ساختارها برای ما انجام میده اینه که نقطه‌ای از سیستم رو که اگه اون نقطه درست کار نکنه کل سیستم دچار نقص میشه رو مورد هدف قرار میده و سعی می‌کنه با داشتن تئوری‌های بک‌آپ گونه درصورتی که اون قسمت دچار مشکل شد در کسری از ثانیه سیستم بک‌آپ رو وارد مدار کنه تا مشکل به صورت موقت حل بشه و ما زمان داشته باشیم تا نقطه‌ی اصلیمون رو تعمیر کنیم.حالا تو مثال وبسرور ما، یکی از راه‌ها اینه که چند تا از این وبسرورها رو در مکان‌های مختلف نصب کنیم و در صورتی که وبسرور اصلی‌مون دچار مشکل شد، وبسرورهای بک‌آپ‌مون رو وارد مدار کنیم.از این دست مثال‌ها در سیستم‌ها زیرساختی زیاد هست، مثلا: خاموش شدن سرور،‌ پایین آمدن سرویس دیتابیس،‌ مشکل شبکه در ارتباط با سرویس‌های دیگه، اختلال در سیستم کش و خیلی چیز دیگه که اکثرا جواب یکسانی دارن: سعی کنید وابستگی به یه نقطه رو از بین ببرید ... چند تا سرور داشته باشیم، در چند جای مختلف سرور داشته باشید، چندین تا از هر سرویس بیارید بالا به صورت کلاستر شده یا HA.در دنیای مدیریتی هم این مسائل رو داریم. بیاید با یه مثال ساده این مسئله رو در دنیای مدیریتی هم بررسی کنیم.فکر کنید که در شرکت شما یک محصول با زبان erlang درحال توسعه هستش، و فقط یک توسعه دهنده در شرکت دارید که با اون زبان توانایی برنامه نویسی داره و همون آدم هم صرفا همون پروژه رو جلو میبره. اگه خدایی نکرده اون یه نفر در یه اتوبوسی باشه که اون اتوبوس تصادف جدی‌ای بکنه،‌ شما باید از فردای اون روز کاسه‌ی چه کنم به دست بگیرید و منتظر باشید تا تیم منابع انسانی یک فرد با توانایی‌های خاصی که می‌خواد براتون پیدا کنه، مصاحبه کنه،‌ استخدام کنه، با فضا شرکت آشنا کنه، یک ماه اول کار رو مانیتور کنه و ... قطعا هیچ کسی دوست نداره که حداقل ۲ ماه (از روی تجربه دارم میگم) محصولی که خیلی برای شرکت مهم بوده، هیچ توسعه‌ای نداشته باشه! پس قبل از این هم دردسر، بهتر نیست به این فکر کنیم که حداقل ۲ نفر روی پروژه همزمان کار کنن که اگه یه نفر مشکلی براش پیش اومد (یا حتی پیشنهاد کاری بهتری گرفت) حداقل برای پلن‌های شرکت ریسک حساب نشه؟از مثال بالا کمی کم ریسک‌تر هم می‌تونیم مثال بزنیم: مثلا پروژه‌ای که ۵ نفر از تیم فعلی شرکت توانایی انجامش رو دارن اما به خاطر پیچیده بودن زمان زیادی طول می‌کشه تا روی اون پروژه مسلط بشن.از سمتی فکر کنید در شرکت، برای تهیه‌‌ی مواد اولیه‌ی خط تولید، فقط با یک شرکت تامین کننده روبرو هستیم، اگه خدایی نکرده اون شرکت دچار مشکلی بشه، کل شرکت شما دچار تامین مواد اولیه میشه!همه‌ی این مثال‌ها به ما نشون میده که باید در سیستم‌هایی که طراحی می‌کنیم، نقطه‌ای یا قسمتی از سیستم به گونه‌ای نباشه که روی کارکرد کلیت سیستم تاثیر جدی بگذارد.از سمتی در بعضی از مواقع نیاز متفاوتی در طراحی سیستم وجود دارد که سعی می کنم مثال‌های دیگه ای رو در این راستا بیارم:فکر کنید که در شرکت شما، نیاز به این بوده‌است که اپ شما در چندین زبان مختلف قابل استفاده باشه و پیروی این مسئله توسعه‌دهندگان اپ شما در هر قسمت که نیاز به ترجمه‌ی پیام‌ها و متن‌ها بوده در همان قسمت با شروطی، ترجمه‌های مربوطه رو انجام دادن. چند ماه بعد شرکت نیاز به اضافه کردن یک زبان دیگر به زبان‌ها پیدا می‌کنه. در نهایت توسعه‌دهنده‌های مربوطه باید دونه به دونه‌ی فایل‌های پروژه رو باز کنن و نگاه کنن تا زبان جدید رو اضافه کنن، اما در این مراحل ممکنه قسمتی از برنامه فراموش بشه یا جا بمونه. یکی از راه حل‌های این مسئله این هستش که لیستی از متن‌هایی که در برنامه استفاده میشه رو در یک فایل تجمیع کنیم و هرجایی که متنی میخواستیم از اون فایل مدنظر متن رو بخونیم. با این کار در صورتی که یه زبون دیگه اضافه بشه،‌ کافیه صرفا فایل‌های قبلی رو که تمامی متن‌ها رو شامل میشن رو کامل کرد! یا فکر کنید که برای ساخت فاکتور در سیستم شما، مکان‌های متفاوتی وجود داره، مثلا پنل ادمین، اپ شما، و وبسایت شما. بعد از مدتی تیم محصول شرکت مصمیم به اضافه کردن کد تخفیف می کنه و درخواست می کنه که در تمامی این قسمت‌ها برای ساخت فاکتور باید قابلیت اضافه کردن کد تخفیف در زمان ساخت فاکتور اضافه بشه. برای پیاده‌سازی این قابلیت درصورتی که لاجیک ساختار فاکتوری که اون ۳ قسمت محصول ازش استفاده می‌کنن در جاهای مختلفی پیاده‌سازی شده باشه، می‌بایست در هر سه قسمت این قابلیت رو اضافه کرد و دقت داشته باشید که همیشه هم باید لاجیک اون ۳ قسمت یکسان رفتار کنن. اگر این قابلیت‌های درخواستی در طول زمان بیشتر و بیشتر بشن، امکان عدم تطابق لاجیک‌های اون ۳ قسمت بیشتر و بیشتر میشه تا در نهایت به یه کابوس تبدیل میشه. این مسئله رو نباید نادیده گرفت که مسئله‌ی ساخت فاکتور در صورتی که به هر دلیلی مشکلی داشته باشه،‌ نتایج مالی بدی به همراه میاره! در نهایت برای حل این مسئله کافیه که از ابتدای امر لاجیک‌های مربوط ایجاد یه فاکتور در یک کلاس یا فایل یا متد دور هم جمع بشه تا در زمان تغییر نیازی نباشه که مکان‌های تحت تاثیر رو دونه به دونه بررسی کنیم.یا در مثال دیگه ای در مورد این صحبت کنیم که برای نمایش قیمت‌ها در مکان‌های مختلف اگه هر جایی که نیاز به گذاشتن ممیز و تومان بوده، کدش رو همون مکان زده باشیم، اگه زمانی بخوایم واحد پولی مون رو به ریال تبدیل کنیم یا مثلا خورده‌ی قیمت‌ها رو حذف کنیم، می‌بایست به تک تک فایل‌ها دست بزنیم و احتمال اینکه فایلی رو فراموش کنیم هم زیاد خواهیم داشت! پس بهتره که فرمت کردن قیمت‌ها رو در یک متد جمع کنیم و هرجایی که نیاز به فرمت کردن قیمت بود، از اون متد استفاده کنیم.در مثال دیگه‌ای در حوزه‌ی مدیریت میشه به مدیریت مالی مجموعه سری زد. در اکثر شرکت‌ها پروسه‌ی واریز حقوق افراد توسط یک نفر در مجموعه انجام میشه. دلیل ساده‌ای داره، اگه این کار توسط چندین نفر قابل انجام باشه، ممکنه هستش یا حقوق‌ها واریز نشه یا دوبار واریز بشه (آشپز ۲ تا بشه غذا یا شور میشه یا بی‌نمک)برای جمع بندی مسائل بالا، باید این رو بگم که اینکه چه زمانی، گذشتن اتفاقات از یک نقطه خوبه، و چه زمان‌هایی بده معیار‌های نسبتا ساده‌ای داره.اگه اون یه نقطه کارش رو انجام نده کل سیستم به مشکل بر می خوره و کارها پیش نمیره؟اگه اون نقطه بعضی از کارهاش رو درست انجام نده ترجیح میدید کلا کاری انجام نده یا ترجیح میدید قسمتی از کارهم که شده انجام بشه؟فکر کنم با جواب دادن به این سوال‌ها متوجه بشید که باید اصل پراکندگی رو پی بگیرید یا اصلی تجمیع رو! روزمره ی یک مدیرفنی مهدی یوسف تبار Wed, 09 Dec 2020 22:24:10 +0330 https://virgool.io/asdfadfadf/%DB%B1%DB%B5-%D9%85%D8%B3%D8%A6%D9%84%D9%87%DB%8C-%D9%85%D9%87%D9%85-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%D8%A7%D9%86-%D9%81%D9%86%DB%8C-%D8%B4%D8%B1%DA%A9%D8%AA-%D9%87%D8%A7%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C-kgkuv5cxexjy چند وقتی شده که با رفت و آمد تو شرکت‌های مختلف، متوجه یه سری مشکلات تکراری میشم. و مثل هر برنامه‌نویس دیگه وقتی با یه مسئله ی تکراری روبرو میشی تلاشت رو می‌کنی که این کارها رو براش نظم و قانون و پروسه در بیاری و حتی اگه بشه به یه سیستم اتوماتیک تبدیلش کنی.اما کمی قبل تر، اوایل برخوردم با این مشکلات، روش ساده‌ای برای حلشون پیدا کرده بودم. برای اینکه بتونم منظورم رو بهتر برسونم مثال‌هایی رو سعی می کنم تشریح کنم تا کمی مسئله براتون شفاف تر باشه.مثال اول (طراحی زیرساخت بدون مد نظر گرفتن پایداری)از طریق یکی از دوستان به یه شرکتی معرفی شدم تا به دوستان اون شرکت در حوزه ی مسائل زیرساختی کمک کنم. وقتی شروع به بررسی و گفت و گو کردیم،‌ تیم فنی اون شرکت دیزاینی از زیرساختشون رو به من نشون دادن که می خواستن با استفاده از اون دیزاین سیستمشون رو هم از نظر پویا بودن (سریع بشه تغییر ایجاد کرد در زیرساخت) و هم از نظر رشد پذیری تضمین کنن. در نگاه اول دیزاین ساده و جذابی بود اما یک مسئله ی ساده ای رو در این راستا در نظر نگرفته بودن... اون هم داستان دسترس پذیری بالا (HA - High Availability)این مسئله باعث شده بود وابستگی‌های زیادی به تک تک پازل‌های دیزاین زیرساختشون وجود داشته باشه که از نظر پایداری تهدیدی به حساب میومد. برای حل این مسئله در این مثال،‌ من طرح جایگزینی بهشون دادم و با طرح جدید مشکلاتی که فکر می کردم وجود داره رو حل کردم و با همکاری اون تیم تونستیم به راحتی از پس مشکل بربیایم. مثال دوم (طراحی ساختار تیمی بدون در نظر گرفتن پایداری)از طریق دوست دیگه‌ای به یه شرکتی معرفی شدم و شروع به همکاری با عنوان مشاوره زیرساخت کردم . در ابتدای داستان، از روی عادت، سری به زیرساخت شرکت زدم و مشکل مثال قبل رو هم در این شرکت با همون روش قبلی حل کردم. اما بعد تموم شدن این مسئله از سمت تیم مدیریتی شرکت،‌ از من در راستای کمک به باقی حوزه‌های شرکت کمک خواسته شد و قرار شد در کل حوزه‌ی فنی دست به اصلاحاتی بزنیم.بعد از شروع به بررسی تیم و ساختار انجام کارها و نحوه‌ی کارکرد اکثر قسمت‌ها، دو مسئله برای من تعجب برانگیز شد. اول اینکه تیم فنی شرکت محصول شرکت رو به صورت مایکروسرویس طراحی و پیاده سازی کرده بودند.نمی خوام بگم که مایکروسرویس چیز بدی هستش و نباید استفاده کرد ولی این رو می تونم بگم که اگه برای لانچ یه محصول از مایکروسرویس شروع کنید(حتی اگه عین همون محصول رو قبلا نوشته باشید)، از نظر من (کاملا شخصی) اشتباه بزرگی رو انجام دادید. دلایلش به نظرم خیلی ساده هستند؛ اول اینکه نیازهای سیستم هنوز کامل ثابت و مشخص نیست چون تازه لانچ شده و یه عالمه تغییر پیشرو دارید. دوم اینکه در همون ابتدا وارد مسائل پیچیده ای می‌شید در حوزه ی کد زدن و مانیتور کردن اتفاقات. و از همه مهم‌تر اینکه نمی تونید تضمین کنید که آیا درست تکه‌های پازل رو از هم جدا کردید. (در کنار این مسائل، مارتین فاولر هم میگه که وقتی برید سراغ مایکروسرویس که اول مونولیتیک اش رو دارید و کار می کنه، بعد تکه تکه اش کنید و غیره ...)دوم اینکه در پیاده سازی مایکروسرویس، هر نفر یک مایکروسرویس رو توسعه داده بود (مهمه که بدونید تیم فنی شرکت ۱۳ نفره بود و توی بک اند ۵ نفر در حال کد زدن بودن)اینکه هر نفر روی یه مایکروسرویس کار میکنه، چندین نتیجه‌ی بد می تونه به همراه داشته باشه، اولینش ریسک بالاست،‌ یعنی اگه اون یه نفر خدایی نکرده مشکلی براش پیش بیاد، یه مایکروسرویسمون رسما دچار مشکل میشه و کسی راحت نمی‌تونه بهش فیچر اضافه کنه. از سمت دیگه، یکپارچگی سیستم دچار مشکل میشه، چون اون یک نفر هرجوری که دوست داره و با دست خط خودش کد اون مایکروسرویس رو میزنه و باعث میشه که تک تک مایکروسرویس ها به روش دلخواهی نوشته بشه. البته این مسئله جزو خوبی‌های مایکروسرویس هم هست اما در تیم کوچیک بیشتر از یه مزیت به یه تهدید شباهت داره.در راستای حل مشکلات، نمیشد مایکروسرویس‌ها رو عوض کرد (به خاطر هزینه‌ی بالای تغییر) اما در حوزه‌ی ساختار تیمی میشد یه سری کارها کرد. کاری که پیشنهاد دادم این بود که بر روی هر مایکروسرویس حداقل ۲ نفر و حداکثر ۴ نفر (در بهترین حالت ۳ نفر هستش از دید من) کار باید بکنه. برای پیاده سازی این مسئله مشکل نیروی انسانی خواهیم خورد چون به ۱۰ نفر نیروی توسعه دهنده‌ی بک‌اند نیاز می‌داشتیم. برای حل کمبود نیروی انسانی پیشنهاد ما این بود که هر نفر روی ۲ مایکروسرویس کار کنه، یعنی در نهایت به این شکل شد که تیم فعلی رو به گروه های ۲ نفره تبدیل کردیم (یک نفر استخدام شد) و به ۳ تیم ۲ نفره رسیدیم،‌ و به هر تیم ۲ مایکروسرویس اختصاص داده شد و توافق شد که تسک ها حتما بین ۲ نفر پخش باشه. این تغییر باعث میشد که اگه یه نفر از توسعه دهندگان دچار مشکلی می‌شد،‌ حداقل یک نفر برای ادامه کار اون فرد قبلی در مجموعه وجود داشته باشه تا در طی مراحل استخدام و آموزش نیروی جدید مشکلی نداشته باشیم. در کل شرکت بعد از پیاده سازی این مسئله، تمامی تیم ها رو به تیم های ۳ نفره افزایش داد و از دید تیم مدیریتی ساختاری پایدار در اون حوزه رو درست کرده بودیم.چه چیزی برای شما جلب توجه میکرد؟هر دو مثال‌ شامل یک مشکل یکسان بودند اما در حوزه‌ی متفاوت (زیرساخت، ساختار نیروی انسانی) که نشون دهنده‌ی این مسئله هستش که چه در تیم فنی و چه در تیم مدیریتی، مسئله ی پایداری مورد توجه قرار نگرفته بود.در مثال های بالا، تلاش اصلی من برای حل کردن مشکلات پیش رو بود، از دید خودم نتیجه ی خوبی هم به همراه داشت اما داستان همینجا تموم نشد.جفت شرکت ها بعد از حدود ۳ ماه دوباره به خاطر مشکلات جدیدی که داشتن،‌ با من ارتباط گرفتند. مشکلاتشون این دفعه مشکل قبلی نبود اما در همون سطح بود. چیزی که برام جذاب بود بعد از گذشت چند ماه مشکل قبلی دیگه در هیچ جای سیستم وجود نداشت. انگار مسئله رو درک کرده بودند و خودشون تیکه‌هایی از سازمان که دچار اون مشکل بود رو تغییر داده بودند. این برام خیلی جذاب و دوست داشتنی بود. برداشتی که من کرده بودم این بود که تیم بسیار قوی ای دارن که اگه راه درست مسائل رو یاد بگیرند خودشون می‌تونن مشکلات رو حل کنن. برای اثبات این مسئله به جای اینکه این دفعه وارد داستان بشم و سعی کنم راه حل بدم، ‌سعی کردم مشکل رو درک کنم و به صورت کلی در مورد تئوری‌هاش حل مشکل باهاشون صحبت کنم (در مثال فوق در مورد نحوه‌ی مدیریت منابع باهاشون صحبت کردم نه این که الان چقدر منبع به کجا اختصاص بدید مشکل حل میشه). نتیجه ی صحبت‌هام بعد از یک ماه این بود که تیم بعد از یادگیری نحوه ی مدیریت منابع خودش راه حلی داده بود برای نحوه ی حل مشکلشون و نسبتا هم بدون نقص بود.در نهایت:قسمت جالب کل داستان اینه که برای حل کردن مشکلات سازمان نیازی نیست که آستین ها رو بالا زد و وارد میدان شد، صرفا کافیه که یه مقدار دانش فنی و مدیریتی تیم رو بهبود بخشید، و بعد از اون خود تیم تمامی اون مشکلات رو به صورت خودجوش در مدت زمان کوتاهی حل می کنه.به جای گرفتن ماهی برای کسی،‌ ماهی گیری یادش بدیم!!از اون به بعد تلاش کردم همیشه به این شکل به تیم‌ها کمک کنم و برای اینکه بتونم سریع تر و راحت‌تر این کارو بکنم، ۱۵ تا از بزرگ ترین عناوینی رو که به نظرم به تیم های نرم افزاری کمک خواهد کرد، در پست های بعدی به اشتراک بذارم ... باشد که به کار آید. روزمره ی یک مدیرفنی مهدی یوسف تبار Wed, 09 Dec 2020 14:49:49 +0330