Dış kaynak kararı genelde teknik ekibe sorulmadan alınıyor. Yönetim bir bütçe ayırıyor, satın alma üç teklif topluyor, sözleşme imzalanıyor ve iş masaya geldiğinde geliştiriciler yalnızca entegrasyon sorunlarıyla uğraşıyor. Oysa bu kararın en kritik girdileri teknik tarafta duruyor.
Aşağıdaki sorular, teklif değerlendirme masasına oturan mühendisler için hazırlandı. Ticari değil, teknik risk sorularıdır.
Mimariyi kim belirliyor?
Bazı yazılım firmaları kendi hazır iskeletleri üzerinden çalışıyor. Bu, teslim süresini kısaltıyor ama sizi o iskelete bağlıyor. Firma değiştirmek istediğinizde elinizde kalan şey, dokümante edilmemiş bir çatı üzerine yazılmış iş mantığı oluyor.
Sorulacak somut soru: proje hangi framework ve sürümle geliştirilecek, bu seçim kimin kararı, alternatifleri neden elendi? Cevap "biz hep bununla çalışırız" ise, bu bir mimari karar değil bir alışkanlık.
Kod incelemesi süreçte var mı?
Dış geliştirmede kalite kaybının en sık kaynağı, kodun hiç kimse tarafından okunmadan birleştirilmesi. Sözleşmede sizin tarafınızdan yapılacak kod incelemesinin bir hak olarak yazılı olması gerekiyor. Sadece hak olarak da yetmiyor; hangi sıklıkla, hangi aşamada inceleneceği belli olmalı.
Pratikte işleyen model şu: her iki haftada bir teslimat, teslimatın kabulü kod incelemesinden geçmesine bağlı. Böylece dördüncü ayda "baştan yazmak gerekiyor" sürprizi yaşanmıyor.
Test kapsamı teslimatın parçası mı?
Teklif metinlerinde test genelde geçiştiriliyor. "Testler yapılacaktır" cümlesi bir taahhüt değil. Birim testlerinin yazılıp yazılmayacağı, hangi kapsam oranının hedeflendiği ve bu testlerin size teslim edilip edilmeyeceği ayrı ayrı sorulmalı.
Test yazılmayan projeler daha ucuza teslim ediliyor, bu doğru. Fark, ikinci yıldaki bakım maliyetinde geri geliyor ve genelde ilk teslimat farkından büyük oluyor.
Devir teslim nasıl olacak?
Projenin biteceği günü değil, o günden sonrasını konuşun. Elinize ne geçecek: depo erişimi, ortam değişkenleri, dağıtım betikleri, veritabanı şeması dokümantasyonu, mimari kararların gerekçeleri. Bunların hepsi ayrı ayrı istenmezse çoğu teslim edilmiyor.
Bir de şu var: projeyi geliştiren kişilerle teslimden sonra iletişim kurma imkânınız olacak mı? Firma büyükse geliştiriciler başka projeye geçmiş oluyor ve sorularınız satış temsilcisi üzerinden dolaşıyor.
Firma seçiminde nereden başlamalı?
Teknik ekibin en çok zorlandığı kısım aslında değerlendirme değil, değerlendirilecek listeyi oluşturmak. Piyasada çok sayıda firma var ve bunların ölçekleri birbirinden çok farklı. Üç kişilik bir ekibe kurumsal ölçekli bir proje vermek de, on kişilik bir iç aracı büyük bir firmaya yaptırmak da yanlış eşleşme.
Kısa listeyi çıkarırken firmaları uzmanlık ve ölçek kırılımıyla görebilmek işi hızlandırıyor. İstanbul yazılım firmaları arasından bir ön eleme yapıp sonra teknik derinlik sorularına geçmek, doğrudan tanıdık tavsiyesiyle ilerlemekten daha sağlıklı sonuç veriyor. Tavsiye ile gelen firma iyi olabilir ama karşılaştırma yapmadığınız için iyi olduğunu bilemiyorsunuz.
Fiyatlandırma modeli riski nereye yıkıyor?
Sabit fiyatlı sözleşme riski firmaya yıkıyor, bu yüzden firma kapsamı dar tutmak ve her değişikliği ek işe çevirmek zorunda kalıyor. Zaman-malzeme modeli riski size yıkıyor ama esneklik veriyor. İkisinin de doğru olduğu durumlar var.
Kapsamı net, değişme ihtimali düşük işlerde sabit fiyat mantıklı. Keşif gerektiren, gereksinimlerin yol boyunca netleşeceği işlerde sabit fiyat israfa yol açıyor: firma kendini korumak için tamponlu teklif veriyor, siz o tamponu ödüyorsunuz.
Son bir not
Bu soruların hiçbiri firmaya güvensizlik göstergesi değil. Aksine, iyi firmalar bu soruları soran müşteriyi tercih ediyor çünkü proje ortasındaki tartışmaların çoğu bu maddelerin baştan konuşulmamasından çıkıyor. Cevap vermekten rahatsız olan bir firma varsa, aldığınız bilgi zaten değerli.
Yorum yaparken:
1. Yaptığınız yorumun, mutlaka yazı ile alakalı olmasına özen gösteriniz.
2. Yorumlarınızda yazım ve dil bilgisi kurallarına uymaya çalışın lütfen.