[ad_1]
Benimki gibi mühendislik firmalarını işe alan iş liderleri, yarattığımız değeri ölçtüğünü iddia eden rakamları, metrikleri görmek ister. Okunabilirliği ve kısalığı artırmak için yeniden düzenlemenin ezoterik inceliklerini anlayamasalar da, kod kapsamının %85’ten %90’a yükseldiğini anlayabilirler. Rakamlar artıyor! Yani değerli bir şey oluyor olmalı, değil mi?
Sorun şu ki, bu sayıların çoğu saçmalık ve geçerli önlemler bile yönetim araçları kadar iyi çalışmıyor. Metriklerin yeri vardır, ancak yarattıkları çözümlerin kalitesini ve değerini ölçmek için ekiplerin nereye gittiğini takip etmelidirler. Metrikler öne çıktığında – hikaye noktaları geliştiricilerin nereye gitmesi gerektiğini belirlediğinde – aslında ekiplerin yenilik yapma, yaratma ve anlamlı sorunları çözme becerisinin önüne geçerler.
Etkili mühendislik ekipleri tarafından geliştirilen gerçekten değerli yazılım çözümleri için, liderler bunun yerine morali, geliştirici memnuniyetini ve ekip odağını yönetmeli, ardından verimliliği, kaliteyi ve herkesin gelişebileceği bir şirket kültürünü yönlendirmek için bunlara güvenmelidir.
Metrikleri yönetmek verimsiz ve etkisiz
Oldukça önemsiz bir örnek düşünün. Bir mühendislik ekibi, her sprintte sürekli olarak 20 bileti nakavt ediyor. Metrikler harika, ekip açıkça onu öldürüyor ve ürün sahibi paydaşlarına mükemmel ilerleme bildirebilir.
Ama sonra biraz daha yakından bakarsınız ve bu ekibin haftada 60 saatlik bir dizi çalışarak bu sayılara ulaştığını keşfedersiniz. Yorgunlar, tükenmişler, arkadaşlarını ve ailelerini özlüyorlar ve yarattıklarının değerinden bile emin değiller. Gözleri kör ve karpal tünelli, metalaştırılmış robotlar, sonsuz bir hat boyunca kod toplayan otomatlar gibi muamele görüyor ve hissediyorlar.
Metrikler harika görünüyor, ancak moral korkunç.
Daha yakından bakın ve neredeyse kesinlikle kodlarının kalitesinin düştüğünü ve çözümlerinin potansiyel değerinin bastırıldığını göreceksiniz. Çok az otomatik test, küçük yeniden düzenleme ve çok sayıda hack bulacaksınız. Daha fazla teknik borç, ölçeklendirme sorunları ve istenen kullanıcı deneyimi ile uygulanan kod arasındaki bağlantı kopukluklarını bulacaksınız.
Mühendisleriniz kaliteye önem veriyorsa – ki bunu yapmayanları işe almamalısınız – daha düşük bir iş yaptıklarını bilirler ve moralleri daha da düşer.
Bunun yeterince uzun sürmesine izin verin, yakında başka bir maliyetle karşı karşıya kalacaksınız: kayıp yetenek ve bir projenin ortasında yeni mühendislerin işe alınmasındaki gecikmeler ve eksiklikler.
Ancak moral yerine metrikleri yönettiğiniz için tüm bu sorunları çok geç olana kadar görmeyeceksiniz.
Morali yönetmek, misyona, özerkliğe ve ustalığa odaklanmak
Tamam, itiraf etmeliyim ki, “moral” dünyasını kısmen, “yönet” ve “ölçüler” ile aliterasyon yaptığı için şiirsel olarak hoş bir manşete yol açtığı için seçmiş olabilirim. “Moral” in bazen kutlama ofis pizza partileri ve kurumsal kumbaya ile ilişkili olduğunu biliyorum.
Ancak burada çalışanlara dağıtılan, karizmayla kaplanmış ve suni teşviklerle güçlendirilmiş toksik motivasyonel saçmalıklardan bahsetmiyorum… keyfi ölçülere ulaşmak için ödüller gibi teşvikler.
Bunun yerine ekiplerinize her projenin başarısına sürdürülebilir bir şekilde yatırım yapmaları için ilham veren moralden bahsediyorum.
Olarak Daniel Pembe 2009 en çok satan kitabında yazdı, Drive: Bizi Motive Eden Şeyle İlgili Şaşırtıcı Gerçekgerçek içsel motivasyon – yatırılmış moral, diyebiliriz – özerklik, ustalık ve amaçtan gelir.
Yapay metriklere bağlı işlemsel ödüller, keyfi bir süreçle temel uyumu zorunlu kılabilir, ancak etkili bir yazılım mühendisliği ekibinin yenilik yapma, anlamlı sorunları çözme ve önemli yeni değer yaratma konusunda tam, odaklanmış potansiyelini asla açığa çıkaramazlar. Bunun yerine, mühendislerinizin bir projenin amacına yatırım yapmasına, çözümü sahiplenmesine ve ürettikleri çözümün kalitesinden gurur duymasına ihtiyacınız var.
Moral, misyona dayanır (metriklere değil)
Bir hücrede oturacak ve kendilerine verilen her işi uyumlu bir şekilde yapacak olan “Kunduzuna Bırakın” işgücü çoktan gitmiştir. Alanımıza artık Millennials ve Generation Z hakimdir ve bu nesiller özünde misyonerdir. Tamamen işlemsel istihdamı reddederler. Birçoğu ilkeli ve amaç odaklı şirketlerde çalışmak istiyor.
Gerçekte, tüm iyi geliştiriciler – nesilleri ne olursa olsun – ilginç problemlerin üstesinden gelmek, teknik borç olmadan kaliteli kod oluşturmak ve hizmet ettikleri kişilere değerli çözümler üretmek isteyen ilkeli insanlardır. (Ve yine, bu niteliklere sahip olmayan geliştiricileri işe almayın.)
Arzularını yönlendirmek için anlamsız ölçümlere ihtiyacınız yok. Sen yapmak ekiplerinizin her projenin misyonuyla bağlantı kurmasına, başarılarının önündeki engelleri ortadan kaldırmasına ve en iyi çalışmalarını yapmak için ihtiyaç duydukları her şeyle onları desteklemesine yardımcı olmanız gerekir.
Mühendislerinize projenin amacını açıklayacak ve tartışacak kadar saygı gösterin. Ne yapmaya çalışıyoruz? Bunu neden yapıyoruz? Amaç ne? Felsefe nedir?
Görevin dünyayı kurtarmakla ilgili olması gerekmiyor. Elbette, iklim değişikliğiyle mücadele eden, halk sağlığı krizlerinde hayatları koruyan veya ahlaki evrenin yayı boyunca iğneyi adalete doğru hareket ettiren projeler üzerinde çalışmak için her fırsatı değerlendirin. Bunun gibi asil görevler ekiplerinize derinden ilham verecek.
Ancak, misyonların yatırıma ilham vermesi için çok büyük olması gerekmez. Bir misyon, “ilginç sorunları çözen iyi, etik bir yazılım uygulamak” olabilir. Sorun, “uzun yol kamyoncuları, ailelerinin ev faturalarını ödeyebilmesi için maaş çeklerini yatırmak için mücadele ediyorsa” veya “eski bir altyapı, çok aileli konut mülkleri için önemli bir kontrol sistemi için yeniliği boğuyorsa” sorun değil. (Bunların ikisi de şirketimin müşterilerinin çözmesine yardımcı olduğu gerçek problemlerdir.)
Değerli sorunları çözmek için kaliteli kod oluşturma misyonu onurlandırıldığı ve önemli ölçüde desteklendiği sürece ve keyfi ölçümlerin bu misyonu tehlikeye atmasına izin verilmediği sürece, sorunların küresel olması gerekmez.
Moral, özerklikte etkinleştirilir (metrikler değil)
Paylaşılan bir misyon duygusu harikadır, ancak daha sonra bir ekibin bu misyonun yerine getirilmesine nasıl katkıda bulunduğunu mikro yönetirseniz, motivasyon gücü geri alınır.
“Biz” bir endüstriyi dönüştürüyor, hayat kurtarıyor veya insan başarısının ufkunu genişletiyor olabiliriz. Ama eğer sen tüm sonuçsal kararları verin, ardından mühendislerinizin günlük deneyimi, metriklerini karşılamak için bilet kotalarını kapatmaya indirgenir. Görevden çok uzaktalar. Bu onları çok daha az motive eder ve eleştirel düşünme ve yaratıcılıklarının tüm potansiyelini kaybedersiniz.
Etkili mühendislik ekipleri büyük ölçüde özerktir. Paydaşların ve kullanıcıların misyonunu ve özel ihtiyaçlarını anlamalarına yardımcı olursunuz. Teknik çözüm için bazı temel temel kurallar ve korkuluklar belirlersiniz. Ardından, yollarından çekilin ve onları en iyi yaklaşıma yönlendirmek için kalite odaklı değerlerine güvenerek en iyi yaptıkları şeyi yapmalarına izin verin.
Otonom bir ekibin hala akıllı bir gözetime ve iyi bir liderliğe ihtiyacı var. Geliştirici anarşisi çalışmıyor ve kaos motive edici değil. Ancak mühendislerinize, onlara verdiğiniz sorunları çözme konusunda güvenin. Potansiyel zorlukları belirlemeleri ve daha iyi çözümler üretmeleri için onlara güvenin. Proje misyonunun yerine getirilmesini yönetmek için onlara güvenin.
Ve ekiplerinize bu güveni veremiyorsanız, yanlış insanları işe alıp almadığınızı veya doğru insanları iyi yönetmediğinizi veya keyfi süreçlerin mühendisliğin önüne geçmesine izin verip vermediğinizi inceleyin. Metrikler bu sorunları çözmez. Kalite iradesine ortak bir bağlılık içinde özerkliğe odaklanma.
Moral, ustalıkla iyileşir (ölçülerle değil)
“Ustalık” hakkında konuştuğumuzda, genellikle bireysel mühendislerin beceri setleri ve bu becerileri geliştirmek için sahip oldukları fırsatlar hakkındadır. Ancak ustalık aynı zamanda sistemseldir. Organizasyonel kararlar ve süreçler, mühendislerin ve ekiplerin gurur duyabilecekleri kaliteli işler yapma yeteneklerini destekleyebilir veya engelleyebilir.
Mühendislerinizin net bir yön duygusu var mı? İhtiyaç duydukları araçlara ve bunları iyi kullanmak için kesintisiz zamana sahipler mi? Zaman çizelgelerinin belirlenmesinde söz hakları ve önemli kararlar alma yetkileri var mı?
İşi doğru yapmak için yeterli zamanları var mı? Keşfetmek ve öğrenmek için mi? Dinlenmek, düşünmek ve restore etmek için mi? Çözümlerini düzgün bir şekilde dağıtmak ve ölçmek için mi?
Yoksa metriklerin zorbalığı onları özensiz kod olduğunu bildikleri şeyi göndermeye ve bir sonraki bilete acele etmeye mi itiyor? Gereksiz toplantılar ve keyfi süreçlerle dikkatleri dağılıyor mu? Fazla mı çalışıyorlar ve yanıyorlar mı?
Abi Nodakurucu ortak ve DX’in CEO’su, bu sistemik faktörleri, geliştirici etkinliğini ve iş başarısını doğrudan etkilediğini söylediği “geliştirici deneyimi” (DX) çatısı altında topluyor. Bu, Noda’nın birlikte yazdığı bir konu. Dr. Michaela Greiler ve Margaret-Anne Katlı, “Geliştirici Deneyimini Anlamak ve Geliştirmek için Eyleme Geçirilebilir Bir Çerçeve” (PDF) içinde Yazılım Mühendisliği Üzerine İşlem Dergisi. ve bir DX teknik incelemesi ne çıktı ne de süreç metriklerinin geliştirici deneyimini doğru bir şekilde ölçemeyeceğini iddia ediyor.
Bir güven ve saygı kültüründe liderler, ekiplerinin kaliteli yazılım üretmek istediği varsayımıyla başlar. Bu ustalığı ölçmek veya zorunlu kılmak için metrikleri kullanmazlar. Bunun yerine ekipleriyle açık, güvenli ve dürüst konuşmalar yaparlar. Burada ne yapmaya çalışıyoruz? (Görev.) Yolunuza ne çıkıyor? (Özerklik.) En iyi işinizi yapmanızda size nasıl destek olabiliriz? (Ustalık.)
Bu konuşmalar ortak bir amaç anlayışına dayanır ve her mühendisi ve her takımı memnuniyet ve başarılarında desteklemek için tasarlanmış sistemsel değişikliklere yol açar.
Morali yönetmek, daha iyi çözümlere, daha iyi elde tutmaya ve daha iyi bir şirket kültürüne de yol açar
Moral, keyifli bir çalışma ortamından ve iyi çalışan memnuniyeti puanlarından çok daha fazlasıdır. Yazılım mühendisleri bir projenin misyonuna yatırım yaptıklarında, onu en iyi düşündükleri gibi çözme özerkliğine güvendiklerinde ve ellerinden gelenin en iyisini yapmak için ihtiyaç duydukları destek verildiğinde, gözle görülür şekilde daha iyi, daha değerli çözümler üretirler.
Ayrıca şirketinizde kalma olasılıkları çok daha yüksektir. Haber yayıldıkça, ek yetenekleri işe almak da kolaylaşacak.
Ve evet, morali yönetmek aynı zamanda daha iyi bir şirket kültürüne, daha iyi bir topluluğa yol açar. Sizin ve ekibinizdeki herkesin, gerçekten dönüştürücü yazılım çözümleri oluşturmak için bireysel ve toplu yeteneklerinizin en iyisini uyguladığınız için parçası olmaktan keyif alacağı bir program.
Telif Hakkı © 2022 IDG Communications, Inc.
[ad_2]
Kaynak : https://www.infoworld.com/article/3667377/manage-morale-not-metrics-for-more-effective-engineering-teams.html#tk.rss_all