Çevirmenin Notu:

McKinsey, 2023 yılının Ağustos ayında yazılım dünyasında ilgili kişiler tarafından çok tartışılan “Evet, yazılım geliştiricisi verimliliğini  ölçebilirsiniz” isimli bir makale yayınladı. Büyük tartışma yaratan bu makaleye çevik yazılım geliştirme dünyasının öncü isimlerinden teknoloji danışmanı Daniel Terhorst-North kendi web sitesinde detaylı bir inceleme yazısı ile yanıt verdi. Aşağıda Sharpware olarak önemli bulduğumuz bu inceleme yazısının çevirisine yer veriyoruz.

McKinsey yakın zamanda geliştirici verimliliğinin ölçülebileceğini iddia eden bir makale yayınladı. Bu, önde gelen bazı yazılım uzmanlarının tepkisine neden oldu, ancak kimsenin makalenin içeriğiyle ilgilendiğini görmedim, bu yüzden bu değerlendirmeyi yazmanın yararlı olacağını düşündüm.

Bunu, sanki yazarlar makalelerinin teknik incelemesi için bana ulaşmış gibi yazıyorum. Bunu açık bir mektup olarak düşünebilirsiniz.

Sevgili Chandra ve ekibi,

Beni makalenizi incelemeye davet ettiğiniz için teşekkür ederim. Bunun beni ilgilendiren bir alan olduğunu düşünmekte haklısınız; yıllar boyunca üzerinde düşünmeye ve konuşmaya çok zaman harcadığım bir konu.

Yazınızı okudum ve aşağıda ayrıntılarıyla anlatacağım bazı notlar aldım. Bu önemli bir konu ve McKinsey birçok üst düzey teknik kişinin dinlediği yüksek profilli bir şirket, bu yüzden onların yararlı ve doğru bulacağı bir makale yazmanıza yardımcı olmak istiyorum. Geri bildirimimin bu kadar uzun ve ayrıntılı olmasından dolayı özür dilerim; ele almak istediğim çok şey var ve harika bir makale yazmanızı istiyorum.

Birkaç zayıf noktayı, maddi hataları ve daha ileri çalışmalar için konuları belirledim. Ayrıca ele almak isteyebileceğiniz bazı stilistik veya editoryal sorunları vurgulama özgürlüğünü de kullandım. Ne yazık ki, sizin temel argümanlarınıza karşı çıktığımı fark edeceksiniz, bu yüzden sonunda yazılımcıları etkili bir şekilde ölçmek ve geliştirmek için bazı alternatif öneriler sunuyorum.

Başlamadan önce, katkıda bulunan beş yazarın hepsinin erkek olduğunu fark etmeden duramadım. McKinsey büyüklüğünde ve erişime sahip bir şirket için, geliştirici topluluğunun tamamına hitap eden bir makale üzerinde işbirliği yapacak herhangi bir kadın bulamamanıza şaşırdım. Bir dahaki sefere bunu düşünmek isteyebilirsiniz.

Yazılım geliştirme yeterince ölçülmüyor mu?

Yazılım geliştirmenin yeterince ölçülmediği iddiasıyla yola çıkıyorsunuz. Bu yargıya nasıl ulaştığınızdan emin değilim, çünkü bu açıklamayı hiçbir destekleyici kanıt olmadan -makale boyunca defalarca gerçekleşen bir şey-  yapıyorsunuz; bu yüzden bir karşı argüman sunmama izin verin.

Yazılım geliştirme, tüm ticari faaliyetler arasında en acımasızca incelenen ve ölçülen alanlardan biridir. Tarihsel olarak, 1960’lı ve 70’li yıllardan itibaren yazılım geliştirme pahalı ve riskli bir çaba olmuştur. Başlangıçta bu, bilgisayar ve işletim makinelerinin maliyetinden kaynaklanıyordu, daha sonra bu azalıp programcı maaşları arttıkça ücretlendirmeyle ilgili hale geldi.

