Özel yazılımın maliyetini ne belirler?
Özel yazılımın maliyetini ekran sayısı değil; yazılımın uygulayacağı iş kuralları ve istisnalar, bağlanacağı sistemler, taşınacak veri, güvenlik ve uyum hedefleri ve yayından sonraki işletim belirler. Maliyetin büyük kısmı mühendislik emeğidir: analiz, tasarım, geliştirme, test, dağıtım ve proje yönetimi için harcanan kişi-gün. Buna barındırma ve lisans gibi üçüncü taraf giderleri ile yayından sonra her yıl tekrarlanan bakım eklenir.
Bu yüzden "bir sipariş paneli ne kadar tutar?" sorusunun tek bir cevabı yoktur. Aynı görünen iki panelden biri tek onay adımıyla çalışır ve hiçbir sisteme bağlanmaz; diğeri üç onay katmanı, vekâlet kuralları, ERP entegrasyonu ve denetim kaydı ister. Ekranlar benzer olsa da ikincisinin arkasındaki iş çok daha fazladır. Bu yazıda fiyat vermiyoruz; teklifi oluşturan kalemleri, teklifin nasıl hesaplandığını ve teklifleri nasıl karşılaştıracağınızı anlatıyoruz.
Hangi kalemler maliyeti en çok etkiler?
Maliyeti en çok etkileyen kalemler, keşifte netleşmeyip sonradan ortaya çıkanlardır: istisnalar, entegrasyonlar ve veri. Aşağıdaki tablo, her etkenin maliyeti neden artırdığını ve keşifte sorulması gereken soruyu gösterir.
| Etken | Maliyeti neden artırır? | Keşifte sorulacak soru |
|---|---|---|
| İş kuralları ve istisnalar | Her istisna ayrı kod, ayrı test ve ayrı hata senaryosu demektir | Normal akış dışında ne olur: iade, kısmi onay, vekâlet, iptal? |
| Roller ve yetki katmanları | Her rol, ekran ve veri düzeyinde ayrı yetki kontrolü ve testi gerektirir | Kim neyi görür, kim neyi onaylar, kim neyi değiştirebilir? |
| Entegrasyonlar | API'nin olup olmaması, belgelerin kalitesi, test ortamı ve karşı ekibin erişilebilirliği takvimi belirler | Bağlanacak her sistemin API'si, test ortamı ve sorumlu kişisi var mı? |
| Veri taşıma | Eski verinin temizlenmesi, eşleştirilmesi ve mutabakatı ayrı bir iştir | Ne kadar veri taşınacak, ne kadar temiz, kim doğrulayacak? |
| Güvenlik hedefi | Daha yüksek doğrulama seviyesi daha fazla gereksinim ve test demektir | Hangi güvenlik seviyesini hedefliyoruz, sızma testi yapılacak mı? |
| Erişilebilirlik | Hedef seviye tasarımı, bileşen seçimini ve testi etkiler | Hangi WCAG seviyesi hedefleniyor? |
| Raporlama | Her rapor bir veri modeli, filtre ve doğrulama işidir | Hangi raporlar ilk sürümde şart, hangileri sonra gelebilir? |
| Yük ve kesintisizlik beklentisi | Eşzamanlı kullanıcı sayısı ve kesinti toleransı mimariyi ve barındırmayı değiştirir | Aynı anda kaç kişi çalışacak, sistem ne kadar süre kapalı kalabilir? |
| Barındırma ve ortamlar | Bulut ya da kurum içi tercih, ortam sayısı, yedekleme ve izleme işletim maliyetini belirler | Sistem nerede çalışacak, kaç ortam gerekiyor? |
| Mobil veya çevrim dışı kullanım | Ayrı bir uygulama, eşitleme ve çakışma kuralları gerektirir | Sahada bağlantısız çalışmak gerekiyor mu? |
| Kurum tarafının erişilebilirliği | Karar ve test gecikmeleri ekibin bekleme süresine dönüşür | Kararları kim verecek, testlere kim katılacak? |
| Belgelendirme ve devir | Sistemin başka bir ekip tarafından devralınabilmesi belge ve eğitim gerektirir | Kaynak kod, belgeler ve kurulum adımları teslim edilecek mi? |
Güvenlik ve erişilebilirlik hedefi maliyeti nasıl değiştirir?
Güvenlik ve erişilebilirlik "dahil" ya da "hariç" kalemler değil, seviyesi seçilen gereksinimlerdir; seviyeyi yazmazsanız her tedarikçi farklı bir seviyeyi fiyatlar. OWASP'ın web uygulamaları için yayımladığı Uygulama Güvenliği Doğrulama Standardı (ASVS) 5.0 üç seviye tanımlar. Birinci seviye, gereksinimlerin yaklaşık %20'sini kapsayan asgari başlangıç noktasıdır. İkinci seviyeye uyum için gereksinimlerin yaklaşık %70'inin karşılanması gerekir. Üçüncü seviye ise en yüksek güvenceyi göstermek isteyen uygulamalar içindir. Standart, uygulamaların çoğunun ikinci seviyeyi hedeflemesi gerektiğini söyler ve seviyenin uygulamanın hassasiyetine ve kullanıcı beklentisine göre seçilmesini önerir. Teklif isterken hedef seviyeyi yazmak, iki teklifin aynı güvenlik işini fiyatlayıp fiyatlamadığını görmenin en kısa yoludur.
Erişilebilirlik için de durum aynıdır. W3C'nin WCAG 2.2 önerisi A, AA ve AAA olmak üzere üç uyum seviyesi tanımlar. Hedef seviye tasarım sistemini, bileşen seçimini ve test planını etkiler; kararın yazılım yazıldıktan sonra değil, tasarımdan önce verilmesi işi azaltır. Kamuya açık bir müşteri portalı ile küçük bir iç ekip aracı farklı hedefler isteyebilir; önemli olan hedefin teklif öncesinde yazılı olmasıdır.
Yazılım teklifi nasıl oluşturulur?
Teklif; kapsamın iş kalemlerine bölünmesi, her kalem için efor tahmini, belirsizlik payı ve üçüncü taraf giderlerinin toplanmasıyla oluşur. Tedarikçiler arasındaki asıl fark, bu adımların ne kadar açık yazıldığıdır. Sağlıklı bir teklif şu katmanları görünür kılar:
- Kapsam ayrıştırması: Modüller, iş akışları ve entegrasyonlar ayrı satırlar hâlinde.
- Efor tahmini: Her satır için rol bazında (analiz, tasarım, geliştirme, test, dağıtım) kişi-gün ya da kişi-hafta.
- Ortak işler: Proje yönetimi, kod incelemesi, test otomasyonu, ortam kurulumu, belgelendirme ve kabul testleri. Bu kalemler teklifte görünmüyorsa ya başka satırlara dağıtılmıştır ya da hiç yapılmayacaktır.
- Belirsizlik payı: Netleşmemiş kalemler için açıkça yazılmış bir aralık ya da risk payı.
- Üçüncü taraf giderleri: Barındırma, lisanslar, ücretli servisler (harita, SMS, e-posta, ödeme) ve bunların kimin hesabından ödeneceği.
- Varsayımlar ve kapsam dışı: Teklifin hangi koşullar doğruysa geçerli olduğu ve neyi içermediği.
Belirsizlik payının neden kaçınılmaz olduğunu yazılım tahmini literatüründeki "belirsizlik konisi" açıklar. Construx'un aktardığına göre, projenin ilk fikir aşamasında yetkin tahminciler bile gerçekleşen sonuçtan dört kat yukarı ya da dört kat aşağı sapabilir; en yüksek ve en düşük tahmin arasındaki fark on altı kata çıkar. Koni kendiliğinden daralmaz; kapsam, gereksinimler ve arayüz tasarımı gibi belirsizliği ortadan kaldıran kararlar verildikçe daralır. Alıcı için sonuç nettir: Keşif yapılmadan verilen kesin bir rakam ya yüksek bir risk payı içerir ya da proje ilerledikçe yeniden konuşulur.
Fiyatlama modeli de riski kimin taşıdığını belirler:
| Model | Ne zaman uygun? | Alıcının dikkat edeceği nokta |
|---|---|---|
| Sabit kapsam, sabit fiyat | Kapsam ayrıntılı ve değişme olasılığı düşükse | Tedarikçi belirsizliği fiyata ekler; her değişiklik ayrı bir talep ve fiyattır |
| Zaman ve malzeme | Kapsam keşifle şekillenecek, öncelikler değişebilecekse | Bütçe kontrolü alıcıdadır; düzenli efor raporu ve öncelik toplantısı şarttır |
| Aşamalı teklif | Önce keşif, sonra dar bir ilk sürüm, sonra diğer aşamalar | Her aşama sonunda devam kararı alıcıdadır; kabul ölçütleri yazılı olmalıdır |
| Üst sınırlı zaman ve malzeme | Esneklik istenirken bütçe tavanı da gerekiyorsa | Tavana yaklaşıldığında neyin kapsamdan çıkacağı önceden konuşulmalıdır |
Karşılaştırılabilir teklif için tedarikçiye ne vermelisiniz?
Karşılaştırılabilir teklif almanın en etkili yolu, her tedarikçiye aynı kısa ihtiyaç belgesini vermektir; belge ne kadar netse tekliflerdeki belirsizlik payı o kadar küçülür. Uzun bir şartname gerekmez; çoğu proje için şu başlıklar yeterli bir başlangıçtır:
- İş problemi ve başarı ölçütü: Yazılım neyi değiştirecek ve bunu neyle ölçeceksiniz?
- Kullanıcılar ve roller: Kimler, kaç kişi, hangi yetkilerle kullanacak?
- Bugünkü akış: Mevcut tablolar, formlar, ekran görüntüleri ve bilinen istisnaların listesi.
- Entegrasyon envanteri: Bağlanacak sistemler, API durumları, test ortamları ve sorumlu kişiler.
- Veri: Taşınacak verinin kaynağı, yaklaşık hacmi, örnek kayıtlar ve kişisel veri içerip içermediği.
- İşlevsel olmayan hedefler: Güvenlik ve erişilebilirlik seviyesi, eşzamanlı kullanıcı sayısı ve kesinti toleransı.
- Barındırma kısıtları: Bulut mu, kurum içi mi; verinin nerede tutulması gerektiği.
- Takvim kısıtları: Gerçek bir son tarih varsa nedeni; örneğin bir mevzuat değişikliği ya da sezon başlangıcı.
- Yayın sonrası beklenti: Bakımı kim yapacak, destek hangi saatlerde gerekecek?
Bütçe aralığınızı paylaşmak da işe yarar: Tedarikçi aynı problemi farklı bütçelerle nasıl çözebileceğini, neyin ilk sürüme girip neyin sonraya kalacağını önerebilir. Bu belge aynı zamanda keşif görüşmesinin girdisidir; eksik kalan başlıklar keşifte birlikte tamamlanır.
Teklifleri nasıl karşılaştırmalı?
Teklifleri toplam rakamla değil; aynı kapsamı, aynı varsayımları ve aynı yayın sonrası yükümlülükleri içerip içermedikleriyle karşılaştırın. En düşük toplam çoğu zaman en çok kalemin dışarıda bırakıldığı tekliftir. Bu bir kusur değil, farklı bir varsayımdır; ama görünür olmalıdır. Aşağıdaki çalışma sayfasını her teklif için doldurun:
| Kalem | Teklifte ne yazmalı? | Eksikse ne olur? |
|---|---|---|
| Kapsam ve kapsam dışı | Modül ve akış listesi; açıkça dışarıda bırakılanlar | Belirsiz kalan her iş sonradan değişiklik talebine dönüşür |
| Varsayımlar | Entegrasyonların hazır olup olmadığı, test ortamını kimin sağlayacağı, verinin durumu | Varsayım tutmazsa takvim ve bütçe değişir |
| Kabul ölçütleri | Her aşamanın hangi testle kabul edileceği | "Bitti" tanımı tartışmaya açık kalır |
| Test | Otomatik test, kabul testi, yük ve güvenlik testi | Sorunlar canlıda bulunur |
| Güvenlik ve erişilebilirlik hedefi | ASVS ve WCAG seviyesi | Teklifler farklı işleri fiyatlıyor olabilir |
| Veri taşıma | Hangi verinin, kimin doğrulamasıyla taşınacağı | Taşıma ayrı bir proje olarak geri döner |
| Barındırma ve hesaplar | Sunucuların ve bulut hesaplarının kimin adına açılacağı | Tedarikçi değişince erişim sorunu çıkar |
| Kaynak kod ve fikri mülkiyet | Kodun ve belgelerin kime ait olacağı | Devir ve genişletme zorlaşır |
| Açık kaynak lisansları | Kullanılan bileşenler ve lisansları | Lisans yükümlülükleri sonradan ortaya çıkar |
| Garanti ve bakım | Yayından sonra hata düzeltmenin kapsamı ve bakım anlaşmasının içeriği | Bakım ayrı ve beklenmedik bir kalem olur |
| Değişiklik yönetimi | Kapsam değişikliğinin nasıl fiyatlanıp onaylanacağı | Her değişiklik bir pazarlığa dönüşür |
| Ödeme takvimi | Ödemelerin aşama kabulüne bağlanması | Ödeme ile teslim arasındaki bağ kopar |
Çalışma sayfası dolduktan sonra boş kalan satırları her tedarikçiye yazılı olarak sorun ve teklifi aynı kapsamla yeniden isteyin. Çıkış, devir ve fikri mülkiyetle ilgili sorular için tedarikçi seçimi yazımızdaki maddeler, yapay zekâ dışındaki yazılım projelerine de uygulanır.
Teklifte görünmeyen maliyetler nelerdir?
Teklifte çoğu zaman görünmeyen maliyetler yayından sonra başlar: bakım, barındırma ve işletim, üçüncü taraf lisans ve servisler, bir de kurumun kendi zamanı. Bunları teklif aşamasında ayrı satırlar hâlinde istemek, ilk yılın sonunda sürprizle karşılaşmamanın yoludur.
- Bakım ile işletimi ayırın: Yazılım bakımına ilişkin uluslararası standart ISO/IEC/IEEE 14764, bakım sürecini ve bakım türlerini tanımlar; yedekleme, kurtarma ve sistem yönetimi gibi işletim işlerini ise kapsamına almaz. Teklifte de iki ayrı soru sorun: Hataları, güvenlik ve bağımlılık güncellemelerini kim yapacak? Sunucuyu, yedeği ve izlemeyi kim işletecek?
- Barındırma tek bir rakam değildir: Bulutta maliyet kullanıma göre oluşur. AWS'nin Well-Architected maliyet optimizasyonu ilkeleri, yalnızca hafta içi mesai saatlerinde kullanılan geliştirme ve test ortamlarını kullanılmadıkları saatlerde kapatmanın bu ortamlarda yaklaşık %75 tasarruf potansiyeli taşıdığını örnekler (haftada 168 yerine 40 saat). Ortam sayısı, çalışma saatleri, yedeklerin saklanma süresi, kayıt (log) hacmi ve dışarı veri aktarımı barındırma kaleminin asıl belirleyicileridir.
- Lisans ve servisler: Kullanıcı başına ücretlenen bileşenler, ticari arayüz veya raporlama kütüphaneleri, harita, SMS, e-posta ve ödeme servisleri kullanım arttıkça büyür. Kurum içi kurulumda veritabanı ve işletim sistemi lisansları da eklenir.
- Açık kaynak yükümlülükleri: Açık kaynak ücretsizdir ama koşulsuz değildir. Örneğin GNU AGPL v3 lisansının 13. bölümü, değiştirilmiş bir sürümü ağ üzerinden kullananlara kaynak kodu sunma yükümlülüğü getirir. Teklifle birlikte kullanılan bileşenlerin ve lisanslarının listesini isteyin.
- Kurumun kendi zamanı: Ürün sorumlusunun kararları, kullanıcıların kabul testleri, veri sahiplerinin doğrulaması ve bilgi işlem ekibinin erişim işleri teklifte görünmez ama takvimi doğrudan etkiler.
- Çıkış maliyeti: Kod, hesaplar ve belgeler sizde değilse, tedarikçi değiştirmek yeni bir projeye dönüşür.
Varsayımsal örnek: iki teklif arasındaki fark nereden geliyor?
Bu örnek varsayımsaldır ve rakam içermez. Bir dağıtım şirketi, bayilerin sipariş verdiği ve siparişlerin ERP'ye aktarıldığı bir bayi portalı için iki teklif alıyor. A teklifinin toplamı B'den belirgin biçimde düşük. Çalışma sayfası doldurulunca tablo değişiyor:
| Kalem | Teklif A | Teklif B | Yapılacak |
|---|---|---|---|
| ERP entegrasyonu | "ERP API'si hazır" varsayımıyla tek yönlü aktarım | İki yönlü aktarım, hata durumunda tekrar deneme ve mutabakat raporu | A'ya ERP'nin bugünkü durumunu ve mutabakat ihtiyacını yazılı olarak iletin |
| Veri taşıma | Kapsam dışı | Aktif bayi ve ürün verisinin taşınması | Taşımanın kimde kalacağını netleştirin |
| Güvenlik hedefi | Belirtilmemiş | ASVS 2. seviye | İki tedarikçiden de aynı seviyeyi fiyatlamasını isteyin |
| Test | Manuel kabul testi | Otomatik testler ve kabul testi | Hangi iş kurallarının otomatik testle korunacağını sorun |
| Barındırma | Tedarikçinin hesabında, aylık ücretle | Müşterinin bulut hesabında, kurulumu tedarikçi yapıyor | Hesap sahipliğini ve çıkış koşullarını karşılaştırın |
| Bakım | Belirtilmemiş | Kapsamı yazılı ayrı bir bakım anlaşması | A'dan bakım kapsamını ve fiyatlama yöntemini isteyin |
Bu tabloda A'nın düşük toplamı bir kalite göstergesi değil, kapsam farkıdır. A'nın dışarıda bıraktığı kalemlerin bir kısmını alıcı yine ödeyecektir: ayrı bir teklifle, kendi ekibinin zamanıyla ya da canlıya çıktıktan sonra ortaya çıkan sorunlarla. Doğru karşılaştırma, iki tedarikçiye de aynı kapsamı, aynı güvenlik hedefini ve aynı barındırma modelini yazılı olarak verip teklifleri yenilemektir. B yine daha pahalı kalabilir; ama artık aynı işi karşılaştırıyorsunuzdur.
Maliyeti kaliteyi düşürmeden nasıl azaltırsınız?
Maliyeti kalıcı olarak azaltmanın yolu eforu kısmak değil, belirsizliği ve gereksiz kapsamı azaltmaktır:
- İlk sürümü daraltın: En değerli tek iş akışını uçtan uca çalıştıran bir ilk sürüm, her şeyi biraz yapan bir sürümden daha az risklidir.
- Standart süreçte hazır bileşen kullanın: Kimlik doğrulama, ödeme veya bildirim gibi alanlarda kendi çözümünüzü yazmak ancak gerçek bir gerekçeyle anlamlıdır.
- Entegrasyonları erken açın: Test ortamı erişimi ve karşı sistemin sorumlusu proje başlamadan belli olsun.
- Karar vericiyi ayırın: Karar ve test gecikmeleri ekibin bekleme süresine, bekleme süresi de maliyete dönüşür.
- Güvenlik seviyesini riske göre seçin: Her uygulama en yüksek seviyeyi gerektirmez; ama seçilen seviye yazılı olmalıdır.
- Ortamları kullanıma göre çalıştırın: Geliştirme ve test ortamlarını mesai dışında kapatmak barındırma giderini düşürür.
- Değişiklik payı ayırın: Kullanıcılar yazılımı gördükçe yeni ihtiyaçlar çıkar; baştan ayrılan bir pay, her değişikliğin krize dönüşmesini önler.
Mevcut bir sistemi yenilemeyi düşünüyorsanız, sıfırdan yazmak ile aşamalı yenilemek arasındaki maliyet ve risk farkını uygulama modernizasyonu karar rehberimizde ele aldık.
Hatson Tech teklifini nasıl hazırlıyor?
Sabit bir fiyat listemiz yok. İlk görüşme ve keşif ücretsizdir; keşifte iş kurallarını, kullanıcı rollerini, bağlanacak sistemleri ve veriyi çıkarıyoruz. Ardından pilotun ve sonraki her aşamanın teklifini; kapsamı, teslimatları, kabul ölçütlerini ve dayandığımız varsayımları gösteren yazılı bir belge olarak veriyoruz. Kapsam değişirse fiyat da ancak yazılı bir değişiklikle güncellenir; kullanılan açık kaynak kütüphaneler ve lisansları ayrıca belirtilir. Çalışma şeklimizin ayrıntıları özel yazılım geliştirme sayfamızda. Teklif istemeden önce kapsamı netleştirmek isterseniz, ilk görüşmede bu yazıdaki çalışma sayfası üzerinden birlikte ilerleyebiliriz.