Pazartesi sabahı saat 10:00. Toplantı odasında (veya Zoom ekranında) toplanmış sekiz kişilik bir yazılım ekibi. Önlerinde açık duran Jira tahtası ve ekranın köşesinde parlayan bir "Planning Poker" uygulaması.

Masa başındaki Scrum Master veya Ürün Yöneticisi (Product Manager) boğazını temizleyerek sıradaki görevi okur:

"Kullanıcı ödeme adımlarında çoklu para birimi desteği ve veritabanı şemasının geriye dönük uyumlu refactor edilmesi."

Geri sayım başlar: 3, 2, 1... Kartlar açılır.

Kıdemli backend mühendisi: 13 puan.
Veritabanı uzmanı: 13 puan.
Junior geliştirici: 8 puan.
Ve teknik geçmişi olmayan, kariyerinde tek bir satır kod yazmamış, işin tüm mutfağını Excel tablolarından ibaret sanan Proje Yöneticisi: 2 puan.

Odaya bir anda derin, buz gibi bir sessizlik çöker. Yönetici kaşlarını çatarak ekrana bakar: "Arkadaşlar, neden 13 verdiniz ki? Altı üstü kullanıcı ekranında Dolar ve Euro simgesi gözükecek, bir de veritabanına bir kolon ekleyeceksiniz. Buton rengi değiştirmek gibi bir şey değil mi bu? Bence buna en fazla 3 puan verelim, çarşamba öğleden sonraya biter."

İşte o an, modern kurumsal yazılım dünyasının en trajikomik tiyatrosu olan "Planning Poker Kabaresi" perdesini açmıştır.

Ameliyathaneye Kronometreyle Giren İdari Memur

Bu sahneyi sağlık sektöründeki bir analogla gözünüzün önüne getirin.

Acil serviste bir cerrahi ekip, trafik kazası geçirmiş ve iç kanaması olan bir hastayı acilen ameliyathaneye almıştır. Cerrah batını açmış, parçalanmış dalağı onarmaya, mezenterik damarlardaki kanamayı klemplemeye çalışmaktadır.

Tam o sırada ameliyathanenin kapısı tekmeyle açılır. İçeriye hastanenin mali işler ve idari süreçler müdürü girer. Elinde bir kronometre ve bir pano vardır. Cerrahın omzuna dokunup şöyle der:

"Hocam, apandisit ameliyatını geçen hafta 25 dakikada bitirmiştiniz. Bu dalağı da 20 dakikada dikip kapatın lütfen. Koridorda bekleyen 15 hasta daha var, Sağlık Bakanlığı'nın bekleme süresi KPI'larını tutturamıyoruz. Ayrıca dikiş atarken kullandığınız ipliği de yarıya indirin, maliyetler şişiyor."

Böyle bir durumda cerrah ne yapar? Muhtemelen steril eldivenlerini çıkarıp o yöneticinin suratına fırlatır ve hastayı öldürmemek için onu derhal ameliyathaneden dışarı attırır.

Çünkü tıpta ameliyatın süresini idari memurun arzuları değil; hastanın anatomisi, dokunun kırılganlığı ve kanamanın şiddeti belirler. Cerrah bistüriyi vurduğu anda içeride neyle karşılaşacağını %100 öngöremez; karın boşluğu açıldığında beklenmeyen bir yapışıklık, atipik bir damar varyasyonu veya gizli bir nekroz çıkabilir.

Yazılım mühendisliği de tam olarak canlı bir cerrahidir. Kod tabanınız sizin hastanızdır. Ekranda gördüğünüz "küçük bir para birimi simgesi", aslında buzdağının suyun üstündeki 1 milimetrelik ucudur.

Suyun altında ise; distributed transaction yönetimi, mikroservisler arası eventual consistency problemleri, eski ödeme sağlayıcılarının geriye dönük uyumsuzlukları, veritabanında milyonlarca satır kilitlenmeden (lock contention) yapılacak şema migrasyonları ve concurrency yarış durumları (race conditions) yatmaktadır.

Kodun C'sini bilmeyen bir yöneticinin "altı üstü bir kolon ekleyeceksiniz" demesi, batın cerrahisine "altı üstü deriyi kesip biçeceksiniz" demek kadar vahim bir cehalettir.

Hayatta Kalma Kalkanı: Efor Şişirme ve Padding Sanatı

Peki, bu liyakatsiz baskı karşısında yazılımcılar ne yapar? İsyan edip istifa mı ederler?

