Yazılım Firması Seçerken Dikkat Edilmesi Gereken 12 Nokta

İşletmeniz için bir yönetim paneli, müşteri portalı ya da mobil uygulama yaptıracaksanız vereceğiniz en önemli karar, hangi yazılım firması ile çalışacağınızdır. Doğru ekip belirsiz bir fikri çalışan bir ürüne dönüştürür; yanlış ekip ise aylarca süren gecikmelere, bitmeyen revizyonlara ve kimsenin sahiplenmediği bir koda yol açar. Bu yazıda teklif toplamadan önce bakmanız gereken 12 kriteri, görüşmede sormanız gereken soruları ve uzak durmanız gereken işaretleri sıraladık.

Önce kendi ihtiyacınızı netleştirin

Firmaları değerlendirmeden önce birkaç soruya kendi cevabınızı yazın: Yazılım hangi sorunu çözecek? Kimler kullanacak? Hangi mevcut sistemlerle (muhasebe, ERP, e-ticaret, kargo) konuşması gerekiyor? Bütçe ve zaman sınırınız ne? Bu cevaplar hem teklifleri karşılaştırılabilir kılar hem de firmaların sizi doğru anlamasını sağlar. Görüştüğünüz her yazılım firması aynı bilgiyle teklif hazırlarsa, fiyat farklarının nereden geldiğini de kolayca görürsünüz. Hazır bir yazılımın işinizi görüp görmeyeceğinden emin değilseniz hazır yazılım mı, özel yazılım mı? yazımız karar vermenize yardımcı olur.

Bir yazılım firmasını değerlendirmenin 12 kriteri

1. Benzer projelerde deneyim

Portföydeki ekran görüntüleri yeterli değildir. Canlıda çalışan ürünleri görmek, mümkünse o projelerin sahipleriyle konuşmak isteyin. Sizin sektörünüzde ya da benzer karmaşıklıkta bir proje yapmış olmaları, sürprizlerin önceden görülmesini sağlar.

2. Keşif süreci ve soru kalitesi

İlk görüşmede hemen fiyat veren bir firma, projenizi anlamadan tahmin yürütüyor demektir. İyi ekipler kullanıcıları, iş akışlarını, istisnaları ve entegrasyonları sorar; gerekirse ücretli ya da ücretsiz kısa bir keşif çalışması önerir. Bu süreç, gereksinim analizi belgesinin temelini oluşturur.

3. Yazılı kapsam ve kabul kriterleri

Teklifte “yönetim paneli yapılacak” gibi genel ifadeler yerine hangi ekranların, hangi rollerin ve hangi işlevlerin olacağı yazılmalıdır. Her özelliğin “tamamlandı” sayılması için hangi koşulu sağlaması gerektiği (kabul kriteri) belli değilse, proje sonunda anlaşmazlık çıkması neredeyse kesindir.

4. Projede kimin çalışacağı

Satış görüşmesine gelen kişiyle kodu yazan kişi aynı olmayabilir. Projede hangi rollerin (proje yöneticisi, tasarımcı, yazılımcı, test uzmanı) olacağını, işin bir kısmının dışarıya verilip verilmeyeceğini sorun. Muhatabınızın doğrudan işi yapan kişiler olması iletişimi hızlandırır.

5. Teknoloji seçiminin gerekçesi

Firmanın önerdiği programlama dili ya da çatı, yalnızca “biz bunu biliyoruz” gerekçesine dayanmamalı. Sistemin ölçeklenmesi, bakımı, işe alınabilecek geliştirici havuzu ve lisans maliyetleri açısından neden uygun olduğunu açıklayabilmeleri gerekir.

6. İletişim ritmi ve düzenli demo

Aylarca haber alamadığınız bir proje, sonunda beklediğiniz şey çıkmayabilir. İki haftalık döngülerle çalışan ve her döngü sonunda çalışan sürümü gösteren ekiplerle sorunlar erken yakalanır. Haftalık kısa bir durum raporu da yeterlidir; önemli olan düzenli olmasıdır.

7. Kaynak kod ve fikri mülkiyet

Ödemesini yaptığınız yazılımın kaynak kodu, veritabanı ve sunucu erişimleri size ait olmalıdır. Sözleşmede kaynak kodun hangi aşamada teslim edileceği, kullanılan üçüncü parti kütüphanelerin lisansları ve fikri mülkiyet hakları açıkça yazılmalıdır. Aksi hâlde ileride başka bir ekiple çalışmak isterseniz sıfırdan başlamak zorunda kalabilirsiniz.

8. Test ve kalite güvence

