Yazılım Projesi Yaptırmak: Teklif, Sözleşme ve Firma Seçimi Rehberi

Elinizde üç teklif var. Biri sekiz sayfa, biri tek sayfa, birinde sadece toplam rakam yazıyor. Aradaki fark üç kat. Üçü de aynı işi yaptığını söylüyor. Bu noktada verilen karar çoğunlukla iki şeye dayanıyor: rakama ve görüşmede kurulan güvene. İkisi de kötü kriter değil, ama tek başlarına yetersiz; çünkü rakam kapsamı göstermiyor, güven ise teslim sonrasını garanti etmiyor.

Bu yazı, yazılım projesi yaptıracak tarafın rehberi. Teklif istemeden önce ne hazırlamanız gerektiğini, teklifleri neye göre karşılaştıracağınızı, hangi fiyatlandırma modelinin hangi işe uyduğunu, sözleşmede hangi maddelerin bulunması gerektiğini ve teslim anında neyi kontrol etmeniz gerektiğini anlatıyor. Baştan sona alıcı tarafında duruyoruz; geliştirici tarafının nasıl çalıştığını değil, sizin neyi sormanız gerektiğini yazıyoruz.

Yazılım projesi süreci: alıcı tarafında neler oluyor

Yazılım projesi süreci denince çoğu içerik geliştirme aşamalarını anlatıyor. Oysa yaptıran taraf için süreç, kod yazılmaya başlamadan çok önce başlıyor ve teslimden sonra da devam ediyor. Alıcı tarafında sürecin iskeleti şudur:

1. İhtiyaç özeti. Çözülecek problemin, mevcut durumun ve kısıtların yazıya dökülmesi. Bu belge olmadan alınan teklifler kıyaslanamaz.
2. Kısa liste. Aynı belgeyi üç dört firmaya göndermek. Onun altına inince kıyas kaybolur, üstüne çıkınca değerlendirme yönetilemez hâle gelir.
3. Teklif ve kapsam görüşmesi. Rakamdan önce kapsamın, varsayımların ve kapsam dışının konuşulduğu aşama.
4. Sözleşme. Kapsam eki, kabul kriterleri, ödeme planı, fikri mülkiyet ve destek koşulları.
5. Yürütme. Düzenli demolar, yazılı değişiklik yönetimi ve aşamaya bağlı ödemeler.
6. Kabul. Kendi verinizle, kendi ekibinizle yapılan gerçek senaryo testi.
7. Devir ve bakım. Kod, veri, dokümantasyon ve erişimlerin teslimi; ardından bakım anlaşmasının yürürlüğe girmesi.

Bu yedi adımın hangisinde nelere dikkat edileceğini aşağıda tek tek açıyoruz. Geliştirme tarafında sürecin nasıl işlediğini, yani analiz, mimari, geliştirme ve devreye alma aşamalarını ise özel yazılım rehberinde ayrıca anlattık.

Yazılım teklifi alma: istemeden önce hazırlanması gereken tek belge

Teklifleri karşılaştırılamaz hâle getiren en büyük sebep, herkese farklı bir iş anlatılmış olmasıdır. Aynı toplantıyı üç firmayla ayrı ayrı yaptığınızda üçü de farklı şeyler duyar, farklı varsayımlar yapar ve doğal olarak farklı fiyat verir. Çözüm karmaşık değil: iki üç sayfalık, herkese aynı gönderilen bir ihtiyaç özeti hazırlamak.

Bu belgede bulunması gerekenler:

• Çözülecek problem, çözümün adı değil. "Bize bir CRM lazım" yerine "saha ekibinin ziyaret raporları WhatsApp'tan geliyor, kimse geçmişi göremiyor" yazın.
• Bugün nasıl yapılıyor. Hangi araç, hangi dosya, hangi kişi. Mevcut durumu bilmeden verilen tahminler hep düşük çıkar.
• Kullanıcı rolleri ve tahmini kullanıcı sayısı. Beş kişilik iç araçla iki yüz bayinin gireceği portal aynı iş değildir.
• Entegre olunacak sistemler. Muhasebe programı, ERP, pazaryeri, kargo, e-fatura entegratörü. İsimleriyle yazın; entegrasyon maliyeti dokümantasyon kalitesine göre ciddi değişir.
• Olmazsa olmazlar ile olsa iyi olurlar ayrı listeler hâlinde. Bu ayrım yoksa her firma kendi ayrımını yapar ve fiyatlar kıyaslanamaz.
• Kısıtlar. Tarih baskısı, bütçe bandı, verinin nerede duracağı, mevcut altyapıda kalması gereken bileşenler.