Her türlü riskli ve/veya pahalı girişimi incelemek mantıklıdır ve ne yazık ki yazılım endüstrisi için, Gantt şemaları, kaynak dengeleme ..vb endüstride (inşaat mühendisliği ve fabrika üretimi) işe yarayan aynı indirgemeci modelleri uyguladık. Bilimsel yönetimin endüstriyel çağından kalma araçlar. Yazılım geliştirmenin bir arabanın montajıyla aynı azaltılabilir karmaşıklığa sahip olduğu varsayımı, geliştirici üretkenliği sorununun merkezinde yer almaktadır.

Çevik hareket, 1990’larda çok yıllı çalışma programlarının kötü sonuçlarından kaynaklanan hayal kırıklığı nedeniyle büyüdü; her ne kadar bunlar en ince ayrıntısına kadar planlanmış, ölçülmüş ve incelenmiş olsa da yine de bütçelerini aşmayı ve yanlış şeyi sunmayı başarmıştı. Bu dönemi öyle adlandıramayacağınız tek şey yetersiz ölçülmüşlük olacaktır . Elbette yanlış ölçüldü ve üretkenliği izleyen ve endişe duyulan alanları öne çıkaran yazılım geliştirme ölçme yolları var, ancak asla yetersiz ölçülmüyor!

Konuyu özetlemek gerekirse, tezinizin iki ana noktasını görüyorum; içeriği incelerken bunlara geri döneceğim ve her ikisi de hatalı:

1. Yazılım geliştirme indirgenebilir bir faaliyettir ve indirgemeci araçlarla ölçülebilir.
2. Yazılım geliştirme öncelikle kodlamayla ilgilidir ve bir bilgisayar terminaline kod yazmak dışındaki her şey, ortadan kaldırmaya çalışmamız gereken israftır.

Her ikisinin de neden yanlış olduğunu ilerledikçe açıklamayı umuyorum.

Üretken yapay zeka araçları(Gen-AI) geliştiricileri iki kat daha hızlı mı yapıyor?

Girişinizde birçok iddiada bulunuyorsunuz. Bunlardan ikisini vurgulamak istiyorum çünkü makalenin başka zayıflıklarının nerede olduğunu anlamanıza yardımcı olacağını düşünüyorum.

Üretken yapay zeka (generative ai) araçları, geliştiricilerin iki kat daha hızlı kod üretmesine olanak sağlayabilir. Bilmiyorum, bunu ölçmedim ya da araştırmaya bakmadım ama sizin sözünüze güveneceğim. Bununla birlikte, birçok büyük ve küçük kuruluşta, birçok programlama dili, paradigma ve teknoloji kullanarak ve birçok iş alanında otuz yıllık uygulamalı geliştirme deneyiminden sonra ve sayısız başkasına danıştıktan sonra, programlamanın çoğunun kod yazmak olmadığını söyleyebilirim.

Programlamanın çoğu iş alanını öğrenmektir; sorunu anlamak; olası çözümlerin değerlendirilmesi; geri bildirim ve deneyler yoluyla varsayımların doğrulanması; bir ürünü sinir bozucu olmaktan çıkarıp yasa dışı hale getirebilecek uyumluluk, güvenlik, kullanılabilirlik, dayanıklılık, erişilebilirlik, kullanılabilirlik gibi işlevler arası ihtiyaçların belirlenmesi, değerlendirilmesi ve karşılanması; ölçeklemede tutarlılığın sağlanması; aşırı mühendislik yapmadan olası değişim vektörlerini tahmin edilmesi; uygun teknolojilerin değerlendirilmesi ve seçilmesi; ister şirket içinde ister üçüncü taraflardan olsun, önceden var olan çözümleri belirlenmesi ve bunlardan yararlanılması.

Ben burada sadece yüzeyini çiziyorum. Gördüğünüz gibi, kodu yazma kısmı tüm bunların yalnızca küçük bir kısmı; dolayısıyla bunu hızlandırmak için Gen-AI’yı kullanmak yararlı olsa da “geliştiricileri iki kat daha hızlı hale getirmek” pek mümkün değil.

İlk sonuçlar umut verici mi?

Profesör Daniel Kahneman, Hızlı ve Yavaş Düşünmek adlı kitabında Küçük Sayılar Yasası’nı tanıtıyor. Araştırmacıların küçük veri kümelerine dayanarak genelleme yapma eğiliminde oldukları nokta burasıdır. Bunu hatalı sezgi olarak adlandırıyor.

