Özel Yazılımda Ajans, Müşteri ve Kullanıcı Rolleri Nasıl Ayrılır?

Özel yazılım projelerinde gecikmenin nedeni her zaman teknik zorluk değildir. Bütçeyi kimin onaylayacağı, özellik önceliğini kimin belirleyeceği, kullanıcıların hangi aşamada görüş vereceği veya tamamlanan modülü kimin kabul edeceği net değilse ekipler doğru işi yapsa bile proje bekleyebilir.

Ajans, müşteri ve kullanıcı aynı ürün üzerinde çalışır; fakat aynı sorumluluğa sahip değildir. Ajans teknik çözümün kalitesinden, müşteri iş hedefi ve kararların zamanında verilmesinden, kullanıcılar ise gerçek çalışma koşullarının ve kullanım sorunlarının görünür olmasından sorumludur. Bu rehber, özel yazılım geliştirme projelerinde rol ve karar sınırlarının nasıl kurulacağını açıklar.

Ajans, müşteri ve kullanıcı neden ayrı roller olarak tanımlanmalıdır?

“Müşteri” tek bir kişi veya tek bir beklenti değildir. Projeyi finanse eden yönetici, günlük karar veren ürün sorumlusu, süreç bilgisini sağlayan departman uzmanı ve sistemi kullanacak çalışan farklı ihtiyaçlara sahip olabilir. Ajans tarafında da proje yöneticisi, analist, tasarımcı, geliştirici ve test uzmanının sorumlulukları birbirinden ayrılır.

Roller belirlenmediğinde üç temel sorun ortaya çıkar:

• Aynı karar için birden fazla kişiden çelişkili talimat gelir.
• Kimsenin açıkça üstlenmediği veri, içerik veya kabul işleri gecikir.
• Teknik ekip iş hedefi hakkında, iş ekibi ise teknik yöntem hakkında tek başına karar vermeye başlar.

PMI, iç ve dış kaynakların birlikte çalıştığı projelerde RACI matrisinin rol ve beklenti ayrımını netleştirmek için özellikle önemli olduğunu belirtir Project Management Institute.

Rol ayrımında kullanılan temel kavramlar

Rol tablosu hazırlanırken yalnızca “müşteri yapar, ajans yapar” ifadeleri yetersiz kalabilir. RACI yaklaşımı her teslimat veya karar için dört farklı ilişki tanımlar:

Bir işte birden fazla uygulayıcı bulunabilir; fakat son karar sorumluluğunun mümkün olduğunca tek rolde olması gerekir. Bir komitenin tamamı “son onaycı” olarak tanımlandığında karar süresi uzar ve çelişkide kimin sorumluluk alacağı belirsizleşir.

Müşteri tarafında hangi roller bulunmalıdır?

Müşteri tarafı yalnızca toplantılara katılan bir temsilciden oluşmamalıdır. İş hedefi, bütçe, süreç bilgisi, veri ve kabul sorumlulukları farklı kişilere dağıtılabilir. Küçük işletmelerde aynı kişi birkaç rolü üstlenebilir; ancak hangi şapkayla karar verdiği yine açık olmalıdır.

Proje sponsoru

Proje sponsoru, yatırımın iş gerekçesini ve bütçe sınırını sahiplenir. Projenin neden yapıldığını, hangi sonucun başarı sayılacağını ve önemli kapsam değişikliklerinde nasıl karar verileceğini belirler. Günlük ekran ayrıntılarını yönetmesi gerekmez; fakat ekipler arasında çözülemeyen iş önceliklerinde karar verebilmelidir.

Sponsorun temel sorumlulukları şunlardır:

• İş hedefini ve ölçülebilir başarı kriterlerini onaylamak
• Bütçe ile ana zaman hedefini belirlemek
• Departmanlar arası kaynak ve katılım sorunlarını çözmek
• Büyük kapsam, süre veya maliyet değişikliklerine karar vermek
• Canlıya geçiş için iş tarafındaki nihai desteği sağlamak

Ürün sorumlusu veya müşteri proje sahibi

Günlük iş kararlarının ajansa dağınık biçimde farklı kişilerden gelmemesi için müşteri tarafında tek bir ürün sorumlusu bulunmalıdır. Bu kişi kullanıcı ve yöneticilerden gelen talepleri toplar, çelişkileri çözer, önceliklendirir ve kabul kriterlerini netleştirir.

