شما می توانید بهره وری توسعه دهنده نرم افزار را اندازه گیری کنید

اوت 17، 2023

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

هیچ انکاری وجود ندارد که اندازه گیری بهره وری توسعه دهندگان دشوار است. توابع دیگر را می توان به خوبی اندازه گیری کرد، برخی حتی با یک متریک واحد؛ در حالی که در توسعه نرم افزار، ارتباط بین ورودی ها و خروجی ها به طور قابل توجهی کمتر روشن است. توسعه نرم افزار نیز کار بسیار مشترک، پیچیده و خلاقانه است و نیاز به معیارهای مختلف برای سطوح مختلف (مانند سیستم ها، تیم ها و افراد) دارد. علاوه بر این، حتی اگر تعهد واقعی برای ردیابی بهره وری به درستی وجود داشته باشد، معیارهای سنتی می توانند نیاز به سیستم ها و نرم افزارهایی داشته باشند که برای اندازه گیری دقیق تر و جامع تر تنظیم شده اند. برای برخی از معیارهای استاندارد، کل موارد فناوری و خطوط جریان توسعه باید دوباره پیکربندی شوند تا ردیابی را فعال کنند و قرار دادن ابزارهای لازم برای ارائه بینش معنی دار می تواند نیاز به سرمایه گذاری قابل توجه و بلند مدت داشته باشد. علاوه بر این، چشم انداز توسعه نرم افزار به سرعت در حال تغییر است، زیرا ابزارهای هوش مصنوعی مولد مانند Copilot X و ChatGPT دارای پتانسیل هستند تا توسعه دهندگان را قادر به انجام وظایف تا دو برابر سریعتر کنند.

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

این رویکرد جدید در نزدیک به 20 شرکت فناوری، مالی و دارویی اجرا شده است و نتایج اولیه امیدوار کننده است. انها شامل پیشرفت های زیر هستند:

• 20 تا 30 درصد کاهش در نقص محصول گزارش شده توسط مشتری
• 20 درصد بهبود در نمرات تجربه کارکنان
• 60 درصد بهبود در رتبه بندی رضایت مشتری

استفاده از بینش بهره وری

با دسترسی به داده ها و بینش های بهره وری غنی تر، رهبران می توانند شروع به پاسخ به سوالات فوری در مورد استعداد مهندسی نرم افزار کنند که به سختی برای جذب و حفظ ان مبارزه کرده اند، مانند:

• چه موانعی برای مهندسانی که در بهترین سطح خود کار می کنند وجود دارد؟
• فرهنگ و سازمان چقدر بر توانایی انها برای تولید بهترین کار خود تاثیر می گذارد؟
• چگونه می توانیم بدانیم که ایا از زمان انها در فعالیت هایی استفاده می کنیم که واقعا ارزش را هدایت می کنند؟
• چگونه می توانیم بدانیم که تمام استعدادهای مهندسی نرم افزاری مورد نیاز خود را داریم؟

درک پایه ها

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

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

در ساخت مجموعه معیارهای ما، ما به دنبال گسترش دو مجموعه از معیارهایی بودیم که قبلا توسط صنعت نرم افزار توسعه یافته است. اولین معیارهای DORA است که به نام تیم تحقیق و ارزیابی DevOps گوگل نامگذاری شده است. اینها نزدیکترین بخش فناوری به یک استاندارد هستند و در اندازه گیری نتایج عالی هستند. هنگامی که یک متریک DORA یک نتیجه زیرمجموعه را باز می گرداند، این یک سیگنال برای بررسی انچه که اشتباه بوده است، که اغلب می تواند شامل کار طولانی مدت باشد. به عنوان مثال، اگر یک معیار مانند فرکانس استقرار افزایش یا کاهش یابد، می تواند علل متعددی داشته باشد. تعیین اینکه انها چه هستند و چگونه انها را حل کنیم اغلب ساده نیست.

مجموعه دوم اندازه گیری های توسعه یافته در صنعت، معیارهای SPACE (رضایت و رفاه، عملکرد، فعالیت، ارتباطات و همکاری و بهره وری و جریان) است که GitHub و Microsoft Research برای تقویت معیارهای DORA توسعه داده اند. با اتخاذ یک لنز فردی، به ویژه در مورد رفاه توسعه دهنده، معیارهای SPACE در روشن کردن اینکه ایا یک سازمان مهندسی بهینه سازی شده است، عالی است. به عنوان مثال، افزایش وقفه هایی که توسعه دهندگان تجربه می کنند نشان دهنده نیاز به بهینه سازی است.

