Hedefler işe yaramasa bile geliştiriciler için hedefler belirleme zorunluluğu [kapalı]

Edilir genel kabul görmüş olduğu ölçülebilir hedefler koymaya yazılım geliştiriciler için çalışmalarını değil hedefleri üzerine fazla kuruluş amaçları davranış sayaç yol açabilir olarak, (sözde " ölçüm disfonksiyon ").

Ancak benim şirketimde, tüm personel için hedefler belirlememiz gerekiyor ve İnsan Kaynakları tarafından onları AKILLI hale getirmemiz için teşvik ediliyoruz . Geçmişte, birinci kademe yöneticilerim (takım liderleri) ve ben birkaç yaklaşım denedik:

1. Normal işe ek ölçülebilir hedefler belirleyin, örneğin "X teknolojisi hakkında eğitim yapın", "Kimsenin anlamadığı Y kodu parçası için belgeler oluşturun" ve benzeri. Yıllık performans değerlendirmesine gelince, geliştiricileri yazılı hedeflere göre değil, normal çalışmalarının ölçülemez değerine göre değerlendirin, çünkü aslında şirketin önemsediği şey budur.
2. "Görev yönetim sistemi tarafından kaydedilen çalışma günleri", "ortaya çıkan hataların sayısı", "neden olunan üretim sayısı" gibi çok özel hedefler belirleyin. Bu, daha iyi "puanlar" elde etmek için şişirilmiş tahminlere ve hataların yanlış sınıflandırılmasına yol açtı. İlginç bir şekilde, bu sistemde yüksek puan alan geliştiriciler bile bundan hoşlanmadı, çünkü takım içindeki içsel güven zedelendi ve her zaman yüksek konumlarını hak ettiklerini hissetmediler.
3. "Normal işinizi iyi yapın" da değişkenler olan belirsiz hedefler belirleyin. Yıllık değerlendirme söz konusu olduğunda, derecelendirmeleri hedeflere karşı performansı yansıtır, ancak hedeflerin kendileri ölçülebilir veya ulaşılabilir değildir, bu da hoş karşılanmaz.

Bunların hiçbiri ideal değil. Etkililiklerine karşı kanıtlara rağmen yazılım geliştiriciler için anlamlı, ölçülebilir hedefler oluşturmak zorunda olduğunuz benzer bir durumda olduysanız, hangi yaklaşım sizin için en iyi sonucu verdi?

Aynı noktayı tam olarak ele almayan bulduğum ilgili sorular:

• Bir yazılım mühendisi için bazı iyi performans hedefleri nelerdir?
• Geliştiriciler için Performans hedefleri belirleme
• Programcılar için uygun performans göstergeleri nelerdir?
• Programcılar için adil bir verimlilik ölçüm tekniği nedir?
• Önümüzdeki yıl için bazı kariyer "Hedeflerine" ihtiyacım var

Güncelleme (18 Kasım 2009): Sorum için 10 olumlu oy var ve en yüksek puanlı yanıtlarda yalnızca 4 olumlu oy var (her biri benden bir tane dahil). Bu bize bir şey anlatıyor düşünüyorum: Joel ve diğerleri haklı belki de bu ve stackoverflow birleşik bilgelik ile gelip olamayacağını herhangi olumsuz doğrudur (ölçülemeyen) değerini etkilemeden oynanabildiğinden edilemeyen geliştiriciler için zorlayıcı, ölçülebilir hedefler onların iş. Yine de denediğiniz için teşekkürler!

sizin için en iyi olan yaklaşım hangisi?

Tek bir hedef: ben bir kod teftişini / meslektaş incelemesini, gözden geçiren olarak benimle, herhangi bir hata bulmadan veya başka bir eleştiride bulunmadan, senden bir şeyi yeniden yapmanı istememe neden olacak.

Notlar:

• Yeni işe alımların hızlı bir şekilde bitirme yeteneklerini ölçmüyordum ve onları şunlara teşvik etmedim: İnsanların nasıl iyi bitireceklerini öğrenmelerini istedim (çünkü eğer iyi bitmemişse bitmemiş sayılır)
• İnsanlar aradıklarımı bir kod incelemesinde öğrendiler: yani bu bir öğrenme fırsatı ve kalite kontrol ölçüsü ve sadece bir yönetim hedefi değil
• Yorumlarımın iki kategorisi olacaktır:
  1. Bu bir hatadır: check-in yapmadan önce bunu düzeltmelisiniz
  2. Bir öneri olarak, falan filan yapardım