Bir danışmanlık işi için çok fazla iş gibi görülebilecek 20 örnek olay incelemeniz var, ancak yine de istatistiksel olarak çok az anlam taşıyor. Başka metodolojik sorunlar da var:

• Herhangi bir kontrol kümesi yok gibi görünüyor; temel olarak bu yöntemi uygulamadığınız veya alternatif hipotez olarak başka bir şeyi denediğiniz benzer ekipler.
• Her ne kadar tartışmalı olsa da, ekiplerin gözlemlendiklerinin farkında olduklarında farklı davrandıkları Hawthorne Etkisini dikkate almıyorsunuz .
• Bu ölçümler için izolasyon yapmıyor görünüyorsunuz. O dönemde bu gelişmeleri açıklayabilecek başka neler olmuş olabilir? Bu yaklaşım nedensel mi, sadece ilişkili mi, yoksa rastlantısal mı?

Bunun hakemli bir makale olmaktan ziyade gayri resmi bir makale olduğunu kabul ediyorum, ancak yeni yayınlanmış bir metodolojiyi etkili bir şekilde anekdot niteliğindeki kanıtlarla “umut verici sonuçlar” gösterecek şekilde sunmak yanıltıcı olabilir.

DORA ve SPACE’in yazarları var!

Akademik titizlikten bahsetmişken, siz de açıkça benim gibi DORA Accelerate araştırmasının ve daha sonraki SPACE modelinin hayranlarısınız, ancak her iki girişimin baş araştırmacısı Dr. Nicole Forsgren’den veya ortak yazarlarından herhangi birinden alıntı yapmıyorsunuz. Dr. Forsgren, Puppet Labs tarafından yürütülen orijinal DevOps Durumu Raporu araştırmalarına önemli bir akademik titizlik uyguladı ve  bu savunulabilir araştırmanın ortaya çıkmasına ve birkaç yıl içinde DORA’nın oluşturulmasına yol açtı.

Bu araştırma sektör analistleri tarafından analiz edildi, eleştirildi, incelendi ve incelemelere dayandı. Bu, pratikte çevik yöntemler üzerine sahip olduğumuz tek bağımsız ve akademik açıdan sağlam araştırmadır ve sektörümüzün yazılım mühendisliğine katkıda bulunan kadınları silme geçmişi vardır, bu yüzden bunu bir sonraki revizyonda düzelteceğinizi varsayıyorum.

Katkı analizi?

Makalenin temel taşı gibi görünen bu bölümün tamamı ne yazık ki tamamen yanlış yönlendirilmiştir. Yazılım geliştirmenin azaltılabilir olduğu yanılgısına düşüyor; tıpkı bir duvar inşa etmek gibi; burada kimin en çok tuğlayı ördüğünü, kimin işinin en düzenli olduğunu veya en az düzeltmeye ihtiyaç duyduğunu ölçebilirsiniz. Yakın zamanda bireysel katkıda bulunan metriklerinin özellikle daha kıdemli geliştiriciler için ne kadar yanıltıcı olabileceğini gösteren bir makale yazdım. Aşağıda bu konuyu irdeleyeceğim.

İkinci yanılgı, programlamanın çoğunlukla kod yazmakla ilgili olduğudur. Tecrübelerime göre kodlama genellikle daha kolay olan kısımdır. Bu onu önemsizleştirmek değil; iyi kod yazmak tecrübe gerektirir. Özellikle, daha az kod yazmak uzun yıllar alır: öncelikli hedefe odaklanmak ve dili, temel kütüphaneleri ve destekleyici ekosistemini, kodu küçük ve yalın tutacak seçimler yapabilecek kadar iyi bilmek.

“Her ihtimale karşı” ihtiyacınız olandan fazlasını yazmak, daha basit bir algoritmanın var olduğunu veya bunun temel kütüphanelerde zaten çözülmüş olduğunu bilmediğiniz için cazip geliyor. Bu, bir geliştiricinin deneyim düzeyini değerlendirmenin kolay bir yoludur: Aynı sorunu çözmek için daha az kodla katkıda bulunanlar, hatta gereksiz veya fazla kodu kaldıranlar genellikle en yüksek değere sahip geliştiricilerinizdir.