Kimin, neyi, nasıl test ettiğini sorun. Otomatik testler, ayrı bir test ortamı ve yayından önce sizin onayınıza sunulan bir kabul süreci, canlıda çıkacak hataları büyük ölçüde azaltır.

9. Güvenlik ve KVKK

Müşteri, çalışan ya da ödeme verisi işleyen her yazılım, kişisel verilerin korunmasına dair yükümlülükler taşır. Firmanın OWASP Top 10 gibi yaygın güvenlik risklerine nasıl önlem aldığını, yetkilendirmeyi nasıl kurguladığını ve KVKK kapsamındaki gereklilikleri nasıl ele aldığını dinleyin.

10. Dokümantasyon ve devir

Kurulum adımları, mimari özet, API belgeleri ve yönetici kılavuzu olmadan teslim edilen bir yazılım, ilk ekip ayrıldığında bakımı zor bir sisteme dönüşür. Dokümantasyonun teslim kapsamında olduğundan emin olun.

11. Yayın sonrası destek

Yazılım canlıya çıktığında iş bitmez; hatalar, işletim sistemi ve kütüphane güncellemeleri, küçük iyileştirmeler devam eder. Destek süresini, müdahale sürelerini (SLA) ve bakım ücretini baştan konuşun.

12. Şeffaf fiyatlandırma

Fiyatın hangi kalemlerden oluştuğunu, ödemelerin hangi teslimlere bağlı olduğunu ve kapsam değişikliklerinin nasıl fiyatlandırılacağını bilmeniz gerekir. Maliyetin nasıl oluştuğunu özel yazılım fiyatları yazımızda ayrıntılı anlattık.

Sabit fiyat mı, zaman ve malzeme mi?

Yazılım projeleri genellikle iki modelle fiyatlandırılır. Sabit fiyat modelinde kapsam baştan belirlenir ve bütçe değişmez; kapsamı net projeler için uygundur. Zaman ve malzeme modelinde harcanan emeğe göre ödeme yapılır; ürünün kullanıcı geri bildirimleriyle şekilleneceği projelerde daha esnektir. Pek çok proje ilk sürümü sabit fiyatla, sonraki geliştirmeleri ise aylık bir çerçeve bütçeyle yürütür.

Uzak durmanız gereken işaretler

Aşağıdaki durumlardan biriyle karşılaşırsanız o yazılım firması ile sözleşme imzalamadan önce iki kez düşünün:

• İhtiyacınızı dinlemeden, ilk görüşmede kesin fiyat ve süre veren teklifler.
• “Her şeyi yaparız” yaklaşımı; hangi işte uzman olduğunu söyleyemeyen ekipler.
• Kaynak kodu teslim etmeyen ya da sunucu erişimini kendinde tutmak isteyen sözleşmeler.
• Canlıda gösterilemeyen referanslar ve konuşulamayan eski müşteriler.
• Ödemenin büyük kısmını işin başında isteyen, teslimlere bağlamayan ödeme planları.
• Test, güvenlik ve bakım konularını geçiştiren cevaplar.

Görüşmede sorabileceğiniz 8 soru

1. Bize benzer hangi projeyi yaptınız, canlıda görebilir miyiz?
2. Teklifinizi hangi varsayımlara dayanarak hazırladınız?
3. Projede kimler çalışacak, işin bir kısmı dışarıya verilecek mi?
4. Çalışan sürümü ne sıklıkla göreceğiz?
5. Kaynak kod, veritabanı ve sunucu erişimleri ne zaman bize teslim edilecek?
6. Kapsam değişikliklerini nasıl yönetiyorsunuz?
7. Yayından sonra bir hata çıkarsa ne kadar sürede müdahale ediyorsunuz?
8. İlk sürümü küçültmek için ne önerirsiniz?

Son soru özellikle önemlidir. İyi bir ekip, bütün özellikleri tek seferde yapmak yerine işe yarayan en küçük sürümle başlamayı önerir; bu yaklaşımı MVP nedir? yazımızda anlattık.

Alpa Yazılım ile nasıl çalışıyoruz?

Alpa Yazılım, küçük ve kıdemli bir ekiple çalışan bir yazılım firması; her projede muhatabınız doğrudan işi yapan kişilerdir. Teklif vermeden önce ihtiyacı dinliyor, yazılı kapsam ve kabul kriterleri hazırlıyoruz. İki haftalık döngülerle çalışıyor, her döngüde çalışan sürümü paylaşıyoruz. Kaynak kod ve tüm erişimler size aittir. Özel yazılım hizmetimizin ayrıntıları özel yazılım sayfamızda, tamamlanan işlerden örnekler projeler sayfamızda. Projenizi konuşmak isterseniz bize yazın.