Scrum Guide, Product Owner’ın ürün değerini en üst düzeye çıkarmaktan ve Product Backlog yönetiminden hesap verebilir olduğunu; Product Owner’ın bir komite değil tek kişi olduğunu belirtir The Scrum Guide. Her özel yazılım projesinin Scrum kullanması şart değildir, ancak tek karar sahibi ilkesi çok paydaşlı projelerde faydalıdır.

Ürün sorumlusu teknik ekibe görev dağıtan kişi değildir. “Hangi problem önce çözülmeli, beklenen iş sonucu nedir ve tamamlanan çalışma kabul kriterini karşılıyor mu?” sorularını yönetir. Teknik yöntemi ise ajansın uzman ekibiyle birlikte değerlendirir.

Süreç uzmanları ve departman temsilcileri

Muhasebe, satış, depo, üretim veya insan kaynakları gibi alanların gerçek kurallarını süreç uzmanları açıklar. İstisnaları, kullanılan belgeleri, mevcut sistemleri ve yasal ya da operasyonel sınırları görünür hâle getirirler.

Bu kişiler her özellikte son karar sahibi olmamalıdır. Kendi departmanları açısından önemli talepleri ürün sorumlusuna sunarlar. Ürün sorumlusu, bütün ürünün hedefleri ve diğer departmanların ihtiyaçlarıyla birlikte öncelik kararı verir.

Veri sahibi ve teknik irtibat

Eski sistemden müşteri, ürün, stok veya personel verisi taşınacaksa müşteri tarafında verinin anlamını ve doğruluğunu onaylayan bir sahip bulunmalıdır. Ajans dönüştürme araçlarını ve aktarım yöntemini hazırlayabilir; fakat hangi mükerrer kaydın doğru olduğu veya hangi cari hesabın kapatılacağı iş kararıdır.

Müşterinin bilgi işlem ekibi varsa erişim, alan adı, ağ, mevcut API, kimlik sağlayıcı ve güvenlik politikaları için teknik irtibat belirlenmelidir. Bu rol ajansın geliştiricilerinin yerine geçmez; kurum içi altyapıyla bağlantıyı kolaylaştırır.

Ajans tarafında hangi roller bulunmalıdır?

Ajansın sorumluluğu yalnızca kod teslim etmek değildir. İş hedefini teknik çözüme çevirmek, riskleri görünür kılmak, kaliteyi doğrulamak ve kararların etkisini müşteriye açık biçimde anlatmak da hizmetin parçasıdır.

Proje yöneticisi veya teslimat sorumlusu

Proje yöneticisi; kapsam, takvim, bağımlılık, toplantı, risk ve iletişim akışını koordine eder. Müşterinin ürün önceliklerine tek başına karar vermez ve geliştiricinin teknik uzmanlığının yerine geçmez. Amacı doğru kararın doğru kişiden zamanında çıkmasını sağlamaktır.

Bu rolün sorumlulukları arasında şunlar bulunabilir:

• Proje planını, kilometre taşlarını ve bağımlılıkları izlemek
• Karar, risk ve değişiklik kayıtlarını güncel tutmak
• Toplantıları amaç ve gündemle yönetmek
• Bekleyen müşteri girdilerini ve ajans teslimatlarını takip etmek
• Kapsam değişikliğinin süre ve bütçe etkisini görünür hâle getirmek

İş analisti ve UX araştırmacısı

Analist, müşteri taleplerini doğrudan ekran listesine çevirmek yerine mevcut süreci, kullanıcı hedefini, istisnaları ve veri ilişkilerini anlamaya çalışır. UX araştırmacısı veya tasarımcı ise gerçek kullanıcıların işi nasıl yaptığını gözlemler ve arayüz kararlarını kanıtla destekler.

GOV.UK Service Manual, kullanıcı araştırması olmadan ekibin hangi problemi çözmesi, ne geliştirmesi veya hizmetin kullanıcı için çalışıp çalışmadığı konusunda yeterli bilgiye sahip olamayacağını vurgular GOV.UK Service Manual.

Analistin görevi müşterinin söylediğini olduğu gibi dokümana geçirmek değildir. Çelişkili kuralları, eksik durumları ve gereksiz adımları sorgulayarak karar verilmesi gereken noktaları görünür hâle getirmektir.

Teknik lider ve geliştirme ekibi

Teknik lider; mimari, veri modeli, güvenlik, entegrasyon ve teknik risk kararlarını yönetir. Geliştirme ekibi kabul edilen gereksinimleri çalışan yazılıma dönüştürür, kod incelemesi ve otomatik testlerle teknik kaliteyi korur.

