İçeriğe geç
Özel yazılım

Yazılım geliştirme maliyeti: Teklifi büyüten dokuz etken

Yazılım geliştirme maliyeti ekran sayısıyla değil kapsam, entegrasyon, rol, veri göçü ve belirsizlikle belirlenir. Fiyat modelleri ve maliyeti düşürme yolları.

Sevan Nerse Sevan NerseYayın tarihi: 6 dk okuma
Bu yazıda
  1. Neden tek bir rakam yok
  2. Maliyeti belirleyen dokuz etken
  3. Üç fiyatlandırma modeli ve bedelleri
  4. “Ekran başına fiyat” neden yanıltır
  5. Maliyeti sonucu bozmadan düşürmenin yolları
  6. Teklif almadan önce hazırlanacaklar
  7. Nereden başlamalı?

Yazılım geliştirme maliyetini belirleyen şey ekran sayısı ya da harcanacak saat değil; kapsamın ne kadar net olduğu, kaç farklı rol ve yetki seviyesi bulunduğu, kaç dış sisteme bağlanılacağı, eski verinin taşınıp taşınmayacağı ve işin ne kadarının hâlâ belirsiz olduğudur. Bu yüzden aynı cümleyle anlatılan iki iş arasında birkaç kat fark çıkması olağan. Bu yazıda bilerek rakam vermiyoruz; teklifi büyüten ve küçülten etkenleri, fiyatlandırma modellerini ve maliyeti sonucu bozmadan nasıl düşürebileceğinizi anlatıyoruz.

Neden tek bir rakam yok

“Basit bir sipariş takip programı” cümlesini düşünün. Bir şirket için bu, tek depoda iki kişinin kullandığı, siparişleri listeleyip durumunu güncelleyen bir ekran demek. Bir başkası için üç şubede çalışan, bayilerin de giriş yaptığı, muhasebe programına ve kargo firmasına bağlanan, belirli tutarın üstündeki siparişleri yönetici onayına düşüren bir sistem demek. İkisi de “sipariş takibi”; ikisinin maliyeti arasında ciddi bir uçurum var.

İnternette dolaşan “ortalama şu kadar tutar” listeleri bu farkı görmezden geldiği için işe yaramaz. Yararlı olan, kendi işinizin hangi etkenlerde ağır olduğunu görmek. Hazır bir ürünün işinizi görüp göremeyeceğinden emin değilseniz, maliyete bakmadan önce hazır yazılım mı özel yazılım mı sorusunu cevaplamak daha doğru bir başlangıç olur.

Maliyeti belirleyen dokuz etken

1. Kapsam ve kabul kriterleri

Kapsam “hangi ekranlar olacak” değil, “kim, hangi adımı yapıp hangi sonucu görecek” sorusunun cevabıdır. “Depo sorumlusu siparişi hazırlandı olarak işaretler, müşteri temsilcisi bunu anında görür” bir kabul kriteridir; “sipariş ekranı” değildir. Kabul kriterleri ne kadar netse tahmin o kadar dar, teklif o kadar güvenilir olur.

2. Entegrasyonlar

Her dış sistem bir bağımlılıktır: muhasebe programı, e-fatura entegratörü, banka, kargo, ödeme sağlayıcısı, e-ticaret altyapısı. Maliyeti belirleyen, bağlantının sayısı kadar o sistemin dokümantasyonunun kalitesi, bir test ortamı sunup sunmadığı ve hata verdiğinde ne olacağıdır. İyi bir entegrasyon yalnızca veriyi göndermez; başarısız olduğunda tekrar dener, kayıt tutar ve sorunu birinin görebileceği bir yerde gösterir.

3. Roller ve yetkiler

Belirleyici olan kullanıcı sayısı değil, rol sayısıdır. Elli kişinin aynı yetkiyle kullandığı bir araç, beş kişinin beş farklı yetkiyle kullandığı bir araçtan çoğu zaman daha ucuzdur. Şube bazlı görünürlük, onay zincirleri ve “bu alanı sadece finans görsün” kuralları her biri ayrı iş demek.

4. Raporlama

Rapor istekleri genelde en sona kalır ve en çok sürprizi onlar çıkarır. Bir liste ekranını dışa aktarmak kolaydır; dönemler arası karşılaştırma, birden çok kaynaktan beslenen özetler ve geriye dönük düzeltilebilen veriler üzerinde tutarlı rakamlar üretmek ise ayrı bir tasarım işidir. Hangi raporlara gerçekten her hafta bakıldığını baştan yazın.

5. Tasarım ve kullanım yeri

Ofiste masaüstü ekranda kullanılacak bir iç araç ile sahada, eldivenle, zayıf bağlantıda telefondan doldurulacak bir form aynı iş değildir. Yazılımı müşterileriniz ya da bayileriniz de kullanacaksa, metinler, hata mesajları ve ilk kullanım deneyimi de kapsamın parçası olur.

