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

این مسئله به ویژه زمانی که شما روی مدل های ترکیبی کار می کنید اهمیت خود را بیش از پیش نشان می دهد. این یک واقعیت بسیار جذاب است که سازمان های مبتنی بر فناوری و تکنولوژی برای استخدام توسعه دهندگان با آن مواجه می شوند. توسعه دهندگان نرم افزار زمانی که از نزدیک مدیریت می شوند دچار سردرگمی های زیادی می شوند و بسیاری از آنها مشاغل خود را ترک می کنند.

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

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

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

روش های تشخیصی و بررسی عملکرد

با وجود نکاتی که در بخش قبلی بیان کردیم این واقعیت عملی نیز وجود دارد که سازمان ها به روش هایی نیاز دارند تا تشخیص دهند که آیا تیم های Agile و توسعه دهندگان نرم افزار به اهداف عملکردی، توسعه و کسب و کار می رسند یا از آن فراتر می روند؟ چگونه مدیران می توانند بدون اذیت کردن برنامه نویس ها اقدام به مدیریت توسعه دهندگان نرم افزار کنند؟

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

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

تعریف اهداف و نتایج کلیدی برای کسب و کارها

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

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

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

-          هدف " بهبود قابلیت اطمینان استقرار کد" ممکن است شامل نتایجی مانند افزایش اتوماسیون تست یا کاهش زمان ساخت به میزان قابل توجهی باشد.

به طور مداوم به تعهدات اسپرینت و انتشار عمل کنید

اسکرام بر اساس ریتم ها و انجام تعهدات اجرا می شود و به همین علت نیز دستیابی به ضرب الاجل ها یکی از راه های سنجش نظم و انضباط تیم و همسویی با استانداردها است. یکی از راهکارهای خوبی که برای رهبران تیم ها وجود دارد این است که می توانند سطح انتظارات بالا و پایین را در چندین اسپرینت جمع آوری کنند.

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

جلب رضایت صاحبان محصولات و ذینفعان در مدیریت توسعه دهندگان نرم افزار

agile manifesto همکاری مشترک بر سر مذاکره قرارداد را به عنوان یک ارزش اصلی شناسایی می کند. این در حالی است که ما نباید توسعه دهندگان Agile را مجبور کنیم که بدون عیب و نقص پروژه های خود را ارائه دهند. به این ترتیب ما می توانیم به دنبال ثبت معیارهای مستقل رضایت مشتری باشیم. مسئله رضایت صاحبان محصولات و ذینفعان یکی از ابزارهایی است که سازمان های توسعه بزرگتر می توانند از آن برای گرفتن بازخورد برای توسعه دهندگان و تیم های Agile استفاده کنند. برخی از سوالاتی که ممکن است در این زمینه به وجود بیاید شامل سوالات زیر هستند:

-          همکاری در زمان وجود مشکلات بسیار زیاد و مستندسازی از راه حل ها

-          رضایت از نتایج

-          کیفیت بازخورد در زمان برنامه ریزی و برآورد ویژگی ها

نکته کلیدی که در این جا وجود دارد این است که بازخورد مشتری را باید به توسعه دهندگان و تیم های Agile برگردانید تا بتوانید نتایج را از دیدگاه مشتری و کاربر نیز منعکس کنید و عملکرد پروژه را بهبود دهید.

بازبینی زوجی از طراحی، مستندات و سهولت استفاده از اپلیکیشن را کمی سازی کنید

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

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

نکاتی برای بازبینی زوجی

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

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

برای مدیریت توسعه دهندگان نرم افزار شاخص های کلیدی عملکردی غیر قابل مذاکره را برای devops انتخاب کنید

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

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

Devops، ITSM و infosec دارای KPI های بالغی هستند و رهبران تیم ها باید تعداد معناداری از آنها را برای مدیریت توسعه دهندگان نرم افزار انتخاب کنند تا از بهم خوردن تمرکز تیم های توسعه دهنده نرم افزار جلوگیری کنند. برای تیم های توسعه که روی اپلیکیشن های مبتنی بر کلود فعالیت می کنند بهتر است که ابتدا اهداف سطح سرویس را تعریف کرده و از آنها برای مدیریت میزان خطای موجود در کدها استفاده کنند. برای سایر گروه های توسعه دهنده اندازه گیری کاهش نرخ شکست و میانگین زمان بازیابی پس از شکست ها از جمله شاخص های کلیدی برتر به شمار می آیند که در مدیریت توسعه دهندگان نرم افزار باید توجه ویژه ای به آن داشته باشید.

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

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

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

در گزارشی که از  Dice 2021 Technologist Sentiment منتشر شده است 36 درصد از شرکت کنندگان دلیل فرسودگی شغلی خود را با استفاده از 4 یا 5 مقیاس مختلف توصیف کردند و 48 درصد از آنها نیز گزارش داده اند که احتمالا کارفرمای خود را تغییر می دهند.

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

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

نکته آخری که باید درباره مدیریت توسعه دهندگان نرم افزار بدانید این است که مدیریت و اندازه گیری عملکرد این توسعه دهندگان نیازمند تعامل بیشتر و بحث های مکرر بین کارفرما و مدیران و همینطور کارمندان می باشد. شما باید بررسی کنید که آیا با اهداف و معیارهای موفقیت که تعریف کرده اید همسو هستید؟ آیا استانداردها و محدودیت هایی که وجود دارند را به خوبی درک می کنید؟ حتی زمانی که معیارها شاخص های کلیدی مهمی را ارائه می دهند این بحث درباره اقدامات بعدی است که منجر به بهبود عملکرد توسعه دهندگان نرم افزار و در نهایت کل تیم می شود.