• Bir süre sonra, bir kişinin koduyla ilgili incelemelerim "düzeltilmesi gereken" öğeleri bulmayı bırakacaktı (bu noktada artık çalışmalarını incelememe gerek kalmayacak).

Kişisel olarak iki tür hedef belirlemeye çalışıyorum:

• İş odaklı hedefler (sonuçta bu yüzden para alıyoruz). Örneğin, "X projesini 1 Haziran 2009'a kadar tamamlayın"). Bu hedefler genellikle ekibin birkaç üyesi arasında paylaşılır (ve bunun farkındadırlar). Ekip, projeyi erken getirerek veya gerekli işlevselliği aşarak hedefi aşabilir. Bireyler, daha fazla işlevsellik üreterek, onlara karşı daha az hataya sahip olarak veya takımın diğer üyelerine koçluk yaparak ve destekleyerek hedefi aşabilirler.

• Kişisel gelişim hedefleri, örneğin geliştiricinin beceri setine eklemek istediği bir teknolojiyi içeren bir projeyi tamamlamak, kullanıcının alanını daha iyi anlamak, liderlik deneyimi kazanmak vb.

Aşağıdakilerin önemli olduğunu düşünüyorum:

• Hedefler SMART
• Hedefler, işletmenin ihtiyaçları ile uyumludur
• Hedeflere "normal çalışmayı" dahil ediyorsunuz, aslında bunlar en önemli hedeflerdir!
• Çalışanın belirlediğiniz hedefleri aşma fırsatı vardır

Son olarak, hedef olarak yazılım ölçülerinden uzak dururdum - oynaması çok kolaydır ve muhtemelen size ihtiyacınız olanı vermezler. Yalnızca birine belirli bir davranışın içinde veya dışında koçluk yapmak istediğim durumlarda bir ölçü kullanırdım.

Tüm bunlar, "birinci seviye yönetimin" ve çoğu yönetimin çalışanlarını tanımadığı gerçeğine dayanıyor. Gerçek günlük planlama ve geliştirmenin bir parçası olmak yerine, SMART gibi şeyler ortaya çıkıyor. Yöneticiler asıl işi yapan adamlarla daha fazla zaman geçirirlerse, bunların hiçbirine gerek kalmaz.

Şahsen, geliştiricilerin üretkenlik ve kalite bilinci açısından kimin performans gösterdiğinin açıkça görüldüğü çevik bir ortamda çalışmayı tercih ediyorum . Gerçek bir çevik yaklaşım, yalnızca geliştiricilerin değil, tasarımcıların, test uzmanlarının, müşterilerin ve ürün yöneticilerinin sürece dahil edilmesini gerektirir. Bu, doğal olarak yöneticilerin bakış açısından daha iyi içgörüler sağlar.

Şimdiye kadar gördüğüm ölçülebilir hedefler:

• Bir sertifika sınavını geçin
• X teknolojisi araştırın ve bununla ilgili bir sunum yapın
• Yapılan derleme sonundaki değişikliklerin sayısı
• İç bilgi yönetimi üzerine yazılmış wiki makalelerinin sayısı

Geliştiricilerinize kişisel gelişim için daha sonra hedefler için kullanılabilecek bazı fikirleri olup olmadığını doğrudan sormaya ne dersiniz?

Çalışmasalar bile geliştiriciler için hedefler belirleme zorunluluğu

Geliştiricileriniz işe yoksa, belki bazı hedefleri şunlardır sadece onlara bazı teşvik vermek gerekenler? ;-)

"Kodunuzun en az% n'sinin uygun bir birim testi ile test edildiğinden emin olun" Bunu kanıtlamak için bir kapsam aracı kullanın ve test kalitesi için başka birinin incelemesini sağlayın.

Önceden çok özel hedeflere sahip olmak, yani SMART (belki aynı yerde çalışıyoruz) pratikte iyi bir fikir gibi görünse de çoğu takım için pek pratik değil.

Sorun gerçekten artan hedeflerimizin değişmesidir. İş değişir ve geliştiriciler olarak, uygun bir şekilde ve makul bir süre içinde tepki vermemiz ve tepki vermemiz gerekir.

Ekibinizin veya grubunuzun organizasyondaki amacına uygun hedefler belirlemeyi düşünün. Ekibiniz bir amaca - makro amaca hizmet etmeseydi finanse edilmezdi. Ekibinizin tamamında var olan ve işle uyumlu ortak hedeflere sahip olun. İnsanlara sorumluluk verin ve insanları sorumlu tutun. Başarılarını ve başarısızlıklarını kutlayın (eğer bazen başarısız olmazsak, muhtemelen denemiyoruz ve insanlardan istediğiniz şey budur). HTH