Bütçe bandını yazmaktan çekinmeyin. "Söylersem o rakamı yazarlar" endişesi yaygın, ama bant vermemenin sonucu daha kötü: kapsamı bilmeyen firma ya çok yüksek verip elenir ya da düşük verip sonradan ek fatura çıkarır. Bant verirseniz iyi bir firma size o bandın içine ne sığdığını söyler.

Teklifleri karşılaştırılabilir hâle getirmek

İyi bir teklifte rakamdan önce şu kalemler bulunur. Karşılaştırma tablosunu bu kalemler üzerinden kurun, toplam rakam üzerinden değil.

Son kalem sık atlanıyor. Yazılımın kendisi teslim edilse bile sunucu, alan adı, sertifika, e-posta gönderim servisi, harita veya doğrulama servisi gibi kalemler aylık maliyet üretir. Teklifte bunların kime ait olduğu yazmıyorsa sorun.

Yazılım projesi fiyatlandırma modelleri: sabit fiyat mı, zaman-malzeme mi

İki model de meşru; yanlış olan işe uymayan modeli seçmek. Aradaki farkı riski kimin taşıdığı belirler.

Pratikte en dengeli üçüncü bir yol var: analiz ayrı, geliştirme ayrı sözleşme. Önce sınırlı bütçeli bir analiz işi yapılır, çıktısı ayrıntılı kapsam belgesi ve mimari kararlar olur. Bu belge sizindir; isterseniz geliştirmeyi başka bir firmaya yaptırabilirsiniz. Analizden sonra verilen sabit fiyat gerçeğe çok daha yakın olur, çünkü artık tahmin değil ölçüm vardır.

Yazılım firması seçimi: görüşmede sorulacak sorular

Yazılım firması seçimi, portföydeki işlerin güzelliğine bakarak yapılamaz; ekranların güzel olması o projede sözleşmenin nasıl işlediğini ya da teslimden bir yıl sonra kime ulaşılabildiğini göstermez. Aşağıdaki soruları aynı sırayla her firmaya sorun ve cevapları yan yana yazın; ayrım genelde teknik cevaplarda değil, süreç ve devamlılık cevaplarında ortaya çıkar.

Teknik taraf

• Bu projeyi hangi teknoloji ile geliştireceksiniz ve neden? Cevap "biz hep bununla yaparız" ise, o teknoloji sizin işinize uygun mu diye ayrıca düşünün.
• Kod hangi depoda duracak, benim erişimim ilk günden olacak mı?
• Test ortamı ile canlı ortam ayrı mı olacak?
• Yedekleme nasıl yapılacak, geri dönüş denemesi yapılıyor mu? Alınmayan yedek değil, geri yüklenemeyen yedek asıl sorundur.
• Kimlik doğrulama, yetkilendirme ve loglama nasıl kurgulanacak?

Süreç tarafı

• Ne sıklıkta çalışan sürüm göreceğim?
• Projede benim muhatabım kim, o kişi aynı anda kaç projeye bakıyor?
• Değişiklik talebi geldiğinde süreç nasıl işliyor, etkisini nasıl görüyorum?
• Bu projede alt yüklenici kullanılacak mı, kullanılacaksa hangi kısımda?

Devamlılık tarafı

• Projeyi yazan kişi ayrılırsa ne olur? Dokümantasyon ve kod okunabilirliği bu sorunun cevabıdır.
• Teslimden bir yıl sonra küçük bir değişiklik istesem nasıl bir süreç işler, saatlik ücret nedir?
• Sizinle çalışmayı bırakırsam devir nasıl olur? Kod, veri, altyapı erişimleri ve dokümanların teslim şekli.

Son soru en çok atlanan ve en çok pişmanlık üreten sorudur. Çıkışı konuşmadan girilen ilişkilerde, ayrılma anı hep gergin ve pahalı oluyor.

Kaynak kod mülkiyeti: yazılım kimin olacak

