Özel Yazılım Maliyeti Nasıl Belirlenir?
Sabit bir fiyat listesi, farklı iş akışları ve teknik gereksinimleri olan projeler için yanıltıcı olabilir.
Kapsam ve iş akışları neden belirleyicidir?
Tek bir formun arkasında onay kuralları, kullanıcı yetkileri, bildirimler ve farklı veri kaynakları bulunabilir. Bu nedenle ekrandaki öğeleri saymak yerine her işlemin nerede başladığını, hangi kararı gerektirdiğini ve hangi durumda tamamlandığını anlamak gerekir.
İlk sürümün sınırlarını belirlemek de önemlidir. Kritik işlevleri önce ele almak, ileri aşamaya bırakılabilecek özellikleri görünür kılar; fakat gerçek ihtiyacı gizleyerek düşük bir tahmin üretmek doğru değildir.
Maliyeti etkileyen başlıca kalemler
Aşağıdaki başlıklar teklif görüşmesinde birlikte incelenmelidir. Her biri her projede aynı ağırlıkta değildir.
- İş akışı sayısı ve süreç kurallarının karmaşıklığı
- Kullanıcı grupları, roller ve onay yetkileri
- Mevcut sistemlerle API veya başka izinli entegrasyonlar
- Raporlama, dışa aktarma ve veri görselleştirme ihtiyacı
- Arayüzün farklı cihaz ve kullanıcılar için tasarımı
- Eski verilerin temizlenmesi ve taşınması
- Altyapı, erişim kontrolü, test ve kalite çalışmaları
- Yayın sonrası bakım, destek ve gelecekteki geliştirmeler
Örnek: temsilî bir proje kapsamı
Varsayımsal bir işletmenin talepleri e-postayla aldığı, durumları tabloda tuttuğu ve ay sonunda rapor hazırladığı düşünülsün. İlk sürümde talep kaydı, sorumlu atama ve durum takibi olabilir. İkinci aşamada rol bazlı onay, bildirim ve mevcut muhasebe sistemiyle bağlantı değerlendirilebilir.
Bu örnek gerçek bir Koddex müşterisi veya tamamlanmış proje değildir. Aynı görünen ihtiyaç, kullanıcı sayısı, veri kalitesi ve entegrasyon koşulları nedeniyle farklı emek gerektirebilir.
Keşif ve analiz olmadan neden sağlıklı fiyat verilemez?
Keşif aşamasında kullanıcılar, mevcut araçlar, kritik senaryolar ve teknik sınırlar anlaşılır. Entegrasyon yapılacak bir sistemin belgeleri ve erişim koşulları da bu aşamada incelenir.
Sonuç; kapsam, varsayımlar, dış bağımlılıklar ve teslim aşamalarını içeren bir çerçeve olmalıdır. Bu çerçeve olmadan verilen rakam, gerekli işleri dışarıda bırakabilir veya gereksiz belirsizlik payı taşıyabilir.
İlk geliştirme dışındaki giderler
Barındırma, yedekleme, güvenlik güncellemeleri, destek, yeni kullanıcı eğitimi ve üçüncü taraf servis ücretleri de yaşam döngüsü maliyetine dahil edilebilir. Hangi kalemlerin Koddex kapsamında, hangilerinin dış sağlayıcı tarafından karşılanacağı sözleşmede açıkça belirtilmelidir.
Bakım maliyeti sabit bir oran olarak varsayılmamalı; ürünün kritiklik düzeyi, değişim sıklığı ve destek ihtiyacıyla değerlendirilmelidir.
Görüşmeye hazırlanırken hangi bilgileri paylaşmalı?
Bugünkü iş akışının kısa tarifi, karşılaşılan sorunlar, kullanıcı türleri, mevcut yazılımlar ve ilk sürüm için en önemli sonuçlar iyi bir başlangıçtır. Bütün teknik cevapların baştan bilinmesi gerekmez; görüşmenin amacı zaten belirsizlikleri azaltmaktır.