💡💡 قسمت دوم: استفاده از 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 دشمن اصلی موفقیته (سنگ بزرگ نشونه‌ی نزدنه)
✔️ مستند کنید، یک سال دیگه به این نوت‌ها نیاز خواهید داشت
✔️ انعطاف‌پذیر باشید، برنامه وحی منزل نیست، اما بدون برنامه هم قابل قبول نیست

در مورد این نظرسنجی، من گزینه‌هایی رو انتخاب کردم که به نحوی به هم مرتبط باشن و انتخاب «بزرگ‌ترین» چالش رو کمی به سمت بیان نحوه‌ی تحلیل مسئولیت‌ها ببره 😅

چهار عامل بین گزینه‌ها بود که ساده‌شده‌اش می‌شه:
- کارشناس
- مدیر
- حاکم
- محیط

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

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

💡 ولی رکن چهارم که توی توصیف بالا از هر سه عامل متأثره چی؟

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

قضاوت من با ۱۱۹ نفری که بزرگ‌ترین چالش رو خارج از کارشناس دیدن، همسو است؛ ولی با یک تفاوت مهم!

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

بخشی از بدنه کارشناسی » وارد لایه مدیریتی می‌شن » بخشی از همین مدیران وارد بخش حاکمیتی می‌شن و محیط رو می‌سازن!
حالا سوال اینه: چرا کارشناسان ضعیف به مدیران ضعیف تبدیل می‌شن؟

اینجا دو تا سناریو داریم:

سناریو ۱، خوش‌بینانه: کارشناس قوی وارد مدیریت می‌شه ولی سیستم اون رو می‌بلعه. فشارهای سازمانی، فقدان حمایت، سیاست‌ورزی، و ساختارهای فاسد مجبورش می‌کنن یا سازش کنه یا بره. در این صورت مشکل ۱۰۰٪ ساختاری‌ست و ۹۴٪ نظرسنجی کاملاً درست.

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

نکته اساسی اینه که وقتی می‌گم کارشناس چالشه، منظورم سرزنش کردن قربانی نیست. کارشناس هم قربانی این سیستمه، هم بدون اراده و آگاهی، بازتولیدکننده اون!

چرا؟
۱. سیستم آموزشی فاجعه است » دانشجو با مهارت‌های تاریخ‌گذشته یا ناکارآمد فارغ‌التحصیل می‌شه
۲. فرصت یادگیری واقعی وجود نداره » شرکت‌ها روی رشد مهارت‌‌ها سرمایه‌گذاری نمی‌کنن
۳. شایسته‌سالاری نیست » کارشناس خوب پاداش نمی‌بینه، پس انگیزه از بین می‌ره
۴. فقر اقتصادی » کارشناس مجبوره توی حالت تلاش برای بقا کار کنه، نه حالت رشد

حالا این کارشناس که توسط سیستم شکل گرفته، وارد لایه مدیریتی می‌شه، نه به خاطر شایستگی، بلکه به خاطر seniority (قِدمت)، رابطه، خلأ لایه بالاتر، یا صرفاً گذشت زمان. و چون پیش‌نیازهای مدیریتی رو نداره (تحلیل، تیم‌سازی، استراتژی)، مدیر ضعیفی می‌شه که سیستم رو بازتولید می‌کنه.

پس چرا می‌گم کارشناس چالش بزرگه؟

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

چرا؟
۱. منتظر نشستن برای اصلاح حاکمیت = بی‌نهایت
اگر بخواهیم حاکمیت عوض بشه تا محیط بهتر بشه تا مدیران بهتر بشن تا کارشناسان رشد کنن، این ۵۰ سال طول می‌کشه (اگه اتفاق بیفته).

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

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

- باید یادگیری جمعی ایجاد شه
- و peer accountability شکل بگیره (اشتراک دانش و تجربه واقعی)
- استانداردهای خودِ ما بالا بره (قبول نکردن شرایط زیر خط قرمز)
- بهترین‌ها صدای خودشون رو بلند کنن و الگو باشن

این کافیه؟ قطعاً نه.
بدون این، چیز دیگه‌ای کافیه؟ باز هم نه.

در متن سوال نظرسنجی نوشتم بزرگ‌ترین چالش، و نه مقصرترین؛ چون چالش یعنی سخت‌ترین مانع برای عبور به آینده بهتر؛ حتی اگر ریشه اون در جای دیگه‌ای باشه.

نظر و تحلیل شما چیه؟

⚙️ آمار و میزان محبوبیت مطالب کانال + دسترسی به ویدیو و پادکست

⭐️ محبوب‌ترین مطالب کانال تا امروز
⬇️ خروجی وب مطالب کانال
(تولید شده با استفاده از TeleScribe)

📱ویدیوهای کانال یوتیوب
🎙 پادکست

⌛ در باب اهمیت Traceability

گاهی فکر می‌کنیم «سیستم ما که دو تا سرویس بیشتر نیست» یا «فعلا مونولیت هستیم، پس traceability فعلا اهمیتی نداره و هر وقت بزرگ‌تر شد درستش می‌کنیم». ولی واقعیت اینه که زنجیره‌ی callها از همون روز اول وجود داره. حتی اگر فقط یک API به یک دیتابیس وصل باشه. مسئله این نیست که microservice داریم یا نه.
مسئله اینه که وقتی یک درخواست وارد سیستم می‌شه، آیا می‌تونیم مسیرش رو از ابتدا تا انتها ببینیم یا نه؟

