مسعود بهرامی
پارادوکس بهرهوری در عصر مدرن
در سالهای اخیر، اصطلاح بهرهوری توسعهدهنده (Developer Productivity) به یکی از بحثبرانگیزترین موضوعات در اتاقهای مدیران میانی، تیم لیدها، مریبان چابکی و درون خود تیمهای مهندسی تبدیل شده است. اما یک مشکل اساسی وجود دارد: هرچند اصل موضوع، امری پسندیه و درست است در عمل اما، اکثر سازمانها هنوز از معیارهای اشتباه برای سنجش این مفهوم استفاده میکنند.
اگر از یک تیم توسعه بپرسید چگونه بهرهوری خود را اندازه میگیرید؟، احتمالاً پاسخهایی مانند تعداد کامیتها در روز، تعداد تسکهای تکمیل شده در جیرا! یا تعداد خطوط کد نوشته شده را خواهید شنید. اما واقعیت تلخ این است که این معیارها نه تنها نشاندهنده بهرهوری نیستند، بلکه میتوانند باعث ایجاد رفتارهای مخرب در تیم شوند. نوشتن ۱۰۰۰ خط کد کثیف و پر از باگ، بسیار سریعتر از نوشتن ۱۰۰ خط کد تمیز و تستشده است، اما آیا این به معنای بهرهوری بالاتر است؟ قطعاً خیر!
بهرهوری واقعی در توسعه نرمافزار، به معنای سرعتِ تولیدِ ارزش (Value) است، نه صرفاً انجام فعالیت. برای رسیدن به این درک، ما نیاز به یک رویکرد مبتنی بر داده و خروجی (Outcome-oriented) داریم. خب چارچوبها و تلاشهای مختلف جهت اندازهگیری و قابل شمارش کردن میزان خلق ارزش توسعه دهندگان تحت عنوان Developer Experience(DX) در سالهای اخیر معرفی شدهاند. یکی از آخرین این چارچوب DORA است که به شرطها و شروطها میتواند مفید و کمک کننده باشد.
به عقیدهی من بهرهوری واقعی در توسعه نرمافزار، به معنای سرعتِ تولیدِ ارزش (Value) است، نه صرفاً انجام فعالیت.
بحران معیارهای سنتی و مفهوم تله فعالیت
قبل از ورود به DORA، باید درک کنیم چرا سایر معیارهای سنتی محکوم به شکست هستند، یا شکست خوردهاند. در مدیریت سنتی، ما بر اساس ورودیها (Inputs) یا فعالیتها (Activities) تصمیم میگیریم. اما در نرمافزار، فعالیت لزوماً به نتیجه نمیانجامد.
تله تعداد کامیتها
فرض کنید مدیری برای افزایش بهرهوری، تیم را تشویق میکند که تعداد کامیتهای روزانه را بالا ببرند. توسعهدهنده برای اینکه آمار خود را خوب نشان دهد، شروع میکند به شکستن یک تغییر کوچک به ۱۰ کامیت جداگانه و بیربط. نتیجه؟ تاریخچه Git کثیف شده، بررسی کد (Code Review) برای همتیمیها دشوار شده و در نهایت، فرآیند انتشار (Deployment) با خطا مواجه میشود. در اینجا فعالیت بالا رفت(جنب و جوش توسعه هندگان- از صدای ممتد کیبورد درون اتاق توسعه هم میتوانید متوجه این موضوع شوید 😉)، اما بهرهوری به شدت کاهش یافت.
بنابراین، بهرهوری توسعهدهنده باید از سه منظر بررسی شود:
- سرعت (Velocity): چقدر سریع میتوانیم ایدهها را به تولید برسانیم؟
- کیفیت (Quality): آیا آنچه تولید میکنیم پایدار و بدون خطا است؟
- رضایت و سلامت (Flow & Wellbeing): آیا فرآیند توسعه مانع کار توسعهدهنده میشود یا به او کمک میکند؟
معرفی چارچوب DORA؛ استاندارد طلایی سنجش عملکرد
گروه DevOps Research and Assessment (DORA) پس از سالها تحقیق علمی بر روی هزاران سازمان، متوجه شد که موفقیت در توسعه نرمافزار با احساسات یا تکنولوژیهای خاص در ارتباط نیست، بلکه با چهار معیار کلیدی (Metrics) پیوند خورده است. این چهار معیار، توازن میان سرعت و پایداری را برقرار میکنند. فراموش نکنید که یکی از اصول بنیادین بیانییه چابکی(agile manifesto) این است که تیم بتواند یک سرعت خلق ارزش پایدار(sustainable pace) را داشته باشد، عوض کند گاهی خیلی سریع ارزش تولید کند و گاهی بسیار کند شود.
1. میزان زمان از کد تا تولید (Lead Time for Changes)
این معیار نشان میدهد که از لحظهای که یک توسعهدهنده اولین خط کد را برای یک ویژگی جدید مینویسد، تا زمانی که آن کد در محیط عملیاتی (Production) در دسترس کاربران قرار میگیرد، چقدر زمان میگذرد.
هدف: کاهش زمان چرخه بازخورد (Feedback Loop)
مثال: اگر یک تیم تغییرات را با کامیتهای کوچک و تستهای خودکار انجام دهد، Lead Time آنها بسیار کوتاه خواهد بود. اما اگر تغییرات بزرگ باشند و نیاز به هفتهها تست دستی داشته باشند، این عدد بالا میرود و نشاندهنده کندی فرآیند است.
2. فرکانس انتشار (Deployment Frequency)
این معیار مشخص میکند که سازمان با چه نرخی تغییرات خود را به محیط عملیاتی ارسال میکند.
هدف: رسیدن به حالت انتشار مداوم (Continuous Deployment)
مثال: تیمهای با عملکرد بالا (Elite Performers) ممکن است چندین بار در روز منتشر کنند. تیمهای با عملکرد پایین ممکن است فقط یک بار در ماه منتشر کنند. انتشار مکرر ریسک را کاهش میدهد، زیرا هر تغییر کوچکتر است و مدیریت آن آسانتر.
3. نرخ شکست تغییرات (Change Failure Rate)
سرعت بدون کیفیت، خودکشی است. این معیار درصد تغییراتی را نشان میدهد که منجر به خطا، خرابی سیستم یا نیاز به بازگشت به عقب (Rollback) شدهاند.
هدف: حفظ پایداری سیستم در عین حرکت سریع.
مثال: اگر تیمی روزانه ۱۰ بار منتشر میکند اما در هر بار، سیستم دچار اختلال میشود، آنها “سریع” هستند اما “بهرهور” نیستند. نرخ شکست باید پایین نگه داشته شود.
4. زمان بازیابی سرویس (Time to Restore Service)
وقتی اتفاق بدی میافتد (و حتماً میافتد!)، چقدر طول میکشد تا سیستم دوباره به حالت عادی برگردد؟
هدف: تابآوری (Resilience) و مدیریت بحران.
مثال: این معیار مستقیماً با سیستمهای مانیتورینگ و قابلیتهای خودکارسازی (Automated Recovery) در ارتباط است. تیمی که بتواند در عرض ۵ دقیقه یک سرویس را از حالت خطا به حالت عادی برگرداند، بسیار ارزشمندتر از تیمی است که با شکست مواجه میشود و ساعتها درگیر پیدا کردن علت میماند.
تحلیل ماتریس عملکرد؛ دستهبندی تیمها
DORA تیمها را بر اساس ترکیب این چهار معیار به چهار دسته تقسیم میکند:
- Elite (نخبه): سرعت بسیار بالا + پایداری بسیار بالا (انتشار مکرر و خطای بسیار کم).
- High (بالا): سرعت خوب + پایداری خوب.
- Medium (متوسط): سرعت و پایداری معمولی (معمولاً با فرآیندهای دستی زیاد).
- Low (پایین): سرعت بسیار کم + پایداری بسیار کم (معمولاً با فرآیندهای سنتی و ترس از انتشار).
دقت کنید لطفا:
در اینجا توجه به این نکته استراتژیک بسیار حایز اهمیت که هدف هر سازمان نباید صرفاً رسیدن به سطح Elite باشد، بلکه باید شناسایی شود که تیم در کدام سطح است و گلوگاههای (Bottlenecks) موجود برای حرکت به سطح بعدی چیست.
چگونه بهرهوری را بهبود بخشیم؟ (نقشه راه عملیاتی)
شناسایی مشکل با DORA کافی نیست؛ ما نیاز به راهکار داریم. بهبود بهرهوری مستقیماً با بهبود تجربه توسعهدهنده (Developer Experience – DX) گره خورده است.
حذف اصطکاک در فرآیند (Reducing Friction)
بسیاری از زمان توسعهدهندگان با انجام کارهای که ارزش مشخصی برای خلق نمیکند و نمیتواند استفاده از فیچرهایی که در حال پیادهسازی آن هستند را توسط مشتری ببینید، به راحتی تلف میشوند، ولو اینکه این کارها حتی در ابتدا از نظر فنی جذابیت زیادی داشته باشد. یکی دیگر از مواردی که برای توسعه دهندگان به منزله مرگ خاموش در سازمان است، گیر افتادن در بروکراسیهای طویل و حوصله سر بر در سازمان است. این فرآیندها مملو از اصطاکهای بیخود هستند و اکثر مواقع حتی با برچسب چابکی در سازمان برپا شدهاند و افرادی زیادی آن را دنبال میکنند، ولی در عمل بیشتر به عنوان سرعتگیر چابکی عمل میکنند.
مثال: انتظار برای تأیید دستی از تیم امنیت، انتظار برای بالا آمدن محیطهای تست، یا درگیری با کانفیگهای پیچیده زیرساخت.
راهکار: پیادهسازی Platform Engineering و ایجاد Internal Developer Platforms (IDP). هدف این است که توسعهدهنده بتواند با خودخدمتی (Self-service)، منابع مورد نیاز خود (دیتابیس، سرور، محیط تست) را بدون دخالت تیمهای دیگر دریافت کند.
سرمایهگذاری بر خودکارسازی (Automation)
هر جایی که انسان نیاز به تکرار یک کار دارد، جایی برای خطا و کندی است.
راهکار: پیادهسازی خط فرآیند خودکار CI/CD ، تستهای خودکار (Unit, Integration, E2E) و تستهای امنیتی خودکار در جریان توسعه.
فرهنگ دنبال مقصر نبودن (Blameless Culture)
اگر تیمها از شکست بترسند، از تغییر کردن و انتشار سریع خودداری میکنند، که منجر به افزایش Lead Time و کاهش Deployment Frequency میشود.
راهکار: برگزاری Blameless Post-mortems. وقتی سیستم دان میشود یا بصورت کلی هر باگ ناخواستهای یافت میشود، به جای پرسیدن چه کسی این کار را کرد؟، باید پرسید چه چیزی در فرآیند ما باعث شد این خطا رخ دهد و چگونه سیستم را اصلاح کنیم که دوباره اتفاق نیفتد؟
بهرهوری، یک هدف نیست؛ یک قابلیت است
بهرهوری توسعهدهنده نباید با فشار بیشتر بر افراد یا افزایش ساعتهای کاری معنا شود. این یک اشتباه استراتژیک است که منجر به Burnout (فرسودگی شغلی) و خروج نیروهای متخصص میشود.
بهرهوری واقعی یعنی ایجاد سیستمی که در آن توسعهدهنده بتواند با تمرکز بر حل مسائل پیچیده، با کمترین اصطکاک و بیشترین اعتماد به خود، ایدههای خود را به واقعیت تبدیل کند. چارچوب DORA به ما یاد میدهد که برای رسیدن به این هدف، باید تعادلی هوشمندانه میان سرعت انتشار و پایداری سیستم برقرار کنیم.
سازمانهای آینده، سازمانهایی نیستند که سریعترین کد را مینویسند، بلکه سازمانهایی هستند که سریعترین و مطمئنترین چرخه ارزش را مدیریت میکنند.
