Özel yazılım için birden fazla firmadan teklif aldığınızda tabloda genellikle benzer ifadeler görürsünüz: kullanıcı paneli, raporlama, entegrasyon, mobil uyum ve destek. Buna rağmen fiyatlar ve teslim süreleri ciddi biçimde değişebilir. Farkı yaratan çoğu zaman özellik adları değil; bu özelliklerin hangi iş kurallarıyla, hangi kalite düzeyinde ve hangi sorumluluk paylaşımıyla geliştirileceğidir.
Bu nedenle yazılım firması seçimini yalnızca toplam bedel veya etkileyici bir sunum üzerinden yapmak risklidir. Doğru değerlendirme; firmanın probleminizi nasıl anladığını, belirsizlikleri nasıl yönettiğini, teslim edilecek varlıkları ve yayın sonrası sorumluluğu birlikte inceler. Aşağıdaki başlıklar, farklı teklifleri aynı zeminde karşılaştırmanıza yardım eder.
1. Firma çözüm anlatmadan önce doğru soruları soruyor mu?
Sağlıklı bir ilk görüşmede sadece istediğiniz ekranlar konuşulmaz. Firma mevcut süreci, kullanıcı rollerini, verinin nerede tutulduğunu, işlem hacmini, istisnaları ve başarı ölçütünü anlamaya çalışmalıdır. “Bir CRM istiyoruz” ifadesini olduğu gibi fiyatlandırmak yerine hangi satış probleminin çözüleceğini araştırması, firmanın ihtiyaç analizi yetkinliği hakkında iyi bir işarettir.
Henüz bilinmeyen noktalar varsa bunların varsayım olarak teklife yazılması gerekir. Her ayrıntı ilk toplantıda kesinleşmeyebilir; önemli olan belirsizliğin saklanmaması ve analiz, prototip ya da pilot gibi bir adımla azaltılmasıdır. Hiç soru sormadan kesin süre ve fiyat veren bir teklif, ileride kapsam tartışması çıkarma ihtimalini artırır.
- Bugün hangi iş akışı zaman, hata veya gelir kaybı yaratıyor?
- Sistemi kimler, hangi yetkilerle ve ne sıklıkta kullanacak?
- Mevcut veri hangi dosya veya sistemlerde tutuluyor?
- Hangi istisnalar, onaylar ve geri alma senaryoları var?
- İlk sürüm başarılı olduğunda hangi sonuç ölçülecek?
2. Teklifin kapsamı ve kapsam dışı maddeleri okunabilir mi?
İki teklifi karşılaştırabilmek için her birinin aynı teslimi tarif ettiğinden emin olun. “Yönetim paneli yapılacak” tek başına kapsam değildir. Paneldeki roller, temel ekranlar, onay akışları, raporlar, veri aktarımı, entegrasyonlar ve desteklenen cihazlar yazılı olmalıdır. Tasarım, içerik girişi, altyapı kurulumu, eğitim ve dokümantasyonun dahil olup olmadığı da açıkça belirtilmelidir.
Kapsam dışı maddeler de en az dahil olanlar kadar değerlidir. Lisansları, sunucu bedelini, SMS veya e-posta kullanım ücretini, üçüncü taraf API maliyetlerini ve eski verinin temizlenmesini kimin karşılayacağını sorun. Bu ayrıntılar yazılmadığında düşük görünen teklif, proje boyunca ek maliyetlerle diğerlerinin üzerine çıkabilir.
Karşılaştırılabilir bir yazılım teklifi, sadece neyin yapılacağını değil neyin henüz yapılmayacağını da gösterir.
3. Projede kimlerin çalışacağı ve iletişim düzeni belli mi?
Firmanın portföyü kadar sizin projenize ayrılacak ekibi de inceleyin. Analizi kim yapacak, teknik kararı kim verecek, tasarım ve test sorumluluğu kimde olacak, günlük iletişimde kiminle görüşeceksiniz? Satış toplantısındaki deneyimli ekip ile uygulamayı yapacak ekip birbirinden farklıysa beklenti kolayca bozulabilir.
İlerleme görünür olmalıdır. Kısa aralıklarla çalışan ekran gösterimi, yazılı karar kaydı ve erişilebilir iş listesi, sorunları teslim gününden önce ortaya çıkarır. Toplantı sıklığı, geri bildirim süresi, değişiklik talebinin nasıl fiyatlanacağı ve geciken müşteri onaylarının takvime etkisi proje başlamadan konuşulmalıdır.
Referansları yalnızca tasarım kalitesiyle değerlendirmeyin. Mümkünse kapsam ve entegrasyon karmaşıklığı size benzeyen bir proje sorun; projenin zamanında tamamlanıp tamamlanmadığını, canlı kullanımda sürüp sürmediğini ve yayın sonrası iletişimin nasıl ilerlediğini öğrenin. Gizlilik nedeniyle ayrıntı paylaşılamıyorsa firma benzer bir problemi hangi adımlarla çözdüğünü, hangi riskle karşılaştığını ve neyi farklı yapacağını isim vermeden anlatabilmelidir.
4. Kod, hesaplar ve veriler üzerindeki sahiplik size geçiyor mu?
Özel yazılım uzun ömürlü bir işletme varlığıdır. Kaynak kod deposunun, alan adının, bulut veya sunucu hesabının, veritabanının ve üçüncü taraf servis hesaplarının kimin adına açılacağını öğrenin. Erişimlerin teslim biçimi, fikrî haklar ve tekrar kullanılan hazır bileşenlerin lisansları sözleşmede anlaşılır olmalıdır.
Teknik tercihlerin isimlerinden çok sürdürülebilirliğini sorgulayın. Yedekleme nasıl yapılacak, erişimler nasıl sınırlandırılacak, işlem kayıtları tutulacak mı, bağımlılıklar nasıl güncellenecek ve başka bir ekip gerektiğinde projeyi devralabilecek mi? Temel kurulum, veri modeli, entegrasyon ve yayına alma bilgilerinin dokümante edilmesi, tek bir kişiye veya firmaya gereksiz bağımlılığı azaltır.
5. Test, kabul ve yayına geçiş planı somut mu?
“Testler yapılacak” ifadesinin altını doldurun. Kritik kullanıcı akışları, farklı yetki rolleri, hatalı veri, entegrasyon kesintisi ve performans gibi durumların nasıl doğrulanacağını sorun. Kullanıcı kabul testine işletmeden kimlerin katılacağı, bulguların nasıl sınıflandırılacağı ve hangi koşullarda teslim onayı verileceği önceden kararlaştırılmalıdır.
Yayına geçiş de tek bir tarih değildir. Eski verinin aktarılması, kullanıcıların tanımlanması, eğitim, canlı ortam ayarları, ilk gün izleme ve gerekirse geri dönüş planı birlikte ele alınmalıdır. Karmaşık projelerde sınırlı kullanıcıyla pilot yapmak, tüm operasyonu aynı anda yeni sisteme taşımaktan daha kontrollü bir yaklaşımdır.
6. Bakım, garanti ve yeni geliştirme birbirinden ayrılmış mı?
Yayın sonrası destek başlığını belirsiz bırakmayın. Teslim edilen kapsamdaki hataların hangi süre boyunca düzeltileceği, kritik sorunlarda hangi kanaldan iletişim kurulacağı ve beklenen ilk yanıt süresi yazılı olmalıdır. Sunucu izleme, yedek kontrolü, güvenlik ve bağımlılık güncellemeleri gibi rutin işlerin kimde olduğunu da netleştirin.
Hata düzeltme ile yeni özellik aynı şey değildir. Yeni rapor, değişen onay akışı veya yeni entegrasyon için nasıl talep açılacağını, tahmin ve onay sürecini sorun. Aylık sabit destek, kullanılan saat kadar ödeme veya ayrı proje modeli arasından işletmenizin değişim hızına uygun olanı seçin.
Karar toplantısında sorulacak 10 kritik soru
- Teklif hangi iş problemine ve hangi varsayımlara dayanıyor?
- İlk sürümde kesin olarak hangi akışlar teslim edilecek?
- Kapsam dışındaki işler ve harici maliyetler neler?
- Projede fiilen kimler, hangi sorumluluklarla çalışacak?
- İlerlemeyi ne sıklıkta ve hangi ortamda göreceğiz?
- Kapsam değişikliği takvimi ve bedeli nasıl etkileyecek?
- Kaynak kod, veri, sunucu ve servis hesapları kimin kontrolünde olacak?
- Test ve kabul hangi senaryolara ve ölçütlere dayanacak?
- Pilot, veri aktarımı ve canlıya geçiş nasıl yürütülecek?
- Hata, bakım ve yeni geliştirme talepleri nasıl ayrılacak?
Son kararı verirken her firmayı kapsam netliği, problem anlayışı, ekip, iletişim, teknik sahiplik, test ve destek başlıklarında ayrı ayrı puanlayın. Benzer bir referans proje faydalıdır; ancak sizin sürecinizi dinleme ve belirsizlikleri yönetme biçimi daha güçlü bir göstergedir. En doğru yazılım firması, en fazla özelliği vaat eden değil; neyi, neden ve hangi teslim koşullarıyla yapacağını en açık gösterebilen iş ortağıdır.