BM Tan Mühendislik'te müşteri dosyalarını, belediye takip süreçlerini ve evrak akışlarını yönetmek her geçen yıl biraz daha karmaşık bir hal aldı. Kullandığım araçlar ya çok geneldi ya da harita ofisinin gerçekliğine hiç uymuyordu. Bir gün kendime şunu sordum:
"Ben her gün müşteri takibi yapıyorum, neden bunu otomatik yapan bir sistem yok?"
Cevap basitti: yoktu, çünkü kimse harita ofisi işleyişini gerçekten bilmeden bu yazılımı yazmamıştı. O gün kolları sıvadım. Bir yılı aşkın süren bu macerada; kimi gece dört saatlik uyku, kimi gün "sil baştan" kararları ve kimi hafta "acaba bırakayım mı?" sorularıyla karşılaştım. Ama sonunda HaritaOfis ortaya çıktı. Ve bu süreç bana kodlamanın çok ötesinde üç ders verdi.
Alanı Bilmeden Yazdığın Kod, Alanı Bilmeyen Birine Değer Vermez
İlk prototipimi yazdığımda çok heyecanlıydım. Müşteri bilgilerini girilebilen, dosya eklenebilen güzel bir form ekranı. Teknik olarak çalışıyordu. Ama bir gün ofiste oturup gerçekten kullanmaya çalıştığımda fark ettim: Bu form harita ofisinin dilini konuşmuyordu.
Bir ifraz işleminde "parsel numarası", "pafta", "ada" ve "belediye onay tarihi" birbirinden bağımsız ama aynı anda takip edilmesi gereken kavramlar. Bunları genel bir "müşteri kaydı" formuna sıkıştırmak, işi kolaylaştırmak bir yana, daha da girift hale getiriyordu.
// İlk yazım: Genel bir CRM gibi düşündüm
müşteri.ad = "Ahmet Bey"
müşteri.notlar = "ifraz işlemi var" // ← Bu yeterli değil!
// Doğru yaklaşım: Alanı yansıtan veri modeli
dosya.parselNo = "125/3"
dosya.ada = "42"
dosya.pafta = "F19C2"
dosya.belediyeAşama = "Onay Bekliyor"
dosya.sonTarih = "2026-03-20"Yazılımı yeniden yazmak zorunda kaldım. Ama bu "yeniden yazma" aslında en değerli adımdı. Çünkü bu sefer kağıda önce şunu çizdim: Bir ifraz dosyası ofisimizde nasıl bir yolculuk yapıyor? Hangi adımda hangi bilgiye ihtiyaç var? Belediyeyle muhatap olurken ne soruyorlar?
Kod yazmadan önce en az iki hafta sadece süreci gözlemle. Kağıda çiz. Müşterilerle konuş. Kullanıcı sen bile olsan, "geliştirici gözü" süreci körleştirir.
Mükemmel Sistemi Beklemek, Sistemsiz Çalışmakla Aynı Şey
İkinci büyük hatam "hazır olmadan yayınlamama" takıntısıydı. Belediye entegrasyonu olsun, otomatik SMS bildirimi çıksın, takvim senkronizasyonu eklensin... Ay geçiyor, kod yazılıyor ama ofiste hâlâ eski yöntemle çalışılıyordu.
Bir gün mentorum — aslında deneyimli bir yazılımcı değil, yıllarca müteahhitlik yapmış bir arkadaşım — bana şunu dedi: "Yarım bina, boş arsadan iyidir. İnsanlar içinde yaşamaya başlayınca ne eksik olduğunu söylerler."
Bu söz kafama kazındı. Ertesi gün temel özellikleri çalışır hale getirip sistemi ofisimde kullanmaya başladım. Üç hafta içinde gerçek kullanımdan doğan on beş farklı eksikliği fark ettim — bunların hiçbirini masada otururken tahmin edemezdim.
Harita ölçümünde de aynı ilke geçerli: Önce röper noktalarını al, sonra detay ölçüme geç. Tüm noktaları kafada planlamak yerine sahaya çık.
"Yeterince iyi" olan bir sistem bugün, "mükemmel" olan bir sistem asla olacak bir sistem değildir. Erken kullan, erken öğren.
Teknik Olmayan Problemler, Teknik Problemlerden Daha Zor
Yazılımın teknik kısmını öğrenmek; HTML, CSS, biraz JavaScript ve birkaç AI aracıyla mümkün oldu. Asıl zorluk hiçbir zaman "bu kodu nasıl yazarım?" olmadı. Asıl zorluk şu sorulardı:
- Müşteriyi nasıl sisteme geçiririm, direnci nasıl kırarım?
- Belediye süreçleri değiştiğinde sistemi hızlıca nasıl güncellerim?
- Bir özelliğe haftalar harcadım ama kimse kullanmıyor — ne yapacağım?
- Güncelleme yaparken eski veri bozulursa ne olur?
Bu sorular "yazılım geliştirme" sorusu değil, "değişim yönetimi", "kullanıcı psikolojisi" ve "risk yönetimi" sorularıydı. Basketbol antrenörlüğü yıllarım burada devreye girdi. Bir takıma yeni bir savunma sistemi öğretmek de tam böyle hissettiriyor: Teknik olarak doğru bile olsa, oyuncular benimsemezse sahada işe yaramıyor.
- Yeni sistem önce anlamsız gelir
- Küçük kazanımlar güven oluşturur
- Takım içi direnci kırmak zaman ister
- Gerçek maçta test edilmeden bilgi eksik
- Yeni sistem önce zahmetli gelir
- Küçük kolaylıklar benimsemeyi tetikler
- Kullanıcı direncini kırmak zaman ister
- Gerçek kullanımda test edilmeden bilinmez
Çözüm her iki durumda da aynıydı: Sabır, tutarlılık ve küçük adımlar. Ofisimdeki çalışma arkadaşlarıma sistemi zorla değil, önce en sıkıcı manuel işi otomatikleştirerek tanıttım. İlk günden "her şeyi bu sistemden yönetin" demedim; "belediye takibini bundan yapın, gerisine dokunmayın" dedim.
En iyi yazılım, insanları dönüştürmek yerine insanlara uyum sağlayan yazılımdır. Kullanıcı direnci bir hata değil, bir bilgi kaynağıdır.
Sonuç
HaritaOfis hâlâ gelişiyor. Her yeni özellik, yeni bir ders getiriyor. Ama bu üç temel ders — alanı bil, erken yayınla, insan sorununu ihmal etme — artık her satır kod yazarken aklımın bir köşesinde duruyor.
Harita mühendisliğinde öğrendiğim en önemli şeylerden biri şuydu: Arazinin bir karakteri vardır ve onu sahaya çıkmadan anlayamazsın. Yazılımın da bir karakteri var. Ve onu ancak gerçek kullanıcının eline vererek öğrenebilirsin.
"Hem sahada hem ekranda en değerli alet: gözlemlemek için ayırdığın zaman."
— Mert Tan