آیا باید بهره وری توسعه دهندگان را اندازه گیری کنیم؟

نقطه قوت تیم توسعه نرم افزار هر توسعه دهنده فردی است. نقطه قوت هر توسعه دهنده تیم است.

حدود ۱۰ سال پیش، یک پست وبلاگ نوشتم به نام “ آیا می توانیم بهره وری توسعه دهندگان را اندازه گیری کنیم؟ در آن، من تلاش‌های عینی زیادی را که برای انجام آن انجام شده بود، مورد بحث قرار دادم – خطوط کد، نقاط تابع، و غیره. همچنین برخی اقدامات ذهنی را پیشنهاد کردم. با این حال، نتیجه این بود که علی‌رغم تمایل مدیران عاشق KPI، هیچ راه مناسبی برای اندازه‌گیری بهره‌وری یک توسعه‌دهنده نرم‌افزار وجود ندارد.

من به این مقاله که ۱۰ سال پیش منتشر شد اشاره می‌کنم زیرا در سال‌های پس از آن همه چیز به‌طور قابل توجهی تغییر کرده است. وقتی آن را نوشتم، Git و Mercurial هر دو سیستم های کنترل منبع نرم افزار برجسته و محبوب بودند. من در آن زمان یک مدیر نرم افزار بودم و تیمم را از Visual Source Safe از مایکروسافت خارج کردم و تصمیم گرفتیم Mercurial را انتخاب کنیم زیرا بسیار ویندوز پسندتر بود.

ما اسب اشتباهی را انتخاب کردیم زیرا در سال‌های آینده، Git به استاندارد واقعی برای کنترل نسخه تبدیل خواهد شد. در نتیجه، یک صنعت کلبه در اطراف مخازن Git بوجود آمده است. GitHub یک تجارت بزرگ است که مایکروسافت برای آن ۷.۵ میلیارد دلار پرداخت کرده است. اکنون بسیاری از شرکت‌ها معیارهایی را پیرامون کد شما در Git ارائه می‌کنند. و بسیاری از آن شرکت ها مدعی سنجش بهره وری توسعه دهندگان نرم افزار هستند.

معیارهای ارائه

اگر بپذیریم که امکان اندازه‌گیری بهره‌وری توسعه‌دهنده وجود دارد (گزاره‌ای که من کاملاً به آن فروخته نشده‌ام)، باید بپرسیم که آیا باید این کار را انجام دهیم.

میل به انجام این کار قطعا قوی است. مدیران می خواهند بدانند بهترین توسعه دهندگانشان چه کسانی هستند و معیارهایی را می خواهند که در زمان ارزیابی عملکرد به آنها کمک کند. HR می خواهد بتواند مسائل مربوط به عملکرد را مستند کند. مدیران عامل می‌خواهند بدانند که پولی که خرج می‌کنند به طور مؤثر استفاده می‌شود.

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

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

این تیم ها هستند و نه توسعه دهندگان فردی که کارها را در تجارت نرم افزار انجام می دهند. توسعه نرم افزار از این نظر جالب است. کدگذاری واقعی اغلب توسط افرادی که عمیقاً فکر می کنند به بهترین شکل انجام می شود، اما کاری که قبل و بعد از نوشتن کد اتفاق می افتد، کمک زیادی به موفقیت کارها می کند.

تیم را اندازه گیری کنید

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

قدرت تیم هر یک از اعضا است. نقطه قوت هر عضو تیم است. —فیل جکسون، مربی NBA

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

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

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