1.82 saniyede olay çözümleyen bir ekip nasıl olabiliriz?

1990’ların ortalarında, İngiltere Bristol’deki Great Ormand Street çocuk hastanesinde normalin üzerinde ölüm oranları görülmeye başlandı. 1852’den bu yana hizmet veren ve türünün ilk örneği olan hastane üzerindeki kamuoyu baskısı ve basının ısrarlı soruları artıyor; personel umutsuz bir şekilde, bir çözüme ulaşmaya çalışıyordu. Sonunda çözüm ironik bir şekilde, kuralların ölümle yazıldığı bir spordan geldi.

Cerrahi üniteden yoğun bakım ünitesine geçiş esnasındaki varolan doğal ve yüksek riskle, yaşanan küçük ve fark edilmeyen koordinasyon hatalarının birleşiminin; büyük ve olumsuz sonuçlar doğurduğuna işaret eden bir çalışma yapıldı. Sorunun çözümü üzerine kafa yoran motor sporları hayranı iki doktor, Dr. Goldman ve Dr. Elliot, izledikleri bir Formula 1 yarışında, pit ekibinin çalışma pratikleri ile hastanedeki devir teslim pratiklerinin birbirine çok benzediğini fark etti: Aracın pit alanına girişi ve araç üzerinde uygulanan pit prosedürü ile hastanın, hastaneye girişi ve uygulanan operasyon sonrası üniteler arası transferde uygulanan prosedürün benzerliği.

Peki, hastane ekibinin bu denli bir hıza ihtiyaç duymadan organize olmasına rağmen bütün işleri sarpa sararken; pit ekibi bu denli kısa bir sürede bu harika koordinasyona nasıl imza atabiliyordu?

İki doktor, pit organizasyonu hakkında kendilerini bilgilendirmeleri ricasıyla dönemin Formula 1 ekibi McLaren’i hastanelerine davet ettiler. McLaren ekibi; pit görevlilerinin zihinsel, algısal, fiziksel yeteneklerini ve sınırlarını inceleyen; bu faktörlerin etkileri üzerine stratejiler ve ortamlar hazırlayan “insan faktörü uzmanları” ile nasıl çalıştıklarını; bariz büyük hataların aksine dikkat çekmeyen küçük yanlışların ne kadar endişe verici sonuçlar doğurduğunu gösterdi ve anlattı. Buna ek olarak doktorlar, dönemin Ferrari yetkilisi Nigel Stepney’den de yorum almak üzere kendisine, hastanenin devir teslim ritüelini gösteren bir takım video ve görseller ilettiler. Stepney, organizasyonu kısaca “tamamen dağınık” olarak tanımladı: Pit ekibinde herkesin tek ve kati bir görevi bulunuyordu anca hastane ekibindeki görev tanımı ve bilinci tamamen bir kaos ortamını andırır vaziyette karmaşıktı. Ayrıca bu organizasyonun genelinden sorumlu bir “lolipop adam” hastane ekibinde bulunmuyordu. Son olarak bir noktaya daha dikkat çekti; tüm pit prosedürü kesin bir sessizlik içerisinde gerçekleştiriliyordu; ancak bu, hastane ortamında kesinlikle bulunmuyordu!

İki doktor bu danışmanlık etkileri ışığında acı noktaları tespit ettiler, prosedür değişikliklerinin gerekliliği konusunda ikna oldular ve hastane genelinde uygulamaya geçirdiler. Tabii ki bu değişiklikler çoğu personel tarafından çılgınca ve uygulanamaz bulundu. Bir süre sonra yayınlanan, Ferrari’den alınan danışmanlık öncesi 23, sonrasında ise 27 operasyonu konu olan bir bildiri ile doktorlar; alınan tedbirler sonucu teknik hatalarda %42 düşüş gördüklerini beyan ettiler. Ölüm oranlarındaki azalmayla ilgili ölçümler, bu çalışmanın bir parçası olmadı.

Yukarıdaki gerçek hikayenin orijinal metnine bu adresten ulaşabilirsiniz. Ben biraz yorum katarak, biraz da hikayeleştirme sanatını kullanarak sürükleyici bir çeviri gerçekleştirmeye çalıştım.

Credit

Dün bir dost sohbetinde, Formula 1'de “ne bulduğum” üzerine bir konu çevirdik. Tabii ki efsane v10 motorun sesi, Lauda — Hunt rekabeti, 94' Imola felaketi, Schumacher — Hakkinen mücadeleleri diye ardı ardına bir sürü anı sayabilirim. Ama tüm bu kişisel heveslerin ötesinde bana ilham veren ve beni meraklar içerisinde bırakan yönü, mühendislik ve strateji konularındaki dahiyane yöntemleri ve uygulamaları oldu. Tabii yalnızca beni değil, dünya üzerindeki onbinlerce profesyoneli de aynı oranda etkilemiş olmalı ki günümüzde Formula 1 teknolojileri bir çok sektör ve uzmanlığa endirekt şekilde etki eder vaziyette.

