Yazılım projesinde doğru teklif nasıl alınır?

Bir yazılım projesi için teklif almak, bir inşaat işine fiyat almaya benzemez. İnşaatta metrekare ve malzeme bellidir; yazılımda ise en pahalı belirsizlik, projenin başında henüz tam olarak ne istediğinizi bilmemenizdir. İki farklı firmadan gelen çok farklı iki rakam, çoğu zaman firmaların birinin ucuz diğerinin pahalı olmasından değil, ikisinin projeyi tamamen farklı anlamış olmasından kaynaklanır. Doğru teklif almanın sırrı pazarlıkta değil, teklifi istemeden önce doğru soruları sormaktadır.

Otuz yıldır yazılım geliştiren bir ekip olarak, hem teklif veren hem de projeleri devralan taraf olarak sayısız kez şahit olduğumuz bir şeyi paylaşacağız: iyi biten projeler, teklif aşamasında kapsamı netleştirilmiş projelerdir. Bu yazıda kapsam belirsizliğinden korunmak için teklif öncesi ve sırasında sormanız gereken 12 soruyu, ardından gelen teklifleri karşılaştırırken dikkat etmeniz gereken kırmızı bayrakları anlatacağız.

Neden teklif öncesi hazırlık her şeyi belirler?

Kapsam belirsizken alınan teklif bir tahminden ibarettir; proje ilerledikçe "bu da dahil değil miydi?" cümlesiyle sürekli büyür. Bu, hem bütçenizin hem de firmayla ilişkinizin en sık kırıldığı noktadır. Oysa aynı soruları en baştan sorup cevapları yazıya dökerseniz, teklif bir tahmin olmaktan çıkıp bir sözleşmeye dönüşür. Aşağıdaki sorular, teklif isterken elinizdeki en güçlü araç.

Bir yazılım teklifinde asıl önemli olan rakamın büyüklüğü değil, o rakamın neyi kapsadığının netliğidir. Ucuz ama belirsiz bir teklif, çoğu zaman en pahalı seçenektir.

Sabit fiyat mı, zaman ve malzeme mi?

Sorulacak soruların en can alıcısı fiyat modeliyle ilgili, çünkü model riskin hangi tarafta duracağını belirler. Sabit fiyatta risk büyük ölçüde firmadadır: kapsam baştan net değilse firma kendini korumak için ya fiyatı yukarı çeker ya da kapsamı katı tutar. Bu model, ne istediğinizi çok iyi bildiğiniz, kapsamın değişme ihtimalinin düşük olduğu projelerde işe yarar; net bir teslimatı öngörülebilir bir bütçeyle almak istersiniz.

Zaman ve malzeme modelinde ise risk size geçer, ama esneklik de sizinle kalır. Kapsamın yol boyunca netleşeceği, keşif gerektiren projelerde bu model daha dürüsttür; harcanan gerçek emeğe göre ödersiniz ve önceliği yolda değiştirebilirsiniz. Tehlikesi, denetimsiz bırakıldığında bütçenin sürüklenmesidir. Bunu bir üst sınır ve düzenli ilerleme raporlarıyla dengelemek gerekir.

Pratikte çoğu sağlıklı proje ikisinin karışımıyla ilerler: keşif ve tasarım aşaması zaman-malzeme, kapsamı netleşmiş geliştirme aşaması sabit fiyat. Hangi modeli seçerseniz seçin, kritik olan modelin bilinçli seçilmesi ve sözleşmede net yazması. "Nasıl olsa hallederiz" diye başlayan projelerin çoğu, fiyat modeli konuşulmadığı için sürtüşmeyle biter.

Teklif öncesi sormanız gereken 12 soru

