Yazılım Teklifini Değerlendirirken Sorulacak Sorular: Kapsam, Takvim ve Sorumluluklar

Yazılım teklifi değerlendirme süreci, yalnızca toplam bedeli karşılaştırmaktan ibaret değildir. Aynı ihtiyaca verilen iki teklif; kapsam tanımı, teslim edilecek çıktılar, proje takvimi, teknik yaklaşım ve tarafların sorumlulukları bakımından önemli ölçüde farklılaşabilir. Bu farklar başlangıçta görünür değilse proje başladıktan sonra ek iş talepleri, gecikmeler ve karar belirsizlikleri ortaya çıkabilir.

KOBİ ve kurumsal şirketlerde yazılım satın alma kararının sağlıklı verilmesi için teklif dokümanının iş hedefleriyle birlikte okunması gerekir. Bu makalede, teklifleri daha somut ve karşılaştırılabilir hâle getirmek için sorulabilecek soruları; kapsam, takvim, sorumluluklar, teknik teslimatlar ve ticari çerçeve üzerinden ele alıyoruz.

011. Kapsamı netleştirmek için hangi sorular sorulmalı?

Bir teklifin en önemli bölümü kapsam tanımıdır. “Web uygulaması geliştirilecektir” veya “mobil uygulama yapılacaktır” gibi genel ifadeler karar vermek için yeterli değildir. İşlevlerin, kullanıcı rollerinin ve entegrasyonların açıkça yazılması gerekir.

Teklif değerlendirme görüşmesinde şu soruları yöneltebilirsiniz:

• Hangi kullanıcı rolleri ve yetkiler sistemde yer alacak?
• Teklifte belirtilen her işlevin kabul ölçütü nedir?
• Hangi ekranlar, raporlar ve yönetim panelleri kapsam dâhilinde?
• Mevcut ERP, CRM, ödeme, kargo veya başka bir sistemle entegrasyon yapılacak mı?
• Mobil uygulama için iOS ve Android kapsamı nasıl ele alınacak?
• İçerik girişi, veri aktarımı ve başlangıç verilerinin hazırlanması kimin sorumluluğunda?
• Kapsam dışında kalan işler açıkça listelenmiş mi?

Örneğin bir e-ticaret projesinde “ödeme entegrasyonu” ifadesi; sanal POS bağlantısını, hata durumlarını, iade akışını, mutabakatı ve yönetim ekranını ayrı ayrı kapsamayabilir. Bu nedenle yalnızca özellik adını değil, iş akışını da sorgulamak gerekir.

Teklifte her ana işlev için beklenen çıktı, bağımlılık ve kabul koşulu yazılıysa karşılaştırma daha sağlıklı yapılır. Ayrıca kapsamın değişmesi hâlinde izlenecek yöntem de belirtilmelidir. Değişiklik talebinin nasıl değerlendirileceği, etkisinin nasıl hesaplanacağı ve onay sürecinin kim tarafından yürütüleceği baştan netleştirilmelidir.

022. Teslim takvimini değerlendirirken nelere bakılmalı?

Takvim, yalnızca başlangıç ve bitiş tarihinden oluşmaz. İyi tanımlanmış bir proje planında analiz, tasarım, geliştirme, test, kullanıcı kabulü ve canlıya geçiş gibi aşamalar görünür olmalıdır. Her aşamanın çıktısı ve müşteriden beklenen katkı da takvime dâhil edilmelidir.

Şu sorular takvimin uygulanabilirliğini anlamanıza yardımcı olur:

1. Proje kaç ana aşamaya ayrılıyor?
2. Her aşamanın başlangıç ve tamamlanma ölçütü nedir?
3. Tasarım veya prototip onayı gecikirse takvim nasıl güncellenecek?
4. Test ve kullanıcı kabulü için ne kadar zaman ayrılıyor?
5. Canlıya geçiş öncesinde veri aktarımı veya eğitim yapılacak mı?
6. İki haftalık sürümler gibi düzenli teslim noktaları bulunuyor mu?
7. Takvimde müşteri geri bildirimleri için yeterli karar süresi var mı?