حالا Traceability یعنی چه؟

یعنی بتونیم به این سوال ساده جواب بدهیم: این درخواست دقیقا از کجا اومده، از چه سرویس‌هایی عبور کرده، کجا کند شده، و چرا خطا داده؟
توی معماری microservice این موضوع حیاتیه، چون زنجیره‌ی callها طولانی و توزیع‌شده است. ولی حتی توی یک سیستم کوچک هم اگر این قابلیت رو نداشته باشیم، debugging زمان‌بر، و به حدس و گمان تبدیل می‌شه.

چرا حتی برای سیستم‌های کوچک هم مهمه؟
برخی تصور می‌کنن Distributed Tracing مخصوص سیستم‌های بزرگه. اما به تجربه:
- حتی یک سیستم سه‌لایه ساده هم بدون trace خوب، در زمان بروز مشکل، می‌تونه تبدیل به تاریکی مطلق بشه.
- وقتی یک feature ساده کند می‌شه، اگر trace نداشته باشی، شروع می‌کنی لاگ‌ها رو grep کردن و فرضیه ساختن.
- وقتی فرد جدیدی به تیم اضافه می‌شه، داشتن trace خوب، عملا بهترین مستند معماری زنده است.

پس Traceability باعث می‌شه:
- فرایند debugging از «حدس» به «مشاهده» تبدیل بشه
- به مرور blame culture توی تیم کمتر بشه، چون مسیر واقعی قابل دیدنه
- عملا bottleneckها خیلی سریع‌تر شناسایی بشن
- وابستگی‌ها شفاف باشن

سه ستون اصلی Traceability
۱: اصل Context Propagation
یعنی باید context هر درخواست همراهش حرکت کنه. Trace ID و Span ID باید از سرویس A به B و C منتقل بشن. و اگر این زنجیره قطع بشه، عملا trace بی‌ارزش می‌شه. استاندارد رایج امروز: W3C Trace Context. و این یعنی هدرهای استاندارد برای انتقال trace بین سرویس‌ها.

۲: اصل Correlation بین Log و Trace
داشتن trace بدون لاگ بی‌فایده است. و داشتن لاگ بدون trace هم ناقصه. هر log مهم باید شامل:

trace_id
span_id

باشه تا بتونی از یک error log مستقیم بپری روی trace کامل اون درخواست. Structured logging اینجا حیاتیه (گرچه همه جا مهمه نه فقط توی traceability و متن آزاد و غیرساخت‌یافته توی سیستم‌های جدی قابل دفاع نیست.)

۳: طراحی درست Spanها
نام spanها باید پایدار و کم‌کاردینال باشه. به جای اینکه IDهای متغیر رو داخل نام span بگذاریم، اون‌ها رو به صورت attribute باید ثبت کرد.

مثلا:
درست: HTTP POST /employee/{id}
غلط: HTTP POST /employee/1037685
اگر این موضوع رعایت نشه، هزینه و performance ابزارهای observability صدمه می‌بینه.

توی سیستم‌های Async و Message-based
خیلی وقت‌ها فکر می‌کنیم tracing فقط مربوط به HTTP است. ولی توی سیستم‌های event-driven اگر context رو داخل header پیام منتقل نکنی، زنجیره عملا قطع می‌شه. برای publish و consume هم برای هر پیام باید span جداگانه وجود داشته باشه. وگرنه نمی‌فهمی این job واقعا نتیجه‌ی کدوم درخواست بوده.

چند Best Practice عملی
- از یک استاندارد واحد استفاده کن. OpenTelemetry امروز انتخاب منطقی‌ایه.
- سعی کنید sampling هوشمند داشته باشید. همه چیز رو صددرصد نگه داشتن، راهکار نیست.
- به هیچ وجه PII رو داخل trace و log نریزید. اگر لازمه، hash یا mask کنید (به صورت کلی complience رو جدی بگیرید).
- حتمن naming convention مشخص برای سرویس‌ها و spanها داشته باشید.
- موضوع dependencyهای بیرونی مثل DB و external APIها رو حتما داخل trace بیارید.
- فقط errorها رو log نکنید، داخل span هم record کنید.

موضوع Traceability فقط ابزار نیست، فرهنگه! اگر تیم به این موضوع باور نداشته باشه، ابزار به تنهایی کمکی نمی‌کنه. باید در code reviewها به propagation دقت بشه. باید logging استاندارد enforce بشه. و باید observability contract بین تیم‌ها تعریف بشه (توی سازمان‌های بزرگ‌تر وظیفه تیم اینتگریشن یا پلتفرم است)

جمع‌بندی: داستان Traceability چیزی نیست که «وقتی بزرگ شدیم» اضافه کنیم. این یکی از اون قابلیت‌هاییه که اگر از روز اول درست پیاده بشه:
- هزینه‌ی debugging به شدت کاهش پیدا می‌کنه
- معماری شفاف‌تر می‌شه
- رشد سیستم قابل کنترل‌تر می‌شه
- و در زمان بحران، تیم به جای سردرگمی، تصویر واضحی از واقعیت داره

سیستم بدون trace مثل شهریه که دوربین کنترل ترافیک نداره. شاید در روزهای آروم و تعطیلات مشکلی حس نشه. ولی در اولین روز پرکار و شلوغ، تازه می‌فهمی چی کم بوده.

💬 تجربه شما چی بوده؟