Bir projenin kapsamı teklifin birkaç sayfasını kaplar. Proje boyunca en çok açılan sayfalar da genellikle onlardır. Takvim kaydığında, bütçe zorlandığında ya da teslim edilen iş beklenenden farklı göründüğünde iki taraf da önce kapsama bakar. O anda belgede ne yazdığı kadar, iki tarafın o cümleleri nasıl anladığı da belirleyici olur.
Kapsam sorunlarının çok azı kötü niyetten doğar. Çoğu, aynı cümlenin iki tarafta farklı okunmasından, yazılmayan varsayımlardan ve proje ilerledikçe doğal olarak büyüyen beklentilerden çıkar. Bu yazı tasarım ve yazılım projelerinde kapsamın belirlenmesini, yazılmasını, karşı tarafa aktarılmasını ve gerektiğinde yeniden açılmasını konu alıyor.
Bir fikir iş kalemine dönüşürken #
Müşteri bir projeye çoğu zaman bir fikirle gelir: yeni bir uygulama, yenilenmiş bir marka, işleri hızlandıracak bir yönetim paneli. Fikir müşterinin kafasında bir bütün hâlindedir. Ajansın işi onu ekranlara, modüllere, teslimatlara ve saatlere çevirmektir. Bu çevirinin her adımında bir yorum payı vardır.
Tasarımda "kurumsal kimlik" bir ekip için logo, renk ve yazı karakteri anlamına gelir; bir başkası için kartvizitten araç giydirmesine kadar uzanan bir uygulama setidir. Yazılımda "kullanıcı yönetimi" basit bir giriş ekranı da olabilir, rollere göre yetkilendirilen, işlem kaydı tutan ve şirket hesabıyla tek oturum açmaya bağlanan bir modül de. İki tarafın aynı kelimeyi kullanması, aynı şeyi kastettiği anlamına gelmez.
Bu yüzden kapsamı belirlemek, fikri dinlemekten fazlasını gerektirir. Hedefi, kullanıcıyı, mevcut sistemleri ve olmazsa olmazları konuşmak, sonra bunları sayılabilir teslimatlara dönüştürmek gerekir. Bu emek ister ve o emeğin kime ait olacağı sorusu projeden önce gelir.
Fiyat sorusu ve analizin maliyeti #
Bir proje fikri olan herkes önce ne kadar tutacağını bilmek ister. Bu doğal bir soru; bütçe ayrılmadan iş başlamaz. Ancak doğru bir fiyat, işin ayrıntılı olarak anlaşılmasına bağlıdır. Ayrıntılı analiz de günler süren görüşme, inceleme ve yazım demektir.
Pek çok pazarda bu aşama ayrı bir hizmet olarak satılır. Keşif ya da analiz çalışması kendi bütçesiyle yapılır, çıktısı müşteriye teslim edilir ve asıl proje bu çıktıya göre fiyatlanır. Türkiye'de ise beklenti çoğunlukla ayrıntılı bir teklifin ücretsiz hazırlanmasıdır. Analizin maliyeti böylece henüz onaylanmamış bir iş için ajansın üzerinde kalır.
Bu durumda ajansın önünde iki yol vardır. Birincisi kısa bir görüşmeyle tahmini bir fiyat vermektir. Hızlıdır ama risklidir: fiyat düşük kalırsa ajans ya zarar eder ya da işi sıkıştırır; yüksek kalırsa müşteri gereksiz yere vazgeçer. İkincisi teklif aşamasında ayrıntılı bir analiz yapmaktır. Daha doğru bir fiyat çıkar, fakat iş alınmazsa bu emek karşılıksız kalır. İki yol da taraflardan birini zorlar. Önemli olan, bu yükü kimin hangi ölçüde taşıyacağına baştan karar vermektir.
Kademeli analiz: önce aralık, sonra ayrıntı #
Bu dengeyi kurmak için analizi tek seferde yapmıyor, kademelere bölüyoruz. Her kademe bir sonrakine karar vermek için yeterli bilgiyi üretir. Bir kademede durulursa iki taraf da gereğinden fazla kaynak harcamamış olur.
- İlk görüşmede hedefi, kullanıcıyı, takvimi ve olmazsa olmazları konuşuyoruz. Bu görüşmeden bir bütçe aralığı ve aralığın dayandığı varsayımlar çıkıyor.
- Aralık müşteri için uygunsa ayrıntılı analize geçiyoruz. Teslim edilecek ekranlar, modüller, içerikler ve kapsam dışında kalan her şey bu aşamada yazıya dökülüyor.
- Teklif ve sözleşme bu belgeye dayanıyor. Fiyat, takvim ve ödeme planı belgedeki kalemlerle birebir eşleşiyor.
Bütçe aralığı bir söz sayılmaz; ilk görüşmede anlatılan işe göre yapılmış bir ilk okumadır. Bunu açıkça söylemek, ayrıntılı analizden sonra fiyat değiştiğinde yaşanabilecek hayal kırıklığını önler. Varsayımları aralığın yanına yazmak da hangi bilginin fiyatı neden değiştirdiğini görünür kılar.
Kapsamı büyük ya da belirsiz projelerde ayrıntılı analizi ayrı ve ücretli bir keşif çalışması olarak öneriyoruz. Bu çalışmanın çıktısı müşterinin olur; projeyi başka bir ekiple yapmaya karar verse bile elindeki belgeyle devam edebilir. Böylece analize harcanan emek iki taraf için de boşa gitmez.
Kapsam belgesinde neler olmalı #
İyi bir kapsam belgesi uzun olmak zorunda değildir, ama belirsiz kelimelere yer bırakmaz. Biçimi projeden projeye değişse de şu başlıkları mutlaka içerir:
- Sayılabilir biçimde yazılmış teslimatlar; kaç ekran, kaç şablon, hangi platformlar ve hangi dosya biçimleri olduğu.
- Kapsam dışında kalanlar. Proje sırasında en çok işe yarayan bölüm çoğu zaman budur, çünkü beklentilerin sessizce büyüdüğü yerleri baştan adlandırır.
- Varsayımlar ve müşteriden beklenenler; içeriklerin, görsellerin, erişimlerin ve üçüncü taraf servislerin ne zaman ve kimden geleceği.
- Revizyon turları ve onay noktaları; her aşamanın neyle kapanacağı.
- Proje sırasında gelen yeni isteklerin nasıl ele alınacağı.
Tasarım projelerinde revizyon turu ve uygulama sayısı, yazılım projelerinde ise entegrasyonlar, veri taşıma ve teslim sonrası destek en sık belirsiz kalan başlıklardır. Bunları "gerekirse konuşuruz" diye bırakmak yerine bugünkü bilgiyle yazmak, sonraki konuşmayı kolaylaştırır.
Belge yazılır, peki okunur mu? #
Kapsam belgesini ne kadar ayrıntılı hazırlarsanız hazırlayın, karşı tarafın onu satır satır okuyacağının garantisi yoktur. Müşterinin önceliği kendi işidir. Teklif çoğu zaman yoğun bir haftanın arasında, toplam fiyata ve takvime bakılarak onaylanır. Belge uzadıkça okunma ihtimali de azalır.
Bunu karşı tarafın kusuru olarak görmüyoruz; kapsamı aktarmak da işin bir parçası. Bu yüzden belgeyi göndermekle yetinmiyor, başlangıç toplantısında birlikte üzerinden geçiyoruz. Kapsam dışındaki kalemleri ve varsayımları özellikle sesli okuyoruz, çünkü sonradan sürpriz yaratan konular genellikle oradan çıkıyor. Ayrıntılı belgenin yanında tek sayfalık bir özet veriyor, her yeni aşamanın başında o aşamada neyin yapılacağını kısaca hatırlatıyoruz.
Bu adımların amacı iki tarafın proje boyunca aynı resme bakmasıdır. Neyi onayladığını bilen bir müşteri, proje sırasında daha rahat karar verir.
Proje ortasında gelen yeni istekler #
Proje ilerledikçe müşteri ürününü ya da markasını daha iyi tanır. İlk tasarımları gördükçe yeni fikirler doğar, iş yapılırken eksik bir akış fark edilir, pazarda bir şey değişir. Bu istekler çoğu zaman yerindedir ve ürünü iyileştirir.
Zorluk, bu isteklerin çoğunlukla adı konmadan gelmesidir. "Bunu da ekleyebilir miyiz", "küçük bir şey zaten" gibi cümlelerle gelen istekler tek tek bakıldığında küçük görünür. Ajans ilişkiyi korumak, projeyi aksatmamak ya da o güne kadar kurulan iyi çalışma düzenini bozmamak için çoğunu kabul eder. Tek bir istek sorun yaratmaz. Birikince takvim ve bütçe fark edilmeden kayar; proje sonunda ya kalite düşer ya da ilişki gerilir.
Bunu dile getirmek de kolay değildir. Birlikte iş yapan iki taraf arasında kapsam hatırlatması katılık ya da güvensizlik gibi algılanabilir. Konuyu ertelemek bu yüzden cazip gelir, fakat ertelenen her konuşma proje sonunda daha zor bir konuşmaya dönüşür.
Biz yeni istekleri geldiği gün kayda geçiriyor ve kapsamın içinde mi dışında mı olduğuna müşteriyle birlikte bakıyoruz. Dışındaysa üç seçenek sunuyoruz:
- İsteği bir sonraki aşamaya ya da sürüme almak.
- Kapsamdaki başka bir kalemle yer değiştirmek; takvim ve bütçe aynı kalırken öncelik değişir.
- Ek iş olarak fiyatlamak ve takvime etkisini yazılı olarak paylaşmak.
Seçenekler baştan konuşulduğunda yeni bir istek tartışmaya dönüşmez; müşteri hangi seçeneğin işine yaradığına karar verir. Küçük ve kapsamla gerçekten ilgili isteklerde esnek davranmak da bu düzenin içinde yer alır. Önemli olan, esnekliğin görünür olması ve iki tarafça bilinmesidir.
Anlaşmazlıkta belgeye dönmek #
İki taraf bir konuda farklı şeyler hatırladığında belge işe yarar. Aylar önce yapılmış bir görüşmenin ayrıntısını kimse tam olarak hatırlamaz. Yazılı kapsam, onay e-postaları, toplantı notları ve değişiklik kayıtları konuşmayı hafızadan çıkarıp ortak bir zemine taşır.
Belgeye dönerken aranan şey kimin haklı olduğu olmamalı. Bakılan, o gün neyin konuşulduğu ve neyin varsayıldığıdır. Belgenin açıkça kapsadığı ya da dışarıda bıraktığı konularda karar kolaydır. Belgenin iki türlü okunabildiği gri alanlarda ise maliyeti paylaşmak çoğu zaman iki taraf için de en sağlıklı yoldur. Böyle bir durumu, bir sonraki projede daha açık yazılması gereken bir yer olarak not etmek de işe yarar.
Belge bu noktada ancak hazırlanırken adil yazıldıysa işe yarar. Yalnızca ajansı koruyan, her riski müşteriye yükleyen bir metin kâğıt üzerinde güvence verir ama anlaşmazlık anında güveni zedeler. Kapsam belgesinin dili iki tarafın sorumluluğunu birlikte tanımlamalıdır.
Startuplarda ve sınırlı bütçede #
Erken aşamadaki girişimler çoğu zaman ayrı bir analiz bütçesi ayıramaz. Ürün henüz netleşmemiştir, kaynak sınırlıdır ve proje karşılıklı güvenle ilerler. Bu düzen iki taraf da dengeyi gözettiği sürece iyi çalışır; uzun soluklu pek çok iş birliği bu şekilde başlar.
Denge bozulduğunda risk büyür. Hızlı bir tahminle başlanmış, kapsamı geniş ve belirsiz bir projede yeni istekler eklenirken bütçe sabit kalıyorsa, taraflardan biri mutlaka kayba uğrar. Bu durumda en sağlıklı yol kapsamı daraltmaktır. İlk sürümü gerçekten gerekli olana indirmek, işi aşamalara bölmek ve her aşamayı kendi içinde fiyatlamak hem girişimin bütçesini hem ajansın emeğini korur. İlk sürümün kapsamını nasıl daralttığımızı MVP kapsamını daraltmanın üç sorusu yazımızda anlatmıştık.
Kapsam iki tarafın ortak işi #
Kapsam sorunlarını tamamen ortadan kaldıran bir yöntem yok. İyi yazılmış bir belge, birlikte okunan bir başlangıç toplantısı ve yeni istekler için baştan konuşulmuş bir düzen riski azaltır; ama bunların hepsi iki tarafın da sürece katılmasına bağlıdır.
Ajans tarafında bu, kapsamı açık yazmak, karşı tarafa aktarmak ve sınırları zamanında dile getirmek demektir. Müşteri tarafında ise onayladığı belgeyi bilmek, yeni istekleri adıyla söylemek ve seçeneklere açık olmak. İki taraf bunu birlikte yaptığında kapsam, proje boyunca herkesin başvurduğu ortak bir plan olarak kalır.