Bir projenin yalnızca geliştirme süresine bakmak yanıltıcı olabilir. Kullanıcıların ekranları incelemesi, iş birimlerinin senaryoları test etmesi ve gerekli içerikleri hazırlaması da zaman alır. Bu nedenle teklifin, tedarikçinin çalışma süresi ile müşterinin karar ve onay sürelerini birlikte göstermesi önemlidir.

OPEIS çalışma sürecinde proje; keşif ve analiz, kapsam-planlama, tasarım ve prototip, geliştirme, test-devreye alma, destek ve sürekli iyileştirme adımlarıyla ele alınır. Teklifleri değerlendirirken benzer bir aşama mantığının bulunması, proje ilerlemesinin izlenmesini kolaylaştırır.

033. Sorumluluk paylaşımı nasıl yazılı hâle getirilmeli?

Yazılım projelerinde gecikmelerin önemli nedenlerinden biri, tarafların hangi işi üstlendiğinin açık olmamasıdır. Tedarikçinin geliştirme görevleri kadar müşterinin sağlayacağı erişimler, içerikler, kararlar ve test katkısı da teklif içinde yer almalıdır.

Sorumlulukları karşılaştırırken aşağıdaki başlıkları kontrol edin:

• Proje yöneticisi, teknik sorumlu ve karar verici kişiler kimler?
• Müşteri tarafında tek bir onay mercii belirlenecek mi?
• Sunucu, alan adı, mağaza hesabı, API anahtarı ve test verilerini kim sağlayacak?
• İş birimi senaryolarını ve kabul testlerini kim hazırlayacak?
• Geri bildirimler hangi kanaldan ve hangi formatta paylaşılacak?
• Veri koruma, erişim yetkileri ve güvenlik kontrollerinde görev dağılımı nasıl olacak?
• Canlı sistemde yayınlama ve geri dönüş planını kim yönetecek?

Örneğin bir CRM entegrasyonunda tedarikçi teknik bağlantıyı kurabilir; ancak API yetkilerinin alınması, veri sahiplerinin belirlenmesi ve alan eşleştirmelerinin onaylanması müşteri tarafında olabilir. Bu ayrım yazılı değilse entegrasyonun gecikmesi tek taraflı bir sorun gibi değerlendirilebilir.

Sorumluluk matrisi, bu belirsizliği azaltan pratik bir araçtır. Her teslimat için işi yapan, onaylayan, görüş veren ve bilgilendirilen taraflar belirlenebilir. Özellikle birden fazla departmanın dâhil olduğu kurumsal projelerde bu yaklaşım kararların izlenebilirliğini artırır.

044. Teknik teslimatlar ve kabul koşulları nasıl karşılaştırılır?

Teklif karşılaştırmasında işlevsel kapsam kadar teknik teslimatlar da önemlidir. Kaynak kodu, kurulum dokümantasyonu, dağıtım yapılandırmaları, test raporları ve kullanıcı eğitimleri gibi çıktılar açıkça belirtilmelidir.

Şu soruları listeye ekleyebilirsiniz:

• Kaynak kodu ve teknik dokümantasyon hangi aşamada teslim edilecek?
• API dokümantasyonu ve entegrasyon bilgileri paylaşılacak mı?
• Birim, API, arayüz veya keşif testleri hangi kapsamda yürütülecek?
• Güvenlik ve performans kontrolleri nasıl raporlanacak?
• Kullanıcı kabul testi için hangi senaryolar kullanılacak?
• Bir işlevin kabul edilmesi için ölçülebilir koşullar neler?
• Canlıya geçişten sonra bakım, destek ve küçük iyileştirmeler nasıl ele alınacak?

“Çalışır durumda teslim” ifadesi tek başına yeterli bir kabul kriteri değildir. Örneğin bir rapor ekranının kabulü için doğru veriyi göstermesi, yetkisi olmayan kullanıcıya kapalı olması, belirlenen filtreleri sunması ve beklenen hata durumlarını yönetmesi gerekebilir. Bu koşullar teklif veya ekindeki gereksinim dokümanında yer almalıdır.

