♻️ چرخه عمر نیروی انسانی (Employee Life Cycle) چیه؟

در بررسی ریشه‌های وضعیت فعلی توسعه نرم‌افزار در ایران، یکی از مهم‌ترین دلایل، ضعف فاحش در مدیریت چرخه عمر کارمند (Employee Life Cycle - ELC) است. این چرخه تمام مسیر یک فرد رو از پیش از جذب تا بعد از خروج پوشش می‌ده، توی شرکت‌ها و سازمان‌های ایرانی عموما جدی گرفته نمی‌شه یا به شوخی شبیهه. ELC یه مدل راهبردی توی مدیریت منابع انسانیه (HRM) که معمولا شامل ۶ مرحله کلیدی می‌شه.

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

مراحل ELC عموما:

➖ برنامه‌ریزی نیروی کار یا Workforce Planning
➖ جذب و گزینش یاRecruitment & Selection
➖ فرایند پذیرش و آشنایی یا Onboarding
➖ توسعه و آموزش یاDevelopment
➖ مدیریت عملکرد یا Performance Management
➖ نگهداشت یاRetention
➖ فرایند خروج یا Offboarding

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

🔗 در باب وضعیت امروز نرم‌افزار ایران، چند خطی رو در از منظر ELC نوشتم که اگر دوست داشتید مطالعه کنید و خوشحال می‌شم نظرتون رو به اشتراک بگذارین 😊

✨ آیا APIهای فعلی‌مون می‌تونن MCPهامون رو بسازن؟! (بخش ۱)

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

مقدمه:

اگر با مفهوم و ساختار MCP آشنایی دارید می‌تونید از روی بخش مقدمه بپرید و برید سراغ «✅ اصل مطلب»!

پروتکل MCP یا Model Context Protocol یک پروتکل باز و استاندارد برای شناسایی و به کارگیری منابع و ابزارها (منابع مثل دیتابیس‌ها، ابزارها هم مثل API و کامندها) توسط مدل‌های زبانیه که شرکت Anthropic (توسعه‌دهنده Claude) سال ۲۰۲۴ معرفی کرد.

💡 هدف و عملکرد
هدف اصلی MCP، ایجاد یه زبان مشترک برای تعامل مدل‌های زبان بزرگ (LLM) با برنامه‌ها و خدمات دنیای واقعیه. به بیان ساده‌تر، این پروتکل به هوش مصنوعی (LLM) اجازه می‌ده تا به‌جای اینکه فقط بر اساس داده‌های خودش متن تولید کنه، اقداماتی (Actions) رو در یک برنامه خارجی انجام بده (مثل فراخونی API یا کوئری گرفتن از دیتابیس یا...).

استانداردسازی: این پروتکل نحوه ارائه "ابزارها" و "قابلیت‌های" یک برنامه به LLM رو به شکل استاندارد تبیین می‌کنه.

سرور MCP: هر برنامه‌ای که بخواد توسط هوش مصنوعی قابل استفاده باشه، باید یه سرور MCP پیاده‌سازی کنه که رابط‌های تعاملی خودش رو اعلام کنه.

🧱 اجزای کلیدی (MCP Server)
سرور MCP سه مفهوم اصلی رو به LLM (که نقش کلاینت رو داره) ارائه می‌ده:

۱: ابزارها یا Tools:
مهم‌ترین جزء هستن. در واقع همون عملیات (Actions) یا APIهای سطح بالایی هستن که LLM می‌تونه فراخونی کنه. مثال: "ایجاد پایگاه داده" یا "رزرو پرواز" یا "درج یه سفارش جدید".
یک LLM برای انجام وظایف بهینه، به تعداد محدودی از ابزارهایی که به خوبی تعریف‌شده باشن نیاز داره.

۲: منابع یا Resources:
داده‌ها یا اطلاعات جانبی مورد نیاز برای اجرای ابزارها (دیتابیس، فایل حاوی داده یا ...).

۳: دستورالعمل‌ها یا Prompts:
متن‌هایی که به LLM کمک می‌کنن تا درک کنه چه زمانی و چجوری از ابزارها استفاده کنه.

🐤 یه نمونه MCP ساده برای تبدیل واحد توی کامنت می‌گذارم

✅ اصل مطلب: آیا API شما برای ساخت MCP کافیه؟
اگر نرم‌افزار شما RESTful باشه، ابزارهای متعددی هستن که از روی OpenAPI Spec شما برای MCP سرور می‌سازن. این رو داشته باشید فعلا تا ۳ تا حالت ساخت MCP رو ببینیم:
۱: خودکار
با استفاده از ابزارهایی مثل Fast MCP از APIهای فعلی رو به عنوان ابزار توی MCP سرور معرفی می‌کنیم. خیلی سریع! (بررسی مشکلات در بخش دوم همین مطلب)

۲: دستی
متناظر با قابلیت‌هایی که می‌خواهیم با استفاده از هوش مصنوعی ارائه کنیم، APIهای اختصاصی برای هوش‌مصنوعی تولید می‌کنیم، طبیعتا تعداد محدوتر، و کلی‌تر (مثلا یک API برای کل یک فرایند)


«ادامه در بخش دوم، فردا»
(مشکلات روش خودکار + معرفی روش سوم یا همون هایبرید)

✨ آیا APIهای فعلی‌مون می‌تونن MCPهامون رو بسازن؟! (بخش دوم)

در بخش ۱ دو روش خودکار و دستی ساخت MCP رو فقط نام بردیم و تحلیل این دو روش و معرفی روش سوم باقی موند!

چهار مشکل اساسی تولید خودکار
۱. معضل انتخاب بیش از حد
یکی از موضوعات مهم در کار با LLMها اینه که این مدل‌ها زمانی که با تعداد زیادی گزینه روبرو می‌شن، خِنگ می‌شن! و پاسخ‌های دقیقی ارائه نمی‌کنن. تصور کنید یک API با ۷۵ تا ۱۰۰ endpoint رو به‌طور خودکار به MCP تبدیل کنید. LLM با کلی ابزارها روبرو می‌شه و تصمیم‌گیری برای انتخاب ابزار مناسب برای هر کار، به یه چالش جدی براش تبدیل می‌شه. نتیجه؟ سردرگمی، انتخاب‌های نادرست، و در نهایت تجربه کاربری ضعیف. (حالا تصور کنین توی یک سیستم بزرگ که چند هزار و یا توی انترپرایزها چند ده هزار API خیلی خیلی عادیه)

۲. توضیحات نامناسب برای LLM
عملا APIهای سنتی با توضیحات نوشته شده برای توسعه‌دهنده‌های انسانی طراحی شده‌ان (بگذریم که ۹۹درصد APIهای خیلی شرکت‌ها همون رو هم نداره!). انسان‌ها می‌تونن استنباط کنن و سوال بپرسن.اما LLMها به توضیحات مستقیم، دقیق و اغلب مثال‌محور نیاز دارن تا بفهمن چه زمانی و چجوری باید از یه ابزار استفاده کنن. توضیحات API موجود شما، صرف‌نظر از اینکه برای انسان‌ها چقدر واضحه، احتمالاً برای LLM بهینه نشده.

