Yazılım projesi brief'i, neyin yapılacağını ve hangi sonucun başarılı sayılacağını ortaklaştıran kısa belgedir. İyi bir brief için teknik mimari çizmeniz gerekmez. Hedef kullanıcıyı, çözmek istediğiniz işi, ilk sürümün sınırını ve henüz bilmediğiniz noktaları açık yazmanız yeterli bir başlangıçtır.
Bu belge hem web sitesi hem mobil uygulama teklifinde kullanılabilir. Özellik seçimi henüz net değilse önce MVP kapsamı rehberini okuyun; aşağıdaki şablon seçtiğiniz kapsamı ekibe aktarmak içindir.
Tekliften önce hangi bilgileri hazırlamalısınız?
Ekran listesi, kullanıcı davranışını her zaman açıklamaz. “Profil ekranı” demek yerine kişinin hangi bilgiyi değiştirebildiğini, neyin doğrulanacağını ve erişimin nasıl yönetileceğini yazın. Mevcut bir süreç varsa bugünkü işleyişi de gösterin.
Hedef ile çözüm önerisini ayırın. “Müşteri teklif durumunu görebilsin” bir ihtiyaçtır; “özel mobil uygulama yapalım” bu ihtiyacı karşılayabilecek çözümlerden biridir. Böyle yazmak, ekibin daha uygun bir yaklaşım önermesine alan bırakır.
Kopyalayabileceğiniz proje brief'i şablonu
Aşağıdaki alanları bir belgeye kopyalayın. Cevabını bilmediğiniz alanı boş bırakmak yerine “karar verilecek” yazıp sorumlusunu belirtin.
- Proje ve hedef: Kimin hangi sorununu çözüyoruz? Bugün nasıl çözülüyor?
- Kullanıcılar: Ana kullanıcı kim? Yönetici veya farklı yetkili roller var mı?
- Ana akış: Kullanıcı nereden başlıyor, hangi adımlarla sonuca ulaşıyor?
- İlk sürüm kapsamı: Bu akışı tamamlamak için zorunlu işler neler?
- Kapsam dışı: İlk sürümde özellikle yapılmayacak işler neler?
- Platform ve diller: Web, iOS veya Android? Türkçe ve İngilizce içeriği kim hazırlıyor?
- Veri ve entegrasyonlar: Ne saklanacak? Hangi sisteme bağlanılacak? Test erişimi hazır mı?
- İçerik ve tasarım: Metin, görsel, marka dosyası ve mevcut tasarımlar kimden gelecek?
- Takvim ve bütçe: Hedef tarih neden önemli? Sabit sınırlar ile esneyebilenler neler?
- Kabul ve teslim: Hangi senaryolar geçince işi tamamlanmış sayacağız? Hangi hesap ve dosyalar devredilecek?
- Bakım ve kararlar: Yayından sonra kim sorumlu? Geri bildirimleri kim birleştirip onaylıyor?
- Açık sorular: Teklif öncesi hangi belirsizliklerin araştırılması gerekiyor?
Bu alanların her biri ilk görüşmede uzun olmak zorunda değil. Özellikle varsayımları görünür kılan bir veya iki cümle, açıklamasız özellik listesinden daha işe yarar.
Doldurulmuş küçük bir örnek
Aşağıdaki örnek hayalî bir servis işletmesine aittir; Nucax müşteri referansı değildir.
Hedef: Müşteri taleplerinin e-posta içinde kaybolmasını azaltmak ve ofis ekibinin tek listeden takip etmesini sağlamak.
Ana akış: Ziyaretçi hizmet türünü seçer, kısa açıklama ve iletişim bilgisi bırakır. Yetkili çalışan talebi görür ve “yeni”, “iletişime geçildi” veya “kapandı” durumuna alır.
İlk sürüm: Talep formu, yetkili giriş, talep listesi ve durum değişikliği. Kapsam dışı: Online ödeme, müşteriye ayrı hesap ve muhasebe entegrasyonu.
Kabul örneği: Geçerli form tek talep oluşturur. Zorunlu alan boşsa anlaşılır hata gösterilir. Yetkisiz kişi talep listesini açamaz. Başarısız gönderimde kullanıcının yazdığı metin kaybolmaz.
Açık soru: Otomatik e-posta bildirimi gerekli mi, yoksa ilk sürümde panelden takip yeterli mi? Karar verilene kadar teklif bunu varsayım olarak ayrı göstermelidir.
Kabul kriterini test edilebilir yazın
“Hızlı ve modern olsun” beklentisini somut senaryoya çevirin. Örneğin telefonda formun tamamlanabilmesi, hata sonrası metnin korunması veya kayıt güncellendiğinde yeni durumun görünmesi test edilebilir davranışlardır.
Nucax'ın Nurena çalışmasında analiz öncesinde taslak saklama kararı, bu yaklaşımın ürün örneğidir. Görünür ekranın yanında kullanıcının emeğini koruyan davranışı da tarif etmek gerekir.
Gelen teklifleri aynı brief üzerinden karşılaştırın
Her ekibin dahil ettiği işleri, hariç tuttuklarını, bağımlılıklarını ve teslim kanıtını yan yana getirin. Yalnız toplam tutarı karşılaştırmayın. İçerik girişi, mağaza yayını, analiz kurulumu veya bakım bir teklifte bulunup diğerinde bulunmayabilir.
Referans site paylaşıyorsanız neyi beğendiğinizi belirtin: gezinme, okunabilirlik veya form akışı gibi. “Aynısını istiyorum” ifadesi hem kapsamı hem özgün tasarım ihtiyacını belirsiz bırakır.
Sık sorulan sorular
Teknik terimleri bilmek zorunda mıyım?
Hayır. Mevcut süreci ve istediğiniz sonucu anlatın. Teknoloji kararının gerekçesini ekipten isteyin; bilmediğiniz entegrasyonlar için araştırma adımı planlanabilir.
Bütçemi paylaşmalı mıyım?
Varsa bir aralık veya üst sınır paylaşmak, hangi kapsamın değerlendirileceğini netleştirir. Kapsam henüz belirsizse önce keşif çıktısı ve sonraki teklifin nasıl oluşacağını konuşun.
Brief yazınca kapsam bir daha değişemez mi?
Değişebilir. Değişikliğin maliyet, takvim ve kabul kriterine etkisini kayda alın. Ürün tasarımı hizmetimiz ihtiyaçları akışa dönüştürür; hazırladığınız kısa özeti proje başlangıç formuyla paylaşabilirsiniz.