Cy Logic Insights

Özel Yazılım Projesi Nasıl Yürütülür? Analizden Bakıma Sekiz Aşamalı Yol Haritası

Keşiften yayına ve sonrasına: bir özel yazılım projesinde her aşamanın çıktısı, en sık yapılan hatalar ve işletme tarafının sorumlulukları. / From discovery to launch and beyond: what each phase of a custom software project delivers, common pitfalls and what the client side owns.

Özel yazılım projelerinin başarısız olmasının nedeni çoğunlukla teknik değildir: belirsiz kapsam, geç alınan kararlar ve kimin neyi onaylayacağının bilinmemesi. Bu yazıda Cy Logic'in sekiz aşamalı sürecini, her aşamanın somut çıktısını ve işletme tarafından beklenenleri anlatıyoruz. Örnek olarak bir gayrimenkul firması için ilan, müşteri talebi ve satış süreçlerini yöneten bir portal düşünelim; bu örnek kurgusaldır ve yalnızca aşamaları somutlaştırmak için kullanılmıştır.

1. Keşif

Amaç, problemi yazılım diliyle değil iş diliyle tanımlamaktır. Örnek portalda sorun şu olabilir: "İlanlar üç farklı sitede elle güncelleniyor, müşteri talepleri WhatsApp'ta kayboluyor, hangi danışmanın hangi müşteriyle görüştüğü bilinmiyor." Çıktı: bir sayfalık problem tanımı, paydaş listesi ve başarı ölçütleri.

2. Analiz

Mevcut süreçler ve veriler incelenir: ilan alanları, talep kaynakları, danışman yetkileri, raporlama ihtiyaçları. Bu aşamada "olmazsa olmaz" ile "olsa iyi olur" ayrımı yapılır. Çıktı: süreç haritası, veri sözlüğü ve öncelik listesi.

3. Planlama

Kapsam, takvim ve mimari belirlenir. Burada verilen en kritik karar teslimat biçimidir: büyük patlama yerine kademeli teslim (önce ilan yönetimi, sonra talepler, sonra satış süreçleri) riskleri dağıtır. Çıktı: aşamalı teslim planı, mimari şema, entegrasyon listesi.

4. Tasarım

Arayüz ve veri modeli birlikte tasarlanır. Veri modeli, yetkilendirme kurallarını da içerir: hangi danışman hangi müşteriyi görür, yönetici hangi raporlara erişir. Çıktı: tıklanabilir prototip, veritabanı şeması, yetki matrisi.

-- Örnek yetki matrisi satırı (kavramsal)
-- rol: danisman   | kaynak: musteri_talebi | işlem: oku   | koşul: atanan_danisman = kullanıcı
-- rol: yonetici   | kaynak: musteri_talebi | işlem: oku   | koşul: aynı şube
-- rol: yonetici   | kaynak: rapor          | işlem: oku   | koşul: yok

5. Geliştirme

Modüler ve test edilebilir kod yazılır. İki ilke önemlidir: her modül bağımsız yayınlanabilmeli ve iş kuralları (örneğin komisyon hesabı) arayüzden ayrı katmanda yaşamalı. Geliştirme boyunca işletme tarafı iki haftada bir çalışan yazılımı görmeli; "sonunda göstereceğiz" yaklaşımı en büyük risktir.

6. Test

Üç seviye test yapılır: otomatik birim ve entegrasyon testleri, güvenlik kontrolleri (yetki politikaları, girdi doğrulama, OWASP Top 10 başlıkları) ve işletme kullanıcılarıyla kabul testi. Kabul testinde gerçek senaryolar kullanılır: "Yeni talep geldi, danışmana atandı, görüşme notu girildi, satış kapandı."

7. Yayına alma

Canlıya geçiş kontrollü yapılır: veri taşıma provası, geri dönüş planı, ilk hafta yoğun izleme. Eski sistemle paralel çalışma süresi önceden kararlaştırılır. Çıktı: yayın kontrol listesi ve işletim el kitabı.

8. Destek ve büyütme

Yayın ilişkinin sonu değil başlangıcıdır. İzleme, yedekleme, güvenlik güncellemeleri ve yeni özellik talepleri düzenli bir bakım planıyla yönetilir. İyi bir pratik, her çeyrekte kullanım verisine bakarak hangi ekranların gerçekten kullanıldığını değerlendirmektir.

Bir yazılım projesinde en pahalı cümle "biz öyle demek istememiştik" cümlesidir; bu cümle aşama ilerledikçe katlanarak pahalılaşır. Prototip aşamasında söylenmesi en ucuzudur.

