Bir yazılım projesine başlama kararı verildiği an, toplantı odasındaki veya zihindeki hava aniden değişir. Masada bir fikir vardır, havada ise belirsizlik. İnsan zihni, özellikle de mühendislik disiplinine yakın zihinler, belirsizlikten hoşlanmaz. Bu rahatsızlığı gidermek için en hızlı, en bilindik ve en tehlikeli yola başvururuz: Somutlaştırmak.

Bu noktada, projenin kaderini daha ilk dakikada belirleyen o klasik soru sorulur:

“Peki, ne yapacağız?”

Bu soru sorulduğu anda odaya bir rahatlama gelir. Çünkü cevaplaması en kolay soru budur. Hemen beyaz tahtalar doldurulur, listeler çıkarılır, ekranlar hayal edilir. “Kullanıcı şuradan girecek”, “Burada bir raporlama butonu olacak”, “Admin panelinde şunlar görülecek”.

Herkes bir şeyler “tanımladığı” için mutludur. Proje başlamış, tekerlek dönmüş, belirsizlik dağılmış gibi hissedilir. Kağıt üzerinde her şey harika görünür. Excel tablolarına yazılan özellik listeleri, projenin bir planı varmış hissi yaratır.

Oysa yazılım projelerinin çok büyük bir kısmının başarısız olmasının sebebi, kodlama aşamasındaki teknik yetersizlikler değildir. Asıl sebep, çoğu zaman organizasyonel alışkanlıklar ve başlangıçta sorulan bu sorunun yarattığı erken netlik yanılsamasıdır.

“Ne yapacağız?” sorusu, henüz problemin kendisi, sınırları ve riskleri netleşmeden, doğrudan çözüme odaklanmayı zorlayan bir tuzaktır. Henüz teşhis konulmamış bir hastaya reçete yazmaya benzer. İlaçlar gerçek olabilir, dozajlar milimetrik hesaplanmış olabilir; ama hastalık o değilse, tedavinin mükemmelliği hiçbir şeyi kurtarmaz.

Somutluk Tuzağı ve İlerleme İllüzyonu

Yazılım geliştirmede en büyük yanılgı, yapılacak işi tanımlamanın belirsizliği çözdüğünü sanmaktır. Oysa çoğu zaman yapılan şey belirsizliği çözmek değil, onu görmezden gelmektir.

Belirsizlik, doğası gereği kaygı yaratır. “Müşterinin buna gerçekten ihtiyacı var mı?”, “Pazar buna hazır mı?”, “Bu teknik olarak beklediğimizden zor olabilir mi?” gibi soruların cevapları hemen verilemez. Araştırma gerektirir, zaman alır ve en önemlisi; cevap “Hayır” olabilir.

Oysa şu cümleler nettir, somutttur ve güven verir:

  • Kullanıcı giriş ekranı yapılacak. (2 gün)
  • Raporlama modülü kodlanacak. (5 gün)
  • Ödeme entegrasyonu sağlanacak. (3 gün)

Bu listeyi yaptığınızda, yöneticiler bütçeyi, proje yöneticileri zamanı, yazılımcılar ise iş yükünü yönetebildiğini sanır. Bu, tehlikeli bir ilerleme illüzyonudur. Çünkü bu liste, doğrulanmış gereksinimlerden değil, olması iyi olur varsayımlarından oluşur.

Bu listeye bir madde eklendiğinde, beyin o maddeyi “yapılacak” olarak işaretler ve “gerekli mi?” sorgusunu kapatır. Artık hedef o özelliği en iyi şekilde kodlamaktır. O özelliğin hiç yazılmaması gerektiği ihtimali, masadan kalkmıştır.

Çözüm Aşığı Olmak: Projeyi Sessizce Kilitleyen Refleks

Bu yanılgı, proje süreçlerinde çok belirgin ve maliyetli davranış kalıpları üretir. Bir ekip problemi anlamak yerine hemen çözümü tasarlamaya başladığında, sektörde çözüme aşık olma denilen körlük başlar.

Bu körlük başladığında, toplantılarda konuşulan konuların ekseni kayar:

1. Araç, Amacın Önüne Geçer

