İyi Bir Yazılım Brief’i Nasıl Hazırlanır? (Şablon)

Bir geliştiriciye “bize de şu uygulamadaki gibi bir sistem lazım” diye yazdığınızda, karşı taraf aklındaki en olası senaryoyu fiyatlar. Siz başka bir şey düşünüyorsanız, ilk toplantıdan itibaren iki farklı projeden söz ediyor olursunuz. Yazılım projesi brief dokümanı, bu yanlış anlaşılmayı baştan önleyen kısa bir özet metindir. Bu yazıda teknik bilgi gerektirmeden doldurabileceğiniz bir şablon paylaşıyor ve her başlığın neden önemli olduğunu anlatıyorum.

Brief nedir, ihtiyaç analizinden farkı ne?

Brief, işletmenin kendi bakış açısıyla hazırladığı, projeyi bir iki sayfada anlatan başlangıç dokümanıdır. Amacı, geliştiricinin projeyi anlamasını ve ilk teklifi verebilmesini sağlamaktır. Teknik terim içermesi gerekmez; sizin işinizi ve sorununuzu anlatması yeterlidir.

İhtiyaç analizi ise brief’ten sonra, genellikle geliştiriciyle birlikte yapılan daha ayrıntılı çalışmadır. Ekranlar, veri yapısı, iş kuralları ve istisnalar burada netleşir. Bu aşamayı yazılım projesi ihtiyaç analizi yazısında anlattım. Kısacası brief kapıyı açar, ihtiyaç analizi odaları tek tek gezer.

Yazılım projesi brief şablonu

Aşağıdaki başlıkları sırayla doldurmanız yeterli. Her başlığa birkaç cümle yazmak, hiç yazmamaktan çok daha değerlidir.

1. İşletme ve proje özeti

İşletmeniz ne yapıyor, kaç kişilik bir ekip, kaç şubeniz var? Ardından projeyi tek cümleyle özetleyin: “Saha ekibimizin servis kayıtlarını telefondan girebileceği bir sistem istiyoruz” gibi.

2. Bugün yaşanan sorun

Yazılım hangi sorunu çözecek? Şu an bu işi nasıl yapıyorsunuz: Excel, kâğıt, WhatsApp grupları ya da hazır bir program mı? Mevcut yöntemin hangi noktada tıkandığını yazın. Bu bölüm, geliştiricinin önceliği doğru belirlemesini sağlar.

3. Hedef ve başarı ölçütü

Proje başarılı olursa ne değişecek? “Sipariş hatalarının azalması”, “gün sonu raporunun elle hazırlanmaması” ya da “müşterilerin telefonla aramadan randevu alabilmesi” gibi somut hedefler yazın.

4. Kullanıcılar ve roller

Sistemi kimler kullanacak? Yönetici, muhasebe, saha personeli, müşteri gibi grupları ve her grubun ne yapabilmesi gerektiğini kısaca belirtin. Yaklaşık kullanıcı sayısı da faydalı bir bilgidir.

5. Olmazsa olmaz işlevler

İlk sürümde kesinlikle bulunması gereken özellikleri listeleyin. Burada kısa ve öncelikli olmak önemlidir.

6. Sonra da olabilecek işlevler

Güzel olur ama beklenebilir dediğiniz özellikleri ayrı bir listede toplayın. Bu ayrım, bütçe ve takvim konuşmasını çok kolaylaştırır.

7. Platform ve cihazlar

Sistem bilgisayardan mı, telefondan mı, tabletten mi kullanılacak? İnternet bağlantısının zayıf olduğu yerlerde de çalışması gerekiyor mu?

8. Entegrasyonlar ve mevcut sistemler

Muhasebe programı, web sitesi, ödeme altyapısı, kargo firması veya e-fatura gibi bağlanılması gereken sistemleri ve şu an kullandığınız programların adlarını yazın.

9. Mevcut veriler

Yeni sisteme aktarılması gereken müşteri, ürün veya geçmiş kayıt verileri var mı? Hangi formatta tutuluyor?

10. Takvim, bütçe aralığı ve karar verici

Belirli bir tarihe yetişmesi gerekiyor mu? Kafanızda bir bütçe aralığı varsa paylaşmak, geliştiricinin size uygun bir kapsam önermesini sağlar. Son olarak proje boyunca karar verecek kişiyi belirtin.

Kısa bir örnek: doldurulmuş brief

Şablonun pratikte nasıl görüneceğini canlandırmak için kurgusal bir örnek düşünelim. Üç şubeli bir fizik tedavi merkezi şöyle bir yazılım projesi brief metni hazırlıyor:

Üç şubede randevuları telefonla alıp ortak bir Excel dosyasına yazıyoruz. Aynı saate iki hasta yazılabiliyor ve terapistler günlük programlarını sabah resepsiyondan öğreniyor. Hedefimiz, hastaların web sitesinden uygun saati görüp randevu alabilmesi, terapistlerin programlarını telefondan görmesi ve resepsiyonun tek ekrandan üç şubeyi yönetebilmesi. İlk sürümde online ödeme şart değil; hatırlatma mesajı sonra eklenebilir. Mevcut hasta listemiz Excel’de. Yeni sezon başlamadan devreye girmesini istiyoruz; karar verici merkez müdürümüz.

Bu birkaç cümle bile sorunu, hedefi, kullanıcıları, öncelikleri, mevcut veriyi, takvimi ve karar vericiyi anlatıyor. Bir geliştirici bu metinle hem anlamlı sorular sorabilir hem de gerçekçi bir ilk teklif hazırlayabilir.

Brief’i güçlendiren ekler

Şablonun yanına ekleyebileceğiniz birkaç şey, anlatımı çok daha net hâle getirir:

• Şu an kullandığınız Excel dosyası veya form örnekleri (gerekirse kişisel verileri çıkararak)
• Beğendiğiniz ve beğenmediğiniz benzer uygulama veya sitelerin adları, nedenleriyle birlikte
• Elle çizilmiş bir ekran taslağı veya iş akışı şeması
• Kullandığınız fiş, fatura, rapor gibi çıktıların örnekleri

Sık yapılan brief hataları

Hata	Daha iyisi
“X uygulamasının aynısı”	O uygulamanın hangi özelliğini neden istediğinizi yazmak
Yalnızca özellik listesi	Önce çözülecek sorunu ve hedefi anlatmak
Her şeyin “öncelikli” olması	İlk sürüm ve sonraki sürüm olarak ayırmak
Teknoloji dayatması	İhtiyacı anlatıp teknoloji önerisini geliştiriciye bırakmak
Bütçeyi tamamen gizlemek	Kabaca bir aralık paylaşarak kapsamın buna göre şekillenmesini sağlamak

Brief’i birden fazla firmaya göndermek

Aynı yazılım projesi brief dokümanını tüm firmalara göndermek, gelen teklifleri karşılaştırılabilir hâle getirir. Her firmanın aynı soruya cevap verdiğinden emin olursunuz. Gelen teklifleri nasıl okuyacağınızı yazılım teklifi değerlendirme rehberinde anlattım.

Firmalardan gelen sorular da değerlidir. Brief’inizi okuyup akıllıca sorular soran bir geliştirici, işi anlamaya çalışıyor demektir. Hiç soru sormadan hemen fiyat veren bir teklife ise biraz daha dikkatli yaklaşmak gerekir. Geliştiriciyle proje boyunca nasıl iletişim kuracağınıza dair önerileri yazılımcı ile çalışmak yazısında bulabilirsiniz.

Bu işi nasıl birlikte yaparız?

1. Brief’i birlikte okuma: Gönderdiğiniz brief’i inceler, eksik gördüğüm noktaları sorularla tamamlarım. Henüz brief’iniz yoksa kısa bir görüşmede bu şablonu birlikte doldurabiliriz.
2. Kapsam ve teklif: Brief’teki olmazsa olmaz ve sonra olabilecek işlevleri esas alarak aşamalara bölünmüş bir teklif hazırlarım.
3. Ayrıntılı analiz ve geliştirme: Onayın ardından ekranları ve iş kurallarını netleştirir, aşamalı teslimlerle geliştirmeye başlarım.
4. Teslim ve destek: Yayına alma, eğitim ve sonrasındaki bakım ile ikinci aşama özelliklerini planlarız.

Hazırladığınız brief’i göndermek ya da birlikte doldurmak isterseniz iletişim sayfasından bana ulaşabilirsiniz.

Sık sorulan sorular

Brief ne kadar uzun olmalı?

Çoğu proje için bir iki sayfa yeterlidir. Amaç her ayrıntıyı yazmak değil, geliştiricinin projeyi doğru anlayıp ilk teklifi verebileceği bir çerçeve sunmaktır.

Teknik bilgim yok, brief yazabilir miyim?

Evet. Brief, teknik değil işle ilgili bir dokümandır. Sorununuzu, hedefinizi ve kullanıcılarınızı kendi kelimelerinizle anlatmanız yeterlidir; teknik kararları geliştirici önerir.

Bütçemi brief’te paylaşmalı mıyım?

Kabaca bir aralık paylaşmak genellikle faydalıdır. Geliştirici bu aralığa uygun bir ilk sürüm önerebilir; aksi hâlde teklif ile beklentiniz arasında büyük fark çıkabilir.

Brief proje sırasında değişebilir mi?

Brief bir başlangıç dokümanıdır; ihtiyaç analizi sırasında ayrıntılar netleşir ve bazı maddeler değişebilir. Önemli olan, değişikliklerin yazılı olarak kayda geçmesidir.

Sonuç

İyi hazırlanmış bir yazılım projesi brief dokümanı; sorunu, hedefi, kullanıcıları ve öncelikleri kısa ve net biçimde anlatarak doğru teklif almanızı ve projenin sağlam başlamasını sağlar. Brief’inizi birlikte gözden geçirmek isterseniz bana yazabilirsiniz.