۳. عدم تطابق سطح انتزاع
بیشتر APIها برای کارهای سطح پایین طراحی شدن: مدیریت منابع، عملیات CRUD، و خودکارسازی‌های فنی. اما LLMها ماهیت انسان‌گونه‌تری دارن و باید کارهای سطح بالا رو انجام بدن. به‌عنوان مثال، به‌جای اینکه یک LLM رو مجبور کنین ده تا endpoint مختلف رو به‌صورت دستی فراخوانی کنه تا یک فرآیند کاری رو کامل کنه، چرا یه ابزار اختصاصی نسازین که کل این گردش کار رو توی یک فراخوانی به صورت هوشمندانه‌تر انجام بده؟

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

🙂 ۳: هایبرید
ترکیبی از هر دو، که نیازی نیست از صفر شروع کنیم. نوشتن یک سرور MCP از ابتدا می‌تونه کار سنگینی باشه (حتی نمونه‌های ساده). راه‌حل بهینه، یک رویکرد ترکیبیه که از نقاط قوت تولید خودکار بهره بگیره، اما با بهینه‌سازی دستی تکمیل بشه.
مراحل پیاده‌سازی راه‌حل هایبرید:
۳-۱. شروع با تولید خودکار
از ابزارهای موجود برای تولید اولیه سرور MCP از API خودمون استفاده می‌کنیم. این به ما یه پایه‌ی سریع می‌ده.

۲-۳: هَرَس کردن ابزارها
تعداد endpointهای اعلان شده رو بنا به نیاز کاهش می‌دیم. فقط مهم‌ترین و پرکاربردترین ابزارها رو نگه می‌داریم. کیفیت بر کمیت ارجحیت داره.

۳-۳. بازنویسی توضیحات
توضیحات ابزارها رو به‌گونه‌ای بازنویسی می‌کنیم که برای LLMها مستقیم و صریح و قابل فهم باشن و بین APIها به اشتباه نیوفتن. از مثال‌های واضح استفاده بشه و سناریوهای استفاده رو به‌طور دقیق توضیح بدید.

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

۵-۳. تست و بهینه‌سازی
تست‌های جامعی بنویسید تا اطمینان پیدا کنین LLMها به‌درستی از ابزارها استفاده می‌کنن. این مرحله حیاتیه! خیلی هم حیاتی. چون خیلی چیزها که تئوری کار می‌کنن، ممکنه در عمل نیاز به تنظیم داشته باشن تا مدل اشتباه نکنه و مزخرف تحویل نده.

«ادامه در بخش سوم، فردا»

✨ آیا APIهای فعلی‌مون می‌تونن MCPهامون رو بسازن؟! (بخش سوم و آخری)

در بخش ۱ و ۲ علاوه بر مرور MCP و روش‌های ساختن MCP سرور، مشکلات تولید خودکار و نحوه ایجاد هایبرید رو مرور کردیم، بریم سراغ بخش سوم و آخر این مطلب:

نتیجه‌گیری:

در واقع MCP فرصت خیلی خوبی برای ایجاد یکپارچگی عمیق بین LLMها و سرویس‌های موجود ماست. اما مثل خیلی از تکنولوژی‌های جدید، موفقیت در جزئیات نهفته است. API موجود شما یک شروع عالیه، اما به‌تنهایی کافی نیست. تولید فَله‌ای و چشم‌بسته می‌تونه علاوه بر یک محصول افتضاح، باعث مشکلات خیلی خیلی جدی بشه، می‌پرسید چه مشکلی؟ یا فکر می‌کنید فوق فوقش درست کار نمی‌کنه؟ نه جانم! خیلی راحت می‌تونه باعث بشه دیتای غیرمجاز رو به کاربر غیر مجاز افشا کنه!! خیلی راحت همین فَله‌ای تولید کردن‌ها می‌تونه باعث بشه از حساب یکی دیگه اعتبار کسر یا اضافه بشه! کافیه بدون کنترل دسترسی، بدون فرایندهای کنترلی مضاعف، فَله‌ای MCP تولید کنین و برید توی لینکدین و توییتر بنویسید «خسته از کد زدن بسیار ولی خرسند از کاویدن اعماق هوش مصنوعی» (عکس با قهوه یا ماچا فراموش نشود!). چند روز بعدش هم که افتضاحش علنی شد، برگردیم به همون بحث عمیقا علمی PHP بهتر است یا Go یا دوران شی‌گرایی به سر اومده!!

ولی با پذیرش یک رویکرد ترکیبی، شروع با تولید خودکار و بعدش با بهینه‌سازی هوشمندانه (هوشمندانه یعنی مرور تمام ابزارهای افشا شده در MCP و بررسی توضیحات، سناریوها و نکات امنیتی) می‌تونید سرورهای MCP بسازین که نه‌تنها کار می‌کنن، بلکه واقعاً قدرت LLM رو توی نرم‌افزار سنتی آزاد می‌کنن تا کارهای «معناداری» برای کاربرها انجام بدن.

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

و یادآوری: اگر اون روزی که باید، OpenAPI رو جدی گرفته باشین، و best practiceها و اصول طراحی رو رعایت کرده باشین، امروز خیلی راحت‌تر می‌تونین همون نرم‌افزار موجود رو با LLM توانمند کنید.
مطالبی مثل این یا این پیشتر در همین باب توی کانال نوشته‌ام که اگر دوست داشتید مطالعه کنید.

💬 تجربه و نظرتون درباره تولید MCP و استفاده توی نرم‌افزارهای LOB چیه؟

✈️ معرفی Microsoft Agent Framework برای پایتون و دات‌نت؛ توسعه ساده‌تر سیستم‌های ایجنتیک

مایکروسافت اخیرا فریم‌ورک کدباز Agent Framework رو معرفی کرد که عملا با ترکیب ایده‌ها و قابلیت‌هایی که پیشتر به صورت مجزا در Semantic Kernel و AutoGen ارائه کرده بود، کمک می‌کنه تا توسعه‌دهنده بتونه ربات‌ها یا ایجنت‌های مورد نظرش رو با انعطاف، مقیاس‌پذیری و پایداری مورد انتظارش بسازه و مدیریت کنه.

چرا MAF مهمه؟ چون پایان یک دوراهیه!
تا الان یه دو راهی مهم جلو پای توسعه‌دهنده‌ها بود:

۱: استفاده از Semantic Kernel: که پایداری و آمادگی لازم برای محیط‌های سازمانی و پروداکشن رو داره.

۲: استفاده از AutoGen: که برای نوآوری، آزمایش و ساخت ایجنت‌هایی که با هم گفتگو و تعامل دارن مناسبه (یعنی Multi-Agent Orchestration؛ همچنین توسعه و نگهداریش هم با Microsoft Research’s AI Frontiers Lab است که از اسمش مشخصه تکنولوژی‌های نوآورانه و در دست توسعه رو دنبال می‌کنه).

ولی حالا هر دو رو در توی یک پکیج واحد داریم.

✅ استانداردهای باز و تعامل‌پذیری
از پروتکل‌هایی مثل MCP، Agent2Agent، و طراحی OpenAPI-first پشتیبانی می‌کنه؛ و امکان اتصال آسون به ابزارها و سرویس‌های مختلف بدون وابستگی به یک اکوسیستم خاص رو فراهم می‌کنه.

✅ پل بین جنبه تحقیقاتی و جنبه تولید محصول
الگوریتم‌ها و الگوهای چند ایجنتی (orchestration) که فعلا آزمایشی هستن (مثل Magetnic یا Group Chat) حالا توی یه محیط عملیاتی قابل استفاده شدن. و این یعنی قابلیت بهره‌گیری از نوآوری‌های خیلی جدید توی پروژه‌های واقعی.

