Yazılım Projesi Briefi Nasıl Yazılır? (Şablonlu)

Aynı projeye üç firmadan alınan teklifler arasında büyük fark varsa sebep genelde firmalar değil, brief. Belirsiz brief, her firmanın farklı bir şey anlamasına yol açıyor ve teklifler kıyaslanamaz hâle geliyor.

Aşağıdaki sekiz başlık, çoğu proje için yeterli bir brief oluşturuyor. Teknik bilgi gerektirmiyor.

1. Problem

Çözüm değil, sorunu yazın. En sık hata brief'e doğrudan çözümle başlamak: "Bir mobil uygulama istiyoruz." Bu cümle firmayı düşünmekten alıkoyar.

Bunun yerine: "Saha ekibimiz servis formlarını kâğıda dolduruyor, ofise dönüp sisteme giriyor. Günde ortalama iki saat kaybediliyor ve formların bir kısmı kayboluyor."

İkinci ifade, firmanın belki de daha ucuz bir çözüm önermesini mümkün kılıyor.

2. Kullanıcılar

Kim kullanacak? Her kullanıcı tipi için üç şey yazın: kim olduğu, ne yapacağı, hangi ortamda kullanacağı.

• Saha teknisyeni — form dolduruyor, sahada, çoğu zaman internetsiz
• Ofis sorumlusu — formları görüyor ve onaylıyor, bilgisayardan
• Yönetici — aylık rapor bakıyor, telefondan

Bu liste, ürünün kaç ayrı arayüz gerektireceğini doğrudan belirliyor — yani maliyetin en büyük belirleyicilerinden biri.

3. Kapsam: olmazsa olmaz / olsa iyi olur / şimdilik hayır

Brief'in en değerli bölümü bu. Her isteği üç kutudan birine koyun:

Üçüncü kutu firmaya çok şey anlatıyor: neyi düşünüp bilerek dışarıda bıraktığınızı gösteriyor. Bu, brief'in olgunluk göstergesi.

4. Mevcut durum

Bugün bu iş nasıl yapılıyor? Hangi araçlar kullanılıyor — Excel, WhatsApp, kâğıt, mevcut bir yazılım? Varsa ekran görüntüsü ekleyin.

Ayrıca bağlanması gereken sistemleri yazın: muhasebe programı, ERP, e-ticaret altyapısı, ödeme sağlayıcısı. Entegrasyonlar maliyetin en çok saptığı kalem ve brief'te görünmediğinde teklifler eksik çıkıyor.

5. Başarı ölçütü

Proje bittiğinde neye bakarak "oldu" diyeceksiniz? Somut yazın:

• "Form doldurma süresi 20 dakikadan 5 dakikaya insin"
• "Kayıp form oranı sıfırlansın"
• "Aylık raporu hazırlamak yarım gün yerine yarım saat sürsün"

Bu ölçütler hem firmaya doğru çözümü seçtiriyor hem de teslimde tartışmayı bitiriyor.

6. Kısıtlar

Gerçek kısıtları yazın; yazmamak süreci uzatıyor:

• Bütçe aralığı. "Teklif verin" demek yerine aralık vermek zaman kazandırıyor.
• Takvim. Sabit bir tarih varsa (fuar, sezon, denetim) mutlaka yazın.
• Teknik kısıtlar. Kurum içi sunucu zorunluluğu, veri yurt içinde kalma şartı, mevcut altyapıyla uyum.
• Kurumsal kısıtlar. Onay süreçleri, bilgi güvenliği politikaları.

Bütçe aralığı vermek pazarlık gücünüzü düşürmez; kapsamı gerçekçi tutar. Aralık bilmeyen firma ya fazlasını önerip pahalı görünür ya azını önerip eksik kalır.

7. İşin sizde kalan kısmı

Projede sizin sorumluluğunuzda olacaklar: içerik ve metinler, görseller, test edecek kişiler, karar verici kim, onay süresi ne kadar.

Bu bölüm gecikmelerin en büyük sebebini önlüyor. Yazılım projelerinde takvimin kayması sıklıkla firmadan değil, müşteri tarafındaki onay ve içerik gecikmelerinden kaynaklanıyor.

8. Ekler

• Mevcut sistemin ekran görüntüleri
• Örnek form, rapor ya da belge
• Beğendiğiniz benzer ürünler ve neyini beğendiğiniz
• Marka kılavuzu ya da logo dosyaları

Üçüncü madde önemli: "şu uygulama gibi olsun" tek başına yeterli değil. Neyini beğendiğinizi yazın — akışını mı, sadeliğini mi, hızını mı.

Sık yapılan hatalar

• Çözümle başlamak. Problemi anlatmadan teknoloji seçmek.
• Her şeyi öncelikli yapmak. Hepsi olmazsa olmaz ise hiçbiri değildir.
• Bütçeyi gizlemek. Teklifleri kıyaslanamaz hâle getiriyor.
• Teknik terim kullanmaya çalışmak. Yanlış terim, yanlış çözüme yol açıyor. Kendi dilinizle yazın.
• Tek sayfa yerine otuz sayfa yazmak. Uzun brief okunmuyor; öncelik listesi olmayan uzun belge, kısa belgeden kötü.

Brief hazır — sonra ne olacak?

Brief'i birden fazla firmaya aynı biçimde gönderin. Gelen teklifleri kıyaslarken bakılacak ilk şey fiyat değil, firmanın brief'i ne kadar anladığı: kapsam dışı bıraktıklarınıza değinmiş mi, eksik gördüğü yerleri sormuş mu.

Teklif değerlendirme aşamasında sorulacak soruları yazılım ajansı seçerken sorulacak 12 soru yazısında, sözleşme aşamasını ise sözleşme rehberinde ele aldık.

Devamı için

Brief'i yazmadan önce fikrin karşılığı olduğundan emin olmak isterseniz uygulama fikri nasıl doğrulanır, kapsamı dar tutmak için MVP 6 haftada nasıl çıkarılır yazılarına bakın. Bütçe aralığı belirlerken mobil uygulama fiyatları sayfasındaki bandlar işinizi görür. Hazır briefinizi bize iletebilirsiniz.