En değerli geliştiricilerin kod yazmasını sağlamak ister misiniz?

Ve burası tüm makalenin özü. En değerli geliştiricilerinizin değeri, diğer geliştiricilerin etkinleştirilmesiyle 10 kat artar! Çoğunlukla yapabilecekleri en az yararlı şey kodu kendileri üretmektir.

Goldman-Sachs, insanları özellikle etki ve nüfuza ve şirket içinde ilerledikçe bu değişimlerin dengesine göre değerlendiriyor. Bir kişinin kariyerinin başlarında odak noktası etkidir; ne üretiyorlar, nasıl üretiyorlar. Daha sonra mesele, sadece üst ve alt kademedekileri değil, organizasyonun geneline doğru etraflarındaki kişileri ne kadar iyi etkiledikleri ile ilgilidir. Kıdemli personel, zengin bir ağ oluşturduğu ve işleri halledebildiği için ödüllendirilir.

Görünüşe bakılırsa, kıdemli insanların sadece gençlerin yaptığını yaptığı, ancak daha fazlasını yaptığı, yani amacın ellerini klavyede tutmak olduğu basit bir modeli benimsiyorsunuz. Makalenizin tüm amacı, en iyi geliştiricilerin düşünmek veya desteklemek yerine kodlaması gerektiğidir .

Daha sonra backlog’un ürün olduğu varsayımını yapıyorsunuz . Elbette teslim süresi veya çıktı miktarı gibi akış metriklerini ölçmek ve kümülatif akış diyagramları oluşturmak için Jira veya Azure DevOps’u kullanabiliriz, ancak bunu bireysel polislik için kullanmanın bir anlamı yok.

Gerçekte olanı tanımlamak kolay ama ölçmek zordur:

1. Daha fazla düşünün, daha az yapın, değer elde etme süresini kısaltın.
2. Hızlı hareket edip uyum sağlayabilmek için işleri küçük ve basit tutun.

İşleri küçük tutmanın gücüne dair bazı örnekler sunayım.

Facebook, 500 milyon aktif kullanıcısı olan WhatsApp’ı satın aldığında WhatsApp’ın 13 mühendisi vardı . (Bu aynı zamanda Erlang’ın gücünün bir kanıtıdır.)

İlişkisel veritabanı SQLite, gezegendeki hemen hemen her bilgi işlem cihazında çalışır: telefonlar, tabletler, tarayıcılar, sunucular, dizüstü bilgisayarlar. Milyonlarca otomatik teste ve yalnızca üç sabit geliştiriciye sahiptir .

1999’da iki İsveçli öğrenci, Java 1.3’ün yeni özelliklerini kullanarak Orion adında tamamen uyumlu bir J2EE Uygulama Sunucusunu sıfırdan yazdılar. Derlenen kod ~6 Mb’dı, IBM WebSphere’inki ise 500+ Mb’lık muazzam bir dosyaydı. Orion’un performansı IBM, Oracle, BEA ve diğer rakiplerin arasında zemini sildi. Diğer sunucularda dakikalar süren işi saniyeler içinde yapardı. Sonunda Oracle, kodun bir kopyasını çok büyük, açıklanmayan bir miktar karşılığında satın aldı ve Oracle App Server’ın yerini aldı.

İç-dış döngü mü?

İç ve dış döngü modelinizi kafa karıştırıcı buluyorum. Hedef kitleniz olduğunu düşündüğüm kurumsal yazılım geliştirme deneyimimi kesinlikle yansıtmıyorlar.

Güvenlik veya uyumluluk denetimlerinin ve gereksinimlerinin dış döngüde ayrı bir inceleme faaliyeti olduğu fikri, McKinsey’in desteklediği sola kayma (shifting left) ilkesiyle doğrudan çelişiyor. Güvenlik ve uyumluluk, yazılım geliştirmenin ayrılmaz bir parçası olmalıdır.

