Geri Dön
"Detayları istemiyorum": olay sonrası gerçek değişimi sağlayan soru
SiTech AI Team3 წთ. საკითხავი

"Detayları istemiyorum": olay sonrası gerçek değişimi sağlayan soru

Bir olayın ardından çoğu kurum "bu neden oldu?" diye sorar ve makul bir açıklamayla yetinir; altı ay sonra aynı hata tekrarlanır. Mühendis Michael Heap'in yazısı başka bir soru öneriyor.

23 Eylül'de yayımlanan bir yazıda mühendis Michael Heap, mühendislikteki muadili ve onun yöneticisiyle — bir mühendislik SVP'si — katıldığı bir toplantıyı anlattı. Olmaması gereken bir şey olmuştu: felaket değil, ama bir SVP'lik önemdeydi. Heap olayın nasıl gerçekleştiğini anlatmaya başladı, ama sözü kesildi: "Michael, detayları istemiyorum." Ardından gerekçe geldi: detaylara girersek tüm nedenler son derece makul görünecek, herkesin kararı anlamlı olacak ve ben de size hak vereceğim. "Sonra aynı şey yine olacak. Bu yüzden detayları istemiyorum. Ne değiştirdiğimizi bilmek istiyorum."

Yanlış soru

Bir şeyler ters gittiğinde çoğu kurum "bu neden oldu?" diye sorar. Ekipler zaman çizelgeleri yazar, kararları yeniden kurar ve olanları anlatan bir belge teslim eder. Herkes başını sallar, "mantıklı" der ve günlük işine döner. Heap'in itirazı basit: bir sorunu anlamak, onu düzeltmekle aynı şey değildir. İyi bir açıklama işleri daha da kötüleştirebilir; herkes davranışın makul olduğunda hemfikir olduğunda değişim aciliyeti kaybolur ve aynı hata altı ay sonra geri döner.

Makul insanlar, değişmesi gereken sistemler

Heap başka bir soru öneriyor: "Aynı hata sınıfının bir dahaki sefere daha az olası olması için neyi değiştiriyoruz?" Yönetici, diye yazıyor Heap, kimin ne yaptığıyla ya da makul davranışın kanıtlanmasıyla ilgilenmiyordu — bu zaten varsayılan beklenti. Yazıda üç örnek var. Bir hata gözden kaçtı çünkü Alice tatildeydi ve Bob, Widgets ekibinin bu işin sahibi olduğunu varsaydı — peki biri ulaşılamaz olduğunda sahipliği nasıl tartışmasız hale getiririz? Gereksinimler lansmandan üç gün önce değişti — peki gereksinimler lansman penceresinde değişirse ne olur? Alarm çaldı, ama nöbetçi mühendis o akşam zaten yirmi düşük değerli alarmla ilgilenmişti — peki alarmlarımızın sinyal-gürültü oranını nasıl iyileştiririz? Her durumda çözüm sistemik: değişmesi gereken genellikle insanlar değildir.

İlerleme kılığındaki umutlar

Heap, "desteği daha erken dahil etmeliyiz", "daha iyi iletişim kurmalıyız" ya da "bir dahaki sefere daha dikkatli olacağız" gibi cümlelerle dolu postmortemler konusunda net: bunlar ilerleme kılığına girmiş umutlardır. Düzeltici bir eylem, insanların altı ay önceki bir konuşmayı hatırlamasına bağlıysa, o bir eylem değil, kurumsal folklordur. Heap'in testi: olaya karışan herkes yarın şirketten ayrılsa düzeltme yine de işler miydi? Bu noktada karar almaya zorlayan bir süreç bir iyileşmedir; hatanın tüm sınıfını önleyen bir sistem daha da güçlüdür — gerçi her arıza yeni bir süreci hak etmez ve bazen tekrarı önlemenin maliyeti, arızayı ara sıra kabul etmekten yüksektir.

Bir güven beyanı

"Detayları istemiyorum" Heap'e önce küçümseyici geldi. Sonra farklı okudu: sabırsızlık gibi görünen şey aslında bir güven beyanıydı. Yönetici, olaya karışanların yetkin olduğunu varsayıyordu ve empatinin kurumun değişme yükümlülüğünden kaçış bahanesine dönüşmesini istemiyordu. Heap'in liderler için kapanış formülü: "Size inanıyorum. Detaylara ihtiyacım yok. Bana neyi değiştirdiğimizi söyleyin."

SSiTech

SiTech — AI destekli web geliştirme

Hızlı ve modern web siteleri kuruyor, AI'yı gerçek iş akışlarına taşıyoruz. Projeniz veya sorunuz mu var? Yardımcı olmaktan mutluluk duyarız.