Özel Yazılım Maliyeti Neye Bağlı: Etkenler ve Teklif Okuma

Temel belirleyici kapsamdır: yazılımın kaç farklı kullanıcı türüne hizmet ettiği, kaç farklı iş akışını yürüttüğü ve her akışın kaç istisnası olduğu. Tek bir kullanıcı türü için yazılmış basit bir kayıt aracı ile satış, stok, muhasebe ve raporlamayı birlikte yürüten bir sistem aynı kategoride sayılsa da çok farklı emek ister.

İkinci belirleyici ekibin yapısıdır. Projeyi bir tasarımcı, bir yazılımcı, bir test sorumlusu ve bir proje yöneticisi birlikte yürütüyorsa maliyet bunların her birinin projeye ayırdığı zamandan oluşur. Deneyimli bir ekip daha pahalı görünür ama daha az tur atar; deneyimsiz bir ekip ucuz görünür ama yeniden yazım riski taşır.

Üçüncüsü süredir. Aynı kapsam daha kısa sürede istenirse ekip büyür ve koordinasyon yükü artar. Acele, maliyetin en sessiz kalemidir.

En büyük etken entegrasyondur. Muhasebe programı, ödeme altyapısı, kargo, e-posta ya da mevcut bir ERP ile konuşan her bağlantı ayrı bir iştir; çünkü karşı sistemin kuralları, hataları ve sürüm değişiklikleri sizin kontrolünüzde değildir. Üçüncü taraf bir sistemin belgesi eksikse maliyet belirsizleşir.

İkinci etken, kuralların kendisidir. 'Siparişi onaylayan kişi tutara göre değişir, bölge müdürü onaylamadıysa genel müdüre gider' gibi bir cümle yazılımda onlarca durumun test edilmesi demektir. İş kuralları ne kadar çok ve ne kadar istisnalıysa maliyet o kadar büyür.

Üçüncü etken veri taşımadır. Eski sistemden temiz olmayan verinin aktarılması, eşleştirilmesi ve doğrulanması çoğu projede en az beklenen ve en çok süre alan işlerden biridir.

• Entegre edilecek sistem sayısı ve karşı tarafın belge kalitesi
• Kullanıcı türü ve yetki farklarının çokluğu
• İş kurallarındaki istisna sayısı
• Eski sistemden veri taşıma ve temizleme ihtiyacı
• Güvenlik, yedekleme ve kayıt tutma beklentileri
• Birden çok dil, para birimi ya da şube desteği

En etkili karar, ilk sürümün kapsamını küçük tutmaktır. Her şeyi ilk günde isteyen proje, hiçbir parçası kullanılmadan büyür. Önce bir iş akışını canlıya alıp gerçek kullanıcıyla denemek, hangi özelliğin gerçekten gerektiğini gösterir ve gereksiz özelliklerin maliyetini baştan keser.

İkinci karar, hazır bileşenleri kullanmaktır. Giriş, ödeme, e-posta gönderimi, yetkilendirme gibi sorunları çözülmüş parçaları sıfırdan yazmak yerine kanıtlanmış hizmetlerle kurmak hem süreyi hem hatayı azaltır. Özel yazılım yazmak, her parçayı özel yazmak demek değildir.

Üçüncüsü karar sürecini kısa tutmaktır. Müşteri tarafında tek bir yetkili kişi olması, değişiklik taleplerinin yazıya dökülmesi ve haftalık kısa gösterimler, belirsizliği erken yakalar. En pahalı düzeltme, en geç fark edilen yanlış anlamadır.

İyi bir teklif tek bir toplam rakam değil, bir kapsam belgesidir. İçinde neyin yapılacağı, neyin dışarıda kaldığı, hangi varsayımlara dayandığı ve değişiklik nasıl ele alınacağı yazar. Kapsamı iki cümleyle anlatan bir teklif, sonradan her ekstra talep için yeni bir pazarlık demektir.

Teklifteki ödeme biçimine bakın. Sabit fiyat, kapsam netse sizi korur; ama kapsam belirsizse ekip riski fiyata ekler ya da sonradan ek talep açar. Zamana dayalı çalışma esnektir ama toplamın nereye varacağını bilmek için düzenli rapor ve üst sınır gerekir. İki biçimin de hangi koşulda size daha iyi geldiğini sorun.

Birkaç teklifi karşılaştırırken toplam rakama değil, kapsamlara bakın. Düşük görünen teklif, test, güvenlik, yedekleme ya da bakımı içermiyor olabilir. Aynı işi tarif etmeyen iki teklifi fiyatla kıyaslamak anlamlı değildir.

Teklifte sık atlanan kalemler yayından sonra ortaya çıkar: barındırma ve altyapı giderleri, üçüncü taraf hizmet abonelikleri, alan adı ve sertifika yenilemeleri, yedekleme ve izleme. Bunlar tek seferlik değil, sürekli giderdir ve toplam sahip olma maliyetinin önemli bir parçasıdır.

Bakım ikinci büyük gizli kalemdir. Yazılım bitince iş bitmez: güvenlik güncellemeleri, bağlı sistemlerin sürüm değişiklikleri, küçük iyileştirmeler ve hata düzeltmeleri sürer. Bakımı konuşulmamış bir proje, bir yıl sonra ya kimsenin sahip çıkmadığı bir yazılıma ya da acil ve pahalı bir müdahaleye döner.

Üçüncüsü eğitim, belge ve devir teslimdir. Yazılımın kodu, kurulum bilgisi ve kullanım belgeleri size mi teslim ediliyor, yoksa yazan ekibe mi bağlı kalıyorsunuz? Bu sorunun cevabı, ileride ekip değiştirme özgürlüğünüzü belirler.

En sık hata, en düşük teklifi seçmektir. Düşük teklif genellikle kapsamı dar tutar ya da riski sonraya bırakır; proje ilerledikçe ek kalemler eklenir ve toplam, başta göz ardı edilen teklifin üstüne çıkar.

İkinci hata, kapsamı yazmadan başlamaktır. Konuşarak anlaşılan şeyler yazıya geçmediğinde herkes kendi hatırladığını savunur. Üçüncüsü bakımı projenin dışında tutmaktır; yazılım canlıya çıktığında maliyet bitmiş sayılmaz.

Dördüncü hata, yazılımı bir kez alınan bir ürün gibi görmektir. Özel yazılım yaşayan bir varlıktır ve iş değiştikçe değişir. Bütçeyi yalnızca ilk geliştirmeye ayırmak, ikinci yıldan itibaren sorun yaratır.

İhtiyacınız piyasadaki hazır bir ürünle neredeyse tamamen karşılanıyorsa özel yazılım yazmanın bir nedeni yoktur. Standart bir muhasebe, randevu ya da e-posta ihtiyacı için hazır ürünü satın almak, hem daha hızlı hem daha öngörülebilirdir.

İş sürecinizi henüz tam tarif edemiyorsanız da erken kalmış olabilirsiniz. Süreç oturmadan yazılan yazılım, süreçle birlikte değişmek zorunda kalır ve her değişiklik yeniden yazım maliyeti getirir. Önce süreci kâğıt üzerinde ya da hazır bir araçla deneyin, netleşince karar verin.