✅ قابلیت گسترش (Extensibility)
ماژول‌های حافظه قابل انتخاب هستن (مثل Redis، Pinecone، Qdrant)، کانکتورهای سازمانی می‌شه براشون نوشت یا از نمونه‌های آماده استفاده کرد، تعریف ایجنت به‌صورت YAML یا JSON. می‌شه خیلی سرراست اجزا رو بر اساس نیاز پروژه تا حد زیادی سفارشی کرد.

✅ آمادگی برای تولید (Production-Ready)
امکانات مورد نیاز محیط پروداکشن مثل observability، کنترل خطا، checkpointing، امنیت و فلوهای CI/CD رو داره و می‌تونه توی پروژه‌های واقعی با الزامات سازمانی به کار بره. و Human-in-the-Loop رو داره؛ یعنی قابلیت "تایید توسط انسان" برای عملیات‌های حساس؛ ایجنت قبل از اقدام منتظر تأیید می‌مونه.

شروع کار:
این فریم‌ورک کاملاً متن‌بازه و برای Python و NET. در دسترسه و مثال‌های خیلی خوبی هم برای شروع داره.

مخزن گیت‌هاب
داکیومنتیشن و راهنمای نصب

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

🐤 مطلب بعدی در مورد ۳ تا از بارزترین خصوصیات «بدترین برنامه‌نویس یا مهندس نرم‌افزار» خواهد بود!

به نظر شما به چه خصوصیاتی می‌شه گفت بدترین و افتضاح‌ترین؟ 🤔
کامنت کنید لطفا

حتی اگه نظرتونه که
- پنگوئن یا سیب یا پنجره دوست داشته|نداشته باشه 😅
- یا همه چیز رو آبجکت ببینه یا فانکشن ببینه!
- یا اینکه موقع کار، ماچا بخوره یا چایی‌شیرین!

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

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

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

۱. نداشتن صداقت و اخلاق حرفه‌ای
یادمون نره: بدترین برنامه‌نویس، کسی نیست که اشتباه می‌کنه؛ کسیه که اشتباهش رو پنهان می‌کنه.

✏️ مصداق‌ها:
- وانمود می‌کنه چیزی رو بلده ولی بلد نیست
- دروغ می‌گه که پیشرفت پروژه خوبه، در‌حالی‌که نیست (green shifting)
- عامدانه code review تقلبی می‌ده؛ فقط یه ابزار آنالیز خودکار باز کرده
- باگ‌ها رو قایم می‌کنه

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

۲. بی‌سؤالی، تعصب، توقف رشد
بزرگ‌ترین ریسک صنعت ما توقف یادگیریه؛ نه نابلدی!

🧠 کسی که سوال نداره، انگار دیگه دنبال بهتر شدن نیست.
🔒 کسی که تعصب داره (فقط فلان زبان، فقط فلان ابزار)، راه اصلاح رو به خودش بسته؛ شاید فکر کنه داره یاد می‌گیره؛ ولی داره مهارتش در یاد نگرفتن و توجیه نادانی‌اش رو تقویت می‌کنه.
🙈 کسی که اشتباه می‌کنه، ولی فکر می‌کنه تقصیر دنیاست، یعنی از دورِ یادگیری خارج شده.

فرق کسی که رو به جلو می‌ره و کسی که رو به زواله توی همین چیزاست.

۳. بی‌مالکیتی و انفعال

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

📡 نشونه‌ها:
- فقط همون کاری رو می‌کنه که دقیقاً بهش گفتن
- هیچ پیش‌فرضی رو به چالش نمی‌کشه (تفکر نقادانه نداره اساسا)
- تغییرات رو با مقاومت پاسخ می‌ده (فناوری، فرآیند، ابزار)
- کارش رو فقط "تا اینجا وظیفه‌م بود" می‌بینه

❓ چرا بده؟ چون تیم رو از یه گروه خلاق به یه کارخانه "دستور بگیر - خروجی بده" تبدیل می‌کنه. هیچ self-organization واقعی‌ای شکل نمی‌گیره. (توی پست نرم‌افزار و این روزهای ایران مفصل نوشتم)

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

یه آدم فاقد principle، بر اساس منفعت لحظه‌ای رفتار می‌کنه. یه بار پنهان می‌کنه، یه بار تقلب می‌کنه، یه بار مقاومت در برابر حرف صحیح، یه بار انفعاله... چون "راهنمای درونی" نداره.

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

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

💬 حالا نوبت شماست:
کامنت کنید؛ شاید کمک کنه فردا کمی بهتر از امروز باشیم 🌱

🧪 مفهوم و کاربرد API Mocking & Virtualization

خیلی از سردردها از نداشتن محیط اجرای مناسب نشأت می‌گیره؛ و خیلی از محیط خوب نداشتن‌ها از ترس پیچیده یا زمان‌بر بودنِ پیاده‌سازی. از طرف دیگه خیلی از integration ها با آسودگی و سرعت پیش نمی‌رن؛ چون API سیستمِ دیگه، شفاف نیست، یا محیط test نداره.

شنیدن جمله "منتظرم API شون آماده شه!" چیز غریب و نادری نیست! ولی واقعیت اینه که توی تیم‌های بالغ، منتظر نمی‌مونن، mock می‌کنن، یا قبل از توسعه API واقعی، اول API Spec رو می‌نویسن و در اختیار تیم‌های دیگه قرار می‌دن. اگر هم خیلی بالغ باشن که به جز API Spec ساز و کارkey management برای محیط‌های dev/test/stage/production رو هم محیا و ارائه می‌کنن.

بیاین در گام اول بیخیالِ میزان بلوغ تیم مقابل بشیم و خودمون رفتارهای بالغانه در تیم داشته باشیم:

مفهوم Mocking و Virtualization یعنی ساخت یه نسخه‌ی شبیه‌سازی‌شده از سرویس‌ها، قبل از اینکه backend واقعی در دسترس باشه. این کمک می‌کنه تا فرانت‌اند یا بکندی که API رو صدا می‌کنه، یا تست خودکار، و حتی هم‌زمانی توسعه بین تیم‌ها سریع‌تر بشه.

🚦 چرا مهمه؟
- کاهش وابستگی‌ها: تیم‌ها می‌تونن موازی کار کنن.
- بهبود تست و استیجینگ: سناریوهای خطا و پاسخ‌های خاص قابل بازسازی هستن.
- تکرارپذیری: تست‌ها بدون وابستگی به داده‌های زنده انجام می‌شن.
- پیشرفت بدون صبر: تا backend آماده بشه، frontend یا consumer هم رشد می‌کنه.

🧰 ابزارها

۱: ابزار Mockoon
رایگانه، دسکتاپ اپلیکیشن با رابط گرافیکی خوب است (نسخه مک و ویندوز داره) نسخه CLI هم داره.

۲: ابزار WireMock
یکی از بهترین ابزارها بود تا اینکه نسخه رایگان و پولی منتشر کرد! هنوز هم از نظر قابلیت‌ها ابزار خیلی خوبیه و مثلا rule-based mock، یا fault simulation رو خیلی خوب پشتیبانی می‌کنه.

