Kısaca
Sigorta yazılım projeleri, mevzuat ve entegrasyon tarihleri gibi sabit kilometre taşlarını çevik (agile) teslimat döngüleriyle birleştiren hibrit bir yaklaşımla en sağlıklı biçimde yönetilir. Başarı; iş biriminden güçlü ürün sahipliğine, aktüerya ve uyum ekiplerinin erken katılımına, gerçekçi test ve veri stratejisine ve prova edilmiş bir canlıya geçiş planına bağlıdır.
Sigorta yazılım projesi yönetimi, poliçe, hasar, tahsilat ve entegrasyon sistemlerindeki değişikliklerin kapsam, zaman, kalite ve risk açısından planlanıp teslim edilmesi demektir. Sigorta projelerini genel yazılım projelerinden ayıran şey, esnek olmayan dış tarihlerle esnek olması gereken iş gereksinimlerinin aynı anda yönetilmesidir. Bir tarife değişikliğinin yürürlük tarihi, bir SEDDK düzenlemesinin uyum süresi ya da SBM'nin yeni bir servis sürümü ertelenemez; ama ürünün ekranları, kanal akışları ve raporları proje ilerledikçe netleşir.
Bu nedenle sigortacılıkta ne klasik şelale (waterfall) modeli ne de saf çevik (agile) model tek başına yeterli olur. Uygulamada en iyi sonuç veren yaklaşım, sabit kilometre taşlarını kısa teslimat döngüleriyle birleştiren hibrit yazılım proje yönetimi modelidir.
Sigorta yazılım projeleri neden farklıdır?
Sigorta projeleri yoğun iş kuralı, düzenleyici tarihler, çok sayıda dış entegrasyon ve yüksek finansal doğruluk beklentisini bir arada taşır. Bu özellikler proje yönetim yönteminin seçimini doğrudan etkiler.
- Yoğun iş kuralı: Bir ürünün teminat, tarife, risk kabul ve komisyon kuralları yüzlerce parametreye ulaşabilir. Gereksinimlerin tamamını baştan eksiksiz yazmak pratikte mümkün değildir.
- Dış tarihler: Mevzuat değişiklikleri, vergi ve kesinti güncellemeleri, yıl sonu kapanışı ve SBM servis değişiklikleri pazarlığa açık olmayan teslim tarihleri yaratır.
- Entegrasyon bağımlılıkları: SBM, bankalar, ödeme kuruluşları, acente sistemleri ve reasürans taraflarıyla yapılan entegrasyonlar, test ortamı ve takvim açısından projenin kontrolü dışındaki taraflara bağlıdır.
- Finansal doğruluk: Prim, komisyon ve karşılık hesaplamalarındaki küçük bir hata binlerce poliçeye ve muhasebe kayıtlarına yayılır. Test ve kabul süreçleri bu yüzden daha titiz olmalıdır.
- Çalışan sistem üzerinde değişiklik: Projelerin çoğu sıfırdan değil, her gün poliçe üreten canlı bir sistem üzerinde yapılır. Operasyonu durdurmadan değişiklik yapmak, sürüm ve dağıtım disiplinini zorunlu kılar.
Agile, şelale ve hibrit yaklaşım arasındaki fark nedir?
Şelale modeli kapsamı baştan sabitler ve aşamaları sırayla ilerletir; agile, kapsamı kısa döngülerde öğrenerek şekillendirir; hibrit model ise tarihleri ve üst kapsamı sabitleyip içeriği çevik döngülerle teslim eder. Sigorta projelerinde doğru seçim, belirsizliğin nerede olduğuna bağlıdır.
| Boyut | Şelale | Agile (Scrum, Kanban) | Hibrit |
|---|---|---|---|
| Kapsam | Başta sabitlenir | Döngü döngü netleşir | Üst kapsam sabit, ayrıntı döngülerde netleşir |
| Planlama | Tek seferlik ayrıntılı plan | Kısa vadeli, sürekli yeniden planlama | Kilometre taşı planı ve döngü planlaması birlikte |
| Uygun olduğu iş | Metni net uyum işleri, altyapı geçişleri | Dijital kanal, müşteri deneyimi, ürün denemeleri | Core sistem, yeni ürün lansmanı, büyük entegrasyonlar |
| İş birimi katılımı | Başta ve kabul testinde | Sürekli | Sürekli, kilometre taşlarında resmî onay |
| Temel risk | Hatalar geç fark edilir | Tarih disiplini zayıflayabilir | Yönetişim yükü doğru ayarlanmazsa ağırlaşır |
| Belgeleme | Kapsamlı | Asgari | Denetim ve uyum için gerekli düzeyde |
Aynı kurum içinde farklı işler farklı yöntemlerle yürütülebilir. Örneğin bir mevzuat uyum paketi kilometre taşı odaklı, mobil uygulama geliştirmesi ise tamamen çevik yönetilebilir. Önemli olan, bu işlerin ortak bir önceliklendirme ve sürüm takvimiyle birbirine bağlanmasıdır.
Hibrit model sigorta projesinde nasıl kurulur?
Hibrit model, projeyi dışarıdan sabit tarihli kilometre taşlarıyla, içeriden ise iki üç haftalık çevik döngülerle yönetir. Kilometre taşları üst yönetime ve düzenleyiciye verilen taahhütleri, döngüler ise ekibin gerçek ilerlemesini gösterir.
- Keşif ve kapsam çerçevesi: İlk haftalar iş analizi, mevcut sistem incelemesi ve entegrasyon envanteriyle geçer. Çıktı; önceliklendirilmiş bir iş listesi (backlog), sabit tarihler ve ana riskler listesidir. Bu aşamanın ayrıntıları sigorta projelerinde iş analizi yazısında ele alınmıştır.
- Kilometre taşlarının belirlenmesi: Mevzuat yürürlük tarihleri, dış taraf test pencereleri, kullanıcı kabul testi (User Acceptance Testing, UAT) ve canlıya geçiş tarihleri sabitlenir. Ay sonu ve yıl sonu kapanışları gibi değişiklik dondurma dönemleri takvime işlenir.
- Asgari kapsamın ayrılması: Her kilometre taşı için olmazsa olmaz kapsam ile ertelenebilir kapsam ayrılır. Tarih sabitse esneyen şey kapsam olmalıdır.
- Teslimat döngüleri: Ekip iş listesinden kısa döngülerle teslimat yapar. Her döngü sonunda iş birimine çalışan yazılım gösterilir; kurallar ve hesaplamalar örnek poliçelerle doğrulanır.
- Entegrasyon ve regresyon testleri: Dış taraflarla test pencereleri erkenden ayarlanır. Her sürümde prim, komisyon ve vergi hesaplamaları otomatik regresyon testleriyle kontrol edilir; yaklaşım sigorta yazılımlarında test otomasyonu yazısında ayrıntılı anlatılmıştır.
- Kullanıcı kabul testi ve paralel çalışma: İş birimi gerçekçi senaryolarla kabul testini yapar. Hesaplama değişikliklerinde eski ve yeni sistemin aynı veriyle çalıştırılıp sonuçlarının karşılaştırılması güçlü bir güvence sağlar.
- Canlıya geçiş ve yoğun destek: Geçiş planı saat saat, geri dönüş (rollback) senaryosuyla birlikte yazılır ve prova edilir. Canlıya geçişten sonraki ilk haftalarda proje ekibi yoğun destek dönemini (hypercare) yürütür.
Hangi roller olmazsa olmazdır?
Sigorta yazılım projelerinin başarısı, iş biriminin projeye ne kadar sahip çıktığıyla doğrudan ilişkilidir. Teknik ekip ne kadar güçlü olursa olsun, kuralların doğruluğunu ve önceliklerini iş birimi belirler.
- Ürün sahibi (Product Owner): İş biriminden gelen, öncelik kararı verebilen ve ekibe düzenli zaman ayırabilen kişi. Sigortacılıkta bu rol çoğu zaman sigorta ürün yöneticisi ile örtüşür.
- İş analisti: Ürün, operasyon ve mevzuat gereksinimlerini test edilebilir kurallara dönüştürür.
- Aktüerya temsilcisi: Tarife, karşılık ve fiyatlama hesaplamalarının doğruluğundan sorumludur ve test senaryolarına beklenen sonuçları sağlar.
- Uyum ve hukuk temsilcisi: Mevzuat yorumunu netleştirir, müşteri belgelerini ve bilgilendirme metinlerini onaylar.
- Teknik lider ve mimar: Entegrasyon, veri ve performans kararlarını verir, teknik borcu görünür tutar.
- Test ve kalite güvence uzmanı: Test stratejisini, test verisini ve regresyon setini yönetir.
- Proje veya teslimat yöneticisi: Kilometre taşlarını, bağımlılıkları, riskleri ve paydaş iletişimini yönetir.
Ekip ve sözleşme modelinin seçimi de proje yönetimini etkiler. Sabit fiyatlı proje sözleşmeleri kapsam değişikliğini zorlaştırırken, dedike yazılım ekibi modeli çevik önceliklendirmeye daha uygun bir çerçeve sunar.
Riskler ve yönetişim nasıl yönetilir?
Sigorta projelerinde yönetişim, çevikliği boğmayacak kadar hafif, ama denetim ve uyum ihtiyacını karşılayacak kadar kayıtlı olmalıdır. Pratikte bu, düzenli ve kısa karar toplantıları ile tek bir risk kaydı demektir.
- Yönlendirme kurulu: İş, BT, finans ve uyum yöneticilerinden oluşan, düzenli aralıklarla ve kilometre taşlarında toplanan, kapsam ile tarih çatıştığında karar veren kurul.
- Risk ve bağımlılık kaydı: Riskler, varsayımlar, sorunlar ve bağımlılıklar tek bir kayıtta, sahibi ve hedef tarihiyle izlenir. SBM test ortamı veya banka entegrasyonu gibi dış taraf bağımlılıkları ayrıca etiketlenir.
- Değişiklik kontrolü: Kilometre taşı kapsamını etkileyen değişiklikler, tarih, maliyet ve risk etkisiyle yazılı olarak değerlendirilip kurul onayına sunulur.
- Ölçümler: Teslim edilen iş, önem derecesine göre açık hatalar, canlıya kaçan hatalar, test kapsamı ve kilometre taşlarına kalan iş düzenli raporlanır. Ekip hızı (velocity) ekipler arası karşılaştırma aracı olarak değil, yalnızca planlama girdisi olarak kullanılmalıdır.
- Test verisi ve güvenlik: Test ortamlarında gerçek müşteri verisi yerine maskelenmiş veya sentetik veri kullanılmalıdır. Bu hem KVKK hem de bilgi güvenliği açısından proje planının ayrılmaz parçasıdır.
Sigorta yazılım projesi için kontrol listesi
- Sabit tarihler (mevzuat, entegrasyon, kapanış dönemleri) proje başında takvime işlendi mi?
- Her kilometre taşı için olmazsa olmaz ve ertelenebilir kapsam ayrıldı mı?
- İş biriminden karar yetkisi olan bir ürün sahibi atandı mı?
- Aktüerya ve uyum ekipleri gereksinim ve test aşamalarına dahil mi?
- Dış taraf test pencereleri önceden ayarlandı mı?
- Hesaplama değişiklikleri için otomatik regresyon testi var mı?
- Test ortamlarında maskelenmiş veya sentetik veri kullanılıyor mu?
- Canlıya geçiş planında geri dönüş senaryosu ve sorumlular tanımlı mı, plan prova edildi mi?
- Canlıya geçiş sonrası destek dönemi ve başarı ölçütleri belirlendi mi?
ProdayTech olarak sigorta projelerinde bu hibrit yapıyı izliyoruz: mevzuat ve entegrasyon tarihlerini sabit kilometre taşı olarak alıyor, ürün ve kanal geliştirmelerini iş birimiyle birlikte kısa döngülerde teslim ediyoruz. Proje ve ekip modeliyle ilgili çalışma alanlarımız için hizmetlerimize göz atabilirsiniz.
Sık sorulan sorular
Sigorta yazılım projelerinde Scrum mı Kanban mı kullanılmalı?
İkisi farklı ihtiyaçlara hizmet eder. Yeni özellik geliştiren ve düzenli teslimat ritmine ihtiyaç duyan proje ekipleri için Scrum, taleplerin sürekli aktığı bakım, destek ve küçük geliştirme işleri için Kanban daha uygundur. Birçok sigorta şirketinde proje ekipleri Scrum, canlı sistem destek ekipleri Kanban kullanır ve ikisi aynı ürün iş listesine bağlanır.
Mevzuat değişikliklerinde agile yaklaşım işe yarar mı?
Yarar, ancak tarih pazarlığa açık olmadığından kapsamın dikkatle bölünmesi gerekir. Önce yürürlük tarihinde zorunlu olan asgari değişiklik belirlenir ve öncelikli teslim edilir; raporlama iyileştirmeleri veya otomasyon gibi ek işler sonraki döngülere bırakılır. Mevzuat yorumunun erken netleşmesi için uyum ekibinin döngü sonu gösterimlerine katılması önerilir.
Sabit fiyatlı sözleşme ile agile çalışmak mümkün mü?
Mümkündür, ancak kapsam değişikliği mekanizmasının sözleşmede tanımlanması gerekir. Sık kullanılan bir yöntem, üst kapsam ve bütçeyi sabitleyip ayrıntılı gereksinimleri eşdeğer büyüklükteki işlerle değiştirme hakkı tanımaktır. Belirsizliği yüksek projelerde zaman ve kaynak bazlı ya da dedike ekip modeli taraflar arasında daha az sürtünme yaratır.
Canlıya geçişte en sık yapılan hata nedir?
En sık hata, geri dönüş senaryosunun yazılmaması ya da hiç prova edilmemesidir. Bunu veri dönüşümünün yalnızca küçük örneklerle denenmesi, dış tarafların geçiş saatinden haberdar edilmemesi ve canlı sonrası ilk günlerde proje ekibinin dağılması izler. Geçiş planının saat saat yazılıp en az bir kez prova edilmesi bu riskleri önemli ölçüde azaltır.
Proje ilerlemesi yönetime nasıl raporlanmalı?
Yönetim raporu; kilometre taşlarının durumuna, önceki rapordan bu yana değişen risklere, karar bekleyen konulara ve kapsam ile tarih dengesine odaklanmalıdır. Döngü ayrıntıları yerine iş değeri üzerinden anlatım tercih edilmelidir. Her dönem aynı yapıda hazırlanan tek sayfalık bir rapor, eğilimlerin görülmesini ve zamanında karar alınmasını kolaylaştırır.