6. Veri göçü

Eski veri taşınacak mı, ne kadar temiz? Yıllar içinde elle düzeltilmiş, aynı müşterinin üç farklı yazımla durduğu bir Excel dosyasını yeni sisteme aktarmak, çoğu zaman yeni ekranı yazmaktan daha fazla dikkat ister. Temizliğin kimin işi olduğu teklifte yazmalı.

7. Barındırma ve altyapı

Yazılım nerede çalışacak: kendi sunucunuzda mı, kendi bulut hesabınızda mı? Yedekleme, izleme, e-posta gönderimi, dosya depolama gibi kalemler hem kurulumda hem her ay maliyet üretir. Bu kalemlerin kimin adına açıldığı ve kimin ödediği ayrıca konuşulmalı.

8. Bakım

Yayına çıkan yazılım durmaz: bağımlılıklar güncellenir, güvenlik yamaları gelir, bağlandığınız servisler arayüzlerini değiştirir. Maliyetin önemli bir kısmı yayından sonra oluşur. Bakımı hesaba katmayan bir bütçe eksik bir bütçedir.

9. Belirsizlik

Süreç sizin tarafta net mi, yoksa yazılım yazılırken mi keşfedilecek? Belirsizlik ne kadar büyükse, sabit fiyat veren tedarikçi o kadar büyük bir pay ekler ya da kapsamı o kadar dar tutar. Belirsizliği azaltmanın en ucuz yolu, kod yazılmadan önce süreci yazıya dökmektir.

Üç fiyatlandırma modeli ve bedelleri

Fiyatın kendisi kadar, hangi riskin kimde kaldığı da önemlidir. Yaygın üç model şöyle ayrışır:

Model Ne zaman uygun Risk kimde Dikkat edilecek nokta
Sabit fiyat Kapsam kâğıt üzerinde netleşebiliyorsa Tahmin riski tedarikçide Değişiklik talebinin nasıl fiyatlanacağı yazılı olmalı
Zaman ve malzeme (gün ya da saat bazlı) Kapsam gerçekten açık uçluysa, öncelikler sık değişiyorsa Büyük ölçüde sizde Haftalık görünürlük ve çalışan sürüm şart
Aylık anlaşma Yayından sonraki bakım ve küçük geliştirmeler Paylaşılır Dahil olan ve olmayan işler ayrı ayrı yazılmalı

Sabit fiyat kulağa en güvenli model gibi gelir ve kapsam netse gerçekten öyledir. Kapsam net değilse ise iki şeyden biri olur: tedarikçi belirsizliği fiyata ekler ya da proje boyunca her istek “kapsam dışı” tartışmasına döner. Zaman ve malzeme modeli esneklik sağlar ama ilerlemeyi her hafta görmüyorsanız bütçe sessizce kayar. Saatlik faturalamanın bir sorunu daha var: yavaş çalışmanın parasını öder. Biz bu yüzden kapsam netleşebiliyorsa sabit fiyat, netleşemiyorsa gün bazlı ücret, yayından sonrası için aylık bakım anlaşması kullanıyoruz.

Modeller birbirini dışlamaz. Sık görülen ve sağlıklı bir düzen şöyle: kapsamı çıkaran kısa bir keşif, ilk sürüm için sabit fiyat, sonraki küçük geliştirmeler için aylık anlaşma. Ödemenin takvime değil, teslim edilen çalışan yazılıma bağlanması da modelden bağımsız olarak isteyebileceğiniz bir koşuldur; iş yavaşladığında elinizdeki tek koz odur.

“Ekran başına fiyat” neden yanıltır

Bazı teklifler işi ekran sayısına böler: on iki ekran, ekran başı şu kadar. Bu yaklaşım anlaşılır görünür ama maliyetin nereden geldiğini gizler. Bir liste ekranı ile içinde onay kuralı, stok düşümü ve muhasebe entegrasyonu tetikleyen bir “sipariş onayla” düğmesi aynı ekran sayılır. Ekranın arkasındaki iş kuralları, yetki kontrolleri, hata durumları ve raporlar ise hiçbir ekran sayımında görünmez.

Ekran başı fiyatın ikinci sorunu, sizi daha az ekranla daha çok şey isteyen bir tasarıma iter. Sonuç, kalabalık ve kullanması zor bir arayüz olur. Teklifleri karşılaştırırken ekran sayısını değil, kabul kriterlerini ve dahil edilmeyen işleri yan yana koyun.

Aynı mantık “modül başına” ya da “özellik başına” fiyat listeleri için de geçerli. Bir listedeki “raporlama modülü” satırı, sizin her ay bakılan üç raporunuzu da kapsayabilir, hiçbirini de. Satırın karşısındaki rakama değil, o satırın sizin sürecinizde tam olarak neyi yapacağının yazılı olup olmadığına bakın.