Eski ABD denizaltı komutanı David Marquet, Turn the Ship Around adlı kitabında teftişe davet etme fikrini tanıtıyor. Tarihsel olarak, bir denizaltının mürettebatı müfettişlere karşı şüpheci ve düşmanca davranırdı. Marquet bu durumu tersine çevirdi ve onları tam bir törenle gemiye bindirdi ve ardından sorunların ve önerilerin tam listesini görmek istedi ve bir sonraki denetimde bunların hepsinin çözüleceğine söz verdi.

Kültürdeki bu değişim, müfettişlerle daha işbirliğine dayalı bir ilişkiye yol açtı ve hem onlar hem de mürettebat bu denetimleri sabırsızlıkla beklemeye başladı. Aynı şekilde, yüksek performanslı ekipler, güvenlik, uyumluluk, erişilebilirlik, dayanıklılık ve benzeri işlevler arası faktörlerdeki uzmanları, geliştirme etkinliklerinin sonunda bekçi olarak görmek yerine danışman olarak kabul eder ve mimarilerinin, tasarımlarının, hatta teknoloji seçimlerinin bu önemli iş ihtiyaçlarını yansıtmasına çalışırlar.

Toplantılar da bir dış döngü etkinliği değildir. Herhangi bir işbirliği bir toplantıdır! Eşli programlama (pair programming), ikilinin çeşitli tasarım fikirleri ve yaklaşımlarını tartıştığı, bazılarını denediği ve birlikte bir çözüm oluşturduğu sürekli bir toplantıdır; aynı şekilde topluluk programlaması (ensemble programming) de örnek gösterilebilir. Yine “kod-test-derleme” işin kolay kısmıdır; peki çözmeye ne dersin ? Bu anlık beyaz tahta oturumları veya daha yapılandırılmış derinlemesine incelemeler bunun içindir ve değer yaratma akışını en üst düzeye çıkarmak için diğer geliştirme faaliyetleriyle paralel olarak gerçekleşmelidirler.

İlerlemeyi göstermek ve geri bildirim almak için dış paydaşlarla düzenli aralıklarla incelemeler yapılması ve diğer yapılandırılmış katılımların olması gerektiğinin farkındayım, ancak makalenizin önerdiği bu değil.

Test verilerini yönetmek “düşük değerli” mi?

Test verilerini yönetmenin düşük değerli bir etkinlik olduğunu öne sürüyorsunuz. Canlı müşteri verilerinin kazara kullanılmasından kaynaklanan itibar riskinin yanı sıra, pek çok bölgede müşteri verilerinin belirtilen amaç dışında kullanılması konusunda yasal kısıtlamalar bulunmaktadır.

Bir test çalıştırmasında gerçek adresler kullanıldığı için yanlışlıkla 16.000 aktif aboneye e-posta göndererek  onlara geniş bantlarının sonlandırıldığını bildiren büyük bir İSS’de çalışıyordum. Tahmin edebileceğiniz gibi, bu sorunu çözmek oldukça zaman ve çaba gerektirdi ve aynı zamanda kamuoyunda utanç yarattı.

Test verilerinin veri temizliği ve yaşam döngüsü yönetimi, sürekli ve kasıtlı bir faaliyet olmalıdır. Bunu güvenlik veya uyumlulukla aynı kategoride düşünüyorum ve benzer şekilde “teftişe davet” ediyorum.

Altyapı işi “düşük değerli” mi?

Canlıya çıkma akışını optimize etmek, yüksek performanslı ekiplerin kritik bir işlevidir. Hızlı, otomatikleştirilmiş bir sürüm hattı, sık sürümler için temel bir önkoşuldur ve bunu destekleyecek altyapıyı tanımlama, sağlama ve geliştirme becerisi, fark yaratan bir unsurdur.

Kötü seçimler veya altyapı tedariği ve yönetimi konusundaki anlayış eksikliği nedeniyle bulut işletim giderlerinde 10 kat, hatta 100 kat etki veya daha doğrusu, tedariğin doğru yapılmasına odaklanılması nedeniyle işletme maliyetlerinde 100 kat azalma gördüm.

“Düşük değerli” işleri sınıflandırmanız yine kodlama dışı faaliyetlerin düşük değerli olduğu fikrine bağlı görünüyor ki bu açıkça yanlıştır.

