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

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

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

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

✏️ مصداق‌ها:
- وانمود می‌کنه چیزی رو بلده ولی بلد نیست
- دروغ می‌گه که پیشرفت پروژه خوبه، در‌حالی‌که نیست (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

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

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

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

💡🌱 چرا بیشتر برنامه‌های توسعه شکست می‌خورند؟ مشکل موقعیت‌یابی اشتباه!

وقتی آقای الف، (یک دولوپر از نظر مهارت فنی، جونیور، ولی با ۱۲ سال تجربه) برنامه یادگیری سال جدیدش رو برای من فرستاد تا نظرم رو بگم؛ لیستش از الگوهای طراحی مایکروسرویس تا هوش‌مصنوعی تا... رو در برداشت. ازش پرسیدم: «آخرین باری که یک Pull Request یا Merge Request دادی که به بخش محدودی از نرم‌افزار بهینگی کارایی یا ساختاری اضافه کرده باشه (و نه فقط خواسته‌ی تسک) و کامنت‌های بیسیک هم از دید دولوپرهای ارشد نگرفته باشه کِی بوده؟ پاسخ صریح و مطمئنی نداشت! این دقیقاً جاییه که اکثر برنامه‌های توسعه، چه فردی، تیمی یا سازمانی، شکست می‌خورن: ما به جای شناخت دقیق موقعیت فعلی، مستقیم سراغ مقصد می‌ریم. مشکل: ما نمی‌دانیم واقعاً کجا ایستاده‌ایم.

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

1️⃣ سناریو ۱: دولوپر جونیور، آقای الف
موقعیت واقعی: کدهاش هنوز فراتر از خواسته‌ها نیست، متدهاش بنا به دانش کم، و نه ضرورت و اقتضای شرایط، بیش از ۸۰ خط می‌شن، استفاده بجا از الگوهای طراحی رو نمی‌دونه.

موقعیت ادراک‌شده: آمادگی برای یادگیری معماری‌های پیچیده، فریب عدد سال‌های تجربه، فریب آشنایی با عنوان مفاهیم پیشرفته

نتیجه: سه ماه وقت صرف یادگیری DDD می‌کنه، اما کدهایش همون if/else تودرتوی قبلی با اسامی fancy است. API چت‌جی‌پی‌تی صدا می‌زنه، توهم دانش GenAI داره.

هزینه: ۳۶۰ ساعت وقت + frustration + از دست دادن فرصت یادگیری Clean Code، کسب توهم بیشتر که مثل یک دیوار محکم جلو یادگیری صحیح و به‌جا رو ازش می‌گیره!

2️⃣ سناریو ۲: تیم توسعه (یک استارتاپ ۱۵ نفره)

موقعیت واقعی: Code coverage زیر ۳۰٪، هیچ integration test ندارن، deployment تقریبا دستی است، تیم آلوده به وایب‌کدینگ مخفی شده.

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

نتیجه: شش ماه صرف split کردن monolith شد، اما debugging چندبرابر شد چون observability ندارند، روز به روز درک کدها سخت‌تر شده، هر اصلاح با وایب‌کدینگ موجب خطا و مشکل در جای دیگه می‌شه.

هزینه: ۶ ماه × ۱۵ نفر × میانگین حقوق = حداقل ۴.۵ میلیارد تومن + velocity کمتر شده

3️⃣ سناریو ۳: مدیر محصول تازه‌کار

موقعیت واقعی: هنوز نمی‌دونه چطوری یک user story خوب بنویسه یا backlog prioritize کنه

موقعیت ادراک‌شده: آماده طراحی استراتژی سه‌ساله محصول

نتیجه: یک سند ۴۰ صفحه‌ای strategy که هیچ‌وقت اجرا نمی‌شه، چون execution از پایه مشکل داره، مدیران فریفته‌ی محتوای غیرواقعی سند شدن

هزینه: اعتماد تیم + فرصت تمرکز روی مهارت‌های بنیادی

فریمورک سه‌مرحله‌ای برای موقعیت‌یابی صحیح

مرحله ۱: Assessment (ارزیابی بی‌رحمانه سطح فعلی) برای موقعیت‌یابی صحیح، باید از خود سؤالات سختی بپرسید که پاسخ‌شان قابل اندازه‌گیری باشه
و اگر نمی‌تونید موقعیت فعلی را با یک عدد یا fact مشخص کنید، هنوز موقعیت‌یابی نکرده‌اید.

مرحله ۲: Gap Analysis (محاسبه فاصله واقعی) حالا که موقعیت فعلی رو می‌دونید، باید بفهمید دقیقاً یک سطح بالاتر کجاست. نه دو سطح، نه سه سطح؛ فقط یک سطح. این مفهوم را Vygotsky، روان‌شناس روس، دهه ۱۹۳۰ ذیل Zone of Proximal Development (ZPD) تعریف کرده (اگر دوست داشتید بیشتر بخونید). و نشون می‌ده یادگیری فقط در یک باند باریک اتفاق می‌افته:

خیلی آسون » Comfort Zone (یادگیری صفر)
کمی چالش‌برانگیز » Learning Zone (یادگیری حداکثر) ← ZPD همینجاست
خیلی سخت » Panic Zone (یادگیری صفر)

مرحله ۳: Action Planning (طراحی گام اول قابل اجرا) بعد از شناخت موقعیت و تعیین گام بعدی، باید یک برنامه خیلی کوچیک طراحی کنید که در عمل اجرا شدنی باشه.

آمار: ۶۸٪ از مهاجرت‌ها به microservices در سازمان‌هایی که بلوغ کافی نداشتن، منجر به کاهش productivity شد (منبع: ThoughtWorks Technology Radar 2019)
یا ۷۵٪ از برنامه‌های یادگیری سال نو تا پایان فوریه رها می‌شن! (منبع: University of Scranton research) دلیل اصلی: اهداف خیلی بالاتر از سطح فعلی

خلاصه اینکه: فقط یک سؤال از خودتان بپرسید: «اگر بخوام امروز به کسی ثابت کنم دقیقا در چه سطحی هستم، چه عددی یا fact مشخصی می‌تونم نشون بدم؟ و این عدد با چه معیار و سنگ محکی سنجیده شده؟»

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

💡 استفاده از GenAI در توسعه نرم‌افزار، خوب، بد، زشت!

چند سالیه که سهم عبارت «AI» لابلای جملات، تیتر اخبار، صحبت‌های یومیه‌ی عوام تا متخصصین، شهروند تا دولتمرد، مصرف‌کننده تا صنعت‌گر روز به روز بیشتر شده. ترم‌هایی مثل Vibe Coding یا AI-Driven Development یا AI Slop به دایره‌ی واژگانمون اضافه شدن. حالا این وسط یه عده سودهای کوتاه‌مدت می‌برن، مثل پکیج‌فروش‌ها، سرویس‌هایی که چند تا API رو صدا می‌کنن و یه سرویس مثلا هوشمند ارائه می‌کنن؛ و برخی هم بیزنس‌های بر پایه‌ی این تحول ایجاد کردن، مثل سازنده‌های مدل‌های پایه، سرویس‌های کاربردی مدیریت AI مثل Agent Manager یا Prompt Engineering Platform و… یا اینکه AI رو مثل یک ابزار دیدن و کاربری اون رو «صحیح و اصولی» یاد گرفتن و مرتبا به‌روز می‌شن تا مثل دورانی که اکثریت با محدودیت‌های نرم‌افزارهای دسکتاپ دست‌وپنجه نرم می‌کردن و عده‌ای خیلی زود و به موقع، توسعه مبتنی بر وب رو جایگزین کردن، بتونن از مواهب AI به نفع بهره‌وری، خلاقیت، و توسعه پایدار بهره ببرن.
این مطلب رو در چند بخش می‌نویسم، با توجه به فضای جامعه توسعه نرم‌افزار، متن رو خیلی مطالعه‌-محور می‌نویسم تا مقاومت کمتری نسبت به تحلیل شخصی داشته باشه؛ اول به «بد»، و در ادامه به «زشت» و نهایتا به «خوب» می‌پردازم:

✅ هوش مصنوعی مولد (GenAI) می‌تونه بهره‌وری رو تا ۵۵٪ افزایش بده، اما اغلب، کدهای ناسازگار و شکننده تولید می‌کنه که نگهداری اون‌ها دشواره. (sloanreview.mit.edu)
✅ توی تیم‌های نوپا، GenAI ضعف‌های فنی رو پوشش می‌دهد اما بدهی فنی ایجاد می‌کنه و حتی تغییرات کوچک‌تغییرات رو پرریسک می‌کنه. (sloanreview.mit.edu)
✅ در شرکت‌های بالغ «با شیوه‌های استاندارد»، GenAI خطاها رو کاهش می‌ده و نوآوری رو تا ۶۴٪ بهبود می‌ده، هرچند نیاز به بررسی انسانی داره. (mckinsey.com)
✅ مطالعات نشون می‌ده ۴۸٪ کدهای GenAI دارای آسیب‌پذیری‌های امنیتی هستن، که البته این یه موضوع بحث‌برانگیزه. (secondtalent.com)

💩 فصل اول: The Bad: بدهی فنی‌ای که نمی‌بینیم

- کد چرخشی (Code Churn): سیگنال خطر: تحقیقات GitClear روی ۲۱۱ میلیون خط کد تغییریافته بین سال‌های ۲۰۲۰ تا ۲۰۲۴ نشون می‌ده که Code Churn (درصد کدی که کمتر از دو هفته پس از نوشته شدن اصلاح یا حذف می‌شه) در سال ۲۰۲۴ دو برابر سال ۲۰۲۱ شده. این یعنی کدی که AI تولید می‌کنه، اغلب ناقص یا اشتباهه و نیاز به بازنگری سریع داره.

- کپی‌پیست به جای معماری: در سال ۲۰۲۴، GitClear افزایش ۸ برابری در بلوک‌های کد تکراری (۵ خط یا بیشتر) رو ثبت کرده (یعنی ۱۰ برابر بیشتر از دو سال پیشش). مشکل اینجاست که AI به جای refactor کردن و استفاده مجدد از کد موجود، ترجیح می‌ده کد جدید بنویسه. نتیجه؟ نقض اصل (DRY (Don't Repeat Yourself و کدبیسی که مدیریتش کابوسه.
در سال ۲۰۲۴، ۴۶٪ تغییرات کد، خطوط جدید بودند و کد کپی‌پیست شده، بیش از کد جابجا شده (moved) بوده (یعنی کمتر refactoring شده و بیشتر به صورت بی‌رویه کد اضافه شده).

- افزایش باگ و کاهش پایداری: مطالعه شرکت Uplevel که توسعه‌دهنده‌های با دسترسی به Copilot رو بررسی کرده، نشون می‌ده این دولوپرها به طور معناداری نرخ باگ بالاتری تولید کردن، در حالی که بهره‌وری کلی‌شون ثابت مونده. گزارش DORA 2024 گوگل هم تأیید می‌کنه: ۲۵٪ افزایش در استفاده از AI منجر به بهبود در code review و مستندات می‌شه، اما ۷.۲٪ کاهش در پایداری تحویل (delivery stability) ایجاد می‌کنه. همچنین گزارش Harness 2025 نشون داد اکثر توسعه‌دهندگان زمان بیشتری صرف debugging کد تولیدشده توسط AI و رفع آسیب‌پذیری‌های امنیتی می‌کنند.


💬 قبل از پردختن به بخش دوم، یعنی «زشت» و بخش سوم، یعنی «خوب» نظرتون رو در مورد استفاده خوب بگید و بنویسید که آیا این آسیب‌ها رو قبول دارین؟

💡💡 قسمت دوم: استفاده از GenAI در توسعه نرم‌افزار، خوب، بد، زشت!

🥴 فصل دوم: The Ugly: تبعات طولانی‌مدت

اگر "بد" نمایانگر اصطکاک عملیاتیه، "زشت" نمایانگر ریسک سیستمیه. داده‌های سال‌های ۲۰۲۴ و ۲۰۲۵ به بحرانی قریب‌الوقوع در قابلیت نگهداری و امنیت نرم‌افزار اشاره می‌کنن...

جنبه‌ی «زشت» ماجرا اینه که نتیجه‌ی نهایی استفاده از هوش مصنوعی مولد به‌شدت وابسته به بلوغ فنی و انضباط تیمه. اگر تیمی فرهنگ کدنویسی سالم، معیارهای کیفی و فرایندهای بازبینی روشن نداشته باشه، برای استفاده از GenAI دستورالعمل «فکر شده» و متناسب با نیازها و استعداد تیم نداشته باشه؛ AI می‌تونه هرج‌ومرج ایجاد کنه یا هرج‌ومرج موجود رو تشدید کنه. توی برخی نظرسنجی‌ها دیده شده که کارکنان احساس کردن بهره‌وری‌شون با وجود هوش مصنوعی کاهش یافته!

بدهی فنی که قابل پرداخت نیست
پروفسور Armando Solar-Lezama استاد دانشگاه MIT می‌گه: "AI مثل یه کارت اعتباری جدیده که به ما اجازه می‌ده بدهی فنی رو به روش‌هایی انباشته کنیم که هرگز قبلاً نتونسته بودیم."
مطالعه دانشگاه Carnegie Mellon روی ۸۰۷ ریپو GitHub که بین ژانویه ۲۰۲۴ تا مارچ ۲۰۲۵ که از Cursor استفاده کرده بودن، نشون می‌ده که با وجود بهبودهای مدل‌های AI (Sonnet، GPT و غیره)، الگوی کاهش کیفیت کد همچنان ادامه داره. حتی با ارتقای ابزارها، کیفیت کد مسیر خودش رو به سمت افول طی می‌کنه! دلایلی مثل زمان صرف زیاد برای آزمون‌وخطا با ابزار یا رفع خطاهای ناشی از اون رو می‌شه در نظر گرفت؛ و تفاوت نتایج بین شرکت‌های مختلف (از افزایش کارامدی تا معضلات عمیق) نشون می‌ده که صرف خریداری یا فعال‌سازی ابزار یا سرویس هوش‌مصنوعی تضمینی برای موفقیت نیست.

- نابودی دانش تیمی: باز هم مطالعات نشون می‌دن در ۱۶.۸٪ از چت‌های ChatGPT، کد تولید شده به صورت دقیق (با تغییرات جزئی) توی پروژه‌های GitHub استفاده شدن. مشکل اینجاست: وقتی توسعه‌دهنده‌ها کد AI رو بدون درک عمیق copy می‌کنن، expertise model توی تیم توسعه آسیب می‌بینه و Truck Factor (تعداد اعضای تیم که از دست دادنشون پروژه را می‌تونه نابود کنه، گاهی هم bus factor گفته می‌شه) بدتر می‌شه.

- معضل Context Collapse در آینده: اگه کدهایی که مدل‌های آینده از روی اون‌ها train می‌شن، پیچیده‌تر و غیرقابل نگهداری‌تر بشه، خطر واقعی اینه که مدل‌های جدیدتر این روندها رو به صورت نمایی تقویت و تشدید می‌کنن و کد بدتری تولید خواهند کرد؛ دلیلش هم اینه که از روی کدهای شلوغ و بی‌کیفیتی آموزش دیده‌اند.

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

- پارادوکس بهره‌وری مهندسی: ترکیب "خوب" (سرعت) و "زشت" (ریزش/کیفیت) منجر به شکل‌گیری "پارادوکس بهره‌وری مهندسی" شده. سازمان‌ها شاهد افزایش چشمگیر خروجی (پول‌ریکوئست‌ها، ویژگی‌ها) هستن، اما همزمان کاهش پایداری و افزایش هزینه‌های نگهداری رو تجربه می‌کنن. گزارش سال ۲۰۲۵ DORA از گوگل نشون داد که افزایش ۹۰ درصدی در پذیرش هوش مصنوعی با افزایش ۹ درصدی نرخ باگ و افزایش ۹۱ درصدی زمان بازبینی کد همبستگی داره (بدتر از گزارش DORA در سال ۲۰۲۴ که پیش‌تر در بخش افزایش باگ و کاهش پایداری قسمت اول اشاره کردم). زمان صرفه‌جویی شده در تایپ کردن کد، عملاً به مرحله بازبینی و دیباگ منتقل شده؛ با این تفاوت که هزینه این مرحله بالاتره، چون خوندن کد تولید شده سخت‌تر از نوشتنشه.

- انباشت بدهی فنی: انباشت کدهای ضعیف ساختاری، که با پیچیدگی بالا (Cyclomatic Complexity) و تکرار زیاد مشخص می‌شن؛ بدهی‌ای ایجاد می‌کنه که باید با بهره پرداخت بشه. Forrester پیش‌بینی می‌کنه که سال ۲۰۲۶، ۷۵٪ از شرکت‌ها به دلیل تولید کد کنترل‌نشد‌ه‌ی هوش مصنوعی، با بدهی فنی "متوسط تا شدید" مواجه خواهند شد.

💬 قسمت بعدی از بخش دارک ماجرا خارج خواهیم شد و به بخش «خوب 👌» خواهم پرداخت ولی نظر و تجربه شما رو دوست دارم بدونم...

💡 قسمت سوم: استفاده از GenAI در توسعه نرم‌افزار، خوب، بد، زشت!

🏆 فصل سوم: The Good: موفقیت در سازمان‌های بالغ

شنیدید که مارگزیده از ریسمون سیاه و سفید می‌ترسه؟ در حقیقت من هم اینقدر طی این سال‌ها شاهد جَوزَدگی اهالی نرم‌افزار بوده‌ام که سعی می‌کنم قبل از محاسن یک تکنولوژی مستعد به حباب و جَو و هیجان، مخاطرات و الزامات و موارد کاربردش رو بگم! طی دو قسمت اول، با توجه به اقبال و وابستگی زیادی که توی اکوسیستم نسب به GenAI پدید اومده، سعی کردم تا مبتنی بر بررسی‌ها و با حداقل رسوندن نظر شخصی، جنبه‌های بد و زشت رو اشاره کنم و سرنخ‌هایی برایی مطالعه عمیق‌تر به اشتراک بگذارم. حالا توی قسمت سوم، بریم سراغ جنبه‌ی خوب استفاده از GenAI در فرایند توسعه!

- کارایی در سازمان‌های بالغ و دارای دیسیپلین: توی شرکت‌ها و تیم‌هایی که اصول مهندسی نرم‌افزار و فرایندهای بازبینی کد، به‌خوبی درک و نهادینه شده باشه، هوش مصنوعی مولد می‌تونه بدون افت کیفیت به بهبود عملکرد کمک کنه. به عنوان مثال، eBay با یه آزمایش A/B روی ۳۰۰ توسعه‌دهنده بهبود ۱۷٪ روی زمان مرج شدن کدها و بهبود ۱۲درصدی Lead Time for Change روی گروهی که از Copilot استفاده می‌کردن دیده! علاوه بر این کیفیت کد (بر اساس آنالیز Sonar) بین دو گروه آزمایشی و کنترل تفاوت معناداری نداشته. (نتیجه زمینه‌سازی استفاده از AI و بعد، به خدمت گرفتنش)

- فرصتی برای بزرگ‌تر و پخته‌تر بودن: اگر به «شکل اصولی» استفاده بشه، آموزش داده بشه، و نه اینکه تجربی و آزمون و خطایی باشه؛ گام‌به‌گام و با برنامه، مرحله به مرحله به فرایندها بیاد؛ شما فرصت یادگیری مداوم، بسترسازی برای بهبودها و تحلیل‌های بعدی از طریق تیکت‌ها و مستندات بهتر، تست‌نویسی بهینه و یادگیری رو در تیمتون فراهم کردید. مثلا به جیرا وصلش کنید تا اگر تیکت دقیق و اصولی نوشتید، چک کنه توی PR/MR آیا همه Acceptance Criteria لحاظ شده یا چیزی از قلم افتاده! مثلا مستندسازی فرایندها روی از کدهای قدیمی برای بازنویسی سیستم تسریع کنید، یا مثلا با ابزارهای غیر GenAI ترکیب کنید تا پیش‌گیرانه مانع از ورود الگوهای تکراری و پیچیدگی اشتباه شید (لطفا اگر علاقه داشتید مطالب مرتبط با code metricها رو در کانال مطالعه کنید)

- ذره‌بینی برای واضح‌تر دیدن: تنبلی و رخوت و بی‌انگیزگی چیزی نیست که با GenAI از بین بره؛ شاید فردی که زمینه‌اش رو داره و عاشق «حل‌ِمسئله» نیست، کم‌کم تنبلی نهان یا غیرفعالش رو نشون بده، ولی می‌شه از یک منظر به سرویس‌های هوش مصنوعی به مثابه ذره‌بینی پرداخت که می‌تونن کمک کنن خصوصیات منفی افراد آشکارتر بشه؛ آیا این تبعات منفی داره؟ بله حتمن داره؛ ولی یادمون نره ریشه‌ی خصوصیات کسی که حاضره ۳ ساعت با کوپایلوت و کرسر ور بره ولی روی حل یه مسئله فکر نکنه، قدیمی‌تر از دوران پیدایش GenAI است و این آدم ۳ سال پیش، بدون خوندن توضیحات مردم، کدها رو از StackOverflow کپی‌/پیست می‌کرده. این آدم، در گذشته‌ی دورتر توانایی‌هایی رو کسب نکرده که حالا دیره! و من شخصا این رو یه مزیت GenAI میدونم.
یه نکته مهم و خوشبینانه اینه که ۶۸٪ سازمان‌ها طبق گزارش World Quality Report 2024 به طور فعال از GenAI استفاده می‌کنن یا roadmap دارن براش و «برخی» موفق هستن؛ این عدد توی گزارشات ۲۰۲۵ رشد معنی‌داری کرده؛

- نکته مهم: کلی آمار توی فیش‌ها و نوت‌هایی که حین بررسی جمع می‌کنم، برای این بخش در نظر گرفتم ولی به ذهنم رسید با این موضوع جایگزین کنم که کلی عدد و آمار وسوسه‌کننده از بهبود اعتماد به نفس تیم، افزایش بهره‌وری، لذت برنامه‌نویسی و... توسط مراکز معتبر منتشر شده و خواهد شد؛ دقت کنید که خیلی از این‌ها درسته، ولی مثلا مایکروسافت در مورد برنامه‌نویس‌هاش اعلام کرده، ولی نکته مستتر اینه که کلی تیم به صورت تخصصی در شرکت‌هایی مثل مایکروسافت، گوگل، اوبر و تسلا و... به صورت تخصصی دارن زیرساخت AI و GenAI برای تیم‌های توسعه فراهم می‌کنن، پس راه‌به‌خطا نرفتن اون تیم‌ها کمتر محتمل است تا شرکتی که توسعه‌دهنده‌هاش خودجوش دارن با یه سری ابزار وَر می‌رن یا به صورت غیرساختاریافته ازشون استفاده می‌کنن؛ بدون هیچ guideline درون‌سازمانی، agent داخلی و نظارت platform engineering. یا برخی از این آمارها با حمایت سرویس‌دهنده‌هایی تهیه شده که نتیجه بایاس است به سمت ترغیب شما به خرید copilot یا هر سرویس دیگه‌ایه؛ درست مثل تبلیغ بستنی است که طبیعتا کسی از چربی و شکر و عوارضش رنج نمیکشه و همه با لذت بستنی رو می‌خورن!

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

چه دسامبر؛ چه اسفند؛ چه آخر پاییز؛ باید بالاخره جوجه‌ها رو شمارد...

فیدبک، خصوصا از نوع سازنده‌اش خیلی خیلی از چیزی که فکر می‌کنیم مهم‌تره. فیدبک، یه مهارت، یه فرهنگ و یه ابزار مهم برای ایجاد و «حفظ» یک فضای سازنده توی تیم و سازمانه. نه فقط یه ابزار «بالا به پایین» با رویکرد هویج و چماق!
فیدبک باید از هر سطحی به هر سطحی از تیم و سازمان جاری و ساری باشه. و فیدبک سالانه هم در کنار فیدبک‌های دوره‌ایِ طی سال، لازم و مهمه...
با توجه به نزدیک‌شدن به آخر پاییز و آخر سال میلادی، شاید بد نباشه مرور کنیم فیدبک خوب، چجوریه؛ متدهای ساختاریافته فیدبک مثل SBI (Situation-Behavior-Impact) یا EEC (Example-Effect-Change/Continue) چی هستن و چرا باید «تبیین، آموزش، و پیاده‌سازی» بشن توی تیم/سازمان...


💬 مطلب بعدی‌مون این باشه؟

♻️ فیدبک، راه‌حل بهبود و توسعه مداوم...
فیدبک، یک فرهنگه، که برای ایجادش باید تلاش کرد، ممارست داشت و رهاش نکرد. باید مستندش کرد، آموزشش دارد، به عنوان ارزش و روش نهادینه‌اش کرد و از روز آنبوردینگ روش تکیه کرد؛ تا بتونه در میان/بلند مدت میوه بده.

🥕🪓 فیدبک: فراتر از هویج و چماق

خیلی از ما فیدبک رو با «نقد کردن» یا «تشویق کردن» اشتباه می‌گیریم. فکر می‌کنیم ابزاریه که الزاما مدیر از موضوع بالا نسبت به کارمند استفاده می‌کنه تا بتونه با تشویق و تنبیه یا ملقمه‌ای از هر دو وادارش کنه تا رفتار و کارآمدی دلخواهش رو دنبال کنه! (رویکرد هویج و چماق).

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

چرا فیدبک‌های "حسی" کار نمی‌کنند؟
همه ما جمله‌هایی مثل «کارت عالی بود» یا «باید بیشتر دقت کنی» را شنیدیم. این‌ها فیدبک نیستن؛ این‌ها نظرات گُنگ هستند! فیدبک مبهم نه تنها باعث بهبود یا اصلاح رفتارها نمی‌شه، بلکه می‌تونه باعث سوءتفاهم و گارد گرفتن طرف مقابل بشه. برای حل این مشکل، ما به مدل‌های ساختاریافته نیاز داریم تا بتونیم قبل از ارائه بازخورد محتوا رو بریزیم توی یک قالب استاندارد، ببینیم آیا قالب رو پر می‌کنه؟ یا باید ازش کم و زیاد کنیم!

۱. مدل SBI: شفافیت به جای قضاوت
مدل SBI (مخفف Situation-Behavior-Impact) یکی از بهترین روش‌ها برای حذف قضاوت شخصی و تمرکز روی واقعیت‌هاست.

- موقعیت (Situation): دقیقاً بگید این عمل کِی و کجا رخ داده. (عمل یا اتفاق می‌تونه مثبت یا منفی باشه)
- رفتار (Behavior): دقیقاً چه رفتاری دیدید؟ (بدون استفاده از صفاتی مثل تنبل، بی‌دقت، عالی، دقیق و...).
- اثر (Impact): آن رفتار چه تاثیری روی شما، تیم یا پروژه گذاشته.

❌ مثال غلط: «تو توی جلسات خیلی بی‌نظمی.»
✅ مثال با SBI: «امروز صبح در جلسه بررسی اسپرینت (موقعیت)، وقتی وسط صحبت جعفر پریدی و صدات رو بالا بردی (رفتار)، باعث شد بقیه اعضای تیم ساکت بشن و دیگه ایده‌هاشون رو مطرح نکنن (اثر).»

۲. مدل EEC: چرخه یادگیری و اصلاح
مدل EEC (مخفف Example-Effect-Change/Continue) هم برای بازخورد اصلاحی (منفی) و هم برای بازخورد تقویتی (مثبت) خوبه.

- مثال (Example): یک مثال مشخص از رفتار رو بیان کنید.
- اثر (Effect): نتیجه رو شفاف بیان کنین.
- تغییر/ادامه (Change/Continue): اگر بازخورد منفیه، چه تغییری انتظار دارید؟ اگر مثبته، به ادامه دادنش تشویق کنید.

مثال برای ادامه (Continue): «گزارشی که دیروز فرستادی (مثال)، خیلی داده‌های دقیقی داشت و باعث شد مشتری قانع بشه (اثر). لطفاً همین ساختار رو برای گزارش‌های بعدی هم حفظ کن (ادامه).»

⚠️خطر » سوگیری‌های ناخودآگاه در کمین ما هستن! (Unconscious Biases)
یه فیدبک رو می‌شه ریخت توی قالب SBI یا EEC یا هر مدل دیگه‌ای. ولی این کافیه؟ نه. باید حواسمون باشه که فیدبک دادن می‌تونه به سوگیری‌های ناخودآکاه ما یا Unconscious Biases آلوده بشه و از مسیر سازنده بودن خارج! ۳ دشمن نامرئی فیدبک سازنده:

۱. سوگیری شباهت (Similarity Bias)
ما ناخودآگاه با کسانی که شبیه به ما فکر می‌کنن، لباس می‌پوشن یا پیش‌زمینه مشابهی دارن، راحت‌تریم. توی فیدبک، این باعث می‌شه با افراد «شبیه به خودمون» مهربون‌تر باشیم و خطاهاشون را نادیده بگیریم، در حالی که نسبت به بقیه سخت‌گیرتریم. این سمِ تنوع و رشد تیمه.

۲. سوگیری تأییدی (Confirmation Bias)
اگر من باور داشته باشم که «فلانی کارمند بی‌دقتیه»، مغز من فقط لحظاتی رو ثبت می‌کنه که اون اشتباه کرده و تمام کارهای دقیقش رو نادیده می‌گیره تا باور قبلی‌ام تأیید بشه! فیدبک بر اساس این سوگیری، فقط تکرار مکرراتِ ذهن فیدبک‌دهنده است؛ نه واقعیتِ عملکرد فیدبک‌گیرنده.

۳. سوگیریِ رویدادهای اخیر (Recency Bias)
این آفتِ ارزیابی‌های پایان سال (Year-end reviews) است. ممکنه همکار شما ۱۰ ماه عالی کار کرده باشه، اما چون دو هفته پیش یک اشتباه کرده، تمام ارزیابی سالانه‌اش تحت‌الشعاع اون خطای اخیر قرار می‌گیره. یا برعکس؛ یک سال کم‌کاری کرده ولی با یک ماه تلاشِ دقیقه نودی، همه‌چیز پوشیده می‌شه!

❓ پادزهر سوگیری چیه؟ ساختار به جای احساس
یکی از دلایل پیدایش مدل‌هایی مثل SBI یا EEC همینه، که جلو سوگیری‌ها گرفته بشه. باید با داده صحبت کنیم، پس باید داده‌ها رو ثبت کنیم و مغزمون رو مجبور کنیم از قضاوت حسی فاصله بگیره و به فکت‌ها نگاه کنه.

💬 میشه ساعت‌ها در مورد شیوه‌های بیان فیدبک، اشتباهات رایج، عکس‌العمل در قبال سوءبرداشت‌ها و شرایط پیچیده‌ی تقابلی صحبت کرد. خوشحال می‌شم تجربیات و نظراتتون رو بشنوم 😊

✅ چک‌لیست پیشنهادی جامع پایان سال برای تیم‌های نرم‌افزاری

🧐 بخش اول: مرور و ارزیابی سال گذشته (Retrospective)

1️⃣ محصول و deliverableها:
- مقایسه اهداف تعیین‌شده با نتایج واقعی (roadmap vs. delivery)
- بررسی کیفیت تحویل‌ها: باگ‌های پرتکرار، incident های مهم، downtime ها
- تحلیل feature هایی که موفق بودن در مقایسه با اون‌هایی که استفاده نشدن (impact کمی داشتند)
- مرور feedback تیم، کاربرها و مشتریان در طول سال

2️⃣بدهی فنی (Technical Debt)
- فهرست بدهی‌های حل‌شده: چه چیزهایی refactor شد؟ کدوم dependency های قدیمی آپدیت شدن؟
- بدهی‌های باقی‌مونده: اولویت‌بندی بر اساس تأثیر و ریسک
بدهی‌های جدید: چرا اضافه شدند؟ آیا قابل اجتناب بودن؟
- تخمین زمان لازم برای پرداخت بدهی‌های critical در Q1 سال پیش‌ِ‌رو

3️⃣عملکرد تیم
- بررسی velocity تیم در sprint ها/iteration ها
- تحلیل bottleneck ها و موانع اصلی
- شناسایی skill gap های تیم
- مرور میزان رضایت و engagement تیم (اگر نظرسنجی کردید)

4️⃣ زیرساخت و DevOps
- مرور incident های سال و زمان میانگین بازیابی (MTTR)
- بررسی هزینه‌های cloud/infrastructure، آیا optimization لازمه؟
- وضعیت CI/CD pipeline: سرعت build، deploy، test coverage
- مرور امنیت: آسیب‌پذیری‌های شناسایی‌شده و رفع‌شده


📡 بخش دوم: تحلیل ترندها و آینده‌نگری

رصد ترندهای ۲۰۲۶
- مطالعه حداقل ۳ منبع معتبر مثل Gartner, Deloitte, ThoughtWorks Tech Radar, Pluralsight Tech Trends
- بررسی roadmap پروژه‌های کدباز مرتبط با stack شما
- شناسایی ۳-۵ ترند مرتبط با حوزه کاری شما
- ارزیابی: کدوم ترندها به اهداف کسب‌وکار/محصول شما کمک می‌کنن؟

بررسی رقبا و صنعت
- رقبای اصلی شما چه feature های جدیدی اضافه کردن؟
- از مسیر آینده استک‌تکنولوژی، لایبری‌ها و... مورد استفاده‌تون آگاهید؟
- چه تکنولوژی‌های جدیدی توی صنعت شما در حال adoption هستن؟
- استانداردها و regulation های جدید رو در شناسایی کردید؟


⌛ بخش سوم: برنامه‌ریزی سال جدید

اهداف استراتژیک (Strategic Goals)
- تعریف ۳-۵ هدف کلیدی سال (SMART goals)
- اولویت‌بندی: چه چیزی باید بشود و چه چیزی خوبه که بشود
- تخصیص بودجه و منابع به اهداف
- تعریف معیارهای موفقیت برای هر هدف (KPI ها)

تبیین Roadmap فنی
- تمرکز اصلی شما در Q1 چیه؟ (معمولاً stability + پرداخت بدهی فنی)
- تمرکز آتی یعنی Q2-Q4: اهداف کلیدی و milestone ها
- لیست تکنولوژی‌هایی که می‌خواهید adopt کنین (با justification)
- برنامه آموزش تیم برای مهارت‌های جدید

مدیریت ریسک
- شناسایی ریسک‌های فنی و کسب‌وکاری سال آینده
- برای هر ریسک: احتمال، تأثیر، و راهکار کاهش
- برنامه backup برای سناریوهای بدبینانه (team churn، budget cut و حوادث غیرمترقبه یا شرایط دشوارتر اقتصادی و...)


♻️ بخش چهارم: چرخه بهبود مستمر

بازنگری سه‌ماهه (Quarterly Reviews)

- پایان Q1 (اسفند ۱۴۰۴):
آیا اهداف Q1 محقق شد؟
آیا roadmap نیاز به تعدیل داره؟


- پایان Q2 (تیر ۱۴۰۵):
بررسی نیمه‌سال
نیاز pivot یا persevere؟

- پایان Q3 (مهر ۱۴۰۵):
آمادگی برای push نهایی سال


- پایان Q4 (دی ۱۴۰۵):
چرخه جدید retrospective

متریک‌های کلیدی برای tracking
- ایجاد dashboard های پایش پیشرفت
- تعیین cadence بررسی متریک‌ها (هفتگی/ماهانه)
- تعیین مسئول جمع‌آوری و گزارش هر متریک

💡 بخش پنجم: بهبود فرآیندها

فرآیند توسعه
- آیا Agile/Scrum/CMMI فعلی کارآمده؟ نیاز به تغییر داره؟
- وضعیت code review: کیفیت، سرعت، یادگیری تیم
- وضعیت testing strategy: manual و automated، test coverage مطلوبه؟

ارتباطات و مستندات
- وضعیت documentation: آیا به‌روزه؟ آیا accessible است؟ ساختار مناسب داره؟
- کیفیت ارتباط بین تیم‌ها (dev, product, design, QA)
- برنامه برای بهبود knowledge sharing

بررسی Developer Experience
- آیا onboarding برای اعضای جدید ساده است؟
- زمان setup محیط توسعه؟
- ابزارهای مورد نیاز تیم فراهمه؟

🎯 بخش ششم: Action Items

فوری (تا پایان دی‌ماه)
- برگزاری جلسه retrospective تیم
- نهایی کردن roadmap Q1
- به‌روزرسانی dependency های critical

کوتاه‌مدت (Q1 سال جدید)
- اجرای برنامه پرداخت بدهی فنی
- شروع training برای تکنولوژی‌های جدید
- پیاده‌سازی بهبودهای فرآیندی

بلندمدت (سال ۲۰۲۶)
- رصد و tracking پیشرفت نسبت به اهداف سالانه
- بازنگری و تطبیق با تغییرات بازار/صنعت

📌 مهم:

✔️ این چک‌لیست یک پیشنهاده، ولی چک‌لیست خودتون رو با تیمتون مرور کنید؛ مالکیت جمعی بسازید
✔️ واقع‌بین باشید؛ overcommitment دشمن اصلی موفقیته (سنگ بزرگ نشونه‌ی نزدنه)
✔️ مستند کنید، یک سال دیگه به این نوت‌ها نیاز خواهید داشت
✔️ انعطاف‌پذیر باشید، برنامه وحی منزل نیست، اما بدون برنامه هم قابل قبول نیست