Maliyeti sonucu bozmadan düşürmenin yolları

Bütçeyi düşürmenin kötü yolu testleri, dokümanı ve bakımı kesmektir; fatura ilk yıl küçülür, sonraki yıllarda büyür. Daha iyi yollar şunlar:

  • İlk sürümü, Excel'i ya da e-postayı gerçekten devre dışı bırakan en dar akışa indirin; gerisini ikinci faza yazın.
  • Kararı verebilen tek bir kişiyi belirleyin. Üç departmanın onayına bağlı kapsam hem süreyi hem maliyeti büyütür.
  • Veriyi göçten önce kendi tarafınızda temizleyin ya da temizliği ayrı ve ölçülebilir bir iş olarak tanımlayın.
  • Hazır ürünün iyi yaptığı işi yeniden yazdırmayın; entegrasyonla bağlanın.
  • Raporları “hepsi” yerine her hafta gerçekten bakılan üç beş raporla sınırlayın.
  • Test edecek bir kullanıcının haftada bir saat ayırmasını sağlayın. Geç fark edilen hata, erken fark edilenden pahalıdır.
  • Bütçe aralığınızı baştan söyleyin. Kapsam ona göre kesilir, iki tur boşa gitmez.

Teklif almadan önce hazırlanacaklar

Bir teklifin isabeti, ona verdiğiniz bilgiyle sınırlı. Görüşmeye şunlarla gelin: süreci bugün fiilen yürüten kişi, kullandığınız Excel dosyasının temizlenmemiş gerçek hali, günde ya da ayda kaç kayıt geçtiği, kaç kişinin hangi yetkilerle kullanacağı, bağlanması gereken sistemler ve varsa kesin bir tarihin nedeni. Bu bilgiler olmadan verilen her rakam, iyi giyinmiş bir tahminden öteye geçmez.

Nereden başlamalı?

Kapsam henüz netleşmemişse, doğrudan büyük bir teklif istemek yerine kısa ve sınırlı bir keşif adımıyla başlamak çoğu zaman en ucuz yoldur: süreç yazıya dökülür, kabul kriterleri çıkar ve sabit fiyat bunun üzerine verilir. Sürecin nasıl işlediğini ve süreyi neyin uzattığını yazılım yaptırma rehberimizde, çalışma modellerimizi ve paketlerimizi fiyatlar sayfamızda bulabilirsiniz.

Kendi işinizin hangi etkenlerde ağır olduğunu birlikte görmek isterseniz, özel iş yazılımı hizmetimizin nasıl işlediğine göz atıp iletişim sayfamızdan 30 dakikalık bir görüşme ayarlayın. Bu görüşmede fiyat vermiyoruz, ama işin hangi modele oturduğunu ve teklifinizi neyin büyüteceğini açıkça söylüyoruz.

Sevan Nerse

Yazan

Sevan Nerse

LokumTech'in kurucusu. 2018–2022 arasında Akaunting ekibinde Senior Software Developer olarak çalıştı; son beş yıla yakın süreyi İK teknolojilerinde, farklı dönemlerde Tech Lead ve CTO olarak geçirdi.

Hakkımızda

SSS

Sık sorulan sorular

Yazılım geliştirme maliyeti için ortalama bir rakam var mı?
Anlamlı bir ortalama yok. Aynı cümleyle anlatılan iki iş, rol sayısı, entegrasyonlar ve veri göçü yüzünden birkaç kat farklı tutabilir. Güvenilir bir rakam ancak kapsam yazıya döküldükten sonra verilebilir.
İlk görüşmede fiyat isteyebilir miyim?
İsteyebilirsiniz ama kimse süreci görmeden verilen fiyata güvenmemeli. Daha doğru yol, kısa ve ücretli bir keşif adımıyla kapsamı yazdırıp sabit teklifi onun üzerine almaktır. Bütçe aralığınızı baştan söylemek de kapsamın ona göre kesilmesini sağlar.
Sabit fiyatlı projede kapsam değişirse ne olur?
İyi kurulmuş bir sabit fiyatlı projede yazılı kapsamın fiyatı değişmez; yeni istekler ayrı bir yazılı teklifle, işe başlanmadan önce onaylanır. Sözleşmede değişiklik talebinin nasıl fiyatlanacağı baştan yazılmalı.
Bakım maliyeti geliştirme teklifine dahil mi olmalı?
Teklifte ayrı bir satır olarak görünmeli ama projeye şart olarak bağlanmamalı. Neyin dahil olduğu, yanıt süresi ve dahil olmayan işler yazılı olmalı ki yayından sonra sürpriz çıkmasın.

Aynı konuda

Okumaya devam edin

Her iyi ürün bir sohbetle başlar.

Canınızı sıkan süreci anlatın. Doğru adres olup olmadığımızı dürüstçe söyleriz — değilsek, kimin olduğunu da.