Hayır, çoğu zaman hayatta kalma mekanizmasını devreye sokarlar: Eforları sistematik olarak şişirmek (Padding).

Mühendis bakar ki, gerçekçi bir tahmin verdiğinde (örneğin "Bu iş temiz ve testleriyle birlikte 3 gün sürer" dediğinde), yönetici bunu 1 güne indirmek için pazarlık yapıyor. O zaman mühendis zihninde bir savunma algoritması çalıştırır:

İşin gerçek süresi: 3 gün.
Beklenmeyen teknik borç payı: 2 gün.
Yöneticinin pazarlıkla kırpacağı pay: 3 gün.
Toplam talep edilen efor: 8 gün.

Mühendis toplantıda "Bu iş en az 8 gün sürer" der. Yönetici zafer kazanmış bir komutan edasıyla pazarlığa oturur: "8 çok, bunu 5 günde bitirin, anlaşalım."

Mühendis yüzünü ekşitir, sanki büyük bir fedakarlık yapıyormuş gibi iç çeker: "Peki, ekip olarak gecemizi gündüzümüze katarız, 5 günde bitirmeye çalışırız."

Sonuç? Herkes mutludur! Yönetici "üç günlük tasarruf sağladım" diyerek üst yönetime sunum yapar; mühendis ise aslında 3 günde bitireceği iş için 5 gün alarak arkasını sağlama almış, stresini minimize etmiştir.

Ancak bu sahte mutluluğun bedeli çok ağırdır: Karşılıklı güvenin tamamen yok olması.

Yönetici bilir ki yazılımcı eforu şişiriyor; yazılımcı bilir ki yönetici her tahmini yarıya indirmeye çalışacak. Ortada mühendislik tahmini kalmaz; pazar yerinde domates fiyatı için yapılan şark kurnazlığı kalır.

Story Point Bir Para Birimi Değildir

Scrum ve Çevik (Agile) metodolojilerin ortaya çıkış amacı bu değildi.

Fibonacci dizisi (1, 2, 3, 5, 8, 13...) zamanı değil; karmaşıklığı, bilinmezliği ve riski ölçmek için tasarlanmıştı. Bir işe 13 puan vermek, "bu iş 13 gün sürer" demek değildir; "bu işte çok fazla bilinmeyen değişken var, risk yüksek, mimari olarak dikkatli adım atmalıyız" demektir.

Fakat teknik bilgisi olmayan yöneticilerin elinde Story Point, doğrudan saate ve güne dönüştürülen bir kölelik katsayısına evrildi: "Ekibin sprint hızı 40 puan, demek ki adam başı günde 2 puan kod yazacaksınız!"

Bu matematiksel ilkellik, yazılımın doğasına aykırıdır. Bir mühendis bazen üç gün boyunca ekrana tek bir satır kod yazmadan sadece mimari çizer, logları inceler ve bellek profili çıkarır; dördüncü gün tek bir satırlık bir konfigürasyon değişikliğiyle tüm sistemi 10 kat hızlandırır. O tek satır kodun değeri, bin satır kopyala-yapıştır kod yazmaktan çok daha büyüktür.

Tiyatroyu Bitirmek

Bu kısır döngüyü kırmanın tek bir yolu vardır: Teknik liderliğe saygı duymak ve tahminin doğasını anlamak.

Bir hastanede başhekim nasıl ki mali işler uzmanı değil de kıdemli bir tıp doktoru olmak zorundaysa; yazılım ekiplerinin başında da kodun kokusunu (code smell) bilen, teknik borcun faturasını ödemiş, mimari vizyona sahip teknik liderler olmak zorundadır.

Yöneticinin görevi mühendisle kodun kaç saat süreceği üzerine pazarlık yapmak değildir. Yöneticinin görevi:

İş gereksinimlerinin sınırlarını netleştirmek,
Ekibin önündeki bürokratik ve organizasyonel engelleri kaldırmak,
Ve mühendisin "burada yüksek risk var" uyarısına saygı duyarak ürünün takvimini o gerçekliğe göre yönetmektir.

Tahmin bir taahhüt değil, bir olasılık dağılımıdır. Yazılım dünyasında hiçbir ameliyat yüzde yüz garantili değildir. Ve o masada bistüriyi tutan insana güvenmiyorsanız, o masaya hiç oturmamalısınız.

efor-tahmini

"Teknik Bilmeyen Yönetici" ve Şişirilen Efor Tahminleri (Planning Poker Tiyatrosu)