Web sitesi projelerinde anlaşmazlıkların büyük kısmı kötü niyetten değil, yazılmamış bir cümleden çıkar. İşletme "site yapılacak" der, tedarikçi "site yapılacak" diye anlar, ikisi de aynı kelimeyi kullanır ve altı hafta sonra ortaya çıkan şey ikisinin de kastettiği şey değildir. Metinleri kim yazacaktı, kaç tur revizyon vardı, "yayında" ne demekti — bunların hiçbiri konuşulmadıysa cevabı işin ortasında, gergin bir toplantıda aranır.
Brief bu boşluğu kapatan belgedir. Türkçe kaynaklarda bu başlıkta bulunan içeriğin büyük çoğunluğu ya metin yazarlığı hizmeti satan sayfalar ya da teklifin nasıl değerlendirileceğini anlatan yazılar. İkisi de faydalı ama ikisi de aynı boşluğu bırakıyor: teklifi karşılaştırabilmek için önce karşılaştırılabilir bir talep yazmak gerekir, ve o talebi yazan taraf işletmedir.
Aşağıdaki metin brief'i bir istek listesi olarak değil, kapsamın taslağı olarak ele alıyor: hangi alanlar doldurulmalı, kapsam dışı nasıl yazılır, revizyon nasıl tanımlanır ve teslim ölçütü neye benzer.
Brief bir istek listesi değil, kapsamın taslağıdır
Çoğu brief bir dilek listesi biçiminde yazılır: modern olsun, hızlı olsun, rakiplerimiz gibi olmasın. Bu cümlelerin hiçbiri kapsam üretmez, çünkü hiçbirinin karşılığı "yapıldı" ya da "yapılmadı" diye işaretlenemez.
İşe yarayan brief, sonunda sözleşmeye dönüşebilecek cümlelerden kurulur. Ölçüt şudur: brief'teki her madde, proje bittiğinde iki tarafın da aynı biçimde "tamam" diyebileceği bir ifade olmalı. "Modern bir tasarım" bu ölçütü geçmez; "üç şablon tasarlanacak: ana sayfa, hizmet sayfası ve yazı sayfası" geçer.
Bu, brief'in teknik bir belge olması gerektiği anlamına gelmiyor. İşletme tarafının teknik bilgisi olmayabilir ve olması da gerekmez. Gerekli olan, isteklerin sayılabilir ve gözlenebilir hâle getirilmesi. Kaç sayfa, hangi diller, hangi işlevler, metni kim yazıyor, hangi tarihte neyin hazır olması bekleniyor.
Brief'te mutlaka bulunması gereken sekiz alan
Aşağıdaki sekiz alan doldurulduğunda gelen tekliflerin karşılaştırılabilir olma ihtimali belirgin biçimde artar.
İşin amacı. Site neden yapılıyor: yeni müşteri talebi mi, mevcut müşteriye bilgi vermek mi, işe alım mı, hepsi mi. Amaç sayfaların önceliğini belirler.
Kitle. Siteye kim gelecek ve hangi soruyla gelecek. İki farklı kitle varsa ikisi de yazılır.
Sayfa listesi. Kesin olmasa da bir ilk liste. Liste yoksa teklif veren taraf kendi varsayımını kullanır ve iki teklif farklı sayıda sayfa üzerinden fiyatlanır.
İçerik durumu. Metinler var mı, kısmen mi var, hiç mi yok. Görseller ve logo dosyaları elde mi. Bu alan projenin süresini en çok etkileyen kalemdir.
İşlevler. Form, çok dillilik, üyelik, arama, rezervasyon, harita, canlı destek gibi kalemler tek tek yazılır. "Standart bir site" ifadesi iki tarafta iki farklı şey demektir.
Teknik kısıtlar. Mevcut alan adı, mevcut hosting, kurumsal e-posta düzeni, marka kılavuzu ve kullanılması zorunlu araçlar.
Takvim beklentisi. Sabit bir tarih varsa nedeni de yazılır: bir fuar, bir lansman ya da bir sözleşme yenilemesi. Neden yazıldığında tedarikçi hangi kalemin kısaltılabileceğini söyleyebilir.
Karar süreci. Kim onaylıyor, kaç kişi onaylıyor, geri bildirim ne kadar sürede geliyor. Bu alan brief'lerde neredeyse hiç bulunmaz ve süreyi en çok belirleyen kalemdir.
Kapsamın dışında kalanı yazmak: en pahalı iki cümle
Brief'lerin çoğu ne yapılacağını yazar, ne yapılmayacağını yazmaz. Oysa anlaşmazlıklar neredeyse her zaman ikinci listeden çıkar.
Kapsam dışı yazmak tedarikçiyi korumak için değil, iki tarafı da korumak içindir. İşletme, dahil sandığı bir işin dahil olmadığını proje ortasında değil başında öğrenir; tedarikçi de yazılmamış bir beklentiyi karşılamak zorunda kalmaz.
Kurumsal site projelerinde en sık tartışma çıkaran kalemler şunlardır: metin yazımı, fotoğraf çekimi, logo ve marka kimliği çalışması, ürün veya hizmet verisinin girilmesi, mevcut siteden içerik aktarımı, çok dilli sürümün çevirisi, yayın sonrası bakım ve eğitim. Bunların her biri için brief'te tek satır yeterlidir: dahil, dahil değil ya da ayrıca fiyatlanacak.
İkinci pahalı cümle "ve benzeri" ifadesidir. Kapsam listesinin sonuna eklenen bu iki kelime, listenin tamamını belirsizleştirir. Liste kapalı olmalı; sonradan ekleme yapılacaksa yöntemi yazılmalı.
İçerik kimde: metin, görsel ve veri sorumluluğu
Web projelerinin gecikme nedenlerinin başında bekleyen metin gelir. Tasarım biter, geliştirme biter, sayfa yapay metinle yayına hazır bekler ve proje haftalarca askıda kalır.
Sorumluluk paylaşımını brief'te üç kalemde ayırmak bu riski görünür kılar.
Metin. Üç seçenek var: işletme yazar, tedarikçi yazar, işletme taslak verir tedarikçi düzenler. Üçünün maliyeti ve süresi farklıdır. Tedarikçi yazacaksa neye dayanarak yazacağı da belirtilmeli — görüşme mi, mevcut belgeler mi, satış sunumu mu.
Görsel. Gerçek mekan, ekip ve iş fotoğrafı var mı, çekim yapılacak mı, stok görselle mi ilerlenecek. Bu üçünün sonucu birbirinin yerine geçmez; stok görselle kurulan bir kurumsal sayfa, işletmenin kendi gerçekliğini göstermez.
Veri. Hizmet listeleri, ekip bilgileri, referanslar, sertifikalar, iletişim bilgileri ve varsa fiyat tabloları. Bu verinin kimde olduğu ve kimin doğruluğundan sorumlu olduğu yazılmalı; özellikle mevzuata tabi sektörlerde nihai kontrol işletmededir.
Her kalem için tek bir sorumlu isim yazmak, "ekip halleder" ifadesinden çok daha iyi sonuç verir.
Revizyon turu nasıl tanımlanır, "sınırsız revizyon" neden kötüdür
"Sınırsız revizyon" ifadesi ilk bakışta işletmenin lehine görünür. Uygulamada ikisi için de kötü sonuç verir, çünkü kapsamı belirsizleştirir ve belirsiz kapsam iki yerden birine yansır: fiyata ya da işin kalitesine.
Sağlıklı tanım şu üç parçayı içerir.
Tur nedir. Bir revizyon turu, geri bildirimlerin toplu olarak iletildiği tek bir döngüdür. Beş ayrı e-postayla gelen beş ayrı istek beş tur değil, bir turun parçalarıdır — ama bu ancak yazıldıysa böyledir.
Kaç tur var. Tasarım aşamasında ve geliştirme aşamasında ayrı ayrı belirtilir. İki tur çoğu proje için makul bir başlangıçtır.
Tur dışı ne sayılır. Onaylanmış bir karara geri dönmek revizyon değil, kapsam değişikliğidir. Örneğin sayfa planı onaylandıktan sonra yeni sayfa eklemek bir revizyon turu değildir; ayrıca değerlendirilir.
Bu tanım yazıldığında geri bildirim kalitesi de artar: taraflar geri bildirimi biriktirip tek seferde vermeye başlar ve dağınık, birbiriyle çelişen istekler azalır.
Teslim kriteri: "yayında" ne demek
Projeyi bitiren cümle "site yayında" değildir; "kabul testinden geçti"dir. Kabul testi, brief'te önceden yazılmış ve iki tarafın da aynı biçimde okuyabileceği bir kontrol listesidir.
Kurumsal site projeleri için bu listenin çekirdeği genellikle şunları içerir: tüm sayfalar doğru adreslerinden açılıyor, mobil ve masaüstünde düzen bozulmuyor, formlar gerçek bir gönderimle test edildi ve e-posta ulaştı, sayfa içeriği kaynakta görünüyor, arama motoru engeli kalmadı, site haritası ve robots dosyası doğru, analitik kurulumu çalışıyor, yönetim erişimleri işletmenin adına devredildi.
Son madde özellikle önemli ve teslimin ayrılmaz parçası: alan adı, hosting, yönetim paneli ve ölçüm araçlarının kimin adına olduğu teslim anında netleşmeli. Bu kalemin tam listesini ve devir sırasını dijital varlık mülkiyeti ve devir kontrol listesi yazımızda ayrıntılı çıkardık.
Teknik kabul ölçütlerinin neden bu kalemlerden oluştuğunu ve her birinin nasıl doğrulanacağını KOBİ web sitesi altyapı rehberimizde anlattık.
Süreyi belirleyen gerçek kalem: onay döngüsü
Teklif aşamasında konuşulan süre genellikle üretim süresidir: tasarım kaç hafta, geliştirme kaç hafta. Gerçek takvimi belirleyen kalem ise çoğu zaman bu değil, onay döngüsüdür.
Basit bir gözlem: aynı kapsamdaki iki proje, biri tek karar vericiyle ve iki günde dönen geri bildirimle, diğeri beş kişilik bir onay komitesiyle ve iki haftada dönen geri bildirimle yürütüldüğünde belirgin biçimde farklı sürede biter. Üretim süresi aynıdır; fark bekleme süresindedir.
Bu yüzden brief'te karar sürecinin yazılması bir formalite değil. Yazılması gerekenler: nihai onayı kim veriyor, ara onaylar kimden geçiyor, geri bildirim için taahhüt edilen süre ne, tatil ve yoğun dönemler var mı.
Aynı şekilde, sabit teslim tarihi vaat eden bir teklif de dikkatle okunmalı: içerik işletmeden gelecekse ve onay süresi belirsizse, o tarihi tek taraflı olarak tedarikçi tutamaz.
Fiyat farkını okumak: aynı işi anlatan iki teklif neden farklı
İki teklif arasındaki fark çoğu zaman aynı işin farklı fiyatlanması değil, farklı işlerin aynı adla anlatılmasıdır. Farkı okumanın yolu tutara değil kapsam satırlarına bakmaktır.
Farkı yaratan tipik kalemler şunlardır: şablon sayısı (üç şablonla on şablon aynı iş değildir), metin yazımının dahil olup olmaması, çok dilli sürüm, hazır tema üzerine kurulum ile özel geliştirme ayrımı, teslim sonrası bakım süresi, eğitim ve dokümantasyon, ölçüm kurulumunun kapsamı.
Ücretlendirme modeli de farkı büyütür. Sabit fiyat, kapsam net olduğunda iki taraf için de öngörülebilirdir. Aşamalı ödeme, kapsamın aşama aşama netleştiği projelerde daha adildir. Zaman bazlı çalışma ise kapsamın baştan yazılamadığı işlerde kullanılır ama bu durumda üst sınır ve raporlama biçimi yazılmalıdır.
Karşılaştırmayı mümkün kılan tek şey, tekliflerin aynı brief'e cevap vermesidir. Farklı brief'lere verilmiş iki teklif karşılaştırılamaz; yan yana konabilir, o kadar. Bir tedarikçinin çalışma biçimini ve raporlama disiplinini nasıl sorgulayacağınıza dair dokuz soruluk bir seti mevcut ajansınızı denetleme yazımızda toplamıştık; aynı sorular yeni bir tedarikçiyi değerlendirirken de çalışıyor. Ücret modellerinin işleyişini ve modelin yarattığı teşvikleri ise ajans ücret modelleri yazımızda ayrı olarak ele aldık.
Bakım, güncelleme ve destek teslimin neresinde
Teslimden sonra site kendi başına ayakta durmaz. Yazılım güncellemeleri, sertifika yenilemeleri, yedekleme, içerik ekleme ve küçük düzeltmeler devam eden işlerdir ve brief'te bunların kimin sorumluluğunda olduğu yazılmalıdır.
Üç model yaygın. Kendi ekibiniz yürütür: bu durumda teslimde eğitim ve dokümantasyon istemek gerekir. Tedarikçi bakım anlaşmasıyla yürütür: kapsamın ne olduğu — kaç saat, hangi işler dahil, acil müdahale süresi — yazılır. Karma model: içerik girişi işletmede, teknik bakım tedarikçide.
Hangi model seçilirse seçilsin, brief'te tek bir cümle netleştirilmeli: teslim tarihinden itibaren hangi işler ücretsiz destek kapsamındadır ve bu süre ne kadardır.
Brief şablonu
Aşağıdaki liste kopyalanıp doldurulabilir. Her satır tek cümleyle cevaplanmalı; cevaplanamayan satır projenin en riskli yeridir.
- Sitenin amacı ve başarı ölçütü
- Hedef kitle ve geldikleri sorular
- Sayfa listesi ve her sayfanın karşıladığı soru
- Diller ve hangi sayfaların çevrileceği
- İşlev listesi (form, arama, rezervasyon, üyelik vb.)
- Metin, görsel ve veri sorumlulukları (isim isim)
- Kapsam dışı kalemler
- Revizyon turu sayısı ve turun tanımı
- Kabul testi maddeleri
- Takvim ve onay süreci
- Ücretlendirme modeli ve ödeme aşamaları
- Teslimde devredilecek erişimlerin listesi
- Teslim sonrası bakım ve destek kapsamı
Kapsam, revizyon ve teslim ölçütlerini nasıl yazdığımızı görmek isterseniz kurumsal web sitesi hizmet sayfamıza bakabilir, kendi brief'inizi birlikte çıkarmak için bize ulaşabilirsiniz.
Sıkça Sorulan Sorular
Brief'i biz mi yazmalıyız, ajans mı çıkarmalı?
En sağlıklısı ikisinin sırayla yapılması. İşletme ilk taslağı yazar — amacı, kitleyi, sayfa fikrini, içerik durumunu ve takvim beklentisini kendi diliyle anlatır. Tedarikçi bu taslağı okuyup eksik ve çelişkili yerleri soru olarak geri gönderir, kapsam bu turda netleşir. İlk taslağı tamamen tedarikçiye bırakmanın sakıncası şu: brief teklif veren tarafın varsayımlarıyla dolar ve o brief'le alınan tekliflerin karşılaştırılması zorlaşır. İşletmenin teknik bilgisi olması gerekmez; gerekli olan işini bilmesidir.
Ne kadar detay çok detaydır?
Ölçüt şu: brief, sonucun nasıl görüneceğini değil, neyin karşılanması gerektiğini yazmalı. Hangi sayfaların olacağını, hangi işlevlerin gerektiğini, kimin ne yazacağını ayrıntılı belirtmek faydalıdır. Buna karşılık düğmenin rengini, yazı tipini ve bölümlerin sırasını brief'te sabitlemek, tedarikçinin çözüm üretmesini engeller ve genellikle daha kötü bir sonuç verir. Pratik bir sınır: bir madde "yapıldı mı" diye işaretlenebiliyorsa brief'e girer, "beğenildi mi" sorusuna bağlıysa tasarım aşamasına bırakılır.
Sabit fiyat mı, aşamalı ödeme mi?
Kapsamın netliğine bağlı. Sayfa listesi, işlevler ve içerik sorumlulukları baştan yazılabiliyorsa sabit fiyat iki taraf için de öngörülebilirdir. Kapsam ancak keşif çalışmasından sonra netleşecekse, önce keşfin ayrı bir aşama olarak fiyatlanıp kalan işin o çıktıya göre teklif edilmesi daha gerçekçidir. Hangi model seçilirse seçilsin, ödemenin aşamalara ve teslim edilen somut çıktılara bağlanması — tasarım onayı, geliştirme tamamlanması, kabul testi — belirsizliği azaltır.
Teslimden sonra değişiklik istersek ne olur?
Bu, brief'te önceden cevaplanması gereken bir soru. İki kategori ayrılmalı: hata düzeltme ve yeni istek. Kabul testinde tanımlanmış bir ölçütün karşılanmaması hatadır ve düzeltilmesi teslimin parçasıdır. Onaylanmış kapsamın dışında kalan yeni bir istek ise yeni bir iştir ve ayrıca değerlendirilir. Bu ayrımın brief'te yazılı olması, teslim sonrası dönemi en çok geren tartışmayı baştan çözer. Ayrıca ücretsiz destek süresinin ne kadar olduğu da aynı bölümde belirtilmelidir.
Aynı brief'i kaç ajansa göndermeliyiz?
Üç ile beş arası çoğu proje için yeterli bir aralık. Daha azı karşılaştırma imkânı bırakmaz; daha fazlası değerlendirme yükünü işletmenin taşıyamayacağı bir noktaya çıkarır ve gelen tekliflerin her birine hakkını vermek zorlaşır. Önemli olan sayıdan çok tutarlılık: hepsine aynı brief gitmeli, aynı sorular sorulmalı ve teklifler aynı sütunlarda karşılaştırılmalı. Farklı brief'lere ya da farklı sözlü açıklamalara verilmiş teklifler karşılaştırılabilir değildir.