۳: ابزار Microcks
هنوز به بلوغ WireMock نرسیده ولی ابزار خیلی خوبیه، یه UI وب ساده هم داره ولی هنوز کامل نیست (مثلا اینکه بتونید با UI انواع payloadها رو تعریف کنید یا chain بسازید رو نداره.

۴: ابزار (سرویس) Postman Mock Server
خب پست‌من دیگه برای همه شناخته شده است، ولی سرویس‌ها انترپرایزش نیاز به لایسنس داره چون نسخه رایگان همین mock server فقط ۳ کاربر رو پشتیبانی می‌کنه و محدودیت‌های زیادی داره.

چجوری payload رو محیا کنیم؟

۱. استخراج از مستندات موجود
اگر تیم backend مستندات OpenAPI/Swagger داره، راحت‌ترین راهه:

curl https://api.company.com/openapi.json -o spec.json
mockoon-cli import --data spec.json

حتی اگر schema دقیق نباشه، حداقل مسیرها و ساختار پایه آماده‌ست.

۲. Sniff کردن درخواست‌ها در زمان کار
اگه endpointها در محیط تست یا staging یا جایی که بتونین حداقل یک بار صداشون کنین در دسترس هستن؛ ولی مستندات ندارن:
از Fiddler, Charles, یا mitmproxy یا ابزارهای مشابه استفاده کنید برای کپی کردن و استخراج درخواست‌ها و پاسخ‌ها. بعد اون‌ها رو به JSON تبدیل و برای mock استفاده کنین.
(یه snapshot واقعی از تعامل سیستم‌هاست)

۳. تولید خودکار مدل از JSON
وقتی چند تا نمونه JSON داری ولی model نه:
ابزارهای زیادی از جمله خود IDE های رایج سریع JSON رو به تایپ تبدیل می‌کنن و این کمک می‌کنه تا schema بسازین و بر اساس اون mock بنویسین.

۴. ساخت چند سناریو
فقط happy path رو mock نکن! یعنی اینکه همه چیز خیلی خوب و باب طبع باشه کافی نیست؛ سناریوهای مختلف مثل انواع خطاهای کد 4xx یا 5xx یا کندی‌ها یا تام‌اوت یا... رو هم در mock‌هات بسازین.

جمع‌بندی
فراموش نکنین که Mocking فقط یه کار “موقتی” نیست، یه مهارت توسعه‌ی تیمیه برای استقلال، سرعت و کیفیت. وقتی payloadها درست جمع‌آوری بشن، Mocking تبدیل میشه به پلی بین توسعه، تست و واقعیت سیستم.

💬 اگر موضوعاتی مثل Governance and Standardization یا API-First یا API Monitoring براتون جذاب بود حتمن بگید تا کمی در موردشون گپ بزنیم.

💡♻️ مفهوم و کاربرد API-First Development

توسعه‌ی نرم‌افزار رو میشه مثل ساختمون، بدون نقشه و طرح معماری ساخت! نگید نمیشه؛ چون خیلیا می‌سازن و شده! 😂 تیم‌ها شروع می‌کنن به دیوارکشی (توسعه فرانت‌اند و بک‌اند)، ولی وقتی می‌رسن به اتصالات (Integration)، می‌بینن لوله‌کشی و سیم‌کشی (API) شبیه خونه‌ی پت‌ومت در اومده که از پریز برق آب میاد، لوله برق داره یا درِ پارکینگ به جای کوچه، به پذیرایی همسایه باز می‌شه؛ ساختمونه هم بین ساختمون‌های مجاورش شبیه جوجه کلاغ وسط صد تا جوجه اردکه!

رویکرد سال‌های دور (دلار هزار تومنی) این بود که API یه "محصول جانبی" برای ارتباط با سایر سیستم‌ها محسوب می‌شد؛ یعنی اول بک‌اند نوشته می‌شد، بعد یه قسمتی از اون رو به‌صورت API در معرض استفاده قرار می‌دادن. ریشه‌های این روش، عموما توی خاک سیستم‌های داده‌محور (Data-First) رشد می‌کرد؛ و کمتر "مصرف‌کننده‌محور" (Consumer-Centric) بود.
از طرفی زیاد دیدیم که تیم‌ها معطل هم برای آماده شدن API می‌مونن! یا اعصابشون سر تغییراتی که تیم مقابل روی APIهاش بعد از تفاهم اولیه داده خورد می‌شه! فرانت می‌گه "API تون درست کار نمی‌کنه"، بکند می‌گه "شما درست صداش نمی‌زنین"، و QA هم وسط این دعوا نرخ تعیین می‌کنه! یه بخش بزرگ از این سردردها از نداشتن یه زبون مشترک و قرارداد واضح بین تیم‌هاست.

از طرف دیگه، خیلی وقت‌ها می‌بینیم که بکند کدش رو نوشته، بعد مستندات رو می‌نویسه، بعد معلوم می‌شه مصرف‌کننده یه چیز دیگه می‌خواسته! حالا برگردیم و دوباره بنویسیم؟ یا همینجوری با کثیف‌کاری وصلش کنیم؟ شنیدن جمله "ما بعداً مستندات رو کامل می‌کنیم!" چیز غریب و نادری نیست! ولی واقعیت اینه که توی تیم‌های بالغ، اول API Spec رو می‌نویسن، بعد کد. اگر هم خیلی بالغ باشن، این Spec رو به عنوان یه قرارداد (Contract) بین تیم‌ها در نظر می‌گیرن و با ابزارهای خودکار، صحت پیاده‌سازی و انطباق عینی با طرح و نقشه‌ی اولیه رو کنترل می‌کنن.

🧭 مفهوم API-First یعنی چی؟
مفهوم API-First یعنی قبل از نوشتن کد، اول API رو طراحی کنیم (عموما توسط معمار این اتفاق می‌افته) یعنی بشینیم، فکر کنیم، بنویسیم که چه endpointهایی داریم، چه input/output هایی، چه status codeهایی، چه headerهایی... و همه‌ی این‌ها رو توی یه فایل OpenAPI Spec یا مشابهش ثبت کنیم.
این یعنی API ما از ابتدا مستند شده، با بیزنس، با پروداکت، با تیم‌های همکار می‌شه سناریوسازی و مرور کرد؛ تغییر داد و منطبقش کرد با نیاز واقعی؛ و بعد به کد! بعتر هم برای تغییرات، اول API Spec تغییر می‌کنه و بعد کد. چه اتفاق میوفته؟

- پیش‌بینی‌پذیری: همه می‌دونن قراره چه داده‌ای رد و بدل بشه.
- موازی‌سازی توسعه: تیم‌های مختلف می‌تونن هم‌زمان پیش برن؛ یکی Mock بسازه، یکی پیاده‌سازی واقعی.
- مستندسازی خودکار: چون API از اول با استانداردهایی مثل OpenAPI تعریف میشه، مستندات همیشه با واقعیت هم‌راستا می‌مونن.
- کیفیت بالاتر: چون قبل از کدنویسی، درباره طراحی و naming و consistency فکر می‌کنی.

اینطوری API Spec شما اولا توی سورس‌کنترل نگهداری می‌شه، همواره نسخه تست، استیج رو به صورت live در دسترسی داریم، API Owner هر دامنه مشخصه؛ هر کی عشقش کشید به هر شکلی یه API نمی‌نویسه، breaking changeها و کانفلیکت‌ها قبل از تغییر در API آشکار می‌شن و کلی مزیت دیگه که از حوصله پست تلگرامی خارجه.

رویکرد API-First فقط یک روش نیست، یک تغییر فرهنگی در سازمان، و تغییر استراتژیک در توسعه نرم‌افزاره. این رویکرد، API رو از یک "افزونه" به یک "محصول اصلی" تبدیل می‌کنه که برای تجربه توسعه‌دهنده، سرعت و کیفیت نهایی خیلی حیاتیه. وقتی API-First باشیم، سیستم‌های ما در برابر تغییرات مقاوم‌تر، انعطاف‌پذیرتر و آماده‌تر برای Integration Economy خواهند بود. یکی از شرکت‌هایی که بر اساس رویکرد API First کار می‌کنه زالاندو است که اتفاقا خیلی سخاوتمندانه، یا به توصیف دقیق‌تر، هوشمندانه، دستورالعمل و راهنمای خودش رو سال‌هاست به صورت کدباز منتشر کرده و به نظر من بسیار مستند پخته و خوبیه.

پیشنهاد می‌کنم API رو با ساده‌سازی‌هایی که go, fastAPI, flask, .NET یه موضوع خیلی ساده نبینیم، طراحی و نگهداری بد، مصیبت‌های خودش رو در بلندمدت نشون می‌ده، موقع اینتگریشن‌های بعدی نشون می‌ده و اون وقته که متوجه می‌شیم ای کاش از ابتدا مشورت گرفته بودیم و صرف «کار کردن» API به خودمون نمره قبولی نمی‌دادیم! حتمن این روش پرهزینه‌تر و نیازمند زمان‌ آماده‌سازی و توسعه بیشتریه، ولی عملا سرمایه‌گذاری زمان رشد و اینتگریشن خواهد بود.

Zalando RESTful API and Event Guidelines

💡📡 اهمیت اندازه‌گیری بازگشت سرمایه (ROI) در Platform Engineering

چرا اندازه‌گیری ROI حیاتیه؟
طی چند سال اخیر Platform Engineering نه فقط به عنوان یک شغل یا تیم جدید اضافه شده، بلکه دیگه یک موضوع «اختیاری» نیست؛ یک قابلیت استراتژیک برای بقای رقابتی سازمان‌هاست که به صورت بومی یا خدمت باید داشته باشن. اما خیلی از مدیرهای تصمیم‌گیر در حوزه فنی و بودجه، هنوز توی توجیه دقیق برای سرمایه‌گذاری‌ روی مهندسی پلتفرم مشکل دارن. دلیل؟ نداشتن ماشین‌حسابی که بتونه هزینه‌های پنهان و بهبودها رو به شکل علمی و مستند منعکس کنه. یا به بیانی، عدم وجود یک مدل ROI پایه‌ای (Foundational ROI) که هم شفاف باشه، هم قابل اندازه‌گیری، و هم مستقل از فروشندگان ابزار و سرویس.

این مدل، برخلاف مدل‌های «تخصیصی» (Attributional) یا «محصولی» (Product ROI)، روی بهبودهای بنیادی در بهره‌وری تیم مهندسی تمرکز داره؛ نه فقط صرفه‌جویی در هزینه، بلکه افزایش سرعت تحویل، کیفیت کد، و نوآوری.

مثال واقعی:
شرکتی با ۱۰۰ مهندس، سالانه ۳۰٪ از ظرفیت تیم رو در کارهای دستی (manual toil) از دست می‌ده. با یک پلتفرم مهندسی مناسب، این عدد به ۱۵٪ کاهش پیدا می‌کنه »» یعنی معادل ۱۵ مهندس تمام‌وقت اضافی بدون استخدام جدید!

چهار لایه ROI در مهندسی پلتفرم

۱. پایه‌ای (Foundational)
با تمرکز روی بهره‌وری بنیادی تیم
مثل کاهش manual toil، استانداردسازی محیط

۲. محصولی (Product)
متمرکز روی اثرگذاری روی سرعت تحویل محصول
مثل کاهش MTTR، افزایش deployment frequency

۳. تخصیصی (Attributional)
با هدف نسبت دادن بهبود به ابزار خاص
مثل استفاده از ابزاری که ۲۰٪ سرعت یا حجم کار CI/CD رو بهبود بده

۴. استراتژیک (Strategic)
برای هم‌راستایی با اهداف کسب‌وکار
مثل تسریع ورود به بازار، کاهش ریسک

نکته:
مدل Foundational ROI باید اولین لایه باشد. بدون اون، مدل‌های بالاتر (مثل تخصیصی) دقت و اعتبار ندارن.

ورودی‌های اصلی مدل ROI پایه‌ای
برای محاسبه دقیق، باید ۷ ورودی کلیدی رو جمع‌آوری کرد:

۱: اندازه تیم: تعداد مهندس‌هایی که به واسطه مهندسی پلتفرم تجربه بهتری خواهند داشت.

۲. میانگین حقوق: حقوق سالانه پایه به ازای هر مهندس، ضرب در ۱.۳ برای در نظر گرفتن ۳۰٪ مزایا و هزینه‌های سربار. این ساده‌ترین معیار برای اضافه کردنه.

۳. ساعات کار روتین هفتگی: میانگین ساعات هفتگی به ازای هر مهندس که صرف وظایف دستی و تکراری می‌شه. این یک معیار تخمینی برای شروعه و می‌تونه در طول زمان بهتر شه.

۴. استفاده فعلی از هوش مصنوعی: فاکتور افزایش بهره‌وری پایه (هیچ = ۱.۰، پایه = ۱.۱۵، پیشرفته = ۱.۳۵، متخصص = ۱.۵). (به نظرم METR study منبع خوبیه؛ اینکه چقدر بهینگی ایجاد کرده که مثلا ۱ یعنی هیچی (یه نفر همون‌قدر کار می‌کنه که می‌کرد)، و ۱.۵ یعنی پنجاه درصد بهبود عملکرد، یا به عبارت ساده‌تر، با یک نفر معادل ۱.۵ نفر خروجی می‌گیرید که این طبق مطالعه METR عالی‌ترین حالته)

۵. آمادگی تیم برای هوش مصنوعی: ضریب ریسک (پایین، متوسط، بالا، متخصص) برای هزینه پیاده‌سازی. یک ضریب ریسک که نشون‌دهنده آمادگی تیم‌های شما برای پذیرش و بهره‌برداری مؤثر از هوش مصنوعیه.

۶. تناوب استقرار: چرخه انتشار ماهانه، هفتگی یا روزانه.بر اساس مدل مطالعاتی DORA، این یک شاخص از منظر بلوغ و کاراییه. تناوب استقرار بالاتر؛ با حلقه‌های بازخورد سریع‌تر، و در نهایت چابکی کسب‌وکار بالاتر همبستگی داره.

۷. صنعت: ضریب نظارتی (عمومی = ۱.۰، مالی = ۱.۳، مراقبت‌های بهداشتی = ۱.۴، استارتاپ = ۰.۸). بر اساس تجربیات، یک ضریب نظارتی برای در نظر گرفتن هزینه‌های سربار complience بر اساس حوزه فعالیت محاسبه می‌شه. صنایع عمومی دارای وزن خنثی هستند (۱.۰)، در حالی که خدمات مالی (۱.۳) و مراقبت‌های بهداشتی (۱.۴) بار سنگین‌تر complience و governcance رو همراه دارن.

۸. سطح بدهی فنی: ضریب تلاش مضاعف برای دست و پنجه نرم‌ کردن با بدهی فنی (پایین = ۰.۹، متوسط = ۱.۰، بالا = ۱.۳، بسیار بالا = ۱.۶). یک ضریب تلاش مرتبط با وضعیت کد و معماری شماست. نسبت بدهی پایین (۰.۹) یعنی تغییرات می‌تونن نسبتاً راحت انجام بشن، در حالی که نسبت بدهی بسیار بالا (۱.۶) نشون می‌ده تقریباً هر بهبودی با هزینه و پیچیدگی نامتناسبی همراهه (میزان بدبختی و فلاکت همراه با اعمال تغییرات).


💬 این یک مقدمه خیلی خیلی خلاصه بود برای سرنخ دادن. اگر به عنوان تک‌لید یا مدیرمهندسی یا ب صورت کلی به این مبحث علاقه‌دارید، حتمن بگید تا در ادامه این بحث، بریم سراغ نحوه محاسبه، خروجی‌هایی که چنین مدل‌هایی ارائه می‌دن و مسئولیت‌ها و استراتژی‌های یک سازمان نرم‌افزاری برای این موضوعات ⚙️

تا دقایق دیگه، رویداد ۳ روزه NET Conf 2025. شروع می‌شه و دات‌نت ۱۰ به صورت رسمی ارائه می‌شه.
مشاهده زنده رویداد
https://www.dotnetconf.net

💬 اگر دوست داشتید در مورد قابلیت‌های مورد انتظار یا حتی مورد نفرتتون 😁 بگید!

💡 پرسش روز جمعه: API Federation چیه؟ و تفاوتش با API Gateway چیه؟

🪙سوال امتیازی: با Service Mesh جمله بسازید و در یک پاراگراف بگویید تابستان گذشته API Composition در مقابل API Aggregation چه فرقی داشتند؟

💬 مطلب بعدی: پرسش روز جمعه باشه: ⚙️ یا در مورد سوال سوال امتیازی: 🤓

💡🪐 مفهوم و کاربرد API Federation

سال‌هاست که معماری سیستم‌ها به سمت ریزشدن (fragmentation) رفته و
تعداد زیادی سرویس‌ها، APIها، دیتابیس‌ها و کانال‌های ارتباطی که هر کدوم یک گوشه‌ای از سیستم زنده‌اند و کار می‌کنند.

این آزادی و انعطاف‌پذیری خیلی خوبه… اما روی طرف دیگر سکه، تجربه مصرف API رو تبدیل کرده به چیزی شبیه یک هزارتوی پیچیده و گاها کابوس!

توی چنین شرایطی API Federation وارد می‌شه؛ یک الگوی معماری نسبتا مدرن که کمک می‌کنه تا مصرف‌کننده فقط یک نقطه ورودی ببینه؛ اما پشت صحنه هرچقدر دوست داریم API و سرویس مستقل داشته باشیم، بدون اینکه مجبور شیم یک monster gateway بسازیم (تفاوتش رو با API Gateway خواهم گفت) و بدون اینکه همه‌چیز رو hard-code کنیم، merge کنیم، rewrite کنیم یا به هم بچسبونیم.

به زبان ساده؛ API Federation یعنی یک لایه هوشمند که چندین API مستقل رو به شکل یک API واحد و یکپارچه در اختیار کاربر قرار می‌ده.

👁 پرسش مهم: تفاوت API Gateway و API Federation

تفاوت این دو تا رو خیلی ساده مرور کنیم، چون اکثر تیم‌ها اشتباه می‌کنن:

توصیف API Gateway:
نقش اصلی API Gateway عملا یک reverse proxy است که خاصه‌ی API هاست و درخواست‌ها رو route می‌کنه، و توانایی داره تا احراز هویت و محدودیت روی درخواست‌ها و logging رو اعمال کنه. عملا دیدگاهش متمرکز بر مدیریت ترافیک و امنیته. و معمولاً نمی‌دونه محتوای درخواست چیه، فقط اون رو به سمت درست هدایت می‌کنه
مثل Kong، Nginx، AWS API Gateway

توصیف API Federation:
نقش اصلی API Federation نقطه‌ی ورودی متمرکز برای یکپارچه‌سازی منطقی چندین API مستقل به صورت یک API واحد است. تمرکزش هم روی تجربه کاربری و یکپارچگی داده است تا صرفا هدایت ترافیک. و عملا می‌دونه schema و معنای داده‌ها چیه، می‌تونه داده‌ها رو از چند منبع aggregate کنه و به شکل یکپارچه برگردونه (مثلا اطلاعات هویتی مشتری رو از یه API بگیره، وضعیت حسابش رو از یه جا و وضعیت سفارشاتش رو از جای دیگه، و نهایتا در یک ساختار مشخص بچینه و برگردونه). معماریش داخلی‌اش هم عموما distributed/composable است و هر API می‌تونه در دامین خودش باقی بمونه و federation فقط اون‌ها را به هم نشون بده.

مثال: GraphQL Federation (Apollo), KrakenD Federation Mode, API Mesh (Solo.io), WunderGraph

به عبارت دیگه Gateway مثل یک دربون سختگیره که می‌گه "بیا اینجا، برو اونجا"، اما Federation مثل یک مترجم و هماهنگ کننده است که می‌گه "من می‌فهمم چی می‌خوای، از هر جایی که لازمه می‌گیرم و یکجا به زبون خوت بهت برمی‌گردونم".

🍴 کاربردهای عملی API Federation

مایکروسرویس‌های بزرگ
وقتی +۵۰ سرویس دارید، federation به جای یه گیت‌وی سنگین، یک schema یکپارچه می‌سازه.

جلوگیری از API Explosion
وقتی +۲۰ تا تیم داریم، معمولاً +۲۰ نوع API هم ساخته می‌شه؛ مصرف‌کننده هم نمی‌دونه باید به کدومش و چجوری وصل بشه (البته این آسیب آبشخور دیگه‌ای داره که جدای از این بحثه) اینجا می‌شه همه رو توی یک نقطه خلاصه کرد.

ادغام با سیستم‌های قدیمی (Legacy Integration)
وقتی انواع APIها از SOAP، REST، gRPC دارید، federation اون‌ها رو پشت یه facade یکسان پنهان می‌کنه. اینجوری با حداقل کردن couplingدیگه نیازمند تغییر در API اصلی نیستیم.

تیم‌های مستقل (Team Autonomy)
هر تیم API خودش رو deploy می‌کنه و federation به صورت داینامیک اون‌ها رو کشف و ترکیب می‌کنه (مثل service mesh + API).

محیط‌های ترکیبی (Multi-cloud / Hybrid Environments)
مثل وقتی که API توی AWS، Azure و on-prem دارین، اون‌وقت یک endpoint واحد خواهید داشت.


💬 این مقدمه کوتاهی در مورد API Federation بود، مبحث مفصلیه که پرداختن بهش از حوصله تلگرام خارجه، امیدوارم اگر براتون جذاب بوده باشه، پیگیرش باشین، اگر هم سوالی در موردش بود حتمن همینجا طرح کنین تا در موردش صحبت کنیم 😊

📕 پیشنهاد کتاب: Crafting Engineering Strategy

کمتر از ۲ هفته دیگه (۲۵ نوامبر ۲۰۲۵)، کتاب

Crafting Engineering Strategy:
How Thoughtful Decisions Solve Complex Problems


یا: طراحی استراتژی مهندسی: چگونه تصمیم‌گیری‌های سنجیده مسائل پیچیده رو حل می‌کنن؛ منتشر می‌شه. توی معرفی اولیه اومده:
خیلی از مهندس‌ها تصور می‌کنن سازمانشون استراتژی مهندسی نداره! در حالی که در واقع، اغلبشون دارن؛ ولی ممکنه این حس ناشی از ناکارآمدی اسراتژی‌ها باشه. نویسنده، یعنی ویل لارسون (نویسنده کتاب‌هایی مثل Elegant Puzzle یا Staff Engineer) یک راهنمای کاربردی، و در عین حال غنی از مثال‌های واقعی، برای مسیریابی در پیچیدگی‌های فنی، و همچنین پیچیدگی‌های سازمانی از طریق «استراتژی ساختاریافته و هدفمند» ارائه می‌ده.

این کتاب که برای مهندس‌های ارشد، رهبران مهندسی، و معمارها نوشته شده. مثال‌های واقعی از شرکت‌هایی مثل استرایپ، اوبر، و کَلم استخراج ارائه میده. چارچوب پیشنهادی نویسنده، برای شکل‌دهی تصمیم‌گیری‌های حیاتی در مورد مهاجرت سیستم‌ها، منسوخ کردن APIها، سرمایه‌گذاری‌های پلتفرم و موارد مشابه کاربرد داره. کتاب، در طول مسیر، یاد قراره تا یاد بده برنامه‌ریزی فنی رو با ارتباطات، حاکمیت، و تفکر سیستمی تقویت کنید. چه در حال شکل‌دهی به مسیر تیمتون باشید و چه رهبری یک ابتکار در سطح شرکت رو به عهده داشته باشین، «طراحی استراتژی مهندسی» به شما کمک می‌کنه تصمیم‌های سنجیده‌ای بگیرید که پایدار باشن.

دلیل معرفی این کتاب اول موضوعش بود، دوم اینکه من چند کتاب از این نویسنده رو خوندم و سبک نوشتار و مسیر پرداختن به موضعش رو دوست دارم (این یک نظر شخصیه و شاید برای شما صدق نکنه)

نسخه کاغذی با قیمت 36.92€ عرضه خواهد شد.
در مورد نویسنده

🧮 به نهضت NoEstimates# بپیوندیم؟ هنوز Story Point برای تخمین اندازه تسک‌ها لازمه؟

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

مرگِ یک آیین قدیمی یا تکامل طبیعی؟

سوال تکراری همیشگی بعد از اینکه یک تیم یا شرکت تخمین Story Point رو کنار می‌گذاره؛ اینه: «خب جایگزینش چیه؟»
ولی عملا سوال بهتر اینه که اصلاً نیاز واقعی‌مون به Story Point چی بوده؟ و چرا به وجود اومده؟
این بحث، بحثِ خیلی از تیم‌های نوپا و بالغ دنیا طی سال‌های اخیر بوده.
عملا Story Point در سال‌های ابتدایی پیدایش مفهوم agile در توسعه نرم‌افزار، ناجی خیلی از تیم‌ها بود. یعنی وقتی تیم‌ها از تخمین زمانی (مثل person-hour یا person-day) خسته شده بودن و می‌دیدن این اعداد عموما دروغ می‌گن؛ Story Point با نگاه «بی‌خیال ساعت شید، فقط بگید این کار نسبت به اون یکی چقدر بزرگ‌تره» به وجود اومد. و واقعاً هم کمک کرد. تیم‌ها بهتر پیش‌بینی می‌کردن، Velocity داشتن، ظرفیت اسپرینت مشخص بود.

اما این سال‌ها بعضی از تیم‌ها Story Point رو کنار گذاشتن، مهم‌ترین دلایلی که من دیدم، اینا بوده:

۱. طی گذر زمان؛ Story Point تبدیل به دروغ شد!
همون چیزی که قرار بود جلوی دروغ رو بگیره، خودش تبدیل به دروغ شد.
چرا؟ چون مدیر محصول یا PO می‌گفت: «این فیچر باید تو همین اسپرینت جا بشه، پس ۸ نزنید، ۵ بزنید!»
یا توسعه‌دهنده از ترس فشار بعدی، همیشه عدد بزرگ‌تر می‌زد.
نتیجه؟ Velocity غیرواقعی، تخمین غیرواقعی، بی‌اعتمادی کامل. من از حدودای ۲۰۱۲-۲۰۱۳ یادم میاد که نهضت NoEstimates# با این گفتمان راه افتاده که تخمین، هزینه داره و اغلب دقتش اون‌قدری نیست که ارزش هزینه‌ش رو داشته باشه!

۲. تیم‌ها دیگه نیازی به «واحد خیالی» ندارن
وقتی تیم کوچیکه، در اثر تجربه و هم‌نشینی گاهی دیگه نیازی نمی‌بینن بگن «این ۵ پوینته، اون ۸ پوینته».
فقط می‌گن: «این کار حدود ۲-۳ روزه، اون یکی یه هفته».
و این تخمین «تقریبی و رنج‌دار» گاهی دقیق‌تر از Story Point در میاد!
از طرفی، تیم‌های خوب به جای اندازه تسک، روی شکل دادن (Shaping) فیچرها تمرکز می‌کنند و تخمین ریز نمی‌زنن.

۳. کار رو باید انجام داد چه یه روز چه ده روز!
بعضی تیم‌ها ماهیت تسک‌هاشون «ضرورتِ محصوله»، یعنی قابل حذف یا جایگزینی نیست، محصول هم باید تولید شه. لذا برای مدیر و شرکت مهمه که زودتر برسه، ولی اگر چند وقت دیرتر هم بشه، راهی جز پذیرش نداره. اینجاست که تیم می‌گه خب so what؟ تخمین بزنم که چی بشه؟ من که اول و آخر باید این کار رو انجام بدم!

۴. کارهای روتین، یا قابل پیش‌بینی هستن
وقتی کارها به طور نسبی زمان مشابهی برای اجرا نیاز دارن، یا توی چند دسته‌ی قابل پیش‌بینی قرار می‌گیرن، تکرار مکررات باعث می‌شه تیم بیخیال تخمین بشه و می‌دونه چه کاری حدودا طی چی زمانی انجام می‌شه. اینجا دیگه به جای story point گاها T-Shirt sizing هم جواب می‌ده (S, M, L, XL)

پس کِی و کجا Story Point هنوز مفیده؟

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

- تیم‌های جدید که هنوز Flow پایداری ندارن

- وقتی تیم‌ها توزیع‌شده (distributed) هستن و ارتباط لحظه‌ای کمه

یادمون نره که Agile یعنی انعطاف. اگر ابزاری به درد تیم شما نمی‌خورد، کنارش بگذارید. اینکه process templateهای متنوعی وجود داره، از مدل‌های ساده مثل kanban تا scrum و agile و حتی مدل‌های خیلی سخت‌گیر و دقیقی مثل CMMI هم هست، یعنی «نسخه واحد برای همه تیم‌ها و محصولات وجود نداره».

سوال این نیست که "Story Point خوبه یا بد؟"
سوال اینه: "برای تیم ما، در مرحله فعلی، چه چیزی بهترین کمک رو می‌کنه؟"

بعضی‌ها هم که story point رو گذاشتن کنار از سر بلد نبودنشون بوده! نه از سر مناسب نبودنش! و اساسا باید عارضه رو در خودشون پیدا می‌کردن یا اینکه تا زمان بلوغ، می‌رفتن سراغ متد دیگه‌ای که مبتنی بر SP نباشه، نه اینکه متد رو نگه دارن و SP رو از دلش بکشن بیرون.

این موضوع خیلی مفصله ولی امیدوارم در حد سرنخ دادن کمک کرده باشه... 😊

⌛ اصول نرم‌افزارهای انترپرایز یا Enterprise Software Principles
💡 بررسی از دریچه‌ی آسیب‌شناسی شکست‌ها

بخش صفر: مقدمه و آسیب‌شناسی

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

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

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

۱: فرق نرم‌افزار انترپرایز با یک استارتاپ چیه (۱)؟
استارتاپ‌ها رو به تغییرات سریع در بازه زمان کوتاه می‌شناسیم. و اگر یک استارتاپ طی ۵ سال ۲ نسل از نرم‌افزار خودش رو توسعه بده، چیز دور از ذهنی نیست، در حالیکه یک انترپرایز شاید طی یک دهه، فقط یک نسل از یک سیستم رو تجربه کنه و به صورت گاهی مرتب، گاهی دیربه‌دیر، تغییراتی رو روی همون نسل اعمال می‌کنه، پس یک گروه از از تفاوت‌ها رو می‌شه به «عمر مفید نرم‌افزار» و «سرعت و تناوب تغییرات» نسبت داد.
همچنین تیم و ساختار فنی و محصول، گاهی برای سال‌ها ثابت می‌مونه، گاهی بعد از مدت‌ها ثبات، به یکباره تغییرات اساسی می‌کنه (ادغام/تجزیه تیم، دامین، یا حتی سازمان، برون‌سپاری یا حتی آف‌شور توسعه و نگهداری یا...)

پس ماهیت اصلی نرم‌افزارهای انترپرایز، عمر طولانی، پیچیدگی سازمانی و هزینه‌ی نگهداشت است؛ و نه صرفاً تکنولوژی.

💡حالا با همین چند پیش‌فرض، به نظرتون می‌شه بدون «ساختار و سازمان‌دهی تولید» سراغ تولید رفت؟
بله می‌شه رفت! ولی نتیجه‌اش می‌شه صدها «سامانه» با باگ‌های تموم‌نشدنی، فاصله داشتن با زمانه و نیازهای روز در حوزه‌های سازمانی، بانکی و دانشگاهی و... سازمان‌هایی که فاقد ساختار مشخص برای توسعه، مالکیت یا نگهداری نرم‌افزار هستند؛ چه به عنوان توسعه‌دهنده، چه بهره‌بردار، چه مالک محصول؛ در عمل محصولاتی با ویژگی‌های زیر تولید می‌کنند:

- نرخ Technical debt بالا (هزینه نگهداری ۳-۵ برابر توسعه اولیه)
- فقدان documentation قابل استفاده
- وابستگی به افراد خاص (bus factor پایین)
- دشواری یا عدم امکان‌پذیری scale یا refactor
- زمان onboarding طولانی، در عین تسلط کم دولوپر جدید روی سیستم
- نارضایتی و ناکارآمدی رو به رشد طی حتی زمان کوتاه

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

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

ادامه (مولفه‌های موثر بر سازماندهی و توسعه) در بخش ۲

⌛ اصول نرم‌افزارهای انترپرایز یا Enterprise Software Principles
1️⃣ بخش یک: ساختار و سازمان‌دهی تولید (ابزار، فرایند، فرهنگ)

- ساختار و سازمان‌دهی تولید چیه؟

ساختار و سازماندهی تولید نرم‌افزار رو من ذیل ۳ مولفه اصلی بیان می‌کنم. یعنی فرهنگ، فرایند، و ابزار:

۱: ابزار:
ابزار را شاید بشه ساده‌ترین مولفه از بین ۳ عامل دونست (هرچند خیلی‌ها همین رو هم به درستی ندارن). ابزار یعنی هر سرویس سخت‌افزاری و نرم‌افزاری که به شما کمک می‌کنه تا چرخه عمر نرم‌افزار رو بهتر مدیریت و تجربه کنید. مثلا:

پلتفرم مناسب برای مستندسازی که جستجوی خوب، نسخه‌بندی، امکانات امنیتی، کامپلاینس، پشتیبانی از نمودار (به‌صورت کد، نه صرفاً تصویر)، و کوئری پویا از سورس‌کد یا سیستم مدیریت پروژه رو فراهم کنه.

یا سرور/سرویس Version Control و CI/CD درست و حسابی (منظورم TFS 2012 اونم به صورت شلخته نیست)

یا ابزارهای مدرن نظارت (منظورم observability است نه monitoring)

یا سرویس Secret Manager (منظورم KeePass نیست طبیعتا)

یا...

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

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

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

فرق سازمان با جامعه اینه که شما در جامعه وقت، زیاد داری! بین رنسانس تا انقلاب صنعتی چند قرن زمان برد، ولی یک سازمان چند قرن یا چند سال زمان نداره! حساب دو دو تا چهار تا است؛ دیر بجنبی زیان‌ده و ورشکسته می‌شی. حتی اگر دولتی باشی، به خودت میای و می‌بینی ۲,۲۴۵,۶۲۳ نفر کارمند داری که راهی جز تعدیل و جایگزینی درصد بسیار بالایی از اونها نداری... و دلیل اصلیش: «فرهنگ نیروی انسانی» است

همون‌طور که در ادبیات Enterprise Architecture اومده "Culture Ensures Sustainability" فرهنگ، پایداری رو تضمین می‌کنه. حالا فرهنگ مهندسی در اینجا به معنی ترکیب سه عامل است:

۱. شایستگی فنی (Technical Competence):
تسلط بر معماری، الگوهای طراحی، و...

۲. تعهد به فرایند (Process Commitment):
پایبندی به code review، testing، و documentation

۳. مهارت در ابزار (Tool Proficiency):
استفاده مؤثر از CI/CD، و observability tools

بعضی گزارش‌های McKinsey می‌گن حدود ۷۰٪ پروژه‌های تحول دیجیتال، به دلایل فرهنگی و سازمانی شکست می‌خورن. تجربه شخصی من در ایران این عدد رو حتی بالاتر، و حدود۹۰٪ نشون می‌ده.

تغییر فرهنگ، کندترین و حیاتی‌ترین بخش transformation است و نیازمند ۳-۵ سال زمان، تعهد مدیریت ارشد، و گاهی جایگزینی تدریجی ۲۰-۴۰٪ نیروی انسانی است.

به فرض، اگر فردا تحریم برداشته بشه، فلان شرکتِ استارتاپی دیروز که امروز نسبتا بالغ شده، شاید خیلی زود بتونه از سرویس‌های متنوع کلادی بهره بگیره و پرسنلش کاراتر عمل کنن. ولی فلان سازمان دولتی تا سال‌ها درگیر انواع مقاومت‌ها و مباحثات زمان‌بر درباره تغییرات هرچند ساده است. پس ابزار، مولفه‌ی ساده‌تر، فرایند مولفه‌ی دشوار، و فرهنگ رو می‌تونیم مولفه‌ی حیاتی و بسیار بسیار دشوار برشمریم!

چکیده:

- Tools Provide Acceleration, Not Discipline
- Processes Create Predictability
- Culture Ensures Sustainability

اگر از این مطلب استقبال بشه، در ادامه، موضوعات زیر رو هر کدوم ذیل ۳ مولفه‌ای که در این مقدمه عرض کردم در یک نرم‌افزار انترپرایز بررسی می‌کنم:

بخش دوم: الزامات توسعه و نگهداری محصول
بخش سوم: الزامات زیرساخت
بخش چهارم: الزامات امنیت
بخش پنجم: الزامات طراحی و نگهداشت محصول

💬 فیدبک شما حتمن در جهت‌دهی ادامه مطالب کمک می‌کنه 😊