Programcılar çalışırken toplanan bir dizi metrikimiz var, örneğin:

• Değiştirilen / eklenen SLOC sayısı
• Sürecin çeşitli aşamalarında enjekte edilen hataların / hataların sayısı (akran değerlendirmesi sırasında, akran değerlendirmesi sonrası, yayın sonrası)
• Değişiklik istekleri yerine getirildi / reddedildi
• Resmi belgeler (yazılım sürüm açıklamaları, tasarım belgeleri vb.)

Bunların tümü, yönetim ve yazılım kalite güvencesi sunumlarında faydalı bulduğum somut öğelerdir. Ancak, bunları insanların performansının gerçek değerlendirmelerinde hiç bir zaman çok yararlı bulmadım - bu, listelediğiniz bağlantıların birçoğunun işaret ettiği noktadır. Joel'in puanlarını burada buldum geçerlidir - ölçümlerini iyi bir takım atmosferi teşvik olmadı.

Ne yazık ki, hepimiz metriklerin başkaları tarafından gerekli görüldüğü bir dünyada yaşıyoruz (yönetim, kalite güvencesi, dış yükleniciler vb.). Dengeleyici bir eylemin gerekli olduğunu buldum - bu ölçütleri sağlamak, ama aynı zamanda maddi olmayanlara ilişkin kanıtlar sağlamak - her programcının başardığı, mutlaka izlenmeyen, maddi olmayan şey. Örneğin, başka hiç kimsenin dokunmak istemediği eski kodu araştırmak için çok zaman harcayan bir programcım vardı. Ölçütleri o dönem için düşük olsa da, bu çaba paha biçilemezdi.

Bu tür şeyleri dahil etmenin tek yolu, ek bir soyut kategori yaratılması ve diğer ölçütlerle eşit ağırlık verilmesi oldu. Genellikle bu, belirli bir programcı için dengeyi değiştirmek için yeterlidir.

Sorunlardan biri, bir bölüm / departman olarak BT organizasyonlarının ölçülebilir stratejik hedeflere sahip olmaması gibi görünüyor. Yapsalardı bireyler için hedefler belirlemek daha kolay olurdu.

Örneğin, ortaya çıkan sorunlu biletlerin sayısını azaltmak için bir departman girişimi varsa, baktıkları yazılımla ilgili çağrı sayısına dayalı olarak bir kişinin hedeflerini belirleyebilirsiniz.

Yazılım geliştirme büyük ölçüde bir işbirlikçi olduğundan, ekip düzeyinde hedefler belirlemek ve ardından bireyleri takıma yaptıkları katkıya göre değerlendirmek daha mantıklı olacaktır.

Sevdiğim bir hedef:

Proje müşterisinden bir projeye katılımınız hakkında N olumlu yorum isteyin.

Bu, müşterilerden (dahili veya harici) yazılı olumlu geri bildirimler almak her zaman iyi olduğu için yardımcı olur. Alması zor değil, alakalı ve listede kolay ama anlamsız olmayan bir işaret.

Kişisel gelişimin yapılan projelerle nasıl uyumlu hale getirileceğini belirlemek bence önemli bir nokta. Geliştiricilerin zayıf yönleri bulmak için kendilerini analiz etmeleri ve başkaları hakkında geri bildirim vermeleri, neyin iyileştirilebileceğini bulmanın ve ardından onu ölçmenin bir yolunu bulmanın bir yolu olabilir. Örneğin, tamamlanmış kalemleri nadiren belgelediğimi görebilirim ve bu nedenle yıl için hedeflerimde bunu geliştirmek istediğimi ve ürettiğim belge miktarının bunun bir ölçüsü olabileceğini söyleyebilirim. Gerçekten nasıl takip ettiğime bağlı olarak işe yarayabilir veya geri tepebilir. Bir yandan, işimi nasıl geliştirdiğime ve uygun bir yol olarak görülebilecek şeyi yaptığıma dair geçerli endişeler olabilirken, pasif agresif veya çocukça bir görüş, eğer değilse bir yığın belge üretmek olabilir.

Etkili bir geliştirici tanımlamak, bunun başka bir unsurudur. Hataları en iyi düzelten kişi mi? Yeni işler en hızlı mı? Yeni işler, hızlı yapılmasa bile testler ve belgelerle tamamlanıyor mu? Aradığınız Ne etkili beri "değişir" standart tepki Burada açıklığa kavuşturulmalıdır.