- Dış kaynak projesinde müşteri neyi yönetir?
- Sözleşmeden önce: kapsam ve sözleşme modeli
- Proje boyunca yönetim ritmi
- Değişiklik kontrolü ve kabul
- Örnek senaryo: bayi portalının dış kaynakla geliştirilmesi
- Sık yapılan hatalar ve riskler
- Bu beceriyi Mindset programlarında nerede çalışırsınız?
- Sık sorulan sorular
Yazılım Firmasıyla Proje Yönetimi: Sözleşmeden Devre Kadar
Yazılımı dış kaynakla yaptırmak, sorumluluğu devretmek anlamına gelmez; müşteri tarafı kapsamı, kabulü ve ilerlemeyi yönetmeye devam eder. İşin başarısı sözleşmedeki netliğe ve proje boyunca kurulan görünürlüğe bağlıdır.
Bir bakışta
- Dış kaynak, yönetim sorumluluğunu kaldırmaz. Kapsam, öncelik ve kabul kararları müşteri tarafında kalır; tedarikçi üretimi yürütür.
- Sözleşme kapsamı, kabulü ve değişikliği tanımlamalıdır. Belirsiz kapsam ve tanımsız kabul, projelerde en sık anlaşmazlık kaynağıdır.
- Görünürlük düzenli demo ve rapor ile sağlanır. Sürpriz çıkmaması için ilerleme çalışan ürün üzerinden sık aralıkla izlenmelidir.
- Kabul kriterleri iş başlamadan yazılır. Kabul testi, teslimde değil tanımlama aşamasında planlanan bir etkinliktir.
- Devir teslim, sözleşmenin parçası olarak planlanır. Kaynak kod, doküman, erişim ve bilgi aktarımı bitişte değil baştan hükme bağlanır.
Dış kaynak projesinde müşteri neyi yönetir?
Yazılım firmasına iş verdiğinizde kodlamayı ve çoğu teknik kararı tedarikçi üstlenir, ama projenin başarısı yalnız onun işi değildir. Ne yapılacağına, nelerin öncelikli olduğuna, hangi koşulda iş kabul edileceğine ve değişikliklerin nasıl ele alınacağına müşteri tarafı karar verir. Bu kararlar belirsiz kaldığında tedarikçi kendi varsayımlarıyla ilerler ve sonuç beklentiden uzaklaşır.
Müşteri tarafında birkaç rol netleşmelidir. İş sahibi, çözümün neden gerektiğini ve hangi sonucu beklediğini temsil eder. Proje yöneticisi, tedarikçiyle günlük koordinasyonu, riskleri ve ilerlemeyi yürütür. Teknik sorumlu ise mimari, güvenlik ve entegrasyon konularında tedarikçiyi denetler. Küçük kurumlarda bu roller bir kişide toplanabilir ama sorumluluklar yine de ayrı düşünülmelidir.
Tedarikçi tarafında da tek bir iletişim noktası ve bir proje yöneticisi bulunmalıdır. Hem sizin hem onların ekibinde kimin hangi konuda karar verdiği baştan yazılı olmalıdır; kararların kişiler arası mesajlaşmalarda kaybolması sık görülür.
Sözleşmeden önce: kapsam ve sözleşme modeli
Dış kaynak projesinin temeli kapsamdır. İhtiyaçları iş diliyle yazın: hangi kullanıcı ne yapabilmeli, hangi sistemlerle bütünleşmeli, performans ve güvenlik beklentileri nelerdir? Kapsamın dışında kalanları da yazın; tartışmaların çoğu 'bu zaten kapsamdaydı' cümlesiyle başlar.
Sözleşme modeli, riskin kimde olduğunu belirler. Sabit fiyatlı modelde kapsam net olmalıdır; tedarikçi riski fiyatlandırır ve kapsam dışı her talep ayrıca ele alınır. Süre ve malzeme modelinde esneklik yüksektir, ancak bütçe kontrolü müşterinin izleme disiplinine bağlıdır. Çevik sözleşmelerde kapsam sprintler boyunca netleşir, bütçe ve zaman bir üst sınırla yönetilir. Kapsamı belirsiz ve değişken projelerde sabit fiyat zorlanır, kapsamı net ve değişmez işlerde ise uygun olabilir.
Sözleşmede şunlar bulunmalıdır: teslimatlar ve kabul kriterleri, ödeme koşulları ve ödemenin kabule bağlanması, değişiklik talebi süreci, fikri mülkiyet ve kaynak kod sahipliği, gizlilik ve veri güvenliği yükümlülükleri, garanti ve destek süresi, ekip değişikliği ve yedekleme koşulları, projeden çıkış ve devir teslim hükümleri. Hukuk birimi bu maddeleri gözden geçirmelidir.
Sözleşme modeli, kapsamın ne kadar net olduğuna göre seçilir
- Kapsam net ve değişmesi beklenmiyorSabit fiyatlı modelKapsam dışı talepler değişiklik sürecinden geçer.
- Kapsam belirsiz, ihtiyaç keşfedilecekSüre ve malzeme ya da çevik modelBütçe üst sınırı ve düzenli izleme şarttır.
- Önce küçük bir doğrulama gerekiyorKısa bir ön çalışma ile başlayınSonuca göre ana sözleşmenin kapsamı netleştirilir.
Proje boyunca yönetim ritmi
Dış kaynak projesinde en büyük risk, sorunun geç görülmesidir. Bunu önlemek için düzenli ve kısa bir yönetim ritmi kurun. Haftalık durum toplantısında ilerleme, karşılaşılan engeller, riskler ve alınacak kararlar konuşulur. Her sprint ya da aşama sonunda çalışan ürün üzerinden demo yapılır; yazılı rapor demonun yerini tutmaz çünkü yüzde olarak bildirilen ilerleme gerçek durumu saklayabilir.
Bir risk ve karar kayıt defteri tutun. Açık riskler, sorumlu kişiler, alınan kararlar ve bekleyen konular tek bir yerde olmalıdır. Eskalasyon yolunu baştan belirleyin: taraflar proje yöneticisi düzeyinde çözemezse hangi üst düzey kişiye gidilecek?
Kalite görünürlüğünü sözleşmeye bağlayın. Kaynak koda ya da bir depoya erişim, otomatik test sonuçları ve test ortamına erişim, müşteri tarafının kaliteyi sürekli gözlemlemesini sağlar. Tedarikçinin ekibinde değişiklik olursa bilginin kaybolmaması için dokümantasyon ve devir yükümlülüğü bulunmalıdır.
Tedarikçiyle ilişkiyi yalnızca denetim olarak görmeyin. Sorunları erken ve açıkça paylaşan bir ilişki, her sorunun ceza maddesine dönüştüğü bir ilişkiden daha iyi sonuç verir.
Değişiklik kontrolü ve kabul
Her proje sırasında kapsam değişir. Önemli olan değişikliğin kayıtsız kalmamasıdır. Değişiklik talebi yazılı olarak gelir, tedarikçi etkisini (efor, takvim, maliyet, risk) değerlendirir, müşteri onaylar ya da reddeder, onaylanan değişiklik plana ve bütçeye işlenir. Sözlü anlaşmalar sonradan anlaşmazlık doğurur.
Kabul, projenin en kritik kontrol noktasıdır. Kabul kriterlerini işin başında yazın ve ölçülebilir kılın: 'hızlı çalışmalı' yerine ölçülebilir bir yanıt süresi koşulu. İş tarafı UAT senaryolarını hazırlar, tedarikçi önce kendi testlerini yapar, sonra müşteri test ortamında senaryoları çalıştırır. Bulunan hatalar kayıt altına alınır ve ağırlığına göre sınıflandırılır.
Ödemeyi kabule bağlayın. Teslimatın tamamı kabul kriterini sağlamadan son ödeme yapılmaz; ara ödemeler de kilometre taşı kabullerine bağlanır. Kabul sürecinde ayrıntılı bir çıkış kriteri bulunması, 'bitti mi' tartışmasını önler.
Dış kaynak projesi, kapsamla başlar ve devirle kapanır
- HazırlıkKapsam ve tedarikçi seçimiİhtiyaç, kapsam dışı ve ölçütler yazılır.
- SözleşmeKabul ve değişiklik kurallarıTeslimat, ödeme, mülkiyet ve çıkış hükümleri.
- YürütmeDüzenli demo ve izlemeHaftalık durum, risk kaydı, çalışan ürün.
- DoğrulamaUAT ve kabulKriterlere göre test, hata sınıflandırma, onay.
- DevirKaynak kod, doküman, bilgi aktarımıErişimler, dokümanlar ve eğitim müşteriye geçer.
- DestekGaranti ve işletmeGaranti süresi ve destek düzeni işletmeye bağlanır.
Örnek senaryo: bayi portalının dış kaynakla geliştirilmesi
Kurgusal bir şirket, bayi siparişlerini yöneten bir portalı yazılım firmasına yaptırmak ister. İş sahibi satış direktörü, proje yöneticisi ise BT biriminden bir uzmandır. Kapsam dokümanı, bayi girişi, sipariş oluşturma, stok görüntüleme ve muhasebe sistemiyle entegrasyonu içerir; raporlama ekranları kapsam dışıdır ve açıkça yazılır.
Kapsam bir ölçüde belirsiz olduğundan çevik bir model seçilir: bütçe üst sınırı ve kilometre taşı kabulleri tanımlanır, kapsam sprintler boyunca netleşir. Her sprint sonunda demo yapılır, iş birimi bayilerden birkaç temsilciyle geri bildirim toplar.
Projenin ortasında satış birimi ek bir kampanya modülü ister. Talep değişiklik sürecine alınır: tedarikçi etkiyi, takvimi ve maliyeti yazar; iş sahibi, mevcut kapsamdan ne çıkarılacağını belirleyerek onaylar. Kabul aşamasında bayiler gerçek siparişlerle senaryoları dener, hatalar sınıflandırılır. Devir aşamasında kaynak kod deposunun sahipliği, ortam erişimleri ve işletme dokümanı müşteriye aktarılır; tedarikçinin ekibinden bir kişi şirket BT ekibine eğitim verir. Proje kapsam kayması ve devir belirsizliği olmadan kapanır.
Sık yapılan hatalar ve riskler
En yaygın hata, belirsiz kapsamı sabit fiyatla bağlamaktır. Bu, hem tedarikçiyi savunmacı hem müşteriyi mutsuz kılan bir kombinasyondur. Kabul kriterlerini işin sonuna bırakmak, ilerlemeyi yalnız yüzde ile izlemek ve kaynak kod ile dokümantasyon sahipliğini sözleşmede belirtmemek de sık görülür.
Bir başka risk tedarikçiye aşırı bağımlılıktır. Mimari kararlar, erişimler ve bilgi yalnız tedarikçide kalırsa, ilişki bozulduğunda proje rehin alınmış olur. Bunu önlemek için müşteri tarafında teknik bir sorumlu bulundurun, depoya ve ortamlara erişimi baştan alın.
İletişimde, sorunları saklamak ya da cezalandırıcı bir dil kullanmak güveni zedeler. Sonuçta gizlenen sorunlar büyür. Ekip değişikliğini ve bilgi kaybı riskini önceden sözleşmeyle ele almak da gereklidir. Son olarak, devri sona bırakmak ve işletme için bilgi aktarımı planlamamak, proje tamamlansa bile çözümün sürdürülemez olmasına neden olur.
Bu beceriyi Mindset programlarında nerede çalışırsınız?
IT Proje Yönetimi Sertifika Programı'nın proje yönetimi zihin seti, IT projeleri için çevik ve Scrum uygulamaları, kalite güvence ve test yönetimi ile IT projesi hazırlama ve planlama uygulamaları, bir yazılım projesini hem tedarikçi hem müşteri tarafından yönetebilmek için gereken kapsam, kalite ve planlama becerilerini bir araya getirir.
Özellikle dış kaynak projesinde müşteri tarafında koordinasyon üstlenecek BT proje yöneticileri ve iş birimi proje sorumluları için bu başlıklar, kabul ve izleme kararlarını daha sağlam vermeye yardımcı olur.
İlgili Mindset programı
IT Proje Yönetimi Sertifika Programı
Sık sorulan sorular
Dış kaynak yazılım projesinde sabit fiyat mı süre-malzeme modeli mi seçilmeli?
Kapsam net ve değişme olasılığı düşükse sabit fiyat uygundur. Kapsam keşfedilerek netleşecekse süre-malzeme ya da çevik model daha gerçekçidir; ama bütçe üst sınırı ve düzenli izleme gerekir. Karar verirken riskin kimde kalacağını açıkça tartışın.
Kaynak kodun sahibi kim olmalıdır?
Bu, sözleşmede açıkça yazılması gereken bir konudur. Genellikle müşteri için özel geliştirilen kodun sahipliği ya da kullanım hakkı müşteriye geçer, tedarikçinin hazır bileşenleri için lisans koşulları belirtilir. Hukuk birimiyle netleştirin; belirsizlik sonradan pahalıya mal olur.
Tedarikçinin bildirdiği ilerlemeye nasıl güvenebilirim?
Yüzde bildirimi yerine çalışan ürün üzerinden demo isteyin, kaynak koda ve otomatik test sonuçlarına erişim talep edin, kilometre taşlarını somut teslimatlara bağlayın. Gözlemlenebilir kanıt, sözlü güvenceden daha güvenilir bir ilerleme göstergesidir.
Proje sırasında tedarikçi değiştirmek mümkün mü?
Mümkündür ama maliyetlidir. Kaynak koda, dokümana ve ortamlara erişiminiz varsa geçiş kolaylaşır; yeni tedarikçinin sistemi tanıması için de bilgi aktarımı gerekir. Bu yüzden sözleşmede erişim, devir ve çıkış hükümlerinin bulunması, ilişkiyi sorunsuz sürdürürken bile bir güvence sağlar.
Müşteri tarafı ne kadar teknik olmalı?
Kodu yazacak kadar değil, ama mimari kararları, güvenlik ve kalite beklentilerini değerlendirecek bir teknik sorumlu şarttır. Kurum içinde böyle biri yoksa bağımsız bir danışmanlık desteği almak, tedarikçi denetiminde ciddi fark yaratır.