Yazılım tekliflerini karşılaştırırken en büyük tuzak, birbirinin aynısı sanılan ama aslında farklı işleri fiyatlayan teklifleri yalnızca toplam rakama göre sıralamaktır. Ucuz görünen bir teklif, yönetim panelini, testleri ya da yayın sonrası desteği dışarıda bırakmış olabilir. Bu kontrol listesi, gelen teklifleri aynı ölçüyle okumanızı sağlar.
Önce: herkese aynı brifi gönderdiniz mi?
Karşılaştırılabilir teklif almanın ilk şartı, tüm ekiplere aynı yazılı brifi göndermektir. Brifte uygulamanın amacı, kullanıcı rolleri, temel iş akışları, zorunlu entegrasyonlar ve hedef tarih yer almalı. Bir brif şablonu için mobil uygulama maliyeti yazımızın son bölümüne bakabilirsiniz.
Brifi telefonda anlatıp geçerseniz her firma kafasında farklı bir proje kurar ve teklifler arasındaki fark size fiyat farkı gibi görünür. Bir firmaya sonradan ek bilgi verdiyseniz, aynı bilgiyi diğerlerine de iletin.
Teklifteki kalemleri nasıl okumalı?
Bir teklifi okurken toplam rakamdan önce, emeğin hangi işlere dağıtıldığına bakın. Kalemlerin dengesi, ekibin projeyi nasıl kavradığını gösterir.
Ayrıntılı bir teklifte genellikle şu başlıklar ayrı ayrı görünür:
- Analiz ve tasarım: Kullanıcı akışları, ekran tasarımları ve onay turları. Bu kalem çok silikse tasarım geliştirme sırasında doğaçlama yapılacak demektir.
- Geliştirme: Uygulamanın, yönetim panelinin ve entegrasyonların kodlanması. Modül modül ayrılmışsa neyin ne kadar emek istediğini görmek kolaylaşır.
- Test: Ayrı bir kalemse firma testi gerçek bir iş olarak görüyordur. Geliştirmenin içine gömüldüğünde genellikle en sona ve aceleye kalır.
- Proje yönetimi: Toplantılar, raporlama ve iletişim. Ayrı yazılması şart değil, ama bir yerde hesaba katılmış olmalı.
- Yayın ve kurulum: Sunucu kurulumu, mağaza başvuruları, alan adı ayarları gibi işler.
Kalemlerin dağılımı tekliften teklife çok farklıysa "Test kalemi neleri kapsıyor?" gibi sorularla nedenini öğrenin.
1. Kapsam açıkça yazılmış mı?
Kapsam, teklifin dayandığı zemindir. Neyin yapılacağı yazılı değilse fiyat da takvim de havada kalır.
İyi bir teklif "e-ticaret sitesi" gibi tek bir başlık değil, yapılacak işlerin listesini içerir:
- Hangi ekranlar ya da sayfalar var?
- Hangi kullanıcı rolleri hangi işlemleri yapabiliyor?
- Yönetim paneli dahil mi, dahilse neleri yönetiyor?
- Hangi entegrasyonlar teklife dahil?
Kapsamı belirsiz bir teklif, proje ilerledikçe ek faturalara dönüşür.
Sık yaşanan bir yanlış anlama: Müşteri "ürün yönetimi" dendiğinde stok takibi ve varyantlar bekler, firma ise ürün ekleme ekranını kasteder. Kapsam maddelerini kendi iş akışınız üzerinden okuyun; "Siparişi kim, hangi ekrandan iptal edecek?" gibi bir senaryonun cevabını bulamıyorsanız sorun. Kapsam dışını açıkça listeleyen teklifler de değerlidir, çünkü sınırı baştan çizerler.
2. Teslim edilecek kalemler neler?
Teslim kalemleri, proje bittiğinde neye sahip olacağınızın listesidir. Bu liste ne kadar somutsa, ileride bir firmadan diğerine geçmeniz o kadar kolay olur.
Proje bittiğinde elinize ne geçecek? Şunların listede olup olmadığına bakın:
- Kaynak kod ve depo erişimi
- Tasarım dosyaları
- Yayınlanmış uygulama ya da site
- Teknik dokümantasyon ve kullanım notu
- Sunucu, alan adı ve mağaza hesaplarının erişim bilgileri
"Uygulamanın teslimi" ile "kaynak kodun teslimi" sık karıştırılır. Mağazada yayında olan bir uygulama, kodu firmada kaldığı sürece tam kontrolünüzde değildir. Kodun nerede tutulacağını ve depoya sizin hesabınızın eklenip eklenmeyeceğini sorun. Dokümantasyonun da başka bir ekibin projeyi devralmasına yetecek düzeyde olup olmadığını öğrenin.
3. Süreç ve takvim gerçekçi mi?
Gerçekçi bir takvim, işi aşamalara böler ve her aşamada sizden ne beklendiğini de gösterir. Tek bir teslim tarihinden ibaret bir takvim, planlamanın henüz yapılmadığını düşündürür.
Teklif, işin hangi aşamalardan geçeceğini ve her aşamanın ne kadar süreceğini göstermeli. Tasarım onayı, ara teslimler ve test dönemi takvimde ayrı ayrı görünmüyorsa sorun. Çok kısa bir süre vaat eden teklif, ya kapsamı yanlış anlamıştır ya da test aşamasını atlamıştır.
Takvimde sizin payınızı da arayın. İçeriklerin ve onayların sizden ne zaman bekleneceği yazmıyorsa, gecikmenin kaynağı sonradan tartışma konusu olur. Ara teslimlerde neyi göreceğinizi de sorun: tıklanabilir bir tasarım mı, test ortamında çalışan bir sürüm mü, yoksa yalnızca bir durum raporu mu?
4. Ödeme planı teslimlere bağlı mı?
Ödemeler, sizin görüp onaylayabileceğiniz somut çıktılara bağlanmalı. Böylece her ödeme, işin gerçekten ilerlediğini gösteren bir adımla eşleşir.
Sağlıklı bir ödeme planı, ödemeleri somut teslimlere bağlar: tasarımın onaylanması, ilk çalışan sürüm, yayın gibi. Projenin tamamını en başta peşin isteyen teklifler sizin açınızdan risklidir.
Başlangıç ödemesi istenmesi normaldir, çünkü firma projeniz için ekip ve takvim ayırır. Asıl bakmanız gereken, son ödemenin neye bağlandığıdır. Son ödeme kabul testlerinin tamamlanmasına bağlandığında eksikleri kapatma motivasyonu iki taraf için de korunur.
5. Kapsam değişirse ne olur?
Değişiklik talepleri kaçınılmazdır, bu yüzden teklifte nasıl yönetileceği yazmalıdır. Yazmıyorsa, her yeni fikir bir pazarlık konusuna dönüşür.
Proje sırasında yeni fikirler çıkması doğaldır. Teklifte ek taleplerin nasıl fiyatlanacağı (saat ücreti, değişiklik talebi formu gibi) yazılı olmalı. Bu konuda sessiz kalan teklifler, en çok tartışma çıkaranlardır.
İyi işleyen bir süreçte talep yazılı iletilir, firma takvime ve bütçeye etkisini yazılı bildirir, siz onaylamadan iş başlamaz. Neyin "küçük düzeltme", neyin "yeni özellik" sayılacağını firmaya bir örnekle sorun.
6. Test ve kalite güvencesi var mı?
Test, teklifte kimin, neyi, nerede ve ne zaman test edeceği yazıyorsa vardır. "Gerekli testler yapılacaktır" gibi genel bir cümle, test planı yerine geçmez.
Testin kim tarafından, hangi cihazlarda ve hangi aşamada yapılacağı belirtilmeli. Yayından önce sizin de deneyebileceğiniz bir test ortamı sunulması iyi bir işarettir.
Hangi tarayıcı ve cihazların test kapsamında olduğunu, hataların nasıl kayda alınıp size raporlandığını sorun. Kabul testini sizin yapmanız bekleniyorsa, firmadan bir senaryo listesi isteyin.
7. Sahiplik ve fikri haklar kimde?
Ödemeyi tamamladığınızda, ürünü başka bir ekiple geliştirmeye devam edebilecek durumda olmalısınız. Sahiplik maddesi bunu güvence altına alır.
Kaynak kodun, tasarımların ve içeriklerin mülkiyetinin ödeme tamamlandığında size geçtiği açıkça yazmalı. Uygulama mağazası hesapları ve alan adı en baştan sizin adınıza açılmalı.
Firmanın birçok projede kullandığı kendi altyapısını size lisansla kullandırması mümkündür ve tek başına sorun değildir. Önemli olan bunun yazılı olması ve firmayla yollarınız ayrıldığında bu bileşenleri kullanmaya devam edip edemeyeceğinizin belli olmasıdır.
8. Yayından sonra destek ve bakım nasıl?
Yayın, projenin bittiği değil, ürünün gerçek kullanıcılarla buluştuğu andır. İlk haftalarda çıkacak sorunların nasıl ele alınacağı teklifte yazmalı.
- Ücretsiz destek süresi ne kadar?
- Hangi hatalar bu desteğe dahil?
- Sonrası için aylık bakım ya da saat bazlı destek seçeneği var mı?
- Sunucu ve üçüncü taraf servis ücretleri kimde?
Destek ile yeni geliştirme sık karıştırılır: Destek, teslim edilen özelliklerin çalışmasını sağlar; yeni bir ekran eklemek ayrı bir iştir. Bakımda işletim sistemi güncellemelerine uyum, güvenlik yamaları ve yedekleme olup olmadığını, acil durumda kime hangi kanaldan ulaşacağınızı da yazılı olarak alın.
9. Ekip kim, işi kim yapacak?
Teklifi hazırlayan kişiyle projeyi geliştirecek ekip her zaman aynı değildir, bu yüzden kiminle çalışacağınızı baştan öğrenin.
Projenizde kimlerin çalışacağını ve iletişimin kimin üzerinden yürüyeceğini sorun. İşin başka bir firmaya devredilip devredilmeyeceğini öğrenin.
Dış kaynak kullanımı tek başına kötü değildir, ama sizden saklanmamalı ve sorumluluğun kimde kaldığı belli olmalıdır. Küçük ekiplerde bir kişinin birden fazla rolü üstlenmesi olağandır; önemli olan tasarım, geliştirme ve test rollerinden hiçbirinin boşta kalmamasıdır. Firma hakkında daha geniş bir değerlendirme için Konya'da yazılım firması seçerken yazımızdaki sorular da işinize yarar.
10. Benzer işleri canlıda görebiliyor musunuz?
Bir ekibin ne yapabildiğini en iyi yayındaki işleri gösterir; ekran görüntüleri bunu kanıtlamaz.
Referans listesi yerine yayında olan ürünleri bizzat kullanın. Telefonunuzdan açın, kayıt olun, bir işlemi baştan sona deneyin. Bizim yayındaki ürünlerimiz portfolyo sayfamızda.
Denerken hıza, hata mesajlarının anlaşılırlığına ve telefondaki düzene bakın. Mümkünse firmanın eski bir müşterisiyle konuşun; "Bir sorun çıktığında ne oldu?" sorusunun cevabı, referans listesinden daha öğreticidir.
Takip görüşmesinde sorulacak sorular
Teklifleri okuduktan sonra öne çıkan firmalarla kısa bir görüşme yapıp teklifteki boşlukları doldurun.
İşinize yarayacak sorulardan bazıları:
- Bu projede sizi en çok düşündüren risk nedir?
- Teklifte bilerek dışarıda bıraktığınız bir şey var mı?
- Proje başladığında ilk adımlar neler olacak?
- Bizden hangi bilgileri, hangi sırayla bekliyorsunuz?
- Proje yarıda kalırsa elimizde ne olur?
Riskleri açıkça konuşabilen bir ekip, her soruya "sorun olmaz" diyen ekipten genellikle daha güvenilirdir.
Fiyat yerine kapsam üzerinde pazarlık
Bütçeniz en uygun teklifin altında kalıyorsa, aynı işi daha ucuza istemek yerine işin kendisini küçültmeyi konuşun. Fiyatı baskıyla düşürülen bir proje, çoğu zaman testten ya da destekten kesilir.
Özellikleri "ilk sürümde mutlaka olmalı" ve "sonra eklenebilir" diye ikiye ayırın ve firmadan ikinci grup çıkarıldığında teklifin nasıl değiştiğini görmek isteyin. Böylece ürünü erkenden gerçek kullanıcılarla denersiniz. İlk sürümün kapsamı için MVP nedir yazımıza bakabilirsiniz. Bazı ihtiyaçlar için hazır bir çözüm de yeterli olabilir; bu kararı vermek için hazır yazılım mı, özel yazılım mı karşılaştırmamıza bakabilirsiniz.
Sözleşmeye neler yazılmalı?
Teklifte konuşulan her şey, imzalanacak sözleşmede ya da ekinde yazılı olmalı. Sözlü verilen sözler, anlaşmazlık anında işinize yaramaz.
Sözleşmede ya da eklerinde aramanız gereken başlıklar:
- Kapsam eki: Teklifteki ekran, rol ve entegrasyon listesinin sözleşmeye eklenmiş hali.
- Kabul kriterleri: Her aşamanın hangi koşullar sağlandığında tamamlanmış sayılacağı ve onay sürecinin nasıl işleyeceği.
- Fikri hakların devri: Kaynak kod, tasarım ve içeriklerin hangi aşamada size geçeceği, firmanın kendi altyapısının nasıl lisanslanacağı.
- Garanti ve destek: Ücretsiz destek döneminin kapsamı, hataların nasıl bildirileceği ve sonrasında bakımın hangi koşullarla süreceği.
- Çıkış maddesi: Taraflardan biri projeyi sonlandırmak isterse yapılan işin nasıl teslim edileceği ve ödemelerin nasıl hesaplanacağı.
Bu bir hukuki tavsiye değildir; sözleşmeyi imzalamadan önce bir avukata okutmanızı öneririz.
Uyarı işaretleri
Aşağıdaki işaretler tek başına bir firmayı elemek için yeterli olmayabilir, ama her biri ek bir soruyu hak eder.
Şunlardan birini görürseniz daha fazla soru sorun:
- Kapsamı konuşmadan, ilk görüşmede verilen kesin fiyat
- "Her şey dahil" deyip neyin dahil olduğunu yazmamak
- Kaynak kodun teslim edilmeyeceğini söylemek
- Test ve destekten hiç bahsetmemek
- Yayında gösterilebilecek bir iş olmaması
Sorularınıza kaçamak cevap verilmesini de bu listeye ekleyin. Teklif sürecindeki iletişim, proje sürecindeki iletişimin provasıdır.
Teklifleri yan yana koymak için tablo
Tabloyu doldururken cevabını teklifte bulamadığınız her hücre, firmaya soracağınız bir sorudur.
| Kriter | Teklif A | Teklif B | Teklif C |
|---|---|---|---|
| Kapsam listesi var mı? | |||
| Yönetim paneli dahil mi? | |||
| Kaynak kod teslim ediliyor mu? | |||
| Ödemeler teslimlere bağlı mı? | |||
| Değişiklik talebi süreci yazılı mı? | |||
| Test ortamı sunuluyor mu? | |||
| Ücretsiz destek süresi | |||
| Toplam süre | |||
| Toplam fiyat |
Fiyatı en son satıra koymamızın bir nedeni var: Ancak üstteki satırlar eşitlendiğinde fiyatlar gerçekten karşılaştırılabilir hâle gelir.
Sık sorulan sorular
Teklif değerlendirirken sık duyduğumuz sorular.
En ucuz teklifi seçmek her zaman yanlış mı?
Hayır. Kapsamı diğerleriyle aynıysa ve tablodaki satırları karşılıyorsa iyi bir seçim olabilir. Sorun, düşük fiyatın eksik kapsamdan gelmesi ve bunun proje ortasında fark edilmesidir.
Teklifler arasında büyük fark varsa ne yapmalıyım?
Teklifleri kalem kalem yan yana koyup farkın hangi başlıkta toplandığını bulun, sonra iki firmaya da o kalemde tam olarak ne yaptıklarını sorun. Fark çoğu zaman kapsam, test ya da destek anlayışından çıkar.
Teklifi başka bir firmaya göstermek doğru mu?
Teklif, hazırlayan firmanın emeğidir ve rakibiyle paylaşılması hoş karşılanmaz. Bunun yerine tekliflerden öğrendiğiniz eksikleri brifinize ekleyip güncel brifi tüm firmalara gönderin.
Projeniz için net kapsamlı, kalem kalem bir teklif almak isterseniz bize yazın. Web siteleri için ayrıca web sitesi yaptırırken sorulacak sorular yazımıza da göz atabilirsiniz.