Türkiye'de yazılım, Fikir ve Sanat Eserleri Kanunu kapsamında ilim ve edebiyat eseri olarak korunur. Bu şu anlama gelir: eseri meydana getiren taraf hak sahibidir ve mali hakların devri için yazılı sözleşme aranır. Yani "parasını ben ödedim, kod benimdir" varsayımı, sözleşmede yazmıyorsa güvenli bir varsayım değildir.

Sözleşmede netleşmesi gereken üç ayrı senaryo var:

1. Tam devir. Proje için yazılan kodun mali hakları size devredilir. Genellikle daha yüksek fiyatlanır, çünkü geliştirici o kodu başka müşteride yeniden kullanamaz.
2. Kullanım lisansı. Kod geliştiricide kalır, siz süresiz ve devredilemez bir kullanım hakkı alırsınız. Ürünleşmiş çözümlerde yaygındır ve tek başına kötü değildir; ama abonelik bitince ne olacağını bilmeniz gerekir.
3. Karma. Geliştiricinin daha önce yazdığı ortak altyapı bileşenleri lisanslanır, size özel yazılan iş mantığı devredilir. En sık karşılaşılan ve çoğu durumda en makul olan modeldir.

Hangisi olursa olsun sözleşmede şunlar da bulunmalı: kullanılan açık kaynak kütüphanelerin lisans türleri, ticari lisans gerektiren bileşenlerin listesi ve bu lisansların kimin adına alındığı. Bir bileşenin lisansı geliştirici adına alınmışsa, ayrıldığınız gün o bileşen sizde çalışmaz.

Yazılım sözleşmesinde aranacak maddeler

• Kapsam eki. Sözleşme metnine ek olarak, teklifteki kapsam ve kapsam dışı listeleri ekte yer almalı ve sözleşmenin parçası sayılmalı.
• Kabul kriterleri ve kabul süresi. Neyin "çalışıyor" sayılacağı ve teslimden sonra kabul için kaç iş gününüz olduğu.
• Değişiklik yönetimi. Talep nasıl iletilir, etki analizi kaç günde verilir, onay kim tarafından verilir. Bu madde yoksa değişiklikler sözlü kalır ve fatura zamanında tartışma çıkar.
• Aşamalı ödeme. Ödemeler takvime değil teslim edilen çıktılara bağlanmalı. "İkinci ay sonunda" değil, "sipariş modülü kabul edildiğinde".
• Gecikme ve karşılıklı sorumluluk. Gecikme yaptırımı yazılacaksa, sizin kaynaklı gecikmelerin takvimi nasıl etkileyeceği de yazılmalı. Tek taraflı yazılmış gecikme maddeleri uygulamada işlemiyor.
• Fikri mülkiyet devri. Yukarıdaki üç senaryodan hangisi geçerliyse, devredilen hakların kapsamı ve süresiyle birlikte.
• Kaynak kod erişimi. İlk günden depoya okuma erişimi almak, teslim tartışmalarının çoğunu baştan bitirir.
• Gizlilik ve kişisel veri. Geliştirici sizin verilerinizi işleyecekse KVKK anlamında veri işleyen konumundadır; sorumlulukların yazılı olması gerekir. Verinin nerede tutulacağı ve yurt dışına aktarım olup olmayacağı da bu maddede yer almalı.
• Garanti. Teslimden sonra sözleşmeye aykırı çalışan durumların ücretsiz düzeltileceği süre.
• Destek seviyesi. Bakım anlaşması varsa yanıt süreleri ve kapsam; kapsam dışı işlerin saatlik ücreti.
• Devir ve fesih. İlişki bittiğinde kod, veri, dokümantasyon ve altyapı erişimlerinin hangi formatta ve kaç gün içinde teslim edileceği.

Teslim anında kontrol listesi

Kabul, ekranların gösterildiği toplantı değildir. Kabul testini kendi verinizle, kendi ekibinizle ve gerçek senaryolarla yapın. En az şunları deneyin:

1. En sık yapılan işlemi baştan sona, gerçek bir kayıtla tamamlayın.
2. Yetkisi olmayan bir kullanıcıyla, olmaması gereken ekrana ulaşmaya çalışın.
3. Hatalı veri girin: boş alan, çok uzun metin, geçersiz tarih, negatif tutar.
4. Entegrasyonun karşı tarafını kapatın ve sistemin ne yaptığını görün. Sessizce veri kaybediyor mu, yoksa uyarı mı veriyor?
5. Yedekten geri dönüş denemesi isteyin; bu denemeyi bir kez birlikte yapın.
6. Bir kullanıcıyı silin veya pasife alın; geçmiş kayıtlarının ne olduğunu kontrol edin.

Yaptıran taraf olarak sizin sorumluluklarınız

Yazılım projelerinin gecikme sebepleri incelendiğinde ortaya çıkan tablo çoğu kişiyi şaşırtıyor: gecikmelerin önemli kısmı geliştirme hızından değil, müşteri tarafındaki bekleyen kararlardan kaynaklanıyor. İyi bir teklifte bu kalemler "sizden beklenenler" başlığı altında yazılı olur; yazılı değilse siz sorun.

• Tek karar mercii. Projenin sizin tarafınızda tek bir sahibi olmalı. Kararların üç kişiden üç farklı yönde gelmesi, en hızlı ekibi bile durdurur.
• Geri bildirim süresi. Demolara ne kadar sürede yanıt vereceğinizi baştan taahhüt edin. Bir hafta geciken geri bildirim, o hafta üzerine kurulan işin de değişmesi demektir.
• Test kaynağı. Sistemi gerçekten kullanacak kişilerden en az biri test için zaman ayırmalı. Testi geliştiricinin yapması, kabulün anlamını ortadan kaldırır.
• İçerik ve veri. Ürün listeleri, görseller, metinler, eski sistem dökümleri. Bunların gecikmesi takvimi doğrudan öteler ve genelde en sık yaşanan gecikme sebebidir.
• Erişimler. Entegre olunacak sistemlerin test hesapları, API anahtarları ve gerekli izinler. Üçüncü taraf onayı gereken erişimlerde süre uzayabilir; bu işi projenin başında başlatın.
• İç iletişim. Sistemi kullanacak ekibin projeden haberdar olması. Teslim gününde varlığından haberdar olunan sistemler kullanılmıyor.

Bu maddeler yalnızca nezaket konusu değil; sabit fiyatlı sözleşmelerde geliştiricinin gecikme itirazının dayanağı da bunlar oluyor. Karşılıklı sorumlulukların yazılı olduğu projelerde gecikme tartışması çok daha az çıkıyor.

Kırmızı bayraklar

• Soru sormadan fiyat veren firma. Kapsamı anlamadan verilen rakam ya çok yüksektir ya da sonradan artacaktır.
• Her şeye "evet, o da olur" diyen firma. İyi bir muhatap, bazı taleplerin maliyetini ya da riskini baştan söyler.
• Kapsam dışı listesi olmayan teklif.
• Depoya erişim vermeyi reddetmek. Ticari gerekçe ileri sürülebilir, ama en azından teslimde tam kod aktarımı yazılı olmalı.
• Referans verilememesi. Gizlilik sebebiyle isim verilemeyebilir; ama benzer ölçekte bir işin nasıl yürüdüğünü anlatamamak farklı bir şeydir.
• Toplam süreyi çok kısa söylemek. Gerçekçi olmayan takvim, teslimde kalite düşüşü olarak geri gelir.

Biz teklifi nasıl veriyoruz

Bize gelen taleplerde ilk yaptığımız şey fiyat vermek değil, kapsamı yazıya dökmek oluyor. Görüşmeden sonra problem tanımını, çözüm önerisini, kapsam dışı bıraktıklarımızı ve varsayımlarımızı yazıp geri gönderiyoruz. Bu belge üzerinde anlaşılmadan rakam konuşmuyoruz; çünkü rakam üzerinde anlaşıp kapsam üzerinde anlaşmamak, projenin ortasında iki tarafı da zor durumda bırakıyor.

Kapsamı büyük işlerde analizi ayrı bir aşama olarak öneriyoruz ve analiz çıktısını koşulsuz size veriyoruz. Kişiye özel yazılım, entegrasyon ya da kurumsal web sitesi tarafında bir işiniz varsa, elinizdeki ihtiyaç özetiyle iletişim sayfasından yazabilirsiniz; ihtiyaç özetiniz yoksa ilk görüşmede birlikte çıkarıyoruz.