• 1. Kapsam yazılı mı? Neyin dahil, neyin hariç olduğu tek tek listelenmiş mi? "Hariç olanlar" listesi çoğu zaman "dahil olanlar" listesinden daha değerlidir.
• 2. Fiyat modeli ne? Sabit fiyat mı, zaman ve malzeme esaslı mı, yoksa karma mı? Her modelin riski farklı tarafa biner; hangisinin sizi koruduğunu bilin.
• 3. Tam olarak ne teslim edilecek? Çalışan yazılımın yanında kaynak kodu, teknik dokümantasyon, tasarım dosyaları ve kurulum talimatları da veriliyor mu?
• 4. Kod ve fikri mülkiyet kime ait? Proje bittiğinde kodun sahibi siz mi oluyorsunuz, yoksa yalnızca kullanım hakkı mı alıyorsunuz? Bu, ileride başka bir firmayla çalışmanızı belirler.
• 5. Zaman çizelgesi ve kilometre taşları neler? Tek bir bitiş tarihi yerine, ara teslimler ve her aşamada göreceğiniz somut çıktılar tanımlı mı?
• 6. Değişiklik talepleri nasıl yönetiliyor? Kapsam dışı bir istek çıktığında süreç ne? Değişikliklerin nasıl fiyatlandırıldığı baştan belli mi?
• 7. Projede kim çalışacak? İşi yapacak ekibin deneyimi ne? Taşeron kullanılıyor mu, yoksa iş firmanın kendi ekibinde mi kalıyor?
• 8. Test ve kalite süreci nasıl işliyor? Kabul kriterlerini kim belirliyor, teslimi neye göre "tamam" sayacaksınız? Otomatik test var mı?
• 9. Yayına alma ve devir nasıl olacak? Sunucu, alan adı ve altyapı kimin adına? Yayın sonrası sistemi siz mi yönetiyorsunuz, firma mı?
• 10. Yayın sonrası destek ve garanti kapsamı ne? Teslimden sonra çıkan hatalar ücretsiz düzeltiliyor mu, bakım anlaşması ayrı mı? Süresi ne kadar?
• 11. Benzer bir işi daha önce yaptınız mı? Gösterilebilir bir örnek veya konuşabileceğiniz bir referans var mı? Anlatılan değil, görülen deneyim önemlidir.
• 12. Proje yarıda kalırsa ne olur? Bir anlaşmazlık veya vazgeçme durumunda kod, veri ve erişimlerin devri nasıl işliyor? Çıkış planı, en çok ihtiyaç duyduğunuz anda hazır olmalı.

Teklifleri karşılaştırırken kırmızı bayraklar

Cevapları aldıktan sonra teklifleri yan yana koyduğunuzda bazı işaretler sizi durdurmalı. Bunlar firmanın kötü olduğunu değil, ilişkinin ileride sürtüşeceğini gösteren erken uyarılardır:

• Tek satırlık toplam fiyat: Kalemlere ayrılmamış bir rakam, kapsamın da düşünülmediğinin işaretidir. Detaysız teklif, detaysız iş demektir.
• Belirgin şekilde düşük fiyat: Diğerlerinin çok altındaki bir teklif genelde kapsamın eksik anlaşıldığını gösterir; fark, proje ortasında ek maliyet olarak geri döner.
• Soruları savuşturmak: Yukarıdaki sorulara net cevap vermek yerine "merak etmeyin, hallederiz" diyen bir taraf, sözleşme aşamasında da aynı belirsizliği sürdürür.
• Devir ve mülkiyet konusunda muğlaklık: Kodun ve verinin size ait olup olmadığı netleşmiyorsa, en baştan uzak durmak en güvenlisidir.

Sonuç

Doğru teklif, en düşük rakamı veren değil, ne aldığınızı en net gösteren tekliftir. Bu netliği yaratan da satıcı değil, sizin sorduğunuz sorulardır. Yukarıdaki 12 soruyu teklif isterken bir kontrol listesi gibi kullanın; cevapları yazıya döktürün ve gelen teklifleri bu cevaplar üzerinden karşılaştırın. Böylece kapsam belirsizliği, projenin ortasında sürpriz bir fatura olarak değil, en başta çözülmüş bir mesele olarak karşınıza çıkar. İyi bir teklif süreci, iyi bir projenin ilk provasıdır.