Yetenek yetkinliği puanı?

Becerileri ve yetenekleri kataloglamak için birçok girişimde bulundum ve bu tür birkaç çalışmayı kendim yürüttüm. Genel bir beceri ve yetenek listesi üzerinde çalışmak, Kısıtlamalar Teorisi (Theory of Constraints) açısından anlamlı değildir. Bunun yerine müşterinin organizasyonuna dayalı bir beceri kataloğu geliştirmelisiniz: müşterinin teknik durumu, müşterinin iş alanı, müşterinin kısıtları.

Bir ekibi bir araya getirirken temel başarı faktörleri arasında üzerinde çalışılan sistemlere, ilgili iş alanlarına ve süreçlere, yukarı ve aşağı yöndeki bağımlılıklara, paydaşlarla ilişkilere ve ilgili birincil teknolojilere aşinalık yer alır. Bunlar bir yetenek haritası üzerinde modellemeyi sevdiğim türden şeyler: genel ve belirsiz olmaktan ziyade doğrudan taleple ilgili beceriler, yetenekler ve bilgiler.

Bir müşterinin “‘acemi’ yeteneğinde ideal olandan daha fazla geliştiriciye” sahip olduğu örneğiniz ne yazık ki hiçbir anlam ifade etmiyor. Her geliştiricinin benzersiz bir beceri profili olacak, bazı alanlarda daha fazla, bazılarında ise daha az deneyime sahip olacak. Belirli bir alandaki yetenek eksikliğinden bahsediyorsanız, örnek bunu göstermelidir. Tüm yeteneklere dayalı bir doğrusal fonksiyon buluyorsanız, bu ne uygulanabilirdir ne de kullanışlıdır.

Dahası, siz veya onlar bu durumda “ideal”i nasıl tanımlıyorsunuz, yoksa bu normal dağılım gibi genel bir eğriye mi dayanıyor? Bu, takımların yığın sıralamasında (stack-ranking) bulduğumuz hatanın aynısıdır. Yüksek performanslı bir takımda tüm oyuncular eğrinin bir ucundadır! Normal bir dağılım yoktur ve “en zayıf halka” yoktur.

Ekiplere kaynak sağlama açısından, eğer ekibin sonuç verme yeteneği bu eksiklik nedeniyle kısıtlanmıyorsa, bir alandaki yetenek eksikliğinin bir önemi yoktur . Eğer öyleyse, o zaman elbette ekip veya organizasyon bu boşluğu doldurmaya çalışmalıdır, ancak bu genellikle başka yollarla da yapılabilir; rneğin yaklaşımı veya çözümü değiştirerek, örneğin bir alanda beceri geliştirerek.

Ölçmek için çok mu karmaşık?

Son olarak mühendisliğin ölçülemeyecek kadar karmaşık olduğu iddiasındasınız ki buna katılmıyorum. İndirgemeci düşünceyi ve araçları uygulamak bir kategori hatasıdır. “Daha iyi” indirgemeci araçlar, katılık yanılsamasıyla yanlış şeyi yapmayı ikiye katlıyor.

Yazılım geliştirme işbirlikçi, üretken bir girişimdir ve bir ekibin etkinliğini ve daha da önemlisi, Kısıtlamalar Teorisi’ni ve teslim süresi ve üretim hacmi gibi akış tabanlı ölçümleri kullanarak bunun zaman içinde nasıl bir eğilim gösterdiğini kolayca ölçebiliriz. Bunları daha derinlemesine anlamak için Eliyahu Goldratt ve Donald Reinertsen’in çalışmalarına bir göz atın. McKinsey gibi bir kuruluşun bu yaklaşımları desteklemesi sektöre büyük katkı sağlayacaktır.

Ancak bir kişinin bireysel katkısını ölçmeye çalışmak, bir motordaki pistonun bireysel katkısını ölçmeye çalışmak gibidir. Sorunun kendisi hiçbir anlam ifade etmiyor.

Sonuç