علاوه بر این معیارهای قدرتمند، رویکرد ما به دنبال شناسایی انچه که می توان برای بهبود نحوه تحویل محصولات و انچه که این پیشرفت ها ارزش دارند، بدون نیاز به ابزار سنگین است. تکمیل معیارهای DORA و SPACE با معیارهای متمرکز بر فرصت می تواند یک دیدگاه پایان به پایان از بهره وری توسعه دهنده نرم افزار ایجاد کند (نمودار 1).

این معیارهای بهره وری متمرکز بر فرصت از چند لنز مختلف برای تولید یک دیدگاه ظریف از طیف پیچیده ای از فعالیت های درگیر با توسعه محصول نرم افزار استفاده می کنند.

زمان حلقه داخلی / بیرونی صرف شده.  برای شناسایی زمینه های خاص برای بهبود، مفید است که فعالیت های مربوط به توسعه نرم افزار را در دو حلقه مرتب کنید (نمودار2). حلقه درونی شامل فعالیت هایی است که به طور مستقیم با ایجاد محصول مرتبط است: برنامه نویسی، ساخت و ازمایش واحد. یک حلقه بیرونی شامل وظایف دیگری است که توسعه دهندگان باید انجام دهند تا کد خود را به تولید براند: ادغام، ازمایش ادغام، انتشار و استقرار. از هر دو نقطه نظر بهره وری و تجربه شخصی، به حداکثر رساندن میزان زمانی که توسعه دهندگان در حلقه داخلی صرف می کنند مطلوب است: ساخت محصولات به طور مستقیم ارزش تولید می کند و چیزی است که اکثر توسعه دهندگان از انجام ان هیجان زده هستند. فعالیت های حلقه بیرونی توسط اکثر توسعه دهندگان به عنوان ضروری اما به طور کلی ناخوشایند است. قرار دادن زمان برای ابزار و اتوماسیون بهتر برای حلقه بیرونی به توسعه دهندگان اجازه می دهد تا زمان بیشتری را صرف فعالیت های حلقه داخلی کنند.

هدف شرکت های فناوری برتر این است که توسعه دهندگان تا 70 درصد از وقت خود را صرف انجام فعالیت های حلقه داخلی کنند. به عنوان مثال، یک شرکت که قبلا یک تحول چابک موفق را تکمیل کرده بود، متوجه شد که توسعه دهندگان ان، به جای برنامه نویسی، زمان زیادی را صرف وظایف کم ارزش افزوده مانند تامین زیرساخت ها، اجرای تست های دستی واحد و مدیریت داده های تست می کنند. مسلح به این بینش، مجموعه ای از ابزارها و پروژه های اتوماسیون جدید را برای کمک به این وظایف در چرخه عمر توسعه نرم افزار راه اندازی کرد.

معیار شاخص سرعت توسعه دهنده. شاخص سرعت توسعه دهنده (DVI) یک نظرسنجی است که تکنولوژی، شیوه های کاری و توانایی سازمانی شرکت را اندازه گیری می کند و انها را در برابر همرده ها ارزیابی می کند. این مقایسه به کشف مناطق خاصی از فرصت ها کمک می کند، چه در مدیریت عقب مانده، ازمایش یا امنیت و انطباق.^به عنوان مثال، یک شرکت، که به خاطر توانایی های تکنولوژیکی و توسعه دهندگان تمام ستاره شناخته شده است، به دنبال تعریف شیوه های کار استاندارد برای همکاری بین تیمی پس از کشف مقدار زیادی نارضایتی، کار مجدد و ناکارامدی گزارش شده توسط توسعه دهندگان بود.

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