Müşteri hangi teknoloji veya veritabanının kullanılacağını önerebilir; ancak seçimin bakım, ölçek, güvenlik ve ekip yetkinliği üzerindeki etkisini ajans açıklamalıdır. Benzer şekilde ajans da iş politikasını teknik kolaylığa göre tek başına değiştirmemelidir.

Test ve kalite sorumlusu

Ajans; birim, entegrasyon, güvenlik, performans ve teknik kabul testlerini planlar. Müşteriye teslim edilen sürümün tanımlı davranışı karşıladığını doğrular ve bulunan hataları izlenebilir biçimde yönetir.

Teknik testlerin geçmesi, müşteri kabul testinin yerine geçmez. Ajans yazılımın tanımlanan kurallara göre çalıştığını; müşteri ise bu kuralların gerçek işi doğru karşıladığını doğrular. Webioo’nun kalite yaklaşımında olduğu gibi kalite, yalnızca son ekrandaki görünüm değil, sürecin kontrol edilebilir ve tekrarlanabilir olmasıdır.

Son kullanıcıların rolü nedir?

Son kullanıcılar projenin pasif izleyicileri değildir. Günlük işi, istisnaları ve kullanılan geçici çözümleri en iyi bilen kişiler olabilirler. Ancak kullanıcının bireysel tercihi otomatik olarak ürün önceliği veya kapsam kararı değildir.

Kullanıcıların projeye katkı sağlayabileceği alanlar şunlardır:

• Mevcut işi nasıl yaptıklarını ve karşılaştıkları sorunları göstermek
• Prototip ve erken sürümleri gerçek görevlerle denemek
• Eksik bilgi, gereksiz adım ve anlaşılmayan terimleri bildirmek
• Kullanıcı kabul testlerinde tanımlı senaryoları uygulamak
• Canlı kullanım sonrasında ölçülebilir geri bildirim sağlamak

GOV.UK rehberi, kullanıcı ihtiyaçlarının tasarım veya geliştirme başlamadan önce araştırılmasını ve araştırmanın her geliştirme aşamasında planlanmasını önerir GOV.UK Service Manual GOV.UK Service Manual.

Kullanıcı görüşmeleri yalnızca yöneticilerle yapılırsa günlük darboğazlar kaçabilir. Yalnızca kullanıcı talepleri toplanırsa da işletme hedefi ve süreç standardı kaybolabilir. Araştırma bulguları ürün sorumlusu tarafından iş hedefleriyle birlikte değerlendirilmelidir.

Temel proje kararları kim tarafından verilmelidir?

Aşağıdaki örnek matris her proje için aynen kullanılmak zorunda değildir. Amaç, kararların proje başlamadan önce açık sahiplerle eşleştirilmesidir.

RACI matrisi hazırlanırken yalnızca şirket adları değil, gerçek rol veya kişi adları yazılmalıdır. “Müşteri” ifadesi üç farklı departmanı kapsıyorsa karar hâlâ belirsizdir. Aynı şekilde “ajans” yerine proje yöneticisi, teknik lider veya test sorumlusu belirtilmelidir.

Gereksinim ve öncelik kararları nasıl yönetilmelidir?

Her paydaş doğrudan geliştiriciye görev ilettiğinde ürün planı görünmez hâle gelir. Satış ekibi bir müşteri talebini, finans ekibi raporu, yönetici ise yeni kontrol ekranını aynı anda acil ilan edebilir. Ajans hangi talebin önce yapılacağına yalnızca sesin yüksekliğine göre karar vermemelidir.

Sağlıklı akış şu şekilde kurulabilir:

1. Talep tek kayıt kanalından ürün sorumlusuna iletilir.
2. İş problemi, etkilenen kullanıcı ve beklenen sonuç açıklanır.
3. Ajans teknik seçenekleri, bağımlılıkları ve tahmini etkileri sunar.
4. Ürün sorumlusu iş değeri ve mevcut planla birlikte öncelik verir.
5. Bütçe veya ana kapsam etkileniyorsa sponsor kararı alınır.
6. Karar backlog, değişiklik kaydı ve sürüm planına işlenir.

Bu yapı kullanıcıların ajansla konuşmasını engellemez. Kullanıcı araştırması, test ve destek görüşmeleri doğrudan yapılabilir; fakat yeni kapsamın resmî önceliği ürün sorumlusundan geçmelidir.

Kabul kriteri ve onay sorumluluğu nasıl ayrılmalıdır?

“Modül tamamlandı” ifadesi her taraf için aynı anlama gelmeyebilir. Geliştirici kodun çalıştığını, test uzmanı tanımlı senaryoların geçtiğini, kullanıcı işini yapabildiğini, sponsor ise yatırım sonucunun oluştuğunu görmek ister. Bu nedenle tamamlanma tanımı katmanlı olmalıdır.

