Bir projenin zorlaşacağını çoğu zaman ilk toplantıda anlarsınız. Teknoloji seçimi ya da tasarım tercihi yüzünden değil; herkesin "web sitesi yenileme" derken farklı bir şey kastettiği ortaya çıktığı için. Brief, bu farkın işin ortasında değil başında görülmesini sağlayan belgedir. İyi yazılmış bir brief, yaratıcılığı kısıtlamaz; tam tersine, tartışılacak konuları netleştirerek yaratıcı enerjiyi doğru yere yönlendirir.
Brief'in olması gereken bölümleri
- Problem tanımı. Çözülmek istenen iş sorunu, çözümün kendisinden önce yazılır. "Yeni bir site istiyoruz" bir çözümdür; "teklif taleplerinin çoğu eksik bilgiyle geliyor ve satış ekibi her birine tek tek dönmek zorunda kalıyor" bir problemdir. İkincisi, tasarıma yön verir.
- Hedefler ve başarı ölçütleri. Proje bittiğinde neyin değişmiş olacağı ve bunun nasıl ölçüleceği. Ölçüt sayısal olmak zorunda değildir, ama gözlemlenebilir olmalıdır.
- Hedef kitle. Kimin için yapıldığı, bu kişilerin hangi bağlamda ve hangi cihazla geldiği, ne bildikleri ve neyi bilmedikleri.
- Kapsam. Teslim edilecek somut çıktılar: sayfa şablonları, panel modülleri, entegrasyonlar, içerik üretimi, dil sayısı.
- Kapsam dışı. Bu bölüm çoğu brief'te yoktur ve tam da bu yüzden projeler büyür. Neyin bu projede yapılmayacağını yazmak, sonraki tartışmaların yarısını baştan çözer.
- Kısıtlar. Bütçe aralığı, takvim, mevcut altyapı, marka kuralları, yasal ve kurumsal gereklilikler, teknoloji tercihleri.
- Varsayımlar. Doğru kabul ettiğiniz ama doğrulanmamış her şey. "İçerikler müşteri tarafından sağlanacak" bir varsayımdır ve yanlış çıktığında takvimi tek başına bozar.
- Karar mekanizması. Kimin görüş verdiği, kimin onayladığı ve geri bildirimlerin nasıl toplandığı.
Kapsam dışını yazmanın gücü
Kapsam kayması nadiren tek büyük bir talep olarak gelir. Genellikle "küçük bir ekleme" biçiminde, haftalara yayılmış onlarca istekten oluşur ve her biri tek başına makuldür. Toplamları ise projeyi bambaşka bir yere taşır. Kapsam dışı listesi, bu isteklerin reddedilmesi için değil, görünür kılınması için vardır. "Bu, ilk fazın kapsamı dışında; ikinci faz için değerlendirelim" cümlesi, ancak yazılı bir kapsam varsa kurulabilir.
Aynı mantık değişiklik yönetimi için de geçerlidir. Kapsam değişikliği yasak değildir; proje ilerledikçe öğrenilen şeyler doğal olarak yön değiştirtir. Yapılması gereken, her değişikliğin etkisini üç boyutta açıkça ifade etmektir: takvim, bütçe ve kapsamın başka bir parçasından vazgeçme. Bu üçünden hiçbiri değişmeden kapsam ekleniyorsa, ödemeyi kalite yapar.
Keşif fazı: bilinmeyeni fiyatlamayın
Bazı projelerde brief aşamasında yeterli bilgi yoktur. Mevcut sistemin karmaşıklığı, veri kalitesi ya da entegrasyon zorluğu bilinmiyorsa, sabit fiyatlı bir teklif ya ekibi ya müşteriyi zarara sokar. Bu durumda doğru yaklaşım, kısa ve ayrı fiyatlanan bir keşif fazıdır: mevcut durumu inceleyip, riskleri listeleyip, kapsamı ve tahmini gerçek verilere dayandırmak. Keşif fazının çıktısı bir belge değil, uygulanabilir bir plan olmalıdır.
Kabul ölçütü yoksa iş bitmez
"Tamamlandı" sözcüğünün ne anlama geldiği önceden tanımlanmazsa, teslim aşaması pazarlığa döner. Her çıktı için kabul ölçütü yazın: hangi tarayıcılarda, hangi ekran boyutlarında, hangi performans ve erişilebilirlik eşiklerinde, hangi içerik doluluğunda kabul edilecek? Bu ölçütler hem ekibin neyi hedeflediğini netleştirir hem de geri bildirimlerin kişisel zevk yerine anlaşmaya dayanmasını sağlar.
Geri bildirim döngüsünü de baştan kurgulayın. Dağınık kanallardan gelen, birbiriyle çelişen yorumlar en yavaşlatıcı etkendir. Tek bir kanal, tek bir birleştirilmiş liste ve her tur için tanımlı bir süre; bu üç kural revizyon sayısını kendiliğinden düşürür.
Riskleri baştan konuşun
Her projede birkaç bilinen risk vardır: içeriğin geç gelmesi, üçüncü taraf bir sistemin belgelenmemiş davranışı, onay verecek kişinin uzun süre erişilemez olması. Bunları başta yazmak kötümserlik değil, hazırlıktır. Her risk için etkiyi, olasılığı ve gerçekleşirse ne yapılacağını tek satırla belirtin. Sürprizlerin çoğu, aslında konuşulmamış risklerdir.
Fazlara bölmek, kapsamı küçültmek değildir
Büyük projelerde en işe yarayan araç, işi anlamlı fazlara bölmektir. Buradaki incelik, fazın kendi başına değer üretmesidir. "Tasarım fazı" ve "geliştirme fazı" gibi bölünmeler, ilk faz bittiğinde ortada kullanılabilir hiçbir şey bırakmaz. Bunun yerine dikey dilimleyin: birinci faz, kurumsal sayfalar ve teklif akışıyla yayına girsin; ikinci faz kariyer ve başvuru modülünü eklesin; üçüncü faz çok dilli yapıyı getirsin. Her faz sonunda çalışan bir ürün olur.
Bu yaklaşım aynı zamanda öğrenmeyi hızlandırır. İlk faz yayına girdiğinde gerçek kullanıcı davranışını görürsünüz ve sonraki fazların kapsamını varsayımlara değil gözlemlere göre güncelleyebilirsiniz. Böylece brief, dondurulmuş bir sözleşme değil, canlı bir yol haritası hâline gelir.
Brief bittiğinde son bir kontrol yapın: bu belgeyi projeye hiç dahil olmamış bir meslektaşınıza verseniz, neyin neden yapıldığını anlayabilir mi? Cevap evetse belge işini görüyordur. Kapsam ve süreç kurgusunu birlikte netleştirmek isterseniz teklif sihirbazımız üzerinden başlayabiliriz.
