https://virgool.io/feed/@aildermi fa 2026-06-10 14:47:24 https://files.virgool.io/upload/users/3722905/avatar/8ub5wM.jpg?height=120&width=120 https://virgool.io/@aildermi https://virgool.io/@aildermi/%D8%A8%D8%B1%D8%A7%DB%8C-%D8%B1%D8%B4%D8%AF-%D8%AA%DB%8C%D9%85-%D8%AF%D8%B3%D8%AA-%D8%A7%D8%B2-%D9%82%D9%87%D8%B1%D9%85%D8%A7%D9%86-%D8%A8%D9%88%D8%AF%D9%86-%D8%A8%D8%B1%D8%AF%D8%A7%D8%B1%DB%8C%D9%85-%D8%AF%D8%A7%D8%B3%D8%AA%D8%A7%D9%86-%D8%AF%D9%84%DA%AF%DB%8C%D8%B4%D9%86-odtkznvfh6fo چندتا از این جمله‌ها براتون آشناست؟ [هیچ کس مثل من انجامش نمی‌ده]. [به کسی اعتماد ندارم]. [خودم انجامش بدم زودتر انجام می‌شه]. [اگه خودم کنترلش نکنم ممکنه مشکل پیش بیاد]. اگه حداقل یکیش رو تو ذهنتون دارین، شاید وقتشه با مفهوم دلگیشن آشنا بشین.اولین باری که خودم بطور جدی درگیر دلگیشن شدم،‌ اوایل لیدرشیپم بود که همون ابتدای کار، تیم‌لیدر سه‌تا تیم با مجموع ۱۵ نفر بودم. با یه حساب و کتاب سرانگشتی، تقریبا ۷۰ درصد زمانم صرف جلسات یک به یک، جلسات روزانه و جلسات پلنینگ تیم می‌شد و کلا ۳۰ درصد زمان برای کارهایی مثل حفظ یکپارچگی تیم، مدیریت پروژه‌ها، حفظ انگیجمنت و سایر کارهای مدیریتی تیم‌ها باقی می‌موند که روی کاغذ مشخص بود که جواب نمی‌داد.اما خب ما هم روی کاغذ کار نمی‌کنیم و توی دنیای مدیریت، ابزارهایی مثل دلگیشن هستن که می‌تونن توی این شرایط کمکمون کنن تا کارهای به ظاهر نشدنی رو انجام بدیم.دلگیشن چی هست؟دلگیشن یعنی مسئولیت انجام یه کار رو به یه فرد دیگه واگذار کنیم تا هم زمانمون آزاد بشه، هم اعضای تیم رشد پیدا کنن و هم بار تصمیم‌گیری به درستی توی تیم توزیع بشه. منظور از واگذار کردن مسئولیت انجام یه کار اینه که فقط اجرای اون کار رو واگذار نکنیم و مسئولیتش رو واگذار کنیم. دلگیشن درست و موثر فقط انتقال وظیفه نیست، و بیشتر انتقال اعتماد، اونرشیپ و اختیار تصمیم‌گیری هست که وقتی به درستی انجام بشه، باعث افزایش بهره‌وری تیم، رشد فردی اعضا، افزایش انگیجمنت و پایداری عملکرد تیم می‌شه.توی دنیای مدیریت ابزارهایی مثل دلگیشن هست که کمک می‌کنه یه سری کارهای به ظاهر نشدنی رو انجام بدیم. شما لازم نیست و حتی نباید همه کارها رو خودتون انجام بدین و حتی نباید همه مسئولیت‌ها رو به تنهایی به دوش بکشین، و می‌تونین بخشی از مسئولیت‌ها و کارها رو به سایر هم‌تیمی‌هاتون بسپارین و دیگه نیاز نیست درگیر جزئیاتش بشین و می‌تونین با هماهنگی پیش‌رفتن کارها رو مدیریت کنین.دلگیشن رو خیلی‌هامون حتی وقتی اسمش رو هم نمی‌دونستیم داشتیم ازش استفاده می‌کردیم. مثلا توی بازی کانتر استرایک، وقتی لیدر تیم بهمون می‌گفت برو هوای بخش B نقشه رو داشته باش، عملا داشته مسئولیت اون بخش از بازی رو به ما دلگیت می‌کرده.تجربه شخصیتوی شرایطی که بالاتر مطرح کردم، با شکستن کارها و مسئولیت‌ها و دلگیت کردن اون‌ها، تونستم از همون ۳۰ درصد زمانی که برام باقی‌مونده بود استفاده بهتری بکنم و زمان بیشتری برای افزایش بهره‌وری تیم، هماهنگی کارهای بین‌تیمی و سایر کارهای مدیریتی تیم بذارم. جایی که نیروی فنی با تجربه داشتم، مسئولیت تصمیمات فنی رو واگذار کردم، جایی که مسلط به متدولوژی‌ها داشتم، فرایندهای تیم رو دلگیت کردم و با همین فرمون تونستم مسئولیت‌ها رو بین افراد تقسیم کنم. این کار حس اونرشیپ بیشتری به بچه‌ها منتقل کرد و باعث افزایش انگیجمنت اعضای تیم شده بود. یه مثال عینیش، یه بار یه مسئله فورسی رو به یکی از بچه‌ها دلگیت کردم که احتمالا بخشی از آخر هفته‌ش رو هم درگیر کرد و البته کار هم به بهترین شکل انجام شده بود. بخاطر درگیری آخر هفته‌ش با حس شرمندگی رفتم پیشش که نتیجه رو ازش پیگیری کنم، برخلاف تصورم بهم فیدبک داد که خیلی حس خوبی گرفته که کار با این درجه حساسیت رو بهش دلگیت کردم و ازم خواست این فرمون رو هم ادامه بدم. خلاصه این مسئله دومینو وار باعث بهبود حال تیم و دلیوری تیم‌ها هم شد. اینجا بود که حرف آقای برایان تریسی که می‌گفت «If you don’t delegate, you are limited to what you can do personally. But if you delegate effectively, you can multiply your results and leverage your time exponentially» رو با گوشت و پوست و استخونم درک کردم.از اون تجربه و تجربیاتی که در ادامه بدست آوردم، کم کم یه الگویی در مورد نحوه و سطح دلگیشن تو ذهنم شکل گرفت که هنوزم ازش استفاده می‌کنم که سعی می‌کنم یه خلاصه‌ای ازش رو اینجا بنویسم. اینکه درگیر همه کارها بشیم، در حالی که ممکنه از توانمون خارج باشه، از ما یه قهرمان نمی‌سازه. به طور خلاصه توی بحث‌های مدیریتی، دلگیشن نه‌تنها خوبه، بلکه یه باید هست، و البته اصولی هم داره که باید رعایت بشه. هر دلگیشنی خوب نیست و ممکنه تاثیر معکوس هم بذاره. برای همین لازمه دلگیشن رو خوب و به درستی انجام بدیم تا به نتیجه برسیم. توی این مسیر طبیعتا ممکنه اشتباه هم بکنیم، ولی اصلا نکته دلگیشن هم همینه. وقتی کاری رو به کسی دلگیت می‌کنی، باید انتظار وقوع اشتباه رو هم داشته باشی و بپذیری که اون شخص هم در طول این دلگیشن در حال یادگیری هست و خب این اتفاق برای خود ما هم ممکنه بیافته. ولی من سعی می‌کنم چیزهایی که خودم توی این مسیر از دلگیشن خوب یاد گرفتم رو بنویسم.مزایای دلگیشناول از همه اینکه هدف دلگیشن همونطور که بالاتر هم بهش اشاره کردم، فقط خالی کردن زمان لیدر نیست، و یکی از مهمترین اثرات دلگیشن، افزایش بهره‌وری تیم هست. حالا چطوری این اتفاق می‌افته؟اولیش اینکه تا قبل از انجام دلگیشن، باتل‌نک و محدود کننده تمامی تصمیم‌گیری‌های تیم، لیدر اون تیم هست و به خاطر ظرف زمانی محدودی که لیدر داره، تصمیم‌گیری‌ها دیر و با تاخیر انجام می‌شه و همین مسئله باعث کُندتر شدن تیم می‌شه. اما بعد از دلگیشن، این مسئله بین تعدادی افراد توزیع می‌شه و باعث می‌شه تیم برای تصمیم‌گیری پِند یک نفر نمونه و هر بخش از کارها تصمیم‌گیر مختص خودش رو داره که باعث می‌شه سرعت تصمیم‌گیری‌ها و سرعت واکنش نشون دادن به شرایط مختلف بیشتر بشه.علاوه بر این، حس اونرشیپ توی تیم افزایش پیدا می‌کنه. افرادی که کارها بهشون دلگیت می‌شه (البته اگه دلگیشن به درستی اتفاق افتاده باشه) متوجه می‌شن کاری که انجام می‌دن مال خودشونه و فقط مسئول انجام دادنش نیستن. وقتی افراد خودشون بتونن تصمیمات مهم در یک حوزه رو بگیرن، می‌دونن موفقیت یا شکست اون کار به عملکرد خودشون گره خورده و در نتیجه انگیجمنت بیشتری با کار پیدا می‌کنن و کارها رو با دقت، پیگیری و مسئولیت‌پذیری بیشتری انجام می‌دن. طبق مطالعات Gallup، افرادی که حس مالکیت بیشتری دارن، ۲۱٪ بهره‌وری بالاتری دارن، ۵۹٪ احتمال بیشتری داره که با انگیزه بیشتری کار کنن و ۴۰٪ احتمال خطا و اشتباهاتشون کاهش پیدا می‌کنه.همینطور یکی از مهمترین خروجی‌های دلگیشن، اینه که فردی که کاری بهش دلگیت می‌شه، مهارت جدیدی رو کسب می‌کنه. شاید ابتدای راه دلگیشن حس کنین کارها داره کُند پیش می‌ره و لازمه شما زمانی رو برای آموزش انتقال مسئولیت و چک و تیک کردن کارها اختصاص بدین. اما به مرور این شخص رشد می‌کنه و بعد از چندبار دلگیشن دیگه همین چک و تیک رو هم نیاز نداره و می‌تونین سطح مداخله‌تون توی دلگیشن بهش رو به حداقل برسونین و به گفته لیز وایزمن در کتاب Multipliers در بلندمدت این شخص علاوه بر اینکه بدون راهنمایی می‌تونه کارها رو جلو ببره، می‌تونه راهنمای بقیه هم باشه و اینجوری می‌تونین تیم رو بطور مداوم و پایدار رشد بدین.دلگیشن علاوه بر مزایاش برای تیم، مزایایی هم برای دلگیت کننده داره و طبق مطالعاتی که توی HBR انجام شده،  افرادی که تجربه دلگیت کردن کارها به دیگران رو دارن معمولا با سرعت بیشتری وارد نقش‌های رهبری می‌شن و مدت زمان رسیدن به استقلال کاریشون حدود ۳۰ تا ۵۰ درصد کاهش پیدا می‌کنه.و یه عالمه فایده دیگه که دیگه بذارین فعلا به همین‌ها کفایت کنیم و بحث رو ادامه بدیم. حالا که دلگیشن خوبه، کِی و چجوری بهتره انجامش بدیم؟نحوه دلگیشندوتا پارامتر خیلی مهم برای انجام دلگیشن، یکی کاری هست که می‌خواین دلگیت کنین، و اون یکی شخصی هست که می‌خواین کار رو بهش دلگیت کنین. بسته به اینکه هر کدوم از این‌ها چه ویژگی‌هایی داشته باشن، سطح دلگیشن باید متفاوت باشه و یا حتی ممکنه امکان‌پذیر نباشه. هر دلگیشنی خوب نیست و ممکنه تاثیر معکوس هم بذاره. برای همین لازمه دلگیشن رو خوب و به درستی انجام بدیم تا به نتیجه برسیم. توی این مسیر طبیعتا ممکنه اشتباه هم بکنیم، ولی اصلا نکته دلگیشن هم همینه. وقتی کاری رو به کسی دلگیت می‌کنی، باید انتظار وقوع اشتباه رو هم داشته باشی و بپذیری که اون شخص هم در طول این دلگیشن در حال یادگیری هست و خب این اتفاق برای خود ما هم ممکنه بیافته. اما مهمترین نکته‌ای که توی همه حالت‌ها باید حواسمون بهش باشه، اینه که در صورتی که دلگیشن انجام می‌شه باید مراقب باشیم میکرومنجمنت اتفاق نیافته، وگرنه دلگیشن نتیجه معکوس می‌ده و می‌تونه شرایط رو بدتر هم بکنه. همینطور بخاطر اینکه هم کارها و هم آدم‌ها چیزهای پیچیده‌ای هستن، امکان اینکه خط کش بذاریم و یه فرمول دقیق براش ارائه بدیم وجود نداره، ولی با توجه به مشاهدات و تجربیاتی که من توی این مدت داشتم، سعی می‌کنم تا حدی که می‌تونم فرموله‌ش کنم. من دلگیشن رو توی سه دسته می‌بینم:۱. جایی که نباید دلگیشن رو انجام بدیمهمیشه دلگیشن تاثیر مثبت نداره و حتی برعکس تاثیر منفی هم ممکنه بذاره. این الزاما به معنی بی‌اعتمادی نیست. وقتی نیرویی که قراره کاری رو بهش دلگیت کنی، آمادگی یا علاقه لازم رو نداشته باشه، دلگیت کردن کارها بهش، فقط باعث اضطراب بیشترش می‌شه و نه به رشدش کمک می‌کنه، و نه باعث بهبود می‌شه. در صورتی که کار ابهام خیلی زیادی داره و تو مرحله شکل‌گیری هست، این کار رو فقط به اشخاصی که توی این زمینه تجربه کافی داشته باشن می‌تونی دلگیت کنی که در اکثر مواقع توصیه می‌شه توی این سطح کار رو دلگیت نکنیم و صبر کنیم تا کار از یه حدی شفاف‌تر بشه و بعد دلگیشن رو انجام بدیم. یا زمانی که شخصی که می‌خوایم کار رو بهش دلگیت کنیم، به وضوح گفته که آمادگی گرفتن مسئولیت جدید رو نداره، اینجا هم طبیعتا دلگیشن بیشتر آسیب‌زا هست و بهتره دلگیشن رو انجام ندیم. به طور خلاصه اگه شخص هنوز ownership لازم برای تصمیم‌گیری در سطح اون کار رو نداره، دلگیشن بیشتر آسیب‌زا هست تا کمک کننده و بهتره این دلگیشن انجام نشه و اینجا باید گزینه‌های دیگه‌ای مثل آموزش، منتورشیپ و کوچینگ رو مد نظر قرار بدیم.۲. جایی که باید دلگیشن با همراهی بیشتر انجام بشهمرحله بعدی دلگیشن با همراهی بیشتر هست یا چیزی که HBR بهش می‌گه Delegation with Support. این مدل به نظرم در اغلب موارد، توی مسیر دلگیشن هست و در اکثر مواقع با این روش دلگیشن رو شروع کنیم و یه جورایی به بازه‌ای رو با هم هم‌مسیر بشیم که شخصی که قراره کار بهش دلگیت بشه، احساس نکنه هُلش دادیم تو استخر ۴ متری که شنا کردن رو خودش یاد بگیره، و در طول این مسیر کنارش هستیم که بتونم با خیال راحت کار رو تحویل بگیره. معمولا وقتی کار نسبتا پیچیده‌ست و شخص مورد نظر هم تجربه کمتری داره، این مسیر رو طی می‌کنیم که در طول مسیر، تجربه کافی رو بدست بیاره و مدلی که در شرایط پیچیده تصمیم می‌گیریم رو یاد بگیره که بتونه در ادامه از این تجربیات استفاده کنه. یا حتی ممکنه بخاطر شرایط خاص کار تصمیم بگیریم مدل دلگیشن با همراهی رو پیش ببریم. مثلا وقتی کار خیلی روی کاربر نهایی تاثیر جدی‌ای می‌ذاره و کیفیت و دقت خیلی مهمه و اینجا هم این مدل دلگیشن کمک می‌کنه که هم این حس اهمیت رو به شخص دلگیت شونده منتقل کنی، و هم تا زمانی که به استقلال کامل برسه، کارها رو با هم مرور می‌کنیم که هم یادگیری برای شخص داشته باشه و هم بتونیم احتمال وقوع مشکلات رو کاهش بدیم.۳. جایی که باید دلگیشن عمیق‌تر انجام بشهاینجا مهمترین پارامتر «شخص» هست. در صورتی که شخص آمادگی کامل هم از نظر توانمندی و هم از نظر اعتماد به نفس رو داشته باشه، می‌تونه پتانسیل این مدل دلگیشن باشه. در این شرایط، دلگیشن هم می‌تونه روی رشد افراد تاثیر بذاره، چرا که تجربه جدیدی کسب می‌کنن و می‌تونن خودشون رو توی یه فضای جدیدی محک بزنن، و هم می‌تونه سرعت کارها رو بالا ببره، چرا که مسئولیت‌ها توزیع می‌شه و به دلیل آمادگی اشخاص، کارها هم به خوبی پیش می‌ره. فرض کنین اگه شما بصورت متمرکز روی یک مسئله زمان بذارین و بتونین اون رو توی X واحد زمانی دلیور کنین، و اگه این کار رو به یه شخص آماده دلگیت کنین و اون این کار رو توی 1.2X واحد زمانی دلیور کنه، باز هم احتمالا شما بُرد کردین. چون هم اون شخص توی مسیر رشدش حرکت می‌کنه، هم شما احتمالا nتا مسئولیت دیگه هم دارین و بخاطر اون مسائل نمی‌تونین متمرکز روی یه مسئله وقت بذارین. پس در نتیجه در مرحله دلگیشن ایده‌آل گرایی و دید کوتاه مدت رو باید بذاریم کنار و این دید رو داشته باشیم که این شخص ۳ تا ۶ ماه دیگه همین ۲۰٪ رو هم بهبود می‌ده و حتی شاید کار رو سریعتر از خود شما هم بتونه جلو ببره.مدل «رهبری موقعیتی» و استفاده از اون در دلگیشنمن اینجا برای ساده‌تر شدن مسئله، این سه‌تا دسته‌بندی رو انجام دادم. ولی اصل ماجرا الگو گرفته از مدل «رهبری موقعیتی» یا «Situational Leadership» هست که بسته به شرایط لازمه میزان مداخله‌تون در تصمیمات مدیریتی (که اینجا بحث دلگیشن هست) رو مشخص کنین. توی این مدل البته تمرکز بیشتر روی افراد هست و بر اساس دوتا پارامتر Competence و Commitment میزان مداخله رو تعیین می‌کنه. که خب به نظرم ترکیبی از شخص و کار می‌تونه گزینه بهتری باشه. ولی باز همین مدل هم می‌تونه جهت خوبی به سطح مداخله‌مون بده. خیلی خلاصه بخوام این مدل رو باز کنم، بر اساس این دوتا پارامتر، سطح آمادگی افراد رو به ۴ سطح مختلف تقسیم می‌کنه:اگه این مدل و مدلی که بالا بهش اشاره کردم رو بخوایم به هم متصل کنیم، فقط با در نظر گرفتن شرایط افراد، سطوح D1 و D2 توی دسته اول جا می‌گیرن که هنوز شرایط برای دلگیشن فراهم نیست. سطح D3 می‌تونه پتانسیل قرار گرفتن توی دسته دوم، یعنی Delegation with Support رو داشته باشه و در صورتی که کاری که قصد دلگیت کردنش رو داریم شرایط لازم رو داشته باشه، می‌تونیم با این روش پیش بریم. سطح D4 هم پتانسیل قرار گرفتن توی دسته سوم یعنی Full Delegation رو داره و در صورتی که کاری که قصد دلگیت کردنش رو داریم شرایط لازم رو داشته باشه، می‌تونیم با این روش پیش بریم. التبه در صورتی که کار پیچیدگی یا محرمانگی زیادی داشته باشه، ممکنه بهتر بشه وارد دسته دوم بشیم و با پشتیبانی دلگیشن رو انجام بدیم.جمع‌بندیبه طور کلی اگه بخوام حرف‌هام رو جمع‌بندی کنم، استفاده از ابزار دلگیشن توی بحث مدیریت تیم، با توجه به فوایدی که می‌تونه برای تیم داشته باشه، یه کار must have هست و لازمِ در صورتی که شرایطش مهیا باشه، حتما ازش استفاده بشه که در کوتاه مدت، هم استفاده از زمان رو برای لیدر بهینه کنه و سرعت تصمیم‌گیری رو افزایش بده، و در بلند مدت به پایداری بهره‌وری تیم کمک کنه. اگه بخوایم این مدل رو فرموله کنیم، به جدولی مثل جدول زیر می‌رسیم:در آخر همونطور که گفتم، دلگیشن ابزاری هست که ما توی کار و زندگی‌مون داریم ازش استفاده می‌کنیم و قطعا تجربه‌های خوب یا بدی چه از دلگیت کردن کارها به دیگران و چه از دلگیت شدن کارها بهمون داشتیم. همونطور که توی این مقاله سعی کردم بهش اشاره کنم، بد پیشرفتن دلگیشن الزاما به معنی عدم توانمندی افراد نیست و ممکنه نحوه دلگیشن، عمق و یا فرایندهاش به درستی طی نشده باشه. تا حالا شده کاری بهتون دلگیت بشه و احساسات متناقضی نسبت بهش داشته باشین؟ و در انتها چه کردین؟ آرمین ایلدرمی آرمین ایلدرمی Thu, 27 Mar 2025 15:47:35 +0330 https://virgool.io/@aildermi/%D9%85%D9%87%D8%A7%D8%AC%D8%B1%D8%AA-%D8%A8%D9%87-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-fznev3adlhoh کافه بازار هم مثل خیلی از شرکت‌های دیگه، در زمان شروع یه monolith کوچیک بود و به مرور زمان بزرگ شد و از یه جایی به بعد دیگه اینقدر هم خودش بزرگ شده بود و هم تعداد توسعه‌دهنده‌هاش زیاد شده بودن که دیگه کار کردن سخت شده بود. سختی‌هاش هم الان که دیگه مشخصه، ولی چندتا نمونه‌ش رو بخوام بگم coupling زیاد کدها، توسعه رو سخت کرده بود و ریسک دیپلوی‌ها رو هم افزایش داده بود. همینطور تعدد توسعه‌دهندگان روی این monolith هم باعث شده بود توسعه‌های همزمان زیادی روی این سرویس اتفاق بیافته و در نتیجه تعداد زیادی merge request دارای conflict تولید می‌شد که باعث شده بود رفت و برگشت‌ها و هزینه توسعه زیاد بشه. دیگه بقیه چالش‌هاش رو فاکتور می‌گیرم چون الان دیگه اکثرا باهاش آشنا هستیم. برای رفع این مشکلات، شرکت تصمیم گرفته بود که بخش‌هایی از لاجیکی که داخل این monolith هست که از لحاظ پروداکتی استقلال بیشتری داشتن رو از این monolith بیرون بکشه و بجای داشتن یک سرویس، چندتا سرویس داشته باشیم که با هم دائما در حال ارتباط هستن. این کار باعث شد بخش قابل توجهی از مشکلات توسعه‌ای رفع بشه. اما وضعیتی که بوجود اومده بود اون زمان بهش می‌گفتیم از یه monolith به چندتا monolith تغییر پیدا کردیم. یعنی به جای اینکه یه هیولا داشته باشیم، چندتا هیولای کوچکتر داشتیم که هنوز خیلی به هم گره خورده بودن و مستقل رفتار نمی‌کردن. این شد که به همت مهران اخوان که CTO اون زمان بود، یه حرکتی شکل گرفت که این کار رو اصولی‌تر پیش ببریم و monolithهامون رو به microservice تعریف کنیم. برای این کار (و خیلی کارهای دیگه) یه گروهی تشکیل شده بود که بهش می‌گفتیم چپتر بکند، که متشکل از CTO و تعدادی تک‌لید بود، که هر کدوم از تک‌لیدها، نماینده یکی از تیم‌های فنی/محصولی در زمینه مسائل فنی بودن. اینکه مهران چی تو ذهنش داشته و چطور پیش رفته رو که باید از خود مهران بپرسیم، ولی من این روند رو از نگاه خودم که اون موقع به عنوان یه تک‌لید عضو این چپتر بودم روایت می‌کنم که چه مسیری رو رفتیم و چرا اینجوری پیش رفتیم.کلید این پروژه اواسط سال ۹۶ خورد و مسئله توی چپتر مطرح شد. مهاجرت به میکروسرویس، و به طور کلی نگاهمون به میکروسرویس‌ها، چیزی نیست که بشه از یه جای کپی کرد و عینا پیاده‌سازیش کرد. یه جمله‌ای از آدرین کاک‌کرافت هست که می‌گه «People try to copy Netflix, but they can only copy what they can see. They copy the results, not the process» یا به عبارتی «مردم سعی می‌کنن نتفلیکس رو کپی کنن، ولی فقط می‌تونن چیزی که می‌بینن رو کپی کنن، در واقع بجای کپی کردن فرایند، نتایج رو کپی می‌کنن». نتفلیکس و سایر شرکت‌هایی که توی این زمینه‌ها پیشرو محسوب می‌شن، کارهایی که می‌کنن رو بر اساس خیلی پارامترها مثل فرهنگ اون شرکت Tune می‌کنن و وقتی ما عینا همون موارد رو بخوایم کپی کنیم، بخاطر تفاوت‌های فرهنگی‌ای که داریم ممکنه یا قابل اجرا نباشن، یا حتی نتیجه معکوس بدن. در نتیجه لازم بود ما هم استانداردهای مخصوص خودمون رو داشته باشیم که با فرهنگ و شرایط کاری ما همخونی داشته باشه.اولین مرحله از این فرایند مطالعه بود. ما یکم از پایه‌تر هم شروع کردیم و سعی کردیم در این لایه هم بررسی کنیم که اصلا میکروسرویس شدن مناسب ما هست یا نه و باید به سلوشن‌های دیگه‌ای مثل SOA و اینجور چیزها فکر کنیم و بعدش بریم روی اون سلوشن تمرکز کنیم. توی این مرحله بیشتر مطالعه می‌کردیم و منابعی مثل مقالات مارتین‌فاولر، کتاب‌ Release It مایکل نیگارد، کتاب Building Microservices سم نیومن، کتاب Production Ready Microservices سوزان فاولر و هر چیز دیگه‌ای که می‌تونستیم تو اینترنت پیدا کنیم رو لیست کردیم و بین خودمون تقسیم کردیم تا بخونیم که ببینیم داستان چیه و بهترین سلوشن برای مشکلات ما چیه.خلاصه جمع‌بندیمون این شد که بله، میکروسرویس احتمالا مناسبترین گزینه برای ما باشه و حالا سوال این بود که چطور باید به سمتش بریم، تعریف ما از میکروسرویس چیه و چطوری شرکت رو با این تغییر همراه کنیم. اینجا هم هنوز نیاز قابل توجهی به مطالعه داشتیم، ولی میزان ابهام کمتر شده بود و کلیت مسئله دستمون اومده بود. برای اینکه سرعت کار بیشتر بشه، ما بخش‌های مختلفی که میکروسرویس‌ها روشون تمرکز می‌کردن رو بین خودمون تقسیم کردیم و هر نفر مسئول یکی دو بخش شد که بره مطالعه کنه و یه خلاصه‌ای رو آماده کنه که برای چپتر ارائه بده. به نظرم اینجا هدفمون این نبود که یه چارچوب سفت و سخت بذاریم و شرکت رو مجبور کنیم در این راستا حرکت کنن، و بجاش بیشتر هدفمون این بود که سعی کنیم فرهنگش رو توی فرهنگ فنی‌مون جا بندازیم تا این سلوشن رو کنار سلوشن‌های دیگه‌ای که وجود داره ببینیم. برای این کار تصمیم گرفتیم یه تک‌تاک داشته باشیم و نتیجه این بررسی‌ها رو به شرکت ارائه بدیم، و همینطور تک‌لیدی که توی هر تیم هست هم سعی کنه کمک کنه که سلوشن میکروسرویس شدن هم در بررسی‌های فنی تیم‌ها بررسی بشه. در نتیجه هدف این بخش از مطالعه هم این بود که دانش خودمون رو افزایش بدیم، و هم برای یه تاک توی شرکت آماده بشیم.بخش‌های مختلفی که در موردشون قرار بود مطالعه و صحبت کنیم رو اگه بخوام لیست وار بگم، اینا بود:مقدمه‌ای بگیم که اصلا چی شد به این فکر کردیم و چرا این گزینه رو بین گزینه‌ها انتخاب کردیمتوی این مسیر با چه چالش‌هایی قراره روبرو بشیمارتباط بین میکروسرویس‌ها معمولا چطوری هندل می‌شهشفافیت در میکروسرویس‌ها چیه و چرا باید شفافیت داشته باشیمچه اتفاقی برای دیتاها و دیتابیس‌ها می‌افتهاینکه API Gateway چیه و چرا خوبه که داشته باشیمشمیکروسرویس‌ها چه ویژگی‌هایی دارنچطوری monolith رو به میکروسرویس بشکنیمچه مسائل انسانی‌ای در این فرایند بوجود میاد و لازمه حواسمون بهش باشهفرایندهای دولوپمنت و دیپلویمنت چطوری باید باشنتا الان چه تجربیاتی داشتیمچون تمرکز این نوشته روی خود فرایندِ، نمی‌خوام وارد جزئیات اون تاک بشم، و بیشتر روی خود فرایند متمرکز می‌مونم. خلاصه که رفتیم و خوندیم و نوشتیم و به اشتراک گذاشتیم و چَکُش‌کاریش کردیم و در نهایت حدود اردیبهشت ۹۷ بود که این تاک رو تونستیم داخل شرکت داشته باشیم و تقریبا از اونجا به بعد، این بحث کم کم وارد تصمیم‌های مهم فنی شد و بعد از اون تاک، توی چندتا از پروژه‌هامون از مدل میکروسرویس استفاده کردیم.توی هر تیم بسته شرایط و نیازشون، روی یه بخشی از این موارد تمرکز کردن. مثلا جایی که مشکلات و داون‌تایم بیشتر داشتیم، از شفافیت سرویس شروع کردیم و سعی کردیم مانیتورینگ، لاگینگ، Error Aggregation و اینجور مسائل رو بیشتر روش متمرکز بشیم که بتونیم ریشه مشکلات رو سریعتر پیدا کنیم. یه تیمی API Gateway رو توسعه داد. تیم‌هایی که دیپلویمنت‌های ریسکی‌ای داشتن روی بهبود فرایندهای دیپلویمنت‌شون متمرکز شدن. در واقع همه از یه جا شروع نکردن، ولی هر تیمی با توجه به اولویت‌های خودش یه تیکه از مسیر رو برداشت و رفت جلو. اینطوری شد که آروم آروم به این سمت رفتیم که تعدادی میکروسرویس درست و حسابی داشتیم و هم درد توسعه و هم درد نگهداری‌مون کاهش پیدا کرد.این مسیر فقط یه تغییر فنی نبود. برای خیلی‌هامون یه جور یادگیری جدی‌ای بود که چطور یه مسئله بزرگ رو به بخش‌های کوچک تقسیم کنیم، چطور همدلانه مطالعه کنیم، و چطور تصمیم‌های فنی رو با فرهنگ شرکت هماهنگ کنیم.تجربه شما از این زمینه چطور بوده؟ شما هم مسیر مشابهی رو طی کردین؟ یا بر اساس شرایط تصمیم گرفتین monolith بمونین؟ آرمین ایلدرمی آرمین ایلدرمی Sat, 22 Mar 2025 17:37:15 +0330