Henüz neyin, neden yapılacağı, hangi verinin neden kritik olduğu netleşmeden teknik tartışmalar başlar. “Hangi dili kullanalım?”, “NoSQL mi kullanalım Relational mı?”, “Hangi Cloud sağlayıcı daha ucuz?”. Bu sorular önemlidir ama projenin bu aşamasında değil. Bir binanın ne amaçla kullanılacağını bilmeden, temelinde hangi çimentoyu kullanacağını tartışmak mühendislik değil, kaynak israfıdır.

2. Mikro Kararlar, Makro Sorunları Gizler

Ana değer önerisi belirsizken, ekip kendini detaylarda güvende hissetmeye çalışır. “Butonun rengi mavi mi olsun, turuncu mu?” veya “Logonun yeri sağda mı solda mı?” gibi mikro kararlar projenin merkezine oturur. Kritik ve riskli kararlar ertelenirken, önemsiz detaylar saatlerce konuşulur.

3. Kusursuz Senaryo Yazılımı

“Ne yapacağız?” listesi genellikle her şeyin yolunda gittiği senaryoları içerir. Ancak gerçek hayat hatalarla doludur. Listeye odaklanan ekipler, uç durumları ve potansiyel hataları düşünmez. Sonuçta ortaya çıkan yazılım, demo sunumunda harika çalışır ama gerçek dünyada ilk kullanıcının elinde patlar.

Ölçek Fark Etmeksizin Aynı Hata: Girişimciden Kurumsala

Bu tuzağa sadece tecrübesiz ekipler düşmez. “Ne yapacağız?” refleksi, projenin ölçeğine veya sahibine göre farklı kılıklara girer, ancak sonuç her zaman aynıdır: Kaynak israfı ve teknik borç.

Girişimci Dünyasında: Vizyon Zehirlenmesi

Girişimci, aklındaki fikre aşıktır. Onun için “Ne yapacağız?” sorusu, kafasındaki vizyonu geliştiricilere aktarma seansıdır. Genellikle cümleler “Uber gibi olacak ama X sektörü için” şeklinde başlar.

Buradaki temel hata, girişimin en büyük riskinin yazılımı yapamamak olduğunu sanmaktır. Oysa bir startup için en büyük risk, kimsenin istemediği bir yazılımı mükemmel şekilde yapmaktır. Girişimci, ne yapılacağını dikte ederek, yazılım ekibini sadece birer uygulayıcıya dönüştürür. Ekip, iş modelindeki açıkları veya mantıksız akışları görse bile, görev tanımı verilen listeyi kodlamak olduğu için uyarmaz. Sonuç? 6 ay sonra yayına alınan, hatasız çalışan ama kimsenin kullanmadığı bir hayalet kasaba.

Kurumsal Dünyada: Bütçe Koruma Refleksi

Kurumsal dünyada durum daha politiktir. Burada “Ne yapacağız?” sorusu, genellikle yıllık bütçe dönemlerinde sorulur. Bir departman, bütçe alabilmek için yapılacaklar listesini mümkün olduğunca kalabalık tutar. Kapsam ne kadar büyükse, bütçe o kadar büyük olur mantığı işler.

Buradaki motivasyon, problemi çözmekten çok, bütçeyi yakmamaktır. Analiz ve tasarım aşaması genellikle bir zaman kaybı olarak görülür ve hemen kodlamaya geçilmesi istenir. Sonuçta ortaya çıkan ürünler, yüzlerce özelliğe sahip olan, her şeyi yapan ama hiçbir şeyi pratik yapmayan hantal yapılara dönüşür. Şişmiş yazılım tam olarak böyle doğar.

Hizmet Alımında: Sözleşme Tuzağı

Bir firma dışarıdan yazılım hizmeti alırken, parasının karşılığını sayılabilir çıktılarla ölçmek ister. “5 modül, 20 ekran, 3 entegrasyon.” Bu yüzden sözleşmeyi yapılacaklar listesi üzerine kurar.

Ancak yazılım geliştirme süreci lineer değil, iteratif bir öğrenme sürecidir. Üçüncü ayda öğrenilen bir bilgi, birinci ayda planlanan modülü gereksiz kılabilir. Ama sözleşme yapılacaklar üzerine kurulu olduğu için, o gereksiz modül yapılır. Müşteri parasını, ajans da zamanını çöpe atar. İki taraf da sözleşmeye uymuştur ama ortaya çıkan değer düşüktür.

