Bir yazılım projesinin ilk haftasında en sık duyulan cümle şudur: "Biz sadece ekranın tam olarak neyi göstereceğini bilmek istiyoruz." Bu cümle, projenin en tehlikeli başlangıcıdır. Çünkü ekran, bir kurumun dilinin en son çıktısıdır; en başlangıç noktası değil.

Başlangıç noktası: olay, değil belge

İtfaiyede bir çağrı geldiğinde ilk yazılı yapan şey rapor değildir. İlk yazılı yapılması gereken şey karar zinciridir:

  1. Çağrı alınır ve sınıflandırılır.
  2. Hangi birim, hangi ekipman, kaç kişi gidecek?
  3. Kim karar veriyor, kimin onayına gidiyor?
  4. Olay bittiğinde hangi veri gerçekten işe yaradı?

Bu dört sorunun cevabı, uygulamanın ekran düzenini belirler. "Rapor ekranı" en sonda çıkar; en başta gelir.

Ekrana başlamak, kurumun hangi sorulara ihtiyaç duyduğunu sormadan yazılım yazmaktır. Sorular önce gelir.

Kural 1: Sahada yazılan kod, sahada ölçülür

Her yeni sürüm, sahada en az bir ekibin gerçek bir vardiyasında kullanılmadan yayına alınmaz. Bu süreç yavaştır ama alternatifi daha yavaştır: kullanılmayan bir sistem.

Kural 2: Veri modeli kurumun modelini yansıtmalı

İtfaiye bir "vaka" açar, ASKı bir "abone" açar. Bu iki kavramı tek bir tabloya sıkıştırmak, altı ay sonra her iki tarafın da verisini bozar. Alan adları, kurumun konuştuğu kelimeler olmalıdır.

// Kötü: herkes için geçerli görünen, kimse için doğru olmayan model
type Ticket = {
  type: string
  subject: string
  body: string
}

// İyi: kurumun dilini modele taşıyan yapı
type FireCall = {
  reportedAt: Date
  district: District
  callType: 'STRUCTURE' | 'VEHICLE' | 'RESCUE' | 'OTHER'
  dispatchedUnits: Unit[]
  commanderId: PersonId
  decisionLog: Decision[]
}

Kural 3: Giriş ekranı, ihtiyaç duyulan yerde olmalı

Sahadaki operasyoncu eldivenli, karanlıkta ve aceleyle çalışıyor. Üç saniyede iki dokunuşla ekran değiştiremezseniz, kimse kullanmaz. Bu yüzden ilk ekran "tek kart, tek eylem, tek büyük buton" prensibiyle kurulur.

Kural 4: Ölçülebilir olmayan hiçbir iyileştirme yayına giremez

"Kullanıcılar memnun" bir argüman değildir. Çağrı kabul süresi, form doldurma süresi, hatalı kayıt oranı — bunlar tartışmayı bitirir.

Sahadan yazılıma giden bu yol, kamu kurumlarında neden bu kadar zor? Çünkü kurumun bilinmeyen değişken sayısı fazla ve karar yetkisi dağınık. Ama yazılım, dağınık kararı tekrarlanabilir bir akışa dönüştürebilen en güçlü araç.