Kabul süresi sözleşme ve proje planında belirlenmelidir. Müşteri test ortamına sürüm teslim edildikten aylar sonra yeni yorumlar getirirse bunların hata mı, eksik gereksinim mi yoksa yeni talep mi olduğu ayrılmalıdır.

Veri hazırlığı ve migrasyonda sorumluluk nasıl paylaşılır?

Eski Excel dosyaları veya yazılımdan veri aktarılırken ajans teknik eşleme, dönüştürme ve yükleme araçlarını hazırlayabilir. Fakat mükerrer müşteri kaydının hangisinin doğru olduğu, kapanmış ürünlerin taşınıp taşınmayacağı ve eksik vergi bilgilerinin nasıl tamamlanacağı müşteri tarafının iş bilgisini gerektirir.

Görev paylaşımı şu şekilde olabilir:

• Müşteri: Kaynak veriyi sağlamak, veri sahibini belirlemek, temizliği ve iş doğruluğunu onaylamak
• Ajans: Veri profilini çıkarmak, dönüşüm kurallarını uygulamak, deneme aktarımı ve hata raporu üretmek
• Kullanıcılar: Örnek kayıtların günlük işle doğru eşleştiğini kontrol etmek
• Sponsor / proje sahibi: Taşınmayacak veri ve kabul edilebilir kalite sınırı hakkında karar vermek

Veri migrasyonu “ajans eski sistemi taşır” biçiminde tek cümleye bırakılmamalıdır. Kaynak, alan eşlemesi, temizlik, deneme sayısı, doğrulama ve geri dönüş planı ayrı teslimatlar olarak tanımlanmalıdır.

Güvenlik ve mevzuat sorumluluğu tamamen ajansa mı aittir?

Ajans güvenli kodlama, erişim kontrolü, yedekleme, loglama ve teknik korumaları planlamakla sorumludur. Müşteri ise hangi verinin neden işlendiğini, kimlerin erişeceğini, saklama süresini ve kurum içi kullanım politikasını belirlemelidir.

Örneğin ajans rol bazlı yetki altyapısını geliştirir; fakat finansal raporu hangi unvanların görebileceğine müşteri karar verir. Ajans silme ve anonimleştirme özelliğini oluşturabilir; hangi kayıtların hangi hukuki gerekçeyle ne kadar saklanacağı müşteri ve ilgili uzmanlar tarafından doğrulanmalıdır.

Güvenlik ortak sorumluluktur:

• Ajans teknik riskleri ve çözüm seçeneklerini açıklar.
• Müşteri veri sınıflarını ve iş erişim kurallarını onaylar.
• Bilgi işlem ekibi kurum ağı, SSO ve cihaz politikalarını sağlar.
• Hukuk veya uyum uzmanı gerekli mevzuat yorumunu yapar.
• Kullanıcılar hesap paylaşmama ve olay bildirme gibi operasyon kurallarına uyar.

İletişim düzeni rol karmaşasını nasıl azaltır?

Çok sayıda toplantı, iyi iletişim anlamına gelmez. Her toplantının karar türü, katılımcısı ve çıktısı farklı olmalıdır. Teknik ayrıntıların sponsor toplantısında çözülmeye çalışılması veya bütçe kararının kullanıcı testinde tartışılması süreci verimsizleştirir.

Toplantı sonunda karar, sorumlu ve hedef tarih yazılı hâle getirilmelidir. Kararın yalnızca mesajlaşma geçmişinde veya bir kişinin hafızasında kalması rol ayrımını zayıflatır.

Sık yapılan rol hataları nelerdir?

Ürün sorumlusunun komiteye dönüşmesi

Her departmanın eşit son onay yetkisi olduğunda küçük özelliklerde bile uzlaşma beklenir. Görüşler toplanmalı; ancak öncelik ve kabul için tek ürün sorumlusu yetkilendirilmelidir.

Ajansın iş kararını varsayması

Müşteriden zamanında yanıt gelmediğinde ajans iş kuralını tahmin ederek ilerleyebilir. Teknik varsayım açıkça işaretlenmezse daha sonra yeniden geliştirme gerekir. Karar gerektiren konu kayıt altına alınmalı ve etkisi görünür kılınmalıdır.

Kullanıcıların projeye yalnızca finalde katılması