Test ve kalite güvence yaklaşımını da ayrıca sorgulayın. OPEIS, test stratejisi, risk bazlı plan, birim, API ve arayüz test otomasyonu ile keşif ve kullanılabilirlik testlerini kapsamına alabilmektedir. Teklifleri karşılaştırırken hangi test türünün hangi risk için kullanılacağını anlamaya çalışın.

055. Teklifleri karşılaştırmak için pratik kontrol listesi

Birden fazla teklifi değerlendirirken her dokümanı aynı sorularla incelemek gerekir. Aşağıdaki kontrol listesi, karar toplantılarında ortak bir çerçeve oluşturabilir:

1. İş hedefi ve beklenen sonuç açıkça tanımlanmış mı?
2. Kapsamdaki işlevler ve kapsam dışı işler ayrı ayrı yazılmış mı?
3. Entegrasyonlar, veri aktarımı ve üçüncü taraf bağımlılıkları belirtilmiş mi?
4. Takvim aşamalara, teslim noktalarına ve müşteri onaylarına ayrılmış mı?
5. Proje ekibi ve tarafların sorumlulukları belirli mi?
6. Test, kabul ve canlıya geçiş koşulları ölçülebilir mi?
7. Kaynak kodu, dokümantasyon ve dağıtım bilgileri teslimat listesinde mi?
8. Değişiklik talepleri ve ek kapsam için izlenecek yöntem açıklanmış mı?
9. Destek, bakım ve güvenlik güncellemelerinin kapsamı anlaşılır mı?

Bu listeyi puanlama amacıyla kullanabilirsiniz; ancak puanların tek başına karar vermesi yerine riskleri görünür kılması daha doğru olur. Örneğin daha düşük bedelli bir teklif, veri aktarımı veya test sorumluluğunu kapsam dışında bırakıyorsa toplam proje etkisi farklılaşabilir. Bu nedenle fiyatı, teslimat ve sorumluluk çerçevesinden bağımsız değerlendirmemek gerekir.

06Sık sorulan sorular

Teklifte kapsam dışı işlerin yazılması neden önemlidir?

Kapsam dışı işlerin yazılması, tarafların beklentilerini sınırlar ve değişiklik taleplerinin nasıl ele alınacağını görünür kılar. Böylece sonradan ortaya çıkan ihtiyaçlar mevcut teslimatlarla karıştırılmaz.

Takvimde müşteri sorumlulukları bulunmalı mı?

Evet. İçerik sağlama, erişim açma, karar verme, prototip onayı ve kullanıcı kabul testi gibi müşteri katkıları takvimde yer almalıdır. Bu görevlerin tarihi belirtilmezse proje planı gerçekçi olmayabilir.

Teklif değerlendirmeden önce gereksinim dokümanı hazırlamak gerekir mi?

Her proje için aynı ayrıntı düzeyi gerekli değildir; ancak hedef kullanıcılar, temel iş akışları, mevcut sistemler, entegrasyonlar ve başarı ölçütleri yazılı hâle getirilmelidir. Gereksinimler netleştikçe teklifler daha doğru karşılaştırılır.

07Sonuç: Kararı fiyat değil, tanımlı teslimat çerçevesi desteklemeli

Yazılım teklifi değerlendirme sürecinde temel amaç, en düşük rakamı seçmek değil; neyin, ne zaman, kim tarafından ve hangi koşullarla teslim edileceğini anlamaktır. Kapsam sınırları, aşamalı takvim, sorumluluk matrisi, teknik teslimatlar ve kabul kriterleri yazılıysa karar süreci daha öngörülebilir hâle gelir.

İhtiyacınızı analizden yayına kadar yapılandırılmış bir süreçle ele almak için OPEIS Yazılım Geliştirme hizmeti sayfasını inceleyebilirsiniz.