Mimari modernizasyonun yürütülmesi: Tahmin ne zaman teslim tarihine dönüştü?
(domainanalysis.io)- Eski yazılımların modernizasyonunda, işe başlamadan önce görülebilen bilgilerle kapsamın tamamını kesinleştirmek zor olduğundan, ilk tahminler bir teslim tarihi değil, ayarlanabilir bir referans noktası olarak ele alınmalı
- Otomobil tamirinde olduğu gibi başlangıçta 18.000 $·30 gün gibi bir tahmin verilebilir; ancak söküm ve inceleme sonrası gizli hasarlar ortaya çıkarsa ek tahmin ve yeniden onay gerekir
- Modernizasyon projelerinde de entegrasyon başarısızlığı veya beklenmeyen davranışlar gibi gizli karmaşıklıklar ortaya çıkar; bu durumda işi ilk tahmine zorla uydurmak gerçeklikle çatışır
- Sağlıklı liderlik, “neden göremediniz?” demek yerine karmaşıklığı, çözüm yollarını, ödünleşimleri ve geçici çözümleri sorar; devam mı edileceğine yoksa durulacağına karar verir
- Karmaşık bağlamlarda sabit bir kural kitabından çok deneme, deney ve keşfin tekrarı gerekir; liderler aşırı kontrolden ziyade kalıpların ortaya çıkabileceği bir ortam oluşturmalıdır
Tahminler teslim tarihi değil, ilerleme referansıdır
- Karmaşık yazılım modernizasyonunda tahminleri kesin teslim tarihleri gibi ele almak, gerçek iş sırasında ortaya çıkan gerçeklikle çatışır
- İlk tahminler dışarıdan görülebilen bilgiler ve deneyim temel alınarak yapılır; ancak iş başladıktan sonra yeni karmaşıklıklar ortaya çıkabilir
- “Tahmin”, gerçek değere yönelik bir yaklaşımdır; karmaşık modernizasyonda tüm sonuçları başlamadan önce kusursuz biçimde öngörmek zordur
Otomobil tamiri benzetmesi: görünmeyen hasar ve ek tahmin
- Otomobil tamirinde sigorta eksperi önce hasar tahminini tamirhaneye iletir, tamirhane de kendi tahminini sigorta şirketine gönderir
- Örneğin sigorta eksperi hasarı 15.000 $ olarak tahmin eder
- Tamirhane hasarı 18.000 $ ve tamir süresini 30 gün olarak tahmin eder
- Sigorta eksperi ve tamirhane uzmanı hasarı birlikte değerlendirir; sigorta şirketi yeni tahmini onayladığında tamir başlar
- Tamir sırasında başlangıçta görünmeyen hasarlar bulunabilir
- Parçalar sökülürken ek hasar ortaya çıkabilir
- Şasi düzeltme makinesiyle unibody frame hasarı kontrol edilebilir
- Yalnızca darbe noktasını değil, etkinin şasinin arka tarafına iletilip iletilmediğini de kontrol etmek gerekir
- Ek hasar nedeniyle 20.000 $ daha maliyet gerekiyorsa tamirhane sigorta şirketine ek tamir talebi gönderir; sigorta şirketi tamire devam mı edileceğine yoksa tam hasar (total loss) işlemi mi yapılacağına karar verir
- Sigorta şirketinin sırf ilk tahmin 18.000 $ idi diye ek 20.000 $’ı reddetmesi, gerçekçi bir tamir süreciyle uyuşmaz
Eski sistem modernizasyonunda da gizli karmaşıklıklar ortaya çıkar
- Eski yazılımların modernizasyonu karmaşık yazılım alanına girer
- Dışarıdan net görünen sorunlara dayanarak ilk tahmin yapılabilir, ancak gerçek çalışma sırasında daha fazla karmaşıklık ortaya çıkar
- Otomobil tamirinde gizli hasar veya şasi hasarı bulunmasına benzer şekilde, modernizasyonda da ilk tahminde yer almayan sorunlar ortaya çıkabilir
- Bu durumlarda ilk tahmine bağlı kalmak yerine, ek onay ve yeniden değerlendirmeyle bir sonraki adım belirlenmelidir
İyi bir liderin sorduğu sorular
- Sağlıklı bir yazılım geliştirme ortamında, sorunlar ortaya çıktığında suçlamak yerine karar vermek için gerekli sorular sorulur
- Bu sorun ne kadar karmaşık?
- Hangi çözüm yolları var?
- Her bir yöntemin ödünleşimleri neler?
- Geçici çözümler veya alternatif çözümler var mı?
- Buna karşılık süreç “bu karmaşıklığı neden göremediniz?”, “neden bu kadar uzun sürüyor?”, “neden ilk tahmin tarihine uyulmuyor?” noktasına kayarsa ekip ilk tahmin tarihine kilitlenir
- Modernizasyon projelerinde hem devam edilen hem de durdurulan durumlar vardır
- Ek maliyet onaylanırsa bir sonraki aşamaya geçilir ve bu süreç tekrarlanarak tamamlanmaya yaklaşılır
- Maliyet değerden daha büyük hale gelirse proje durdurulabilir
- Devam etmek ile durmak arasındaki karar kolay değildir; yön belirlemek için çerçeveler ve karar alma atölyeleri kullanılabilir
Çetrefilli bağlam ile karmaşık bağlam arasındaki fark
- A Leader’s Framework for Decision Making yazısındaki Cynefin framework’e göre otomobil tamiri veya motosiklet bakımı çetrefilli bağlama (complicated context) daha yakın olabilir
- Otomobil tamirinde uzman, kaza koşullarını dinler; görünmeyen hasar, şasi hasarı gibi birçok unsuru analiz edip test ederek en iyi eylemi belirler
- Karmaşık bağlamda (complex context) ise doğru ile yanlış ancak denedikten sonra değerlendirilebilir
- Çalışacağı varsayılan bir entegrasyon başarısız olabilir
- Bilinmeyen yeni bir davranış keşfedilip bunun hesaba katılması gerekebilir
- Karmaşık eski sistem modernizasyonunda sabit bir yol veya izlenecek bir kural kitabı yoktur
- Modernizasyon; deneme, deney yapma, keşfetme, çözme ve bir sonraki parçaya geçme sürecinin tekrarından oluşur
Beklenmeyen falso istisna değil, gerçeğin kendisidir
- Uygulama modernizasyonu complex ile complicated arasında bir yerdeyse, ilerlemeyi ve başarıyı değerlendirmek için uygun bir gösterge paneli gerekir
- Karmaşık bir bağlama basit bir tahmin süreci uygulamak, tüm vidaları ve bijon somunlarını çekiçle çözmeye çalışmak gibidir
- Modernizasyon projelerindeki beklenmeyen falso gerçektir
- Tüm sonuçlar önceden tahmin edilemez
- Ne kadar çok ön analiz yapılırsa yapılsın kusursuz bir veri modeline ulaşılamaz
- Neredeyse her adımda yeni öğrenme gerçekleşir
- Keşfedilen karmaşıklığa göre veri modelinin değişmesi gerekir
- Tahminlerin değiştiği durumlarda öfkelenmek, suçlamak veya takvimi zorla tutturmaya çalışan analizlere saplanmak yerine ilerlemenin yolu aranmalıdır
Kurum kültürü beklenmeyen falsoları nasıl ele alır
- Ron Westrum’un kurum kültürü modeli, beklenmeyen falsoları haber veren kişiyi ve başarısızlıkları kurumun nasıl ele aldığını ayırır
- Power-Oriented kurumlar, beklenmeyen falsoları bildiren haberciyi vurur; başarısızlık günah keçisi aramaya dönüşür
- Rule-Oriented kurumlar, beklenmeyen falsoları bildiren haberciyi görmezden gelir; başarısızlığı tanımlanmış kuralları uygulama sorunu olarak ele alır
- Performance-Oriented kurumlar, beklenmeyen falsoları bildiren haberciyi eğitir; başarısızlığı araştırmaya dönüştürür
- Çözmeye çalışılan sorun hâlâ ilgiliyse ve iş ihtiyaçlarını karşılıyorsa, adım adım ilerlemek gerekir
- Modernize edilmek istenen yazılımın nihai hedefi kullanıcıdır
Karmaşık alanlar deneysel yönetim gerektirir
- Karmaşık alanı fark etmeyen liderler, hedeflenen sonuçlar hızlı çıkmadığında sabırsızlanabilir
- Karmaşık alanda başarısızlığa dayanabilme becerisi önemlidir; başarısızlık deneysel anlayışın zorunlu bir parçasıdır
- Kurumu aşırı kontrol etmek, yararlı kalıpların ortaya çıkma fırsatını engeller
- Karmaşık bağlama zorla düzen dayatmaya çalışan liderler başarısız olur
- Sahneyi hazırlayan, bir adım geri çekilen, kalıpların ortaya çıkmasına izin veren ve arzu edilen kalıpları değerlendiren liderler başarılı olabilir
1 yorum
Hacker News yorumları
Yönetimin tahminleri teslim tarihi gibi gördüğü, kapsamı sürekli değiştirdiği ama bunun neden değişebileceğini hiç duymak istemediği dönemlerden geçtim.
Böyle durumlarda önemsiz olmayan her iş için “far ışığına yakalanmış geyik” tepkisini seçerdim. “Bu epey büyük bir iş olabilir. Ekipten birinin bir saat kadar ayırıp gerçekten ne gerektiğine bakması gerekecek gibi” dediğimde yönetici her zamanki gibi “kabaca da olsa” sorardı. O zaman sandalyeden zıplatacak kadar büyük bir sayı verirdim; o sayı da akılda kalırdı. Sonra bir saatlik incelemeden sonra da mümkün olduğunca o kaba tahminin dışında başka sayı vermez, sonunda “plandan erken” bitirip iyi görünürdüm.
İyi yöneticilerle böyle bir stratejiye hiç gerek yoktu ve bu gerçekten güzeldi; ama kendi iş yetkinliğini öğrenmeye niyeti olmayan insanlara karşı böyle davranır oldum. Toplantılar da çok daha eğlenceli hale geldi.
Tasarım ekibi, frontend ekibi, backend ekibi ve QA ekibi ayrı ayrı böyle şişiriyor; proje yöneticisi bu toplamı yeniden %150–200 artırıyor; müşteri yöneticisi ve satış ekibi de maliyet çıkarmadan önce bir %150–200 daha ekliyordu.
Sonuçta düzgün 8–10 web/full-stack geliştiriciden oluşan adanmış bir ekibin rahatça götürebileceği bir web sitesinin bakımına ayda yaklaşık 1 milyon dolar harcanıyordu. 7/24 destek hariç, birkaç iyi Rails ya da Django geliştiricisiyle, hatta bir geliştirici ve yarı zamanlı bir grafik tasarımcıyla bile yapılabilirdi diye düşünüyorum.
Birkaç yıl sonra müşteri durumu fark etti; şirket yönetimi işi tamamen batırdı ve yaklaşık 100 kişi işini ve ödenmemiş haklarını kaybetti. O gün ben de yaklaşık 26 bin dolar kaybettim.
Toplam kapasite örneğin 40 puansa, ekipten biri ayrıldığında ya da katıldığında biraz değişir. Velocity, kişi-iş günü puanı bazında ortalama çıktı miktarıdır.
Volatility ise sprint’in ne kadar değiştiğidir. 5 puanlık bir ticket’ı çıkarıp yerine 3 puanlık ve 2 puanlık ticket koymak kabul edilebilir olabilir; ama 2 haftalık sprint’te bunu 12 kez yaparsanız toplam 40 puanın altında kalsa bile sprint’i bitiremezsiniz.
Her gün sprint anlık görüntüsü alıp eklenen/çıkarılan ticket miktarına baktık; değişkenlik düşükken neredeyse her zaman tamamladığımızı, yüksekken ise Velocity’nin aşılıp aşılmadığından bağımsız olarak başarısız olduğumuzu yönetime gösterebildik. Çünkü doğru plan yapmak ve gereksinimleri netleştirmek için zaman kalmıyor. Ürün ekibini 2 haftadan daha ileriyi düşünmeye zorlamak bir ölçüde işe yaradı.
Basit işler için aşırı şişirilmiş tahmin veren mühendislerin düşük performanslı olma ihtimali de yüksekti. Yavaş teslimatı değerlendirmeyen kişilere ya da durumdan habersiz yöneticilere işe yarayabilir; ama durumu bilen bir yönetici bunu çabuk anlar.
Tek bir sabit değer yerine “3 ay, ±4 hafta” gibi bir hata payı da vermek gerekir. Çoğu mühendis kendi tahmininde hata payı olduğunu bilir; ama nedense bunu söylemeyi unutacak şekilde şartlandırılmıştır.
Yönetim açısından da hata payının büyüklüğü tahmine duyulan güveni hemen gösterir ve riskin tartışılmasını sağlar. “Şu an iki yönde de %30 hata payımız var; bunun en büyük nedeni ne ve birkaç gün araştırıp birer birer azaltabilir miyiz?” gibi konuşmalar mümkün hale gelir.
Mühendislik mesleğinde olup da risk, olasılık ve güven aralıkları hakkında düzgün konuşamamak bana anlaşılır gelmiyor. Bu yalnızca yöneticilerin suçu da değil.
Deneyimsiz yöneticiler ya da geçici olarak birinin yerini dolduran kişiler belirsizliğe alışık olmadığı için bunu anlayabilirim; ama diğer durumlarda mazeret yok.
Bu yazı modernizasyon projeleriyle ilgili; bu tür projelerde mevcut yazılım, yerine konacak olan geliştirilirken de çalıştığı için gevşek teslim tarihleri vardır.
Bütçe baskısı, verilen sözler ve yeni özelliklere dair kullanıcı beklentileri olsa da ikame ürünün bir gün geç kalması felaket değildir.
Buna karşılık bir uzay sondası fırlatıyorsanız ve gezegenlerin konumu kütleçekim yardımı için uygun olmaktan çıkarsa uzay aracı hedefine varamaz. Yıllık 100 milyon dolar cirolu küçük bir kalıp üreticisi, Ford’dan 2026 F150 üretim hattı için kalıpları mart ayına kadar teslim etme sözleşmesi aldıysa ve gecikirse dakikada 20 bin dolar ceza ödeyecekse, şubatta “beklenmedik bir şey çıktı, olmayacak” diyemez. Ancak kesin yapabilecekse imza atmalıdır.
Ford ya da NASA, teklif hazırlamanın on binlerce dolara mal olduğunu duyunca şaşırmaz. Bir ECO verirler; elle 30 dakikada yapılabilecek gibi görünen bir parça için 3 hafta ve 8 bin dolar gerektiği söylense bile bunun içinde teslim tarihi riski, kabul aşaması, muayene aşaması, acil durum planları vb. olduğunu bilirler.
Ama OP’nin modernizasyon grubunda “bilgi eksik olduğu için bir düğme metnini değiştirmelik 30 dakikalık iş en fazla 3 hafta ve 8 bin dolar sürebilir” derseniz kapıdan kovulursunuz. İyimser tahminler ödüllendirilir, kötümser tahminler bastırılır, doğru tahminler önemsizleşir. Sonunda hep takvimin gerisinde kalınır ve kimse pek şaşırmaz.
Donanım değişiklikleri, işletim sistemi yükseltmeleri, yeni özelliklere uyum gibi bakım işleri buna dahil olabilir. Bu şekilde 10 yıldan uzun süre paralel yürüyen projeler de gördüm.
1505’te Michelangelo, Papa II. Julius’un mezarını tamamlamanın 5 yıl süreceğini tahmin etmişti.
Sistine Şapeli tavan resmi gibi küçük yan işler yüzünden gerçekte yaklaşık 40 yıl sürdü.
Tahmine dayalı teslim tarihi tutturulamadı ve projenin kapsamı ciddi biçimde küçültüldü. Çünkü Papa II. Julius tamamlanmadan öldü; müşteri Julius ve mirasçılarından gelen değişiklik talepleri, tedarik zinciri sorunları, sözleşme yeniden müzakereleri, iş uyuşmazlıkları, nitelikli işçi eksikliği ve uzun süre nedeniyle fonların tükenmesi yaşandı.
Yani bu tür şeyler en azından 1505’ten beri var. İşin komik yanı, Papa’nın o mezara gömülmüş bile olmaması.
Kariyerimin başlarında önemli bir şey öğrendim. İlk verdiğin sayı akılda kalıyor
Ne yazık ki pratikte çoğu zaman böyle oluyor ve insanlar sürekli “Başta X dememiş miydin?” diyor. “Evet ama yeni bilgi edindik” yanıtı her zaman işe yaramıyor
Bunu bilenlerin sayı vermekten kaçınması gibi bir yan etki de ortaya çıkıyor
Scotty: “Elbette, kaptan. Mucizeler yaratan biri olarak ünümü böyle koruyabiliyorum”
Örneğin gün→hafta, hafta→ay, ay→çeyrek yapıyorum. Bir günlük işse 3 hafta diyorum. Çok görünüyor ama bürokrasi, süreçler ve teknik borç yüzünden sonunda çoğunlukla o civarda bitiyor
“Bir sigorta şirketinin tamirciye, ilk tahmin 18.000 dolardı diye ek 20.000 doları ödemeyeceğini söylediğini hayal edebiliyor musunuz? Saçma değil mi? Ben de öyle düşünüyorum. Neyse ki gerçek dünya böyle işlemiyor” denen bir bölüm var; sigortada bu hep olur
Yalnızca otomobil ve konut sigortasında değil, sağlık sigortasında da aynı. Çoğu zaman makul bir noktada pazarlıkla çözülür ama her zaman değil; “gerçek dünya böyle işlemiyor” şeklindeki kendinden emin ton şaşırtıcı
Pert saymak daha pahalı olabilir ama üst sınır nettir ve dosya kapatılabilir. Sigorta şirketleri açık hasar dosyalarını sevmez
İkincisi, otomobil sigortasında “tercihli tarife” de denen şey, belirli türde işleri sabit ve pazarlıkla belirlenmiş tarifeden faturalamaya yönelik çerçeve bir sözleşmedir
Bu, bağlayıcı bir tahminden çok farklıdır. Bağlayıcı tahmin genellikle belirli bir iş için tek seferlik bir tahmindir; tahmini yapan risk alır ve iş beklenenden çok daha karmaşık çıksa bile o tarifeyle tamamlayacağına söz verir
Bir püf noktası, mümkünse her zaman yalnızca sabit kapsam için tahmin yapmak ve bilinmeyen bilinmezleri dışarıda bırakmaktır
“X özelliğini uygulama”yı tahmin etmeyip “X özelliği motoru”nu tahmin etmek gerekir. Ek işler keşfederseniz bunları “mevcut kodun refaktör edilmesi”, “X+Y özellik entegrasyonu” gibi keşfedilmiş kilometre taşları olarak eklemelisiniz
Ancak bunun işe yaraması için bu adlandırma ve anlayışın yukarıya kadar taşınması gerekir. Birisi “X özelliği motoru” kilometre taşını aynı tahminle “X özelliği tamamlandı”ya çevirirse iş biter
Bununla bağlantılı bir sorun da gördüm: liderliğin son tarihleri “motivasyon” sanması. Evi 72F’ye ısıtmak isteyip “daha hızlı olsun” diye termostatı 80F’ye ayarlayan insanlara benziyor
Bir keresinde, alt seviyede bir mühendis olarak katıldığım bir liderlik toplantısında diğer katılımcılar benim orada olduğumu unutmuştu. Biri X son tarihine uymanın çok zor olduğunu kabul edip daha gerçekçi bir tarihe çekilip çekilmemesi gerektiğini sorunca, kıdemli bir PM “Son tarihleri asla oynatmayız! Mühendislik verilen sürenin hepsini kullanır!” diye yanıtladı
O durumda mühendislik, ben o ekipten ayrılarak zamanı geri verdi
Birçok mühendislik ekibinin verilen sürenin tamamını kullanması da doğru
Ancak yöneticiler, tahmin ve planlamayı mühendislerin önünde katı son tarihlere dönüştürmek yerine organizasyonu aşım ihtimaline hazırlamalı. Beklenen tamamlanma zamanı yaklaştığında geliştirici hangi kısmın neden daha uzun sürdüğünü açıklayabiliyorsa bu makul karşılanmalı
Yöneticiler ayrıca müşterilerin, satışın ve üst yöneticilerin planlanan tamamlanma zamanını son tarih gibi görmemesini sağlamalı. Bir taahhüt verilecekse, müşteriyle yüz yüze olan son tarih beklenen tamamlanma zamanından epey sonra olmalı
Elektrikli radyatörlerde de pratikte etkisi olabilir. Çünkü yalnızca radyatörün yakınındaki hava ısındı diye hemen kapanmayacaktır
Çok fazla “kabaca atılmış tahmin”in sert son tarihe dönüştüğünü yaşadıktan sonra, paydaşlara No Estimates yaklaşımını savunuyorum
Başta elbette direnç oluyor. Kaygıları gidermek için, planlamada meşru biçimde kullanılabilecek kadar oldukça doğru tahminlerin aslında yalnızca iki durumda mümkün olduğunu açıklamak yardımcı oluyor
A) Kalan iş, geçmişte yapılan işin neredeyse kopyası olduğunda. Örneğin aynı sistemin veri merkezini ikinci kez provision etmek
B) Ekip, kalan yeni özellik işinin son çeyreğe girdiğine ve başarıyı engelleyebilecek kalan riskler de dahil olmak üzere iyi tanımlandığına karar verdiğinde
Mikro tahmin mikro yönetimi mümkün kılar. Sağlıklı bir ekip, proje başarısı riskine göre en yüksek öncelikli işleri bulur ve yüksekten düşüğe doğru yapar
0 - https://www.youtube.com/watch?v=MhbT7EvYN0c
1 - https://www.goodreads.com/book/show/30650836-noestimates
Eskiden HN’de gördüğüm eğlenceli bir formül dikkatimi çekmişti. Süslü ve havalı görünüyor ama diğer tahmin yöntemleri gibi biçimsel geçerliliği yok; kişisel deneyime dayalı keyfi bir formülden ibaret
https://news.ycombinator.com/item?id=37965582
Benim tahmin matematiğim: R = t × [1.1^ln(n+p) + 1.3^X]
R gerçek süre, t iletişim gerekmese mümkün olan en kısa süre, n müşteri ve geliştirme organizasyonu dahil sürece katılan kişi sayısı, p proje içindeki en uzun iletişim mesafesi, X ise süreçte kullanılan yeni araç, kütüphane ve teknik sayısıdır
Örneğin tek bir geliştiricinin kod yazdığı bir proje 2 hafta sürüyorsa (t=2), toplam 5 kişi dahilse (n=5), 1 yeni araç varsa (X=1) ve en uzun iletişim mesafesi 4 ise 2×(1.1^ln(5+4) + 1.3^1) = 4,5 hafta olur
Bilinen bilinmezlerin yanı sıra bilinmeyen bilinmezler için de X sayısı eklenmeli
Ne yazık ki tahmin aslında bir pazarlık. Sayıyı ilk veren kişi genelde “yüz ekşitme” yüzünden kaybeder
“Tahmininiz nedir?” “Pek bilmiyorum.” “Kabaca da olsa.”
“Peki ne zamana kadar olmasını istiyorsunuz?”
Yeni yöneticilerin her seferinde düştüğü tuzak bu. Bir yanıt verdiğiniz anda bingo. O zaman “yüz ekşitme”yi gösterirler. Dişlerinin arasından nefes alıp yüzlerini ekşiterek “Ah, bu tamamen gerçekçi değil. Bu sayıyı nereden çıkardınız ki?” derler; sonra birkaç kat daha yüksek bir sayı verir ya da iş kapsamını küçültmeyi önerirler. “Vay canına, o sürede şansımız yaver giderse ve diğer projedeki Y özelliğini kesersek ancak X özelliği mümkün olur” gibi
Ne yaparsanız yapın, önemli olan sayıyı ilk veren taraf olmamak. Poker ya da araba satın almak gibi; hissiyatı geliştirmek biraz zaman alıyor. Zaman büyük şirketlerde de paradır ve öyle ele alınmalı. Sıfır toplamlı oyun
Çalıştığım yerde verimlilik adı altında tahminler sürekli düşürülüyor ve devreden işlere de izin verilmiyor
Toparlanma zamanı olmadan bir yıldan uzun süredir crunch’a yakın bir halde yaşadım. Sürekli düzeleceğini umdum ama aksine daha da kötüleşiyor gibi. Üstelik herkes sürekli ürünün farklı alanlarına rotasyonla kaydırılıyor ve seçenek de yok. Hâlâ koşuyorum ama zihinsel olarak tamamen tükenmiş hissediyorum