İyi bir proje brief’i nasıl yazılır?

İyi bir brief, ne istediğinizi değil hangi sorunu yaşadığınızı anlatır. “Yeni bir site istiyoruz” bir çözüm önerisidir; “müşteriler telefonda fiyat soruyor, kimse siteye bakmıyor” bir problem tarifidir. İkincisi çok daha kullanışlı çünkü çözümü açık bırakıyor.

Bu yazı hem bize brief yazacaklar hem de başka bir ekiple çalışacaklar için.

Brief’te olması gerekenler

1. Bugün ne oluyor

Mevcut durum. Neyi nasıl yapıyorsunuz, hangi araçları kullanıyorsunuz, kim ne yapıyor. Süslemeden.

2. Neyi sorun olarak görüyorsunuz

Somut örnekle. “Süreç verimsiz” yerine “bir teklif hazırlamak yarım gün sürüyor ve iki kişinin onayı gerekiyor”.

3. Başarı neye benziyor

Proje bittiğinde neyin değişmiş olmasını istiyorsunuz? Bu, ölçülebilir olmak zorunda değil ama gözlenebilir olmalı. “Teklif aynı gün çıkabilsin” iyi bir hedef.

4. Sınırlar

Bütçe aralığı, takvim, değiştirilemeyecek şeyler. Kullanılmak zorunda olan bir program, uyulması gereken bir kurumsal kimlik, dokunulamayacak bir sistem.

Bütçeyi söylememek yaygın bir refleks ama işe yaramıyor. Aralık verilmezse hazırlanan öneri ya çok büyük ya çok küçük çıkıyor; iki tur boşa gidiyor.

5. Kim karar veriyor

Tek isim. Birden fazla kişi karar veriyorsa ve aralarında hiyerarşi yoksa proje uzuyor — bu neredeyse istisnasız.

6. Beğendikleriniz ve beğenmedikleriniz

Örnek göstermek en hızlı iletişim yolu. Beğenmedikleriniz beğendiklerinizden daha bilgilendirici çoğu zaman.

Uyarı işareti cümleler

Brief’te şu cümleleri görünce durup soruyoruz:

• “Basit bir şey.” Genelde değil. Basit olduğu düşünülen işler, tarif edilmemiş işlerdir.
• “Rakiplerimizdeki gibi ama daha iyi.” Neyin daha iyi olduğu tanımlanmadan bu ölçülemez.
• “Şimdilik böyle yapalım, sonra bakarız.” Sonra bakılan şeylerin baştan yapılması genelde daha ucuz.
• “Herkese hitap etmeli.” Kimseye hitap etmiyor demek.
• “Bütçe önemli değil.” Her zaman önemli. Söylenmemesi tercih edilmiş oluyor.

Brief kısa olabilir

Uzunluk kalite göstergesi değil. Yukarıdaki altı başlığa birer paragraf, çoğu proje için yeterli.

Uzun ve dağınık bir brief, kısa ve net olandan daha kötü. Otuz sayfalık dokümanların içinde kararın nerede olduğu kaybolabiliyor.

Brief bittikten sonra

Bizim tarafta ilk yaptığımız şey brief’i kendi cümlelerimizle geri yazmak: “Anladığımız şu.” Bu adım gereksiz görünür ama yanlış anlamaların büyük kısmını burada yakalıyoruz.

Yanlış anlaşılma en ucuz burada düzeltiliyor. Uygulama başladıktan sonra düzeltmenin maliyeti kat kat artıyor. Sürecimizin ilk adımının keşif olması bu yüzden.

Sık sorulanlar

Teknik bilgim yok, brief yazabilir miyim?

Evet. Teknik çözümü tarif etmeniz beklenmiyor, zaten istenmiyor. Problemi ve bugünkü durumu anlatmanız yeterli.

Bütçe aralığı vermek pazarlık gücümü düşürür mü?

Pratikte tersi oluyor. Aralık bilinmeden hazırlanan öneriler ya kapsamı şişiriyor ya eksik kalıyor; iki durumda da zaman kaybediyorsunuz.

Brief’i sonradan değiştirebilir miyim?

Değişiklik normal. Önemli olan değişikliğin ne zaman geldiği: tasarım aşamasındaki değişiklik ucuz, uygulama bittikten sonraki pahalı.

Örnek bir brief şablonunuz var mı?

Yukarıdaki altı başlık şablonun kendisi. Her başlığa bir paragraf yazmak yeterli, form doldurmaya gerek yok.