İşletme tarafının sorumlulukları

  • Karar yetkisi olan tek bir proje sahibi belirlemek.
  • Her aşamanın çıktısını belirlenen sürede incelemek ve onaylamak.
  • Gerçek verileri ve mevcut belgeleri (sözleşme şablonları, fiyat listeleri) zamanında paylaşmak.
  • Kabul testine son kullanıcıları dahil etmek.

Entegrasyonlar: baştan planlayın

Çoğu özel yazılım yalnız çalışmaz: muhasebe programı, SMS ve e-posta servisleri, ödeme altyapısı, harita servisleri. Entegrasyonların sözleşme, erişim bilgisi ve test ortamı gereksinimleri keşif aşamasında listelenmezse, yayın tarihini en çok kaydıran kalem bunlar olur. REST API ve webhook temelli, izlenebilir (her aktarımın kaydı tutulan) entegrasyon katmanı kurmak bu riski azaltır.

Sözleşme ve kapsam: belirsizliği nasıl yönetirsiniz?

Özel yazılımda kapsam, proje boyunca öğrenilen şeylerle değişir; bu bir kusur değil, doğasıdır. Sözleşmenin bunu tanıması gerekir. Pratik bir model: analiz ve tasarım aşamaları sabit kapsam ve sabit bedelle, geliştirme aşamaları ise kademeli teslimler (her teslimde tanımlı özellik seti) ile yürütülür. Her teslimin kabul ölçütü yazılıdır; "beğenmedik" bir kabul ölçütü değildir, "şu senaryo çalışmıyor" ise öyledir.

Değişiklik talepleri

Yeni bir istek geldiğinde üç soru sorulur: Bu, mevcut aşamanın kapsamında mı? Değilse hangi aşamaya alınacak? Mevcut takvimi etkiliyor mu? Değişiklik talebi reddedilmez, sınıflandırılır. Bu sınıflandırma yazılı yapıldığında, projenin sonunda "siz söylemiştiniz / biz istememiştik" tartışması ortadan kalkar.

Belgeleme: neyi, ne kadar?

Her şeyi belgelemek mümkün değildir; doğru şeyleri belgelemek mümkündür:

  • Mimari kararlar: Neden bu veritabanı, neden bu yetki modeli; kısa karar kayıtları.
  • Veri sözlüğü: Her tablonun ve kritik sütunun anlamı, kişisel veri sınıfı, saklama süresi.
  • İşletim el kitabı: Yayınlama, yedek alma, geri yükleme, sık karşılaşılan sorunlar.
  • Kullanıcı rehberi: Ekran bazlı değil, görev bazlı ("yeni talep nasıl açılır").

Geliştiren ekip değişirse sistemin yaşayabilmesi bu dört belgeye bağlıdır.

Test stratejisi: hangi testi nerede?

Birim testleri iş kurallarını (komisyon hesabı, onay zinciri), entegrasyon testleri veritabanı politikalarını ve API sözleşmelerini, uçtan uca testler ise kritik kullanıcı akışlarını kapsar. Yetki politikalarının otomatik testi özellikle önemlidir: "danışman A, danışman B'nin müşterisini görememeli" kuralı her sürümde doğrulanmalıdır; bu test yoksa güvenlik, rastlantıya bağlıdır.

// Örnek: yetki politikası testi (kavramsal)
test('danışman yalnızca kendi taleplerini görür', async () => {
  const asConsultantA = clientFor(userA);
  const rows = await asConsultantA.from('enquiries').select('id');
  expect(rows.every((r) => r.assigned_to === userA.id)).toBe(true);
});

Yayın sonrası ilk 30 gün

Canlıya geçişten sonraki ilk ay, projenin en öğretici dönemidir. Kullanıcı soruları, hata bildirimleri ve "aslında şöyle olsa" talepleri bu dönemde yoğunlaşır. Öneri: bu dönem için haftalık kısa değerlendirme toplantıları, önceliklendirilmiş bir iyileştirme listesi ve küçük düzeltmelerin hızla yayınlanabildiği bir dağıtım düzeni. Büyük yeni özellikler bu dönemde değil, sistem oturduktan sonra planlanır.

Ne zaman özel yazılım yapılmamalı?

Dürüst olmak gerekir: ihtiyaç standartsa ve iyi bir hazır çözüm varsa özel yazılım yanlış karardır. Keşif aşamasının çıktılarından biri de bu olabilir ve biz bunu söyleriz. Özel yazılım, sizi farklılaştıran süreçler için anlamlıdır; herkesin aynı yaptığı işler için değil.

Cy Logic'te her özel yazılım projesi bu sekiz aşamayı izler; ölçeğe göre aşamalar kısalır ama atlanmaz.