Sistem tamamlandıktan sonra kullanıcıya gösterildiğinde temel süreç hataları pahalı biçimde ortaya çıkar. Kullanıcılar analiz, prototip ve ara sürüm testlerine temsilî olarak katılmalıdır.

Müşterinin veri ve içerik görevlerini ajansın sorumluluğu sanması

Ajans şablon ve aktarım aracı sağlayabilir; fakat ürün açıklaması, iş kuralı, personel yetkisi veya geçmiş verinin doğruluğu müşterinin bilgi sahipliğini gerektirir. Bu girdiler proje planında teslimat olarak izlenmelidir.

Her talebin “hata” olarak iletilmesi

Onaylanmış kabul kriterini karşılamayan durum hatadır. Daha önce konuşulmamış yeni rapor, alan veya iş akışı kapsam değişikliğidir. Bu ayrım yapılmazsa bütçe, süre ve kalite tartışmaları kişisel algıya dönüşür.

Gerçekçi bir rol ayrımı senaryosu

Varsayımsal olarak saha servis firması için iş emri ve müşteri yönetim yazılımı geliştirildiğini düşünelim. Genel müdür proje sponsoru, operasyon müdürü ürün sorumlusu, servis planlama çalışanları ve teknisyenler son kullanıcı olsun. Ajans tarafında proje yöneticisi, analist, tasarımcı, geliştiriciler ve test uzmanı yer alsın.

Sponsor; servis tamamlama süresini ve eksik kayıtları azaltma hedefini, bütçeyi ve ana takvimi onaylar. Operasyon müdürü hangi modülün önce geliştirileceğine, bir iş emrinin hangi koşulda tamamlanmış sayılacağına ve kullanıcı kabulüne karar verir.

Planlama çalışanları mevcut görev atama sürecini, teknisyenler ise sahadaki bağlantı ve fotoğraf yükleme sorunlarını gösterir. Ajans analisti bu bulguları iş akışına dönüştürür; teknik ekip çevrimdışı taslak, rol bazlı erişim ve entegrasyon yöntemini tasarlar.

Test ortamında ajans teknik senaryoları çalıştırır. Kullanıcılar gerçek görev örnekleriyle kabul testi yapar. Operasyon müdürü kapsamın karşılandığını onaylar; sponsor eğitim, veri ve operasyon hazırlığına bakarak canlı geçişi destekler. Bu senaryo gerçek bir şirket veya sonuç iddiası değil, rol ayrımını göstermek için hazırlanmış örnektir.

Proje başlangıcında hazırlanması gereken rol kontrol listesi

• Proje sponsoru ve bütçe karar sahibi belli mi?
• Müşteri tarafında tek ürün sorumlusu yetkilendirildi mi?
• Her departman için süreç uzmanı ve kullanıcı temsilcisi seçildi mi?
• Ajans proje yöneticisi, analist ve teknik karar sahibi belli mi?
• Her ana teslimat için RACI matrisi hazırlandı mı?
• Kapsam, öncelik ve teknik çözüm kararları birbirinden ayrıldı mı?
• Kullanıcı görüşünün nasıl toplanacağı ve karara nasıl dönüşeceği tanımlı mı?
• Veri temizliği, içerik ve erişim bilgilerinin sahipleri belli mi?
• Kabul kriterini yazan ve nihai kabulü veren kişi belirlendi mi?
• Kapsam değişikliği için kayıt, etki analizi ve onay süreci var mı?
• Toplantı türleri, katılımcıları ve karar kayıtları tanımlı mı?
• Canlıya geçiş, eğitim ve destek sorumlulukları ayrıldı mı?
• Proje süresi değerlendirilirken müşteri karar ve veri teslim süreleri hesaba katıldı mı?
• Yazılım projesinin takvimi karşılıklı bağımlılıklarla birlikte planlandı mı?

Sonuç: Başarılı proje yalnızca iyi ajansla değil, doğru rol yapısıyla oluşur

Özel yazılım projesinde ajans çözüm ortağı, müşteri iş hedefinin ve önceliklerin sahibi, kullanıcı ise gerçek çalışma koşullarının kaynağıdır. Bu roller birbirinin yerine geçtiğinde kararlar gecikir, gereksinimler çelişir ve kabul süreci uzar.

Projenin başında sponsor, ürün sorumlusu, süreç uzmanı, veri sahibi, kullanıcı temsilcileri ve ajans ekibi için açık sorumluluklar tanımlanmalıdır. RACI matrisi, karar kaydı, düzenli iletişim ve katmanlı kabul süreci birlikte kullanıldığında özel yazılım projesi daha öngörülebilir ve denetlenebilir biçimde ilerler.