توسعه‌دهندگان نرم‌افزار با استعداد از این ایده که از نزدیک مدیریت می‌شوند، سر می‌زنند. در اینجا هفت راه برای هماهنگ کردن تیم های توسعه و اهداف تجاری بدون بدبخت کردن توسعه دهندگان آورده شده است.
در سال جاری چندین بار از من در مورد اندازه‌گیری بهره‌وری، کیفیت و نتایج یک توسعه‌دهنده نرم‌افزار سؤال شده است، به‌ویژه زمانی که رهبری مدل‌های کاری ترکیبی را ترویج می‌کند.
اما در اینجا واقعیتی است که سازمان‌های فناوری با آن مواجه می‌شوند، زمانی که استخدام و حفظ توسعه‌دهندگان نرم‌افزار بزرگ دشوار است: توسعه‌دهندگان نرم‌افزار با استعداد از این ایده که از نزدیک مدیریت می‌شوند، سر در گم می‌کنند و بسیاری از آنها مشاغلی را ترک خواهند کرد که در آن فرهنگ مدیریت خرد وجود دارد.
درخواست از یک برنامه‌نویس برای گزارش به مدیری که تجربه توسعه نرم‌افزاری ندارد، می‌تواند باعث ترس از بوروکراسی فرآیند شود. برخی از توسعه‌دهندگان نرم‌افزار چابک که اصول خودسازمان‌دهی افراطی را می‌پذیرند، خواهان استقلال کامل هستند و ممکن است در هر نشانه‌ای از تلاش‌های رهبری برای اندازه‌گیری بهره‌وری، کیفیت یا سایر ملاحظات عملکرد عصیان کنند.
اگر توسعه دهندگان نرم افزار از ریزمدیریت متنفرند، بسیاری نسبت به بررسی عملکرد سالانه تحقیر بیشتری دارند. توسعه دهندگان اهداف عملکرد زمان واقعی را هدف قرار می دهند و هدفشان بهبود سرعت، فرکانس استقرار کد، زمان چرخه و سایر شاخص های کلیدی عملکرد است. تیم‌های اسکرام در پایان هر دوی سرعت عملکرد خود را مورد بحث قرار می‌دهند، بنابراین بازخورد بررسی عملکرد سالانه و فصلی می‌تواند اضافی یا نامربوط به نظر برسد.
اما این واقعیت عملی نیز وجود دارد که سازمان‌ها به روش‌هایی نیاز دارند تا تشخیص دهند که آیا تیم‌های چابک و توسعه‌دهندگان نرم‌افزار به اهداف عملکرد، توسعه و کسب‌وکار می‌رسند یا فراتر می‌روند. چگونه مدیران می‌توانند بدون بدبخت کردن توسعه‌دهندگان به آنچه نیاز دارند برسند؟
آنچه در زیر می‌آید هفت روش توصیه‌شده است که با اصول چابک، اسکرام، توسعه‌دهی و چرخه عمر توسعه نرم‌افزار مطابقت دارد و می‌تواند برای بازبینی توسعه‌دهندگان نرم‌افزار اعمال شود. من آنها را به عنوان اهداف SMART نمی نویسم (مشخص ، قابل اندازه گیری، قابل دستیابی، مرتبط و محدود به زمان)، اما رهبران باید موارد مرتبط را بر اساس روش های چابک کار و اهداف تجاری.
برخی از این موارد ممکن است فقط در سطح تیم مرتبط باشند، در حالی که مدیران می‌توانند از دیگران برای اندازه‌گیری گزارش‌های مستقیم خود استفاده کنند.
اهداف و نتایج کلیدی را که با اهداف تجاری و فنی همسو هستند تعریف کنید
تعریف اهداف و نتایج کلیدی (OKRs) بحثی که صاحبان محصول، مدیران توسعه و معماران می توانند با تیم های خود داشته باشند تا بر اساس معیارهای موفقیت قابل اندازه گیری هماهنگ شوند. در حالت ایده‌آل، این یک همکاری بین رهبران و تیم است که رهبران هدف را تعریف می‌کنند و تیم کامل در مورد نتایج کلیدی بحث، بحث و گفتگو می‌کنند و تصمیم می‌گیرند.
بهترین روش این است که OKR ها را بر روی یک آهنگ معنی دار تعریف کنید. اگر خیلی زیاد باشد، هزینه های تعیین و اندازه گیری OKR ممکن است گران باشد. اگر خیلی نادر باشد، تیم ها ممکن است اهداف را از دست بدهند. دو مثال:
- هدف “بهبود قابلیت اطمینان برنامه” ممکن است شامل نتایجی مانند کاهش زمان پاسخگویی صفحه، بهبود در دسترس بودن برنامه، یا کاهش نرخ خطا به میزان قابل توجهی باشد.
- هدف “بهبود قابلیت اطمینان استقرار” ممکن است شامل نتایجی مانند افزایش اتوماسیون تست یا کاهش زمان ساخت با درصدهای معنی دار باشد.
به طور مداوم به تعهدات اسپرینت و آزادی عمل کنید
Scrum بر اساس آهنگ‌ها و انجام تعهدات اجرا می‌شود، بنابراین دستیابی به ضرب‌الاجل‌ها یکی از راه‌های سنجش نظم و انضباط تیم و همسویی با استانداردها است. من انتظار ندارم که تیم‌ها تعهدات هر دو سرعت را به طور کامل انجام دهند، اما رهبران می‌توانند سطح انتظارات بالا و پایین را در چندین اسپرینت جمع‌آوری کنند.
برای تیم‌هایی که نسخه‌هایی را با آهنگ‌های تعریف‌شده (روزانه، هفتگی، هر چهار سرعت و غیره) انجام می‌دهند، توصیه می‌کنم بررسی کنید که آیا تیم‌ها طبق برنامه منتشر می‌شوند و معیارهای کیفیت را رعایت می‌کنند. رسیدن به تاریخ انتشار اما ایجاد قطعی، حوادث امنیتی یا مشکلات قابل توجه تولید، مشکلات آشکاری هستند.
رضایت صاحبان محصول و ذینفعان را جلب کنید
مانیفست چابک “همکاری با مشتری بر سر مذاکره قرارداد” را به عنوان یک ارزش اصلی شناسایی می‌کند. در حالی که ما نباید توسعه دهندگان چابک را مجبور کنیم که بدون عیب و نقص – به موقع، دامنه و هزینه ارائه دهند، مثلث آهنین – می‌توانیم به دنبال گرفتن معیارهای مستقل رضایت مشتری باشیم.
نظرسنجی رضایت یکی از ابزارهایی است که سازمان های توسعه بزرگتر می توانند از آن برای گرفتن بازخورد برای توسعه دهندگان و تیم های چابک استفاده کنند. برخی از سوالات ممکن است شامل موارد زیر باشد:
- همکاری هنگام طوفان فکری مشکلات و مستندسازی راه حل ها
- تحویل در محدوده و رضایت از نتایج
- کیفیت بازخورد هنگام برنامه ریزی و برآورد ویژگی ها
کلید این است که بازخورد مشتری را به تیم‌های توسعه‌دهنده و چابک بازگردانید تا بتوانند نتایج را از دیدگاه مشتری منعکس کنند و عملکرد را بهبود بخشند.
بررسی های همتایان از طراحی، مستندات و سهولت استفاده را کمی کنید
از یک برنامه‌نویس بپرسید که چقدر آسان است از APIهای تیم دیگر استفاده کنید، کد برنامه‌نویس دیگری را ارتقا دهید، یا معماری برنامه‌ای جدید را از اسناد موجود بیاموزید. متأسفانه، بعید است که پاسخ مثبت یا توسعه‌دهنده‌ای خوشحال دریافت کنید، به‌ویژه زمانی که روی کدهای قدیمی یا در معماری یکپارچه کار می‌کنید.
بنابراین چگونه تعیین می کنید که آیا توسعه دهندگان امروز کار بهتری را در زمینه توسعه کدهای قابل نگهداری، اسناد مفید و میکروسرویس هایی که مصرف آن آسان است انجام می دهند؟ چگونه می توانید این پیشرفت یا پسرفت را اندازه گیری کنید؟
در حالی که ممکن است ابزارها یا تجزیه و تحلیل هایی برای دستیابی به این معیارها وجود داشته باشد، من معتقدم ساده ترین رویکرد ایجاد فرآیندی برای بررسی همتایان است. همتایان می‌توانند هنگام بررسی یک درخواست کششی، در مورد خوانایی کد نظر دهند، در اسناد رتبه‌بندی کنند، و هنگام ادغام میکروسرویس‌ها یا APIها به نظرسنجی‌ها پاسخ دهند.
بررسی‌های همتا باید مکمل بازخورد ابزارهای بررسی کد و تجزیه و تحلیل کیفیت باشد که می تواند در زمان واقعی، بازخورد دقیق در مورد کیفیت کد، امنیت، و مسائل مرتبط ارائه دهد.
شاخص‌های عملکرد کلیدی غیرقابل مذاکره برای devops را انتخاب کنید
صاحبان محصول و همتایان بازخورد مهمی ارائه می دهند، اما مدیران همچنین باید اطمینان حاصل کنند که توسعه دهندگان و تیم های توسعه بازخورد عملیاتی را بررسی کرده و به آنها پاسخ می دهند. بازخورد باید شامل جزئیاتی در مورد مهندسی قابلیت اطمینان سایت، اقدامات امنیتی، و پاسخگویی به حوادث، درخواست‌ها و سایر بلیط‌های مدیریت خدمات فناوری اطلاعات (ITSM) باشد.
Devops، ITSM و infosec دارای KPIهای بسیار بالغی هستند و رهبران باید تعداد معنی دار و قابل مدیریتی را برای تمرکز تیم های توسعه نرم افزار انتخاب کنند. برای تیم های توسعه که روی برنامه های کاربردی ابری کار می کنند، تعریف اهداف سطح سرویس و استفاده از آنها برای مدیریت بودجه های خطا را توصیه می کنم. برای سایر گروه‌های توسعه، اندازه‌گیری کاهش نرخ شکست تغییر و میانگین زمان بازیابی از حوادث مربوط به شاخص KPIهای برتر در این تحقیق.
تأثیر یادگیری، آزمایش و راهنمایی را نشان دهید
امروزه، کسب‌وکارهای بیشتری اهمیت حمایت از یادگیری مستمر، ترویج محیط‌های امن برای آزمایش، و ثبت‌نام شرکت‌کنندگان در برنامه‌های راهنمایی را درک می‌کنند. در حالی که همه اینها اهداف مهمی هستند، مدیران باید بررسی کنند که چگونه توسعه دهندگان این دستورالعمل ها را عملی می کنند و در کجا تأثیرات تجاری را ارائه می دهند. مدیران باید به توسعه‌دهندگان کمک کنند تا یک برنامه توسعه شغلی ایجاد کنند و بازخورد خود را در مورد نحوه هماهنگی یادگیری، راهنمایی و مشارکت آنها در آزمایش‌ها و اثبات مفهوم با اهداف شغلی کارمند ارائه دهند.
از توسعه دهندگان بخواهید که اهداف و اهداف زندگی کاری را پیشنهاد کنند
در گزارش احساسات فن‌آوران Dice 2021، ۳۶% از پاسخ‌دهندگان به خود امتیاز دادند فرسودگی شغلی چهار یا پنج در مقیاس پنج درجه ای، و ۴۸٪ گزارش کردند که احتمالاً کارفرما را تغییر می دهند.
من معتقد نیستم CIOها، CTOها، رهبران تحویل و مدیران توسعه نرم‌افزار بخواهند توسعه دهندگان نرم‌افزار خود را ببینند که از کار افتاده و به استعفای بزرگ بپیوندند. بنابراین، در حالی که من چندین راه برای مدیریت توسعه‌دهندگان نرم‌افزار پیشنهاد می‌کنم، رهبران باید نسبت به محیط کاری امروز و موقعیت شخصی هر توسعه‌دهنده همدلی داشته باشند.
یک راه برای ایجاد تعادل، کار با منابع انسانی برای تعیین اهداف و اهداف زندگی کاری است. توسعه دهندگان باید این اهداف را شخصی سازی کنند و سازمان و مدیران باید آنها را محرمانه نگه دارند. یک هدف کار و زندگی می تواند تعادلی ایجاد کند که بسیاری از توسعه دهندگان امروزه برای احساس حمایت به آن نیاز دارند.
در نهایت، مدیریت و اندازه‌گیری عملکرد مستلزم بحث‌های مکرر بین مدیر و کارمند است. آیا ما بر اساس اهداف و معیارهای موفقیت همسو هستیم؟ آیا ما استانداردها و محدودیت ها را درک می کنیم؟ حتی زمانی که معیارها شاخص‌هایی را ارائه می‌کنند، اغلب بحث و اقدامات بعدی است که منجر به بهبود عملکرد می‌شود. مردم اینطوری کار می کنند.
پست های مرتبط
نحوه مدیریت توسعه دهندگان نرم افزار بدون مدیریت میکرو
نحوه مدیریت توسعه دهندگان نرم افزار بدون مدیریت میکرو
نحوه مدیریت توسعه دهندگان نرم افزار بدون مدیریت میکرو