Vardığınız sonuç güçlü ama karışık görünüyor. Temel bilgileri öğrenmek ve sistemlerinizi değerlendirmek için harekete geçirme çağrınızı seviyorum, ancak kod kapsamı (code coverage) iyi belgelenmiş yanlış bir ipucudur , çünkü kaliteyi göstermek için ne gerekli ne de yeterlidir. Mantıklı bir şekilde bir plan oluşturmayı öneriyorsunuz.. Daha sonra, verimliliği ölçmenin bağlamsal olduğu şeklinde bitiriyorsunuz, ama makalenin tamamı bağlamdan bağımsız değerlendirme araçlarının tanıtımını yapıyor

Bazı öneriler

Beni makalenizi incelemeye davet ettiğiniz için bir kez daha teşekkür ederim. Önemli ve zorlu bir konuyu ele alıyorsunuz ve umarım geri bildirimlerim daha uygun ve sağlam temellere dayanan bir makale oluşturmanıza yardımcı olur. Ben hesap verilebilirlikten yanayım ve bireyleri hem kendi mesleki gelişimlerine hem de şirketin yararına olacak şekilde değerlendirmeyi faydalı buluyorum.

Ancak makalenizin önerdiği gibi kişiyi tek başına ölçmek yerine, düşük performansa bütünsel bir bakış açısıyla yaklaşıyorum. Zeki ve motive insanları işe aldığımızı varsayarsak -ve öyle değilse o zaman işe alma operasyonumuza bakmamız gerekir- o zaman birisi “zayıf” performans gösteren olarak tanımlanırsa, bunu o kişiyi hayal kırıklığına uğrattığımızın bir işareti olarak kabul ediyorum . .

Bu kişinin başarılı olmasını zorlaştıran iş sistemi (iş türü, kişinin bu işe uygunluğu, kullanılan araç veya destek, organizasyonel kısıtlamalar veya diğer kafa karıştırıcı faktörler) nedir? Deneyimlerime göre, “kötü bir performansa sahip olmak”, duyulmamış olmasa da nadir görülen bir durumdur. Büyük olasılıkla, kişi içinde bulunduğu bağlama yanıt veriyordur ve eğer bunları kaldırırsak, yerine koyacağımız kişi muhtemelen aynı kısıtlamaların kurbanı olacaktır.

Kişisel gelişim açısından, bireylere kendilerini pazarlamaları için koçluk yapmayı seviyorum; örneğin periyodik değerlendirmeler sırasında geriye dönüp bakabilecekleri bir başarı günlüğü tutmak ve organizasyonda kendi kişisel markaları üzerinde çalışmak. Yılda bir veya iki defaya kadar pusu gibi gelen grup toplantıları yerine anlık geri bildirimi ve sık sık 1-1 toplantıları tercih ediyorum.

Bir ekipteki bireyleri değerlendirecekseniz gerçek katkıda bulunanların kim olduğunu anlamak için paydaş (peer) geri bildirimini kullanın. “Bu takımda en çok kimin olmasını istiyorsunuz ve neden?”, “Büyümesine yardımcı olmak için X’e ne gibi tavsiyelerde bulunursunuz?” veya “Y’den en çok ne öğrenmeyi istersiniz?” gibi sorular sorarım. ” Zeki bir yönetici, bu paydaş geri bildirimindeki olumlu ve olumsuz kalıpları ve eğilimleri hızlı bir şekilde görecektir ve bunlar daha sonra eyleme geçirilebilir.

Sanırım bunların çoğu ilgili kişinin bireysel değerlendirme yapma motivasyonuna bağlı. Eğer zihniyet “zayıf performans gösterenleri ayıklamak” ise bu, sorumluluktan feragat anlamına gelir; büyüyememe konusunda toprağın ya da iklimin değil, çiçeğin suçlu olduğu düşüncesi. Bu bağlamda insanları “değerlendirmek” için hangi aracı kullandığımızın pek bir önemi yok çünkü açıkça yanlış sorunu çözüyoruz.

Bu makalenin bir sonraki revizyonunda size iyi şanslar diliyorum. Söylediğim gibi bu önemli ve karmaşık bir konu ve McKinsey seviyesinde görünürlüğü ve itibarı olan  bir kuruluşun bu konuyu, bir teknik incelemede ele almayı seçmesinden memnunum.

Saygılarımla, Daniel Terhorst-North