Özel yazılım geliştirme

Hangi iş özel yazılıma değer, hangisi değmez

Her süreç yazılım yazmayı hak etmez. Ayda birkaç kez tekrarlanan, iki kişinin ilgilendiği ve kuralı sürekli değişen bir iş için bir tablo dosyası çoğu zaman yeterlidir. Özel yazılıma değen işlerin ortak yanı başkadır: aynı veri birden fazla yerde yeniden giriliyordur, bir kaydın hangi aşamada olduğu kimsenin ekranında görünmüyordur ve ay sonunda birinin oturup raporu elle toplaması gerekiyordur.

Keşif görüşmesinde ayırt etmeye çalıştığımız şey budur. Mevcut tablolarınızı, WhatsApp gruplarında dönen iş akışını ve kullandığınız hazır programları açıp bakarız. Çıkan listenin bir kısmı yazılımla değil, kuralı netleştirerek çözülür; bunu da söyleriz. Kapsam dışına çıkardığımız işler teklifin bir parçasıdır, çünkü yapılmayacakların listesi yapılacaklar kadar belirleyicidir.

Ekran çizmeden önce veri modeli

Bir sistemin ömrünü belirleyen şey arayüzü değil, altındaki veri modelidir. ASNPRO’da bina, asansör, sözleşme, bakım kaydı, arıza ve tahakkuk birbirine zincirle bağlıdır: bir asansörün hangi binada olduğu, hangi sözleşmeye tabi olduğu ve o sözleşmenin hangi tahakkuku ürettiği tek bir yerde tanımlıdır. Bu zincir doğru kurulduğu için 1.700’ün üzerinde bakım kaydı sonradan tek tek düzeltilmeden raporlanabiliyor.

Sizin projenizde de ilk iş varlıkları ve aralarındaki ilişkileri yazılı hale getirmek olur: hangi kayıt neyin altında yaşar, silinince neye ne olur, aynı kaydın iki farklı yerde tutulması gereken bir durum var mı. Bu çalışma bir hafta sürer ve sonradan ortaya çıkan “bunu böyle düşünmemiştik” maliyetinin çoğunu buradan alırız.

Yetki yapısı ve kayıt izi

Çok kullanıcılı bir sistemde asıl soru kimin giriş yapabildiği değil, kimin neyi görebildiği ve kimin neyi geri alabildiğidir. Saha personeli kendi bölgesindeki işleri görür ama fiyat alanını görmez; muhasebe tahsilatı düzeltebilir ama bakım kaydını kapatamaz; yönetici her şeyi görür ama sildiği şeyin kaydı durur. Rol tanımlarını bu üç eksende — görme, değiştirme, geri alma — ayrı ayrı kurarız.

Kritik kayıtlarda kim, ne zaman, neyi değiştirdi bilgisini tutarız. Bunun pratik karşılığı şudur: bir tutar yanlış göründüğünde tartışma yerine geçmişe bakılır. Fatura, tahsilat, sözleşme ve resmî belge üreten alanlarda bu kaydı varsayılan olarak açık bırakırız.

Mevcut sistemlerle konuşma tarafı

Çoğu proje boşlukta durmaz; ön muhasebe programı, e-fatura entegratörü, bir e-ticaret paneli veya sahadaki bir cihaz zaten vardır. Bu bağlantılarda ilk baktığımız şey karşı tarafın ne sunduğudur: belgelenmiş bir API mı, yoksa gece çalışan bir dosya aktarımı mı. İkisi de olur, ama seçilen yol teslim süresini ve hata senaryolarını doğrudan değiştirir.

Dışarıya açtığımız API’leri de aynı disiplinle yazarız: sürüm numarası olan, hata durumunda ne döndüğü belli olan, yetkilendirmesi anahtar bazlı uç noktalar. Böylece ileride başka bir yazılımcı sizin sisteminize bağlanmak istediğinde bizden bağımsız çalışabilir.

İki haftalık teslim döngüsü

Çalışma düzeni şudur: keşif ve veri modeli, ardından yazılı kapsam ve aşamalı teklif, sonra tıklanabilir prototip. Prototip onaylanmadan kod yazmaya başlamayız; ekranların sırası ve alan isimleri bu aşamada tartışılırsa sonradan değiştirmek saatler yerine dakikalar alır.

Geliştirme başladıktan sonra iki haftada bir, sizin gerçek verinizle doldurulmuş çalışan bir sürüm açılır. Her teslimde neyin bittiğini, neyin sıradaki döngüye kaldığını ve varsa kapsamı etkileyen bir kararı yazılı olarak iletiriz. Geri bildiriminiz bir sonraki döngünün planına girer; teslim aralığında yön değiştirmek pahalı olduğu için kararları teslim toplantılarında toplarız.

Yayın, kod sahipliği ve sonrası

Yayına alma tek bir güne sıkıştırılmaz. Önce sizin ekibinizden birkaç kişi gerçek işlerini yeni sistemde yapar, eski yöntem hâlâ açıktır. Bu paralel dönem bittiğinde eski dosyalar arşive alınır. Eğitim, kullanıcı rollerine göre ayrı ayrı yapılır; saha personeline yöneticinin ekranını anlatmayız.

Kaynak kod sizindir ve deponuza teslim edilir. Sunucu kurulumunu kendi sunucunuzda ya da bizim kurduğumuz bir ortamda yaparız; ikisinde de yedekleme ve geri dönüş adımları yazılı olarak bırakılır. Sonrasında bakım ve geliştirme anlaşmasıyla devam ederiz — hata düzeltmesi ve yeni özellik talepleri aynı sürüm planında sıraya girer.

Raporlama: kim hangi sayıya bakıyor

Rapor ekranları çoğu projede en sona bırakılır ve en çok da orada hayal kırıklığı yaşanır. Sebebi teknik değil: kimin hangi sayıya, hangi sıklıkla ve hangi kararı vermek için baktığı baştan konuşulmamıştır. Saha sorumlusunun her sabah baktığı liste ile yönetimin ay sonunda baktığı özet aynı ekran olamaz.

Bu yüzden rapor tasarımına soruyla başlıyoruz: bu sayıyı gören kişi ne yapacak. Cevabı olmayan grafikleri ekrana koymuyoruz. Her rapor için hesaplama kuralını yazılı hale getiriyoruz — “tamamlanan bakım” neyi sayar, iptal edilen kayıt dahil mi, tarih hangi alana göre filtrelenir. Aynı raporun iki kişide farklı çıkmasının sebebi neredeyse her zaman bu tanımların yazılı olmamasıdır.

Ağır raporları canlı veritabanı üzerinde değil, önceden hesaplanmış özet tablolar üzerinden çalıştırırız. Ayrıca her rapor ekrandan Excel’e aktarılabilir; ekibinizin kendi hesabını yapmak isteyeceğini varsayarız.