"Yazılımcılar Bizi Anlamadı" Efsanesi

Proje kaçınılmaz sona ulaşıp, bütçe aşılıp, ortaya çıkan ürün beklentiyi karşılamadığında, suçlu genellikle teknik tarafta aranır.

  • “Yazılımcılar işi çok uzattı.”
  • “Kullandıkları teknoloji yanlıştı.”
  • “Analiz yetenekleri zayıftı, ne dediğimizi anlamadılar.”

Bu suçlamalar, gerçek sorunu maskelemekten başka bir işe yaramaz. Sorun, yazılımcının React yerine Vue kullanması, Java yerine Go ile yazması veya veritabanı şeması değildir. Sorun, yazılımcının önüne konulan listenin doğruluğunun hiç sorgulanmamış olmasıdır.

Yazılım ekibi, kendisine verilen listeyi harfiyen uygulamış olabilir. Teknik olarak mükemmel, performanslı, hatasız bir kod yazmış olabilirler. Ama eğer o kod, yanlış bir varsayımı hayata geçiriyorsa, teknik mükemmellik bir anlam ifade etmez.

Yönetim biliminde buna yanlış şeyi doğru yapmak denir. Yanlış şeyi doğru yaptığınızda, hatayı fark etmeniz çok daha uzun sürer. Çünkü sistem çalışıyordur, hata vermiyordur, sadece beklenen iş sonucunu üretmiyordur. Bu, en sinsi başarısızlık türüdür.

Listeyi Yırtıp Atın: Doğru Başlangıç Soruları

Peki, bir yazılım projesine nasıl başlanmalı? “Ne yapacağız?” sorusunu çöpe atıp yerine ne koymalıyız?

Sağlıklı, sürdürülebilir ve gerçekten değer üreten bir proje için sorulması gereken soru seti şudur:

1. “Hangi problemi çözüyoruz?”

Bu soru, çözümü değil, acıyı odaklar. “Bir CRM yapacağız” demek bir çözümdür. “Müşteri verilerimiz 3 farklı excelde durduğu için takip edemiyoruz ve satış kaçırıyoruz” demek bir problemdir. Problemi netleştirdiğinizde, çözümün her zaman sıfırdan yazılım yazmak olmadığını, bazen hazır bir aracın veya basit bir entegrasyonun yetebileceğini görebilirsiniz.

2. “Bunu çözmezsek ne olur?”

Bu soru, projenin değerini ve önceliğini belirler. Eğer cevap “Çok da bir şey olmaz, sadece biraz yavaşlarız” ise, o projeye büyük bir özel yazılım yatırımı yapmak hatadır. Yazılım, işletmenin veya kullanıcının kritik darboğazlarını açmak için yapılmalıdır.

3. “En büyük riskimiz ne?”

Teknik risk mi, pazar riski mi, operasyonel risk mi? Listeler genellikle riskleri gizler, her şeyi eşit önemde gösterir. Doğru yaklaşım, önce en riskli varsayımı test edecek en küçük yapıyı kurmaktır.

Bu sorular, rahatsız edicidir. Hemen somut ekranlar, renkli butonlar vaat etmezler. Toplantı masasında derin bir sessizlik yaratırlar. Ancak o sessizlik, projenin kurtulduğu andır.

Yazılım geliştirmek, kod yazma işi değil, karar verme işidir. Kod, verilmiş kararların sadece sonucudur. Eğer kararlar, “Ne yapacağız?” aceleciliğiyle değil, “Neden yapıyoruz?” derinliğiyle alınırsa, ortaya çıkan yazılım sadece çalışan bir program değil, işe yarayan bir çözüm olur.

Bu noktada olan birçok ekip, bu netliği tek başına aramıyor. Kendi varsayımlarını sorgulamak zordur; çünkü insan kendi fikrine kolayca ikna olur. Varsayımları dışarıdan bir gözle konuşmak, “Neden?” sorusuna maruz kalmak, çoğu zaman süreci inanılmaz derecede hızlandırıyor. Asıl zaman kaybı, düşünmek için durmak değil, yanlış sırayla ilerlemekten geliyor.