Önünüzde üç yazılım firmasının teklifi var. Biri diğerinden belirgin biçimde ucuz, biri çok kapsamlı görünüyor, üçüncüsü ise iki sayfalık bir özetten ibaret. Hangisinin doğru seçim olduğunu anlamak zor, çünkü teklifler aynı işi tarif etmiyor olabilir. Doğru bir yazılım teklifi karşılaştırma süreci, rakamları yan yana koymaktan çok, tekliflerin neyi kapsadığını ve neyi dışarıda bıraktığını görünür kılmaktır.
Bu rehberde teklifleri aynı zemine getirmenin yolunu, bakmanız gereken kriterleri, fiyatlandırma modellerinin farkını, kırmızı bayrakları ve basit bir puanlama yöntemini bulacaksınız. Amacımız, karar anında elinizde sezgiden fazlasının olması.
Yazılım Teklifi Karşılaştırma Neden Sadece Fiyat Kıyası Değildir?
Yazılım projelerinde teklif, bir ürünün fiyat etiketi değildir. Belirsizlik taşıyan bir işin nasıl çözüleceğine dair firmanın yazılı taahhüdüdür. İki teklif aynı proje için hazırlansa bile varsayımları, ekip yapıları ve risk payları farklı olabilir.
Düşük görünen bir teklif çoğu zaman şu üç yoldan birini izler: kapsam dar tutulmuştur, test ve yönetim emeği hesaba katılmamıştır ya da değişiklik talepleri sonradan ek ücrete bağlanacaktır. Bu yüzden toplam fiyata bakmadan önce "bu fiyata tam olarak ne alıyorum?" sorusunu her teklif için aynı netlikle cevaplamanız gerekir.
Karşılaştırmadan Önce: Her Firmaya Aynı Brief'i Verin
Teklifler birbirinden çok farklı geliyorsa sorun çoğu zaman firmalarda değil, onlara verilen bilgidedir. Her firma eksik bilgiyi kendi varsayımıyla doldurur ve ortaya kıyaslanamayan teklifler çıkar.
Teklif istemeden önce şu başlıkları tek bir dokümanda toplayın:
- İş hedefi: Projenin hangi sorunu çözeceği ve başarının nasıl ölçüleceği.
- Kullanıcı rolleri: Sistemi kimlerin, hangi yetkilerle kullanacağı.
- Temel özellikler: "Olmazsa olmaz" ve "sonra eklenebilir" diye ayrılmış bir liste.
- Entegrasyonlar: ERP, muhasebe, ödeme, CRM gibi bağlanacak sistemler.
- Kısıtlar: Hedef tarih, bütçe aralığı, veri yerleşimi ve KVKK gereklilikleri.
- Mevcut durum: Varsa eski sistem, veri miktarı ve taşınması gereken kayıtlar.
Bu dokümanı hazırlamak zor geliyorsa teknik şartname hazırlama rehberimiz iyi bir başlangıç noktasıdır. Detaylı bir şartname, tekliflerin aynı varsayımlarla gelmesini sağlayan en etkili araçtır. Şartname hazır değilse bile, firmalardan aynı keşif sorularını aynı sırayla sormaları için eşit zaman tanıyın.
Bir Teklifte Mutlaka Bakmanız Gereken 8 Kriter
Sağlam bir teklif en azından aşağıdaki başlıkların hepsine cevap verir. Eksik başlıklar, firmanın o konuyu henüz düşünmediğini ya da sonraya bıraktığını gösterir.
| Kriter | Neye bakmalısınız? | Dikkat çeken işaret |
|---|---|---|
| Kapsam tanımı | Modüller, ekranlar, roller ve entegrasyonların tek tek yazılması | "Gerekli tüm özellikler" gibi muğlak ifadeler |
| Kapsam dışı maddeler | Neyin dahil olmadığının açıkça belirtilmesi | Bu bölümün hiç olmaması |
| Teknik yaklaşım | Mimari, teknoloji seçimleri ve gerekçeleri | Gerekçesiz, her projeye aynı çözümün önerilmesi |
| Takvim ve aşamalar | Aşama bazlı teslimler, onay noktaları ve bağımlılıklar | Tek bir "bitiş tarihi" verilip aradaki sürecin anlatılmaması |
| Ekip yapısı | Rol dağılımı, kıdem seviyesi, proje yöneticisinin varlığı | Kimin çalışacağının belirsiz olması |
| Test ve kalite | Test türleri, kabul kriterleri, hata düzeltme yaklaşımı | Testin ayrı bir kalem olarak geçmemesi |
| Güvenlik ve veri | Yetkilendirme, yedekleme, KVKK uyumu, güvenlik testleri | Güvenliğe tek cümleyle değinilmesi |
| Teslim sonrası | Garanti süresi, bakım ve destek kapsamı, dokümantasyon | Canlıya çıkışın "proje sonu" sayılması |
Tabloyu her teklif için ayrı ayrı doldurduğunuzda, fiyat farklarının nereden geldiği kendiliğinden ortaya çıkar. Çoğu zaman en ucuz teklifin tam da test, güvenlik ve teslim sonrası satırlarında boş olduğunu görürsünüz.
Fiyatlandırma Modellerini Doğru Okuyun
Teklifleri karşılaştırırken yalnızca tutarı değil, tutarın hangi modele dayandığını da değerlendirmeniz gerekir. Aynı proje için bile farklı modeller farklı riskleri size ya da firmaya yükler.
| Model | Nasıl çalışır? | Size uygun olduğu durum | Risk |
|---|---|---|---|
| Sabit kapsam, sabit bedel | Tanımlı iş için önceden belirlenen toplam bedel | Kapsamın net ve değişme ihtimalinin düşük olduğu projeler | Değişiklik talepleri ek bedele döner, kalite kısılabilir |
| Zaman ve materyal | Harcanan efora göre ödeme | Kapsamın keşfederek şekillendiği projeler | Bütçe kontrolü için düzenli raporlama gerekir |
| Adanmış ekip | Belirli sürede size ayrılmış ekip | Uzun soluklu ürün geliştirme | Önceliklendirmeyi sizin iyi yönetmeniz gerekir |
| Aşamalı sabit bedel | Keşif ve MVP ayrı, sonraki fazlar ayrı fiyatlanır | Belirsizliğin yüksek olduğu yeni ürünler | Fazlar arası geçişte netlik gerekir |
Hangi modelin sizin için uygun olduğunu proje belirsizliği belirler. Fikri henüz olgunlaşmamış bir ürün için sabit bedel çoğu zaman yanıltıcı bir güvence sunar; bu durumda MVP ile başlayan aşamalı bir yaklaşım riski küçültür. Çalışma modelleri ve sözleşme tarafına dair daha ayrıntılı bilgi için özel yazılım projesi yönetimi yazımıza göz atabilirsiniz.
Fiyatı Etkileyen Faktörleri Anlayın
İki teklif arasındaki fark çoğu zaman keyfi değildir; belirli faktörlerden doğar. Bunları bildiğinizde "neden bu kadar fark var?" sorusunu firmalara somut biçimde yöneltebilirsiniz.
- Kapsamın genişliği ve derinliği: Modül sayısı kadar, her modüldeki iş kuralı karmaşıklığı da maliyeti belirler.
- Entegrasyon sayısı: Üçüncü taraf sistemlerin API kalitesi, belgelendirmesi ve test ortamı sunup sunmaması emeği değiştirir.
- Tasarım seviyesi: Hazır bileşenlerle ilerleyen arayüz ile kullanıcı araştırmasına dayanan özgün tasarım aynı kalemde değildir.
- Ekip kıdemi: Kıdemli mühendislik, hata maliyetini sonradan düşürür ama saatlik emeği yükseltir.
- Güvenlik ve performans gereksinimleri: Yoğun kullanıcı yükü veya hassas veri, ek mimari ve test emeği gerektirir.
- Veri taşıma: Eski sistemden temiz olmayan verinin aktarılması çoğu zaman beklenenden fazla zaman alır.
- Teslim sonrası destek seviyesi: Yanıt süreleri ve çalışma saatleri taahhüdü fiyata yansır.
Bu kalemlerin hangisinde fark olduğunu görmek, ucuz teklifin nerede tasarruf ettiğini de gösterir. Bazen bu tasarruf makul bir sadeleştirmedir; bazen de sonradan ödeyeceğiniz bir borçtur.
Teklif Aşamasında Görülen Kırmızı Bayraklar
Her riskli teklif düşük fiyatlı olmaz. Aşağıdaki işaretler fiyattan bağımsız olarak dikkat gerektirir:
- Sizin işinizi dinlemeden, ilk görüşmede kesin fiyat ve süre verilmesi.
- Teklifin sizin sektörünüze ve sürecinize değil, genel bir şablona benzemesi.
- Her soruya "yaparız" cevabı verilmesi; risk, kısıt ve alternatiflerden hiç bahsedilmemesi.
- Kaynak kodun, tasarım dosyalarının ve alan adı ya da sunucu hesaplarının mülkiyetinin belirsiz bırakılması.
- Ödeme planının, teslim edilen çıktıdan bağımsız biçimde büyük bir peşinata dayanması.
- Proje yöneticisi veya tek bir sorumlu iletişim noktası tanımlanmamış olması.
- Değişiklik yönetiminin nasıl yapılacağına dair tek satırın bile bulunmaması.
Son madde özellikle önemlidir. Projelerin en sık sapma sebebi kapsamın kontrolsüz büyümesidir; bunun nasıl önleneceğini kapsam kayması rehberimizde ayrıntılı anlattık. Teklifte değişiklik talebi süreci tarif edilmişse, firma bu riski tanıyor demektir.
Adım Adım Puanlama: Kararı Veriye Bağlayın
Tablolar farkı gösterir ama karar için ağırlıklı bir puanlama pratik bir araçtır. Şu yöntemi kullanabilirsiniz:
- Kriterleri belirleyin. Örneğin kapsam ve iş anlayışı, teknik yaklaşım, ekip ve iletişim, fiyat ve ödeme planı, sözleşme ve teslim sonrası destek.
- Ağırlık verin. Toplamı 100 olacak şekilde, projenizin önceliğine göre dağıtın. Kritik bir sistemde teknik yaklaşım ve destek ağırlığı, tek seferlik basit bir projeye göre yüksek olmalıdır.
- Her teklife 1–5 arası puan verin. Puanı verirken teklifteki yazılı kanıta dayanın; sunumdaki izlenime değil.
- Puanı ağırlıkla çarpıp toplayın. Çıkan sonuç, sezgisel tercihinizi test etmenizi sağlar.
- Karar ekibiyle ortak değerlendirin. IT, finans ve işin sahibi aynı tabloyu bağımsız doldurduğunda sapmalar tartışmaya değer noktaları gösterir.
Örnek bir senaryo: Bir dağıtım şirketi bayi sipariş portalı için üç teklif alıyor. Fiyat ağırlığı yüksek tutulduğunda en ucuz teklif öne çıkıyor. Kapsam dışı maddeler, test ve teslim sonrası destek satırları ayrı puanlandığında ise aynı teklif gerilere düşüyor. Karar, tablo sayesinde fiyat yerine toplam değer üzerinden veriliyor. Bu örnek varsayımsaldır, ancak pratikte sık karşılaşılan bir tablodur.
Teklif Sonrası Görüşme: Sorulacak Sorular
Yazılı teklif tek başına yeterli değildir. Kısa listeye kalan iki ya da üç firmayla yapacağınız görüşme, firmanın çalışma kültürünü gösterir. Şu soruları sorun:
- Bu projede en büyük üç riski nasıl görüyorsunuz ve nasıl yönetirsiniz?
- Benzer bir projede karşılaştığınız zorluk neydi ve nasıl çözdünüz?
- Kapsam değiştiğinde süreç nasıl işliyor, kim onay veriyor?
- Haftalık ilerlemeyi bana nasıl göstereceksiniz?
- Proje sırasında ekipten biri ayrılırsa bilgi devri nasıl sağlanıyor?
- Teslimde hangi dokümanları, erişimleri ve kaynak kodu alacağım?
Cevapların somutluğu, teklifteki cümlelerden daha fazla şey söyler. Müşteri referansı istemekten de çekinmeyin; ancak referansla konuşurken yalnızca memnuniyeti değil, teslim tarihine uyumu, sorun anındaki tavrı ve teslim sonrası desteği sorun.
Sözleşmeden Önce Son Kontrol Listesi
Seçiminizi yaptıktan sonra imzadan önce şu maddeleri teyit edin:
- Teklifin kapsamı ve kapsam dışı maddeleri sözleşme ekinde yer alıyor mu?
- Aşamalı teslimler ve her aşamanın kabul kriterleri yazılı mı?
- Ödemeler takvime değil, onaylanan teslimlere bağlanmış mı?
- Kaynak kod, tasarım ve veri mülkiyeti açıkça size devrediliyor mu?
- Gizlilik ve KVKK yükümlülükleri tanımlı mı?
- Garanti süresi, hata düzeltme kapsamı ve destek yanıt süreleri belirli mi?
- Sözleşmeden çıkış ve devir teslim koşulları tarif edilmiş mi?
Bu liste, olası anlaşmazlıkların büyük bölümünü projenin başında çözer. Bir madde belirsizse bunu sorun olarak değil, görüşülmesi gereken bir başlık olarak ele alın; iyi bir firma bu netliği memnuniyetle sağlar.
Sık Sorulan Sorular
Kaç firmadan teklif almak yeterlidir?
Genellikle üç teklif, kıyas yapmak için yeterli çeşitliliği sağlar. Daha fazlası değerlendirme yükünü artırır ve ek bilgi katmayabilir. Önemli olan sayıdan çok, her firmaya aynı brief'i verip aynı koşullarda teklif istemenizdir.
En ucuz teklifi seçmek neden riskli olabilir?
Düşük fiyat, kapsamın dar tutulduğunu veya test, yönetim ve destek emeğinin hesaba katılmadığını gösterebilir. Bu eksikler genellikle proje ilerledikçe ek maliyet ve gecikme olarak geri döner. Fiyatı tek başına değil, kapsamla birlikte değerlendirin.
Teklif almak için teknik şartname şart mı?
Zorunlu değildir ama tekliflerin kıyaslanabilir olmasını büyük ölçüde kolaylaştırır. Şartname yoksa en azından iş hedefini, temel özellikleri ve entegrasyonları içeren bir brief hazırlayın. Firmalar bu sayede aynı varsayımlarla çalışır.
Sabit fiyat mı, zaman ve materyal modeli mi daha doğru?
Kapsamı net, değişme ihtimali düşük projelerde sabit bedel öngörülebilirlik sağlar. Keşfederek şekillenen ürünlerde zaman ve materyal ya da aşamalı model daha sağlıklıdır. Karar, bütçeden çok kapsamdaki belirsizlik düzeyine bağlıdır.
Teklif sürecinde firmaya hangi bilgileri vermeliyim?
İş hedefini, kullanıcı rollerini, öncelikli özellikleri, entegre olunacak sistemleri, takvim ve bütçe beklentisini paylaşın. Gizli bilgiler için önce bir gizlilik sözleşmesi imzalayabilirsiniz. Ne kadar net bilgi verirseniz teklifler o kadar gerçekçi olur.
Teklif sonrası kapsam değişirse ne olur?
Bu durum sözleşmedeki değişiklik yönetimi sürecine bağlıdır. Her değişiklik talebi etkisi analiz edilip yazılı onayla işleme alınmalıdır. Böylece bütçe ve takvim üzerindeki etki baştan görünür olur.
Sonuç: Teklifi Değil, Çalışma Biçimini Seçin
Doğru bir yazılım teklifi karşılaştırma süreci, her firmaya aynı brief'i vermekle başlar, ortak kriterlerle puanlamakla devam eder ve sözleşmede netliği sağlamakla biter. Fiyat önemlidir, ancak kapsam, teknik yaklaşım, iletişim ve teslim sonrası destek ile birlikte okunduğunda anlam kazanır. Yazılım firması seçimi, aslında önümüzdeki aylar boyunca birlikte nasıl çalışacağınıza dair bir karardır.
Elinizde değerlendirmek istediğiniz teklifler veya henüz netleşmemiş bir proje fikri varsa, biz CodeStup olarak kapsam analizinden teknik yaklaşıma kadar sürece birlikte bakabiliriz. Özel yazılım geliştirme hizmetimizi inceleyebilir ya da ihtiyacınızı anlatmak için bizimle iletişime geçebilirsiniz.
