Site Yönetim Yazılımı: Yüzlerce maddelik şartnameden sprint planına

Masada yüzlerce maddelik bir teknik şartname var. Talep yönetiminden aidat tahakkukuna, ziyaretçi kaydından plaka tanımaya, yapay zekâ asistanından afet ve acil durum yönetimine kadar 13 ana başlık ve onlarca alt gereksinim. Hepsi önemli, hepsi bir gün canlıda olacak. Böyle bir belgeyle yola çıkan bir projede iki tuzak vardır: her şeyi aynı anda yapmaya çalışmak ya da önceliklendirme tartışmasında aylar kaybetmek.

Site Yönetim Yazılımı'nda ilk işimiz kod yazmak değil, bu belgeyi yürütülebilir bir plana çevirmek oldu.

Proje kısaca

Site Yönetim Yazılımı, birbirinden farklı çok sayıda konut sitesini aynı kurumsal çatı altında yöneten bir müşteri için geliştirdiğimiz operasyon platformu. Bir web yönetim paneli ile sakin, saha ve yönetici mobil uygulamalarından oluşuyor. Talep ve şikâyet, arıza-bakım-iş emri, aidat ve finans, ortak alan rezervasyonu, ziyaretçi, kargo, duyuru, envanter ve sayaç modülleri aynı veri omurgası üzerinde çalışıyor. ERP ve muhasebe, banka-POS, e-fatura, SMS, IoT sayaç ve plaka tanıma gibi dış sistemler ayrı bir entegrasyon katmanından bağlanıyor.

Şartname maddesinden kabul kriterine

İlk adımda şartnameyi sekiz çekirdek modül grubuna ayırdık: kimlik ve yetki; site, blok ve fiziksel yapı; talep ve şikâyet; ziyaretçi ve misafir; sakin hizmetleri; iletişim ve bildirim; mobil ve panel temelleri; teknik altyapı ve güvenlik. Sonra her grubu alt modüllere böldük ve her alt modül için aynı kalıpta bir doküman yazdık:

• Hangi şartname maddesine karşılık geldiği ve hangi fazda yer aldığı,
• İş kuralları, ana senaryolar ve istisnalar,
• Veri alanları, ekran ihtiyaçları ve bağımlılıklar,
• Kabul kriterleri, açık noktalar ve varsayımlar.

Bu dokümanlar sprint bazlı iş paketlerine dönüştü. Her şartname maddesi bir modül dokümanına, her modül de bir sprint paketine bağlandı ve kabul kontrolleri bu zincir üzerinden yapıldı. Bir ekranın neden var olduğu ya da bir kuralın nereden geldiği sorusunun cevabı her zaman bir madde numarasıydı.

İlk fazın sprint sırası da bu mantığı yansıtıyordu: önce teknik temel ve kimlik modeli, ardından fiziksel yapı omurgası, panel ve mobil giriş yüzleri, talep akışı ve bildirimler, ziyaretçi ve sakin hizmetleri; en sonda güvenlik, denetim ve izin katmanının sertleştirilmesi ve kabul hazırlığı.

Her fazı bir sonrakine hazır bırakmak

Üç aşamalı bir plan kurduk. İlk aşamada kimlik, yetki, fiziksel yapı, talep ve sakin hizmetleri canlıya alındı; ikinci aşamada finans, aidat, bakım, rezervasyon ve saha mobili eklendi; üçüncü aşamada IoT, erişim kontrol, personel-vardiya ve yapay zekâ asistanı gibi ileri modüllerle platform tamamlandı. Her aşama kendi kabul kriterleriyle devreye alındı ve bir sonraki aynı omurganın üstüne kuruldu.

Planın en işe yarayan bölümlerinden biri, her fazın dokümanında yer alan "faz dışı ama bağımlı alanlar" listesiydi. İlk fazda donanım bağımlı geçiş sistemleri, finansal entegrasyonların tam akışı ya da sayaç verileri teslim edilmiyordu; ama veri modeli ve mimari bu alanlar hesaba katılarak kuruldu. Üçüncü fazda plaka tanıma geldiğinde, araç bilgisini fiziksel yapıyla eşleştiren temel ilk fazdan beri yerindeydi.

Dış sistemler için de aynı mantığı uyguladık. Banka, e-fatura, ERP, plaka tanıma ve sayaç cihazları farklı takvimlerde devreye giriyordu. Entegrasyonları iş kurallarına dokunmayan ayrı bir adaptör katmanından bağladığımız için bir entegrasyonun gecikmesi ürünü bekletmedi. API anahtarları ve servis durumları da panelden yönetiliyor; banka ya da ERP gibi her bağlantının kendi anahtarı, hangi sitelerde ve hangi kapsamlarda kullanıldığı kayıtta duruyor.

Güvenlik tabandan, ayrımlar yazılı

Rol-izin matrisi, denetim kayıtları, KVKK rıza yönetimi ve API anahtar yönetimi sonraya bırakılmadı; ilk aşamanın parçası olarak devreye alındı. İş kurallarını dokümanlarda bu kadar ayrıntılı yazmanın faydasını en çok yetki tasarımında gördük. Aynı kişi bir sitede kat maliki, başka bir sitede kiracı ya da müşavir olabiliyor. Bu yüzden kullanıcı tek kayıt olarak tutuldu; yetkiler site bağlantısı üzerinden ve rol bazlı verildi. Talep ekipleri ile iş ekipleri de birbirinden bağımsız tanımlandı.

Dokümana giren bir ayrım ise ileride çıkabilecek bir açığı baştan kapattı: kayıt tipi ile uygulama rolü aynı şey değil. Kayıt formunda "müşavir" etiketini seçmek kimseye site yetkisi vermiyor; yetki ancak site bağlantısına eklenen rolle açılıyor. Bir etiketin sessizce yetki açması gibi riskler, ancak böyle bir ayrım yazıya döküldüğünde görünür hâle geliyor.

Sahada öğrendiklerimiz

• Şartnameyi küçültmeyin, izlenebilir kılın. Kapsamı azaltmak yerine her maddeyi bir dokümana ve sprint paketine bağlamak, önceliklendirmeyi bir tartışma olmaktan çıkardı.
• Kabul kriteri işin başında yazılır. Neyin ne zaman bitmiş sayılacağını baştan bilmek, aşamaları kendi kabulüyle canlıya almayı mümkün kıldı.
• Bugün yapılmayacak işi de bugün tasarlayın. Faz dışı ama bağımlı alanları veri modelinde hesaba katmak, sonraki fazların aynı omurganın üstüne kurulmasını sağladı.
• Entegrasyon takvimi ürün takvimi olmamalı. Adaptör katmanı, dış sistemlerin gecikmesini ürünün gecikmesine dönüştürmedi.

Büyük bir şartname bir engel değil, iyi okunursa en ayrıntılı yol haritasıdır. Yeter ki her maddenin bir fazı, bir dokümanı ve bir kabul kriteri olsun.

Elinizdeki şartname nasıl bir plana dönüşebilir?

Kapsamı geniş bir şartnameyle yola çıkmak üzereyseniz ya da elinizdeki gereksinimlerin nereden başlanacağını bilmiyorsanız, planlama aşamasından itibaren birlikte çalışabiliriz. Site Yönetim Yazılımı proje sayfasında modülleri inceleyebilir, iletişim sayfamızdan bizimle görüşme planlayabilirsiniz.