Yazılım teklifi nasıl karşılaştırılır? 12 soru ve kırmızı bayraklar
Yazılım teklifi karşılaştırırken fiyattan önce kapsam, hariç tutulanlar, kod sahipliği, bakım ve değişiklik talepleri okunmalı. 12 soru ve kırmızı bayraklar.
Bu yazıda
Bir yazılım teklifini karşılaştırırken önce fiyata değil, teklifin neyi kapsadığına ve neyi açıkça dışarıda bıraktığına bakın; ardından kodun ve hesapların kimde kalacağını, bakımın nasıl işleyeceğini, değişiklik taleplerinin nasıl fiyatlanacağını ve işi fiilen kimin yapacağını sorun. Aynı kapsamı anlatmayan üç teklifin rakamlarını yan yana koymak hiçbir şey söylemez. Aşağıda teklifleri aynı dile çevirmenin yolunu, sormanız gereken on iki soruyu ve dikkat etmeniz gereken işaretleri bulacaksınız.
Önce teklifleri aynı dile çevirin
Teklifler arasındaki fiyat farkının büyük kısmı, firmaların aynı işi farklı anlamasından gelir. Biri sizin anlattığınızı tek bir ekran olarak yorumlar, diğeri onay akışı ve raporuyla birlikte. Bu yüzden karşılaştırmanın ilk adımı tekliflerden önce gelir: herkese aynı yazılı ihtiyaç tanımını gönderin.
İyi bir ihtiyaç tanımı uzun olmak zorunda değil. Şunları içermesi yeterli: süreci bugün kimin, hangi adımlarla yürüttüğü; yazılımı kaç kişinin ve kaç farklı rolle kullanacağı; bağlanması gereken sistemler; taşınacak veri; varsa kesin bir tarih ve nedeni. Ardından gelen tekliflerde şu soruyu sorun: bu teklif benim yazdığım her maddeyi karşılıyor mu, yoksa bazılarını sessizce atlıyor mu?
Teklifin kapsam bölümü “sipariş modülü, raporlama modülü, kullanıcı yönetimi” gibi başlıklardan ibaretse, kapsam aslında tanımlanmamış demektir. Aradığınız şey kabul kriterleri: “Depo sorumlusu siparişi hazırlandı olarak işaretler, müşteri temsilcisi durumu anında görür.” Bir maddenin “bitti” sayılması için neyi görmeniz gerektiği yazmıyorsa, proje sonunda “bitti mi?” sorusu bir tartışmaya dönüşür.
Teklifte yazmayanlar: kapsam dışı listesi
İyi bir teklif neyin dahil olduğunu ne kadar açık yazıyorsa, neyin dahil olmadığını da o kadar açık yazar. Kapsam dışı listesi olmayan bir teklif, sonradan çıkacak her tartışmayı size bırakır.
Sık rastlanan ve teklifte açıkça konuşulması gereken kalemler şunlar: eski verinin taşınması ve temizliği; muhasebe, e-fatura, banka ya da kargo entegrasyonları; mobil kullanım; e-posta ve SMS gönderim altyapısı; sunucu ve alan adı maliyetleri; kullanıcı eğitimi; kurulum ve işletim dokümanı. Bunlardan biri bir teklifte var, ötekinde yoksa iki rakamı doğrudan karşılaştıramazsınız.
Fiyatın arkasındaki koşullar
İki teklif aynı kapsamı ve aynı rakamı yazıyor olabilir, ama koşulları çok farklı olabilir. Aşağıdaki tabloyu her teklif için doldurmak, farkları görünür kılar:
| Konu | Teklif A | Teklif B | Teklif C |
|---|---|---|---|
| Kabul kriterleriyle yazılmış kapsam | |||
| Kapsam dışı listesi | |||
| Kaynak kodun telif ve mali hakları | |||
| Kod deposunun açıldığı hesap | |||
| Sunucu ve alan adının sahibi | |||
| Barındırma maliyeti dahil mi | |||
| Veri göçü dahil mi | |||
| Değişiklik talebi süreci | |||
| Yayından sonra bakım ve yanıt süresi | |||
| Ödeme takvime mi teslime mi bağlı | |||
| Kodu yazacak kişiler | |||
| Demo sıklığı |
Boş kalan hücreler, tedarikçiye sormanız gereken soruların listesidir. Cevap alamadığınız hücreler ise başlı başına bir bilgidir.
Özellikle kod sahipliğine dikkat edin. Yalnızca “kullanım hakkı” verilen bir yazılımı ileride başka bir ekibe geliştirtemeyebilirsiniz. Kod deposunun geliştiricinin hesabında durması da, ilişki bozulduğunda bir pazarlık kozuna dönüşebilir. Sunucu, alan adı ve servis hesaplarının sizin şirketiniz adına açılması aynı mantıkla önemlidir.
Barındırma ve bakım, tekliflerin en kolay farklılaştığı iki kalemdir. Bir teklif sunucuyu kendi altyapısında “ücretsiz” barındırıyor olabilir; bu ilk bakışta avantaj gibi görünür ama sistemin fiilen kimin elinde durduğunu değiştirir. Bir başkası sunucuyu sizin hesabınızda kurar ve aylık maliyeti doğrudan sağlayıcıya ödersiniz. Bakım tarafında da benzer bir fark var: “bir yıl ücretsiz destek” ifadesi, neyin destek sayıldığı yazılmadıkça ölçülemez. Hata düzeltmesi mi, güvenlik güncellemesi mi, küçük değişiklikler mi? Yanıt süresi ne, hangi saatlerde? Yedekler yalnızca alınıyor mu, yoksa düzenli olarak geri yüklenip test ediliyor mu? Teklifler bu sorulara farklı cevaplar veriyorsa, aynı rakam çok farklı bir hizmet anlamına gelebilir.
Değişiklik talepleri nasıl yönetilecek?
Her yazılım projesinde kapsam bir miktar değişir. Prototipi gören kullanıcı, kâğıt üzerinde düşünülmemiş bir adımı fark eder; bu normaldir. Önemli olan, değişikliğin nasıl ele alınacağının baştan yazılı olmasıdır.
Sağlıklı bir süreçte yeni istek yazılı olarak tarif edilir, tedarikçi bunun süreye ve fiyata etkisini işe başlamadan önce bildirir, siz onaylarsınız ve ancak ondan sonra iş başlar. Değişikliklerin “sonra konuşuruz” diyerek yapılıp faturaya eklenmesi ise proje sonunda sürpriz bir rakam demektir. Teklifte bu sürecin nasıl işlediği yazmıyorsa sorun.
İşi kim yapacak, ne sıklıkla göreceksiniz?
Teklif görüşmesini yapan kişiyle kodu yazacak kişi aynı mı? İş başka bir firmaya ya da serbest çalışana devrediliyor mu? Projede kaç kişi çalışacak ve isimleri söylenebiliyor mu? Bu sorulara verilen kaçamak cevaplar, projenin ortasında da kaçamak kalır.
İlerlemeyi nasıl göreceğiniz de önemli. Durum raporu ilerlemenin yerine geçmez. Haftalık ya da iki haftalık aralıklarla, kendi verinizle tıklayabildiğiniz çalışan bir sürüm görmek; yanlış anlaşılmaları erken, ucuzken yakalamanın en güvenilir yoludur. Yalnızca proje sonunda büyük bir teslim vaat eden teklifler, bütün riski son haftaya yığar.
Tedarikçiye sorulacak 12 soru
Bu soruları kiminle çalışırsanız çalışın sorun. Bir tedarikçinin bu soruları duyduğunda rahatlaması ya da gerilmesi, alacağınız en faydalı sinyallerden biridir.
- Kapsamdaki her maddenin kabul kriteri yazılı mı? Bir maddenin bittiğini nasıl anlayacağım?
- Teklifte açıkça kapsam dışı bırakılan neler var?
- Kaynak kodun telif ve mali hakları kime ait olacak, sözleşmede nasıl ifade edilecek?
- Kod deposu ilk günden kimin hesabında açılacak?
- Sunucu, alan adı ve servis hesapları kimin adına olacak, aylık maliyetleri kim ödeyecek?
- Eski verinin taşınması ve temizliği kapsamda mı, temizlikte benden ne bekleniyor?
- Değişiklik talepleri nasıl tarif edilecek, fiyatlanacak ve onaylanacak?
- Kodu fiilen kim yazacak; iş başka bir firmaya ya da kişiye verilecek mi?
- Çalışan bir sürümü ne sıklıkla göreceğim ve testleri kim, nasıl yapacak?
- Ödeme takvime mi, teslim edilen çalışan yazılıma mı bağlı?
- Yayından sonra bakım neyi kapsıyor, neyi kapsamıyor ve yanıt süresi ne?
- İlişki biterse elime ne geçecek: devir dokümanı, ortam değişkenleri listesi, eğitim?
Bu soruların çoğu teknik değil. Cevapları anlamak için yazılımcı olmanız gerekmez; cevabın net ve yazılı olup olmadığına bakmanız yeterli. Sözlü verilen güzel bir cevap, teklifte ya da sözleşmede yer almıyorsa yokmuş gibi davranın. Bir tedarikçi size jargonla cevap veriyorsa açıklama isteyin; kendi işini iyi bilen biri bunu sade bir dille anlatabilir.
Dikkat edilmesi gereken işaretler
Aşağıdaki işaretler tek başına bir firmanın kötü olduğunu göstermez, ama her biri daha fazla soru sormanız gerektiğini söyler:
- Süreci görmeden verilen kesin fiyat. İlk görüşmede, hiçbir şey yazıya dökülmeden verilen rakam büyük ihtimalle bir tahmindir. Ya sonradan büyür ya da kapsam sessizce daralır.
- Kapsam dışı listesinin hiç olmaması. “Her şey dahil” ifadesi, tanımlanmadığı sürece hiçbir şey ifade etmez.
- Kod deposunun ve hesapların tedarikçide kalması. Teslimde devredileceği söylense bile, ilk günden sizin hesabınızda olması daha güvenlidir.
- Ağırlıklı peşin ya da takvime bağlı ödeme. İş yavaşladığında elinizde koz kalmaz.
- İsim verilmemesi. Projede kimin çalışacağı söylenemiyorsa, ekibin değişmesi de size sorulmaz.
- Bakımın projeye şart olarak bağlanması. Bakım isteğe bağlı ve ayrı bir anlaşma olmalı; aksi halde tedarikçiyi değiştirme özgürlüğünüz kalmaz.
- Kendine özgü, belgelenmemiş bir altyapı. Yaygın ve iyi belgelenmiş araçlarla yazılmış bir sistemi başka bir ekip devralabilir; kapalı bir çatıyla yazılmış olanı devralmak çok daha zordur.
Nereden başlamalı?
Teklif istemeden önce ihtiyacınızı bir iki sayfada yazın ve herkese aynı metni gönderin. Teklifler geldiğinde yukarıdaki tabloyu doldurun, boş kalan hücreler için soru sorun ve ancak ondan sonra rakamlara bakın. Rakamların arkasındaki etkenleri anlamak için yazılım geliştirme maliyeti yazımızı, süreç ve sözleşme tarafında neye dikkat edilmesi gerektiğini görmek için yazılım yaptırma rehberimizi okuyabilirsiniz.
Karşılaştırmanın bir parçası olarak bizden de teklif almak isterseniz, özel iş yazılımı hizmetimizin nasıl işlediğini hizmet sayfasında, çalışma modellerimizi ve koşullarımızı fiyatlar sayfamızda yazılı olarak bulabilirsiniz. Yukarıdaki on iki sorunun cevabı yazılı teklifimizde zaten yer alıyor; yine de görüşmede tek tek sormanızı isteriz. Sürecinizi anlatmak için iletişim sayfamızdan 30 dakikalık bir görüşme ayarlayabilirsiniz.

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