نمره توانایی استعداد.  بر اساس نقشه های توانایی استاندارد صنعت، این نمره خلاصه ای از دانش، مهارت ها و توانایی های فردی یک سازمان خاص است. در حالت ایده ال، سازمان ها باید به توزیع “الماس” مهارت، با اکثریت توسعه دهندگان در محدوده متوسط صلاحیت، ارزو کنند. این می تواند فرصت های مربیگری و ارتقاء مهارت را افزایش دهد و در موارد شدید خواستار تجدید نظر در استراتژی استعداد است. به عنوان مثال، یک شرکت شدت بیشتری از توسعه دهندگان خود را در توانایی “تازه کار” نسبت به ایده ال یافت. انها سفرهای یادگیری شخصی را بر اساس شکاف های خاص مستقر کردند و توانستند 30 درصد از توسعه دهندگان خود را به سطح بعدی تخصص در عرض شش ماه منتقل کنند.

اجتناب از اشتباهات معیارها

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

سوء استفاده زمانی شایع تر است که شرکت ها سعی می کنند اندازه گیری های بیش از حد ساده مانند خطوط کد تولید شده یا تعداد کدهای متعهد (زمانی که توسعه دهندگان کد خود را به یک سیستم کنترل نسخه ارسال می کنند) استفاده کنند. چنین معیارهای ساده ای نه تنها نمی توانند بینش های واقعا مفیدی ایجاد کنند، بلکه می توانند عواقب ناخواسته ای داشته باشند، مانند رهبرانی که تجارت نامناسب انجام می دهند. به عنوان مثال، بهینه سازی برای زمان تحویل یا فرکانس استقرار می تواند کیفیت را رنج برساند. تمرکز بر روی یک متریک واحد یا مجموعه ای از معیارها بسیار ساده نیز می تواند به راحتی شیوه های ضعیف را تشویق کند. به عنوان مثال، در مورد اندازه گیری commits، توسعه دهندگان ممکن است تغییرات کوچکتر را بیشتر به عنوان انها به دنبال بازی سیستم ارائه دهند.

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

شروع

برپایی یک ابتکار بهره وری توسعه دهنده می تواند دلهره اور به نظر برسد، اما هیچ زمانی مانند زمان حال برای شروع زمینه سازی وجود ندارد. عواملی که نیاز به افزایش گفتگو در مورد بهره وری توسعه دهندگان نرم افزار را به رهبران سطح C افزایش می دهد، از موانع انجام این کار بیشتر است.

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

یکی دیگر از محرک های کلیدی این نیاز به دید بیشتر، پیشرفت های سریع در ابزارهای فعال AI، به ویژه مدل های بزرگ زبان مانند هوش مصنوعی مولد است. اینها در حال حاضر به سرعت در حال تغییر نحوه انجام کار هستند، به این معنی که اندازه گیری بهره وری توسعه دهندگان نرم افزار تنها اولین گام برای درک چگونگی استقرار این منابع ارزشمند است.

اما به همان اندازه که بهره وری توسعه دهنده در حال تبدیل شدن است، شرکت ها نباید احساس کنند که باید تقریبا یک شبه یک تعمیرات اساسی گسترده و چشمگیر را اغاز کنند. در عوض، انها می توانند فرایند را با تعدادی از مراحل کلیدی اغاز کنند:

اصول اولیه را یاد بگیرید.  تمام رهبران C-suite که مهندس نیستند یا برای مدت طولانی در مدیریت بوده اند، نیاز به یک اغازگر در فرایند توسعه نرم افزار و چگونگی تکامل ان دارند.

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

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

به یاد داشته باشید که اندازه گیری بهره وری متنی است. نکته این است که به کل سیستم نگاه کنید و درک کنید که چگونه می تواند با بهبود محیط توسعه در سیستم، تیم یا سطح فردی بهتر کار کند.

مهم نیست که رویکرد خاص، اندازه گیری بهره وری باید به طور ایده ال شفافیت و بینش در زمینه های بهبود کلیدی ایجاد کند. تنها در این صورت است که سازمان ها می توانند ابتکارات خاصی را برای تاثیر بر بهره وری و تجربه توسعه دهندگان ایجاد کنند – تاثیری که به نفع این افراد و شرکت به طور کلی است.

درباره نویسنده (ها)

Chandra Gnanasambandam و Martin Harrysson شرکای ارشد در دفتر منطقه خلیج مک کینزی هستند، جایی که Alharith Hussin و Shivam Srivastava شریک هستند؛ و جیسون Keovichit شریک در دفتر نیویورک است.

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