Tanıdığım En Kötü Programcı (2023)

• Bu yazı, ekip verimliliğini ölçme girişiminin nasıl başarısız olduğunu anlatıyor
• Bireysel değerlendirme ve gelişim amacıyla bireysel performans göstergeleri kullanılmasına karar verildi
  • Kod satırı sayısı veya hata sayısı kolayca manipüle edilebildiği için bunlar dışlandı; bunun yerine performansın story point ya da teslim edilen story sayısı ile ölçülmesine karar verildi

Tim Mackinnon’ın performansı ‘0’

• Ekibin verimliliğini ölçen araçlar (Jira vb.) üzerinden tüm ekip üyelerinin performansı ölçüldü
• Tim’in performans puanı 0 çıktı → çünkü hiç story point kaydetmemişti
• Yönetici, Tim’in performansı 0 olduğu için değiştirilmesini istedi

Tim Mackinnon neden performans üretmiyordu?

• Tim doğrudan herhangi bir story’nin sorumluluğunu almıyordu
• Bunun yerine ekip arkadaşlarıyla pair programming yapmaya odaklanıyordu
  • Daha az deneyimli geliştiricilerle çalışarak onların sorunları çözmesini sağlıyordu
  • Sorunu kendisi çözmek yerine sorular sorarak çözüme ulaşmalarına yardımcı oluyordu
  • Kıdemli geliştiricilerle ise sorunları birlikte düşünüp çözümü iyileştiriyordu
• Tim doğrudan kod yazmasa da ekibin genel performansını artırıyordu

Tim Mackinnon’ın gerçek katkısı

• Tim’in katkısı bireysel performans puanıyla ölçülemezdi
• Tim sayesinde tüm ekibin verimliliği ve kod kalitesi arttı
• Tim birlikte çalıştığında daha hızlı ve daha iyi sonuçlar alınabiliyordu

Değerlendirme yöntemi ekip verimliliğine göre değiştirildi

• Yöneticiye Tim’in katkısı anlatıldı ve bunu gözlemlemesi için fırsat verildi
• Tüm ekibin performansının arttığı görüldükten sonra bireysel performans ölçümünden vazgeçildi
• Değerlendirme, bireysel performans yerine ekip performansı ve iş etkisi temelinde yapılmaya başlandı

Özet (tl;dr)

• Verimlilik, iş sonuçlarıyla (ör. maliyet tasarrufu, gelir yaratma vb.) ölçülmelidir
• Karmaşık sistemlerde bireysel performans ölçümü anlamlı değildir
• DORA Metrics gibi ölçümler, bireysel katkıyı değil sistem performansını ölçmek için kullanılan araçlardır
• Tim Mackinnon ile çalışma fırsatınız olursa bunu kaçırmayın

[bus710]

Aslında senior seviyesini aşıp staff engineer düzeyine gelince, giderek sahaya dağıtılan koddan uzaklaşıyorsunuz.... onun yerine senior/junior ekiplere daha çok koçluk yapar hale geliyorsunuz gibi görünüyor. Yöneticilerin dertlerini de dinlemek gerekiyor.... bir sorun patlayınca oradan oraya çağrılıp çözüm önermeniz gerekiyor....

Yapılan iş bu tarz olunca Jira ticket’larını ve puanları da nicel olarak ölçmek imkansız oluyor.

[castedice]

Teknik lider olarak bu tür işleri epey sık yapıyorum. Story point tabanlı nicelleştirmeyi denemek de buna benziyor; neyse ki şirket çok büyük olmadığı için yöneticiler dahil ekiptekiler benim nasıl bir rol üstlendiğimin farkında, bu yüzden şimdilik bir sorun çıkmıyor gibi görünüyor.
Organizasyon büyürse nicelleştirme yöntemleri üzerine düşünmem gerekecek gibi görünüyor.

[kallare]

Sanki bir yerde gördüğüm bir hikâyeydi diye düşündüm... meğer 2023 tarihli bir yazıymış
Aynı yazı 2 yıl önce de paylaşılmıştı https://tr.news.hada.io/topic?id=10680

[crawler]

GitHub Copilot gibi birisiniz sanırım....

[GN⁺]

Hacker News görüşleri

• Bireysel geliştiricinin üretkenliğini ölçmek saçma. Kod satırı ya da story point ölçmek, üretkenliğin tam tersidir. Önemli olan geliştiricinin daha az kodla daha fazla değer üretmesidir

  • İş sonuçlarını ölçmek önemlidir, ancak bunu belirli bir geliştiriciye atfetmek zordur
  • Sonuçta öznel yargılara dayanmak zorunda olunduğunu kabul etmek daha iyidir

• Sorunu çözmek için Tim'in adını ticket'a ekleme yöntemini buldum. Ekip üyeleri memnuniyetle yardımcı olacaktır

  • Üretkenlik metrikleri tamamen değersiz değildir. Ekip içinde PR ile Jira ticket'ları arasındaki orana bakarak ekip liderini tahmin edebilirsiniz

• Tim'in ekipte kalıp süreci doğru yöne yönlendirmesine sevindim. Dinleyen yöneticilere ihtiyaç var

  • OKR'ler yüzünden geliştiriciler izole oluyor. Ekip temelli değil birey temelli OKR'ler sorun çıkarır
  • Sorun çözmek uzun zaman alır. OKR'ler yüzünden yardım alınamıyordu

• Bir programcının kişisel işi olmadan sadece sürekli yardım vermesi modeli tuhaf

  • Tim'in başkalarıyla birlikte story'ler üzerinde çalışması ve yardıma ihtiyacı olduğunda gruptan istemesi daha sağlıklı bir durumdur
  • Ekip çok dengesizse Tim bir mentor rolü üstlenmelidir

• Tim'in bireysel iş yapmaması garip. Ekip üretkenliğini en üst düzeye çıkarmak için bireysel katkı ile ekip iş birliği arasında denge gerekir

  • Tim fazla sabırlı davranıp zaman kaybetmiş olabilir

• Tim ekibe katkı sunmuyorsa ona işe başlayıp story teslim etmesini söylerdim. Tim'in başkalarına yardım etmesi iyi ama kendi işini de yapmalı

• Her şeyin grup etkinliği olması gerekmez. Ortalama bir geliştirici Tim'in sürekli yardımı olmadan bir özelliği teslim edemiyorsa ekipte bir sorun vardır

  • Yazılım geliştirme hem bireysel hem de grup çalışması için zaman gerektirir

• En iyi ekiplerde her zaman Tim gibi biri vardır. Tim'in yardımı başkalarına da yayılır ve tüm ekip büyür

  • Geliştirici tıkandığında önce kendi başına çözmeye çalışır, gerekirse yardım ister

• Geliştirici üretkenliğini story point ile ölçmek iyi değildir. Zero adlı bir geliştirici story atanmadan ekibe yardım ediyordu

  • Yönetici Zero'nun önemini anlıyordu. Zero olmadığında önemli bir release'i bile erteliyordu

• Desteğin değerini nicel olarak belirlemek zordur. Ama destek zorunludur. Liderlerin doğru değerlendirme yapabilmesi için onlara güvenmek gerekir