Hikayeyi okurken hastane ekibi yerine bir ürün geliştirme ekibini koymayı denediniz mi? Belki de algınız sizi ona doğru itti, eğer itmediyse bir deneyin — hikayeye baştan, farklı bir okuma ile yaklaşın. Bana ilk zamanlarda, ürün geliştirme ekiplerinde bir takım oyuncusu olma; sonralarda ise — organizasyonlara dokunur bir noktaya geldiğimde — otonom ekipler kurma ve onlara yol açma, işe alım süreçlerinde insan faktörünü daha katma değerli olarak kabul etme gibi konularda önemli bir bakış açısı kattı, katmaya devam ediyor. Bir başka katma değer sağladığı nokta ise, olay yönetimi — nam-ı diğer “incident management” konusu.

Olay anları günlük hayatımızın bir gerçeği, işimizin doğası. Tıpkı her insanın, olaylar karşısında verdiği tepkiler ve tepkime sürelerinin de insan doğasının bir parçası olduğu gibi. Kültürel birikimimiz, yetişme koşul ve ortamlarımız olaylar karşısındaki davranış biçimlerimizi, kararlarımızı etkiliyor. İşe alım esnasında potansiyel ekip arkadaşlarımızın teknik ve beşeri yetkinliklerini bir şekilde ölçme ve değerlendirmeye alıyoruz. Gel gelelim olaylar karşısındaki tutumunu, iş birlikçi tarafını, inisiyatif kaslarını ancak gerçek ortamda deneyimleme ve gözlemleme şansımız oluyor. Üstelik ekip üyemiz, ilk olayda yapmış olduğu gözlemlere ve edindiği deneyimlere göre diğer olaylardaki tavır ve davranışlarında değişikliğe de gidebiliyor. “Neden hep ben koşuyorum?” diyerek inisiyatif almaktan vazgeçen ekip üyeleri görmemiş olan var mı etrafında?

Peki, zaman/iş kritik bir olay anında bir ürün geliştirme takımını pit ekibine nasıl çeviririz? Benim F1 pratiklerinden ilham aldığım ve bunun sonucu olarak da uyguladığım/hala uygulamak üzere yol aldığım dikkat noktalarımı paylaşmak istiyorum. Yazının sonuna geldiğinizde “çok bilinen, az uygulanan” bir takım pratiklerden dem vurduğumu fark edeceksiniz, haklısınız. Tüm bu pratiklere kafa yorarken ve yoldayken şunu fark ettim; bunları yalnızca ben düşünmüş olamam, yalnızca benim inanç sistematiğimin bir parçası olamaz tüm bunlar. Peki tüm bu bilinirliğe, inanmışlığa rağmen neden hala olaylardan sebep yanan, yorulan, tükenen ekip üyelerimiz var? Neden uzun süreler kroniklerimizle boğuşur durumdayız? Neden ekipler hala kahramanlar yaratmaya çalışıyor? En yalın haliyle şunu fark ettim; benim biliyor olmam, inanmam tek başına hiçbir şey ifade etmiyor. Zor olan, bunu bir kültür meselesi haline getiren organizasyonlar inşa edebilmek. Çünkü Charles Fredrick Kettering’in söylediği gibi;

The world hates change, yet it is the only thing that has brought progress. — Dünya değişimden nefret eder, ancak ilerlemeyi sağlayan yegane şey bu.

Sonsuz bir sessizliği sağlamaya gayret gösterin

Nigel Stepney’in de üzerine basarak ifade ettiği bu pratikten taviz vermemenin çok önemli olduğunu düşünüyorum. Buradaki kritik nokta; sessizliği bir “ölüm” sessizliği algısına çevirmemek; “her şeyin bittiği o an” algısından ekip üyelerini uzak tutmak. Bunun için, ekibin bir üyesinden gelecek olan herhangi bir yardım talebine, talebin kalitesini ve zorluk seviyesini sorgulamadan karşılık vermek ve tekrar sessizce olanı biteni takip etmek oldukça kritik.

Buradaki “sessizlik” kavramını, “paratoner” olabilme olarak da düşünmekte fayda var. Olay anlarında, olayın kaynağı bizler; olaydan etkilenen paydaşları unuturuz — ya da unutmak isteriz. Ancak bu esnada paydaşlar da aslında bir etkilenendir ve bu etkilenmeyi bir baskı unsuru olarak kullanmak isteyebilirler — vahşi hayat kuralları. Ekibin sessizliğini bölmeden onlardan geri bildirim alabilmeli, eş zamanlı olarak da harici baskıyı sönümleyebilmelisiniz. Sönümleme esnasında da “idare etmek” yerine olanı tüm gerçekliği ile ifade etmeli ve insanların size güvenmesini sağlamalısınız. İş ekipleriyle olan iletişimde; “MongoDB’de concurrent ticket’ları tükettiğimiz için queue’lar şişti!” bir şey ifade etmeyecektir, aksine bilinmezlik korkutur ve güven duygusunu zedeler. “Teknik bir sorun olduğu için kafa karıştırmamak adına detaya girmiyorum ama kısa sürede çözeceğimiz bir sorun!” size her geçen dakika daha fazla gerginlik — sarkastik bir üsluptan kimse hoşlanmaz — ve soru yaratacak; olayla ve ekiple olan anlık bağlantınızın kopmasına sebep olacaktır. “Uygulamaya gelen yoğun istekten sebep sistem kaynaklarımızda bir darboğaz oluştu. İlgili ekiplerle konuyu inceliyoruz, ben periyodik olarak sizi güncelleyeceğim.” ifadesi, beni daha rahat hissetmem konusunda motive ediyor doğrusu.

Antremansız kalmayın

Formula 1 analojisine geri dönüyorum. Pit ekipleri yaptığı iş itibariyle çok basit gibi görünür. Onların da yarış öncesinde antreman (pit-stop denemelerinden bağımsız, açma germe gibi hareketlerden bahsediyorum) yaptığını gördüğümde çok şaşırmıştım. Sonrasında ise “küçük yanlışlar” aklıma geldi. Düşünsenize, açma germe yapmadığı için tam lastiği sökeceği esnada “tyre gunner”a kramp giriyor! Sıfır onda bir, iki ile şampiyonlukların değiştiği bu sporda, konsantrasyon kaybına sebep olan bu küçük yanlışın, büyük bir felakete sebep olması işten bile değil.

Bağlı olduğum ekiplerimi tatbikat yapma konusunda özendirmeye gayret ediyorum. Slack kanalına fake hata mesajları basma fikrine ne dersiniz? Ya da Grafana’daki bir grafiğin Prometheus sorgusunu değiştirip değerleri pik yapmak? Tabii ki her senaryoyu tatbik etmek mümkün değil ancak iteratif olabilmek önemli. En az bir olaya karşı hazır hissetmek, diğer olaylara karşı ekibi daha cesur ve organize olmaya motive etmeye yetecektir.

“T-Shape” olma konusunda birbirinizi cesaretlendirin

Lastiğe dair mümkün olan her şeyi bilin tabii, bilginin zararı yok. Ancak bu bilgiyi bir konuda uzmanlığınız haline getirin: Sökme konusunda mı çok iyi olmalıyım, takma konusunda mı?

Otonom bir ekibin en önemli özelliğinin, farklı yeteneklerden kurulu bireylerden oluşması olduğunu gördüm zaman içerisinde. Bunun “ürün geliştirme” konusundaki etkisini de eminim hepimiz yaşamışızdır. Ancak en büyük etkisinin olay anlarında hissedildiğini de deneyimledim. Ekip üyelerinden bir ya da bir kaçının, en önemli enstrümanınız konusunda uzmanlaşmasını sağlayın, mümkün mertebe uçtan uca. Bunu bir “yazılım mühendisi” rolü ile de kısıtlamayın. Ürün ekibinin her bir üyesi, birikimine ve ilgisine göre doğru bir enstrümanla eşleştirilebilir. Bir Product Owner’ın olay anında veritabanı metriklerini inceleyip çıkarımlarda bulunması kötü bir fikir midir sizce? Bu konuda size yatırım yapması üzerine şirketlerinize de baskı oluşturmayı ihmal etmeyin. “İşçisin sen, işçi kal!” bırakın şarkı sözlerinde kalsın.

Kim ne yapmalı konusunda her zaman mutabık kalın

Olay anlarında tek bir noktaya, derinlemesine konsantre olunmasını; bunların da bir görev tanımı olarak ekip üyelerine yapışmasını sağlayın (rotasyona tabi tutmakla karıştırılmamalı). Böylece aynı anda bir çok farklı işi, yukarıda da bahsettiğim üzere bir takım uzmanlıklarla inceleme, fark etme ve gerekiyorsa düzeltme fırsatına sahip olabilirsiniz. Bir ekip üyesi, aynı olay içerisinde hem uygulamayı debug edilebilir bir biçimde ayağa kaldırmaya çalışıyor; hem yetki için bir başka ekibin üyesiyle irtibata geçmeye çalışıyor hem de yetkiyi aldıktan sonraki eylem planını oluşturmaya çalışıyorsa muhtemelen o yangında “öncelikli kurtarılması gereken” bir kaç eşyayı kaybettiniz demektir, vedalaşın.

“Lolipop adam”sız olaylara karışmayın

Bu rolün basit bir görevi — eskiden daha etkinlerdi azizim, elektronik tüm işi bozdu — olsa da aslında oldukça hayati. Yersiz bir anda yola çıkış izni verirse, muhtemelen pilotun ceza yemesine ve pit ekibinin müthiş koordinasyonunun çöpe gitmesine sebep olacak.

Geçmişte yaşadığım bir olay anına atıfta bulunayım. Bir kaç arkadaşımla birlikte bir olaya giriştik. Birimiz, olayı çalıştığımız ortamı monitör ediyor; birimiz uygulamaya fix geçmek üzere kafa yoruyor, birimiz ise hasar görmüş veriyi düzeltiyorduk. Sistemi gözümüz kapalı bildiğimiz için çok kısa sürede olayı çözdük, fix commit’ini çıktık. Hemen arkasına ise bir release planladık. Sonra mı? Sonrası koca bir GÜM! Canlı ortam artık farklı bir şekilde çalışamaz hale geldi. Çünkü bir değişkeni, test ortamında çalışmak üzere bırakmıştık.

Tahmin ettiğiniz üzere hepimiz araca konsantre olmuştuk ve aracı düzelttiğimizi düşünerek kendimizi direkt yola attık. O esnada yaptıklarımızı, sorunu çözmek için değil; küçük detayları kaçırıp kaçırmadığımızı izlemek ve bizlere yol göstermek için bir lolipop adama sahip olsaydık, o harika koordinasyonumuza gölge düşürmemiş olacaktık.

Lolipop adam rolünü sadece gözlem için değil, koordine etmek için de kullanmayı öneriyorum. Olay koordinatörü gibi düşünebileceğiniz bu rol ile, olayın tüm tarihsel akışını kayıt altında tutabilir; ekip üyeleri arasında ve ekip dışındaki paydaşlarla bilgi akışını sağlayabilirsiniz. Bunu bir “manager” pozisyonu gibi düşünmemek gerekli. Olay esnasında organizasyonel hiyerarşi devre dışı kalmalıdır.

Gözlem ve izlemede kalın

Hep mekanik ekipten bahsettik ancak, pit duvarındaki yarış mühendislerini anmadan geçmek olmaz. “Ölçemediğin şeyi yönetemezsin” çok klişe bir söz olmakla birlikte en obsesif olduğum noktalardan biri olduğunu belirtmeden geçemeyeceğim. Formula 1 bu konuda belki de veriyi en iyi kullanan 3–5 organizasyondan biridir desem yanlış olmaz. Yarış mühendisleri çok kritik zaman dilimlerini ve metrikleri takip eder; gerekiyorsa daha önce çalışılmış olan stratejilerle yarışın seyrini değiştirecek hamlelerin yapılması konusunda pilotları yönlendirir. Bizlerin olay anındaki gözlem ve metrik okuma yetenekleri bizi sonuca çok daha hızlı götürebileceği gibi, olayı çözdüğünü düşündüğümüz bir noktada farklı bir olaya kapı açtığımızı önden fark etmemize de yardımcı olabilir. Hislerimizle ve/veya tecrübelerimizle hareket etmemiz normal ancak verilerle bunları teyid etmemek sık yaptığımız “küçük” hatalardan.

Son olarak şunu ifade etmeliyim ki tüm bu pratikleri, bir ürün geliştirme ekibinin olgunlaşma serüvenindeki bir seviye olarak görüyorum. Tamamının uygulanması bir zaman alacağı gibi, tamamının uygulanması bugünü dünden daha kötü bir hale de getirebilir çünkü insan faktörü diğer tüm mekanik parametrelerden çok daha etkili ve değişkendir. Bu sebeple, olgunlaşmanın ilk seviyesini “ekibin her bir üyesini bu seviyelere katkı sağlaması konusunda cesaretlendirmek ve bilinçlendirmek” olarak kabul ediyorum.

Siz de bu kültürün bir parçası olmak ve bizimle beraber lastik değiştirmek isterseniz, Twitter veya LinkedIn üzerinden lütfen benimle irtibata geçin. Vakit ayırdığınız için teşekkürler!