Rehberler
Yazılım Proje Brifi Nasıl Yazılır? Doğru ve Sabit Fiyatlı Teklif İçin Şablon (2026)
Aynı proje için bir firma 3.000 $, diğeri 15.000 $ teklif veriyorsa sorun çoğu zaman brifte. Kopyalayıp doldurabileceğiniz yazılım proje brifi şablonu, doldurulmuş örnek, MoSCoW önceliklendirme ve sık yapılan hatalar.
Bu sayfada
- Yazılım proje brifi neden bu kadar önemli?
- İyi bir yazılım proje brifinde olması gereken 14 başlık
- Kopyalanabilir proje brifi şablonu
- Doldurulmuş örnek: randevu sistemi
- Özellikleri MoSCoW yöntemiyle önceliklendirin
- Özellikleri kullanıcı hikâyesi olarak yazın
- Yazılım proje brifinde sık yapılan 7 hata
- İyi bir ekip size hangi soruları geri sormalı?
- Brifi kaç firmaya ve nasıl göndermeli?
- Sonuç: iyi bir yazılım proje brifi neyi değiştirir?
- Sık sorulan sorular
Kısa cevap: İyi bir yazılım proje brifi; işinizi ve hedefinizi, ürünü kimin kullanacağını, çözmek istediğiniz problemi, ilk sürümde mutlaka olması gereken özellikleri, entegrasyonları, bütçe aralığını ve teslim tarihini 2–4 sayfada net olarak anlatır. Böyle bir brif, firmaların aynı kapsamı fiyatlamasını sağlar; teklifler arasındaki uçurum küçülür ve sabit fiyat teklif almak mümkün hale gelir. Aşağıdaki proje brifi şablonunu kopyalayıp doldurmanız 1–2 saatinizi alır.
Aynı proje için bir firmadan 3.000 $, diğerinden 15.000 $ teklif aldıysanız, büyük ihtimalle firmalar aynı projeyi fiyatlamıyor. Biri “basit bir randevu sitesi” anlamış, diğeri “ödeme, mobil uygulama ve çoklu şubeli bir platform”. Aradaki farkı kapatan şey, yazılı ve net bir yazılım proje brifidir.
Bu rehberde brifte neler olmalı, özellikleri nasıl önceliklendirirsiniz, sık yapılan hatalar neler ve iyi bir ekibin size hangi soruları geri sorması gerektiğini anlatıyoruz. En önemlisi: kopyalayıp hemen kullanabileceğiniz bir şablon ve doldurulmuş bir örnek var.
Yazılım proje brifi neden bu kadar önemli?
- Karşılaştırılabilir teklifler: Herkes aynı kapsamı fiyatladığında teklifleri gerçekten karşılaştırabilirsiniz.
- Sabit fiyat imkânı: Kapsam net değilse firmalar ya riski fiyata ekler ya da saatlik çalışmayı önerir. Net bir brif, sabit fiyat teklif almanın ön şartıdır.
- Daha az sürpriz: “Bunun dahil olduğunu sanıyordum” tartışmaları en çok belirsiz kapsamdan çıkar.
- Sözleşmenin temeli: Brif, daha sonra sözleşmedeki kapsam ve kabul kriterlerinin ilk taslağı olur. Bu konuda yazılım sözleşmesi rehberimize göz atabilirsiniz.
- Kendi düşüncenizi netleştirir: Brifi yazarken neyin gerçekten gerekli olduğunu siz de görürsünüz.
İyi bir yazılım proje brifinde olması gereken 14 başlık
- Şirket ve hedef: Ne iş yapıyorsunuz, bu proje hangi iş hedefine hizmet ediyor?
- Kullanıcılar: Ürünü kimler kullanacak (müşteri, personel, yönetici)? Kaç kişi?
- Problem: Bugün iş nasıl yürüyor ve neresi acıtıyor?
- Zorunlu özellikler: İlk sürümde mutlaka olması gerekenler, kullanıcı hikâyesi olarak.
- Sonraya kalabilecekler: Güzel olur ama ilk sürümde şart olmayanlar.
- Örnekler ve rakipler: Beğendiğiniz 2–3 ürün ve neyi beğendiğiniz.
- Entegrasyonlar: Ödeme, muhasebe/ERP, CRM, e-posta, SMS/WhatsApp, harita.
- İçerik ve veri: Metinleri, ürünleri, mevcut verileri kim hazırlayacak? Aktarılacak veri var mı?
- Tasarım varlıkları: Logo, kurumsal kimlik, varsa mevcut tasarımlar.
- Platformlar: Web, iOS, Android, yönetim paneli; diller.
- Bütçe aralığı: Kaba bir aralık bile ekibin doğru kapsamı önermesine yardım eder.
- Teslim tarihi: Sabit bir tarih var mı (fuar, sezon, yatırımcı toplantısı)?
- Başarı ölçütleri: Proje başarılı olursa 6 ay sonra ne değişmiş olacak?
- İletişim: Karar verici kim, sorular kime sorulacak?
Kopyalanabilir proje brifi şablonu
Aşağıdaki proje brifi şablonunu bir belgeye kopyalayın ve köşeli parantezleri doldurun. Bilmediğiniz alanları boş bırakmayın; “bilmiyorum” yazın, iyi bir ekip o konuda size yardım eder.
1. ŞİRKET VE HEDEF - Şirket / sektör: [ ] - Bu projeyle ulaşmak istediğimiz iş hedefi: [ ] 2. KULLANICILAR - Kullanıcı tipleri ve yaklaşık sayıları: [müşteri ~ , personel ~ , yönetici ~ ] 3. PROBLEM - Bugün süreç nasıl işliyor: [ ] - En büyük sorun: [ ] 4. ZORUNLU ÖZELLİKLER (Must have) - [Kullanıcı tipi] olarak [şunu yapmak] istiyorum, böylece [şu fayda]. - ... 5. SONRAYA KALABİLECEKLER (Should / Could have) - [ ] 6. ÖRNEKLER / RAKİPLER - [Ürün adı / bağlantı] — beğendiğimiz yanı: [ ] 7. ENTEGRASYONLAR - Ödeme: [ ] Muhasebe/ERP: [ ] Mesajlaşma: [ ] Diğer: [ ] 8. İÇERİK VE VERİ - Metin ve görselleri kim hazırlayacak: [ ] - Aktarılacak mevcut veri: [Excel / eski sistem / yok] 9. TASARIM - Logo / kurumsal kimlik: [var / yok] Mevcut tasarım: [ ] 10. PLATFORMLAR VE DİLLER - [Web / iOS / Android / yönetim paneli] Diller: [ ] 11. BÜTÇE ARALIĞI - [ ] – [ ] $ 12. TESLİM TARİHİ - İstenen tarih: [ ] Sabit mi: [evet / hayır, neden] 13. BAŞARI ÖLÇÜTLERİ - 6 ay sonra ölçeceğimiz şey: [ ] 14. İLETİŞİM - Karar verici: [ad, rol] Günlük iletişim: [ad, e-posta / telefon]
Doldurulmuş örnek: randevu sistemi
Kısa bir örnekle şablonun nasıl doldurulacağını görelim. Üç şubeli bir güzellik salonu online randevu sistemi istiyor:
- Hedef: Telefon ve WhatsApp’tan gelen randevuları online almak ve gelmeyen müşteri sayısını azaltmak.
- Kullanıcılar: Müşteriler (ayda ~1.500 randevu), 12 personel, 1 yönetici.
- Problem: Randevular deftere ve WhatsApp’a yazılıyor, çakışmalar oluyor, hatırlatma yapılmıyor.
- Zorunlu: “Müşteri olarak şube, hizmet ve personel seçip boş saatlerden birini seçmek istiyorum, böylece telefonla uğraşmam.” “Personel olarak günlük takvimimi telefondan görmek istiyorum.” “Yönetici olarak şube bazında doluluk raporu görmek istiyorum.”
- Sonraya: Kapora ile online ödeme, sadakat puanı, mobil uygulama.
- Entegrasyonlar: WhatsApp veya SMS hatırlatma.
- Veri: Excel’de ~2.000 müşteri kaydı aktarılacak.
- Bütçe: 1.000–3.000 $. Tarih: Yeni sezon öncesi, 8 hafta içinde.
- Başarı: Online randevu oranının %50’yi geçmesi, gelmeyen müşteri oranının düşmesi.
Bu kadarlık bir yazılım proje brifi bile firmaların aynı kapsamı fiyatlaması için yeterlidir. Bu örnekteki gibi bir proje için online randevu sistemi rehberimize de bakabilirsiniz.
Özellikleri MoSCoW yöntemiyle önceliklendirin
Her özelliği “zorunlu” yazmak, bütçeyi ve süreyi patlatmanın en kısa yoludur. Agile Business Consortium’un DSDM çerçevesinde tanımlanan MoSCoW yöntemi, özellikleri dört gruba ayırır:
| Grup | Anlamı | Basit test |
|---|---|---|
| Must have (Olmazsa olmaz) | Bu olmadan ürünü yayına almanın anlamı yok | Bu olmazsa projeyi iptal eder miydik? |
| Should have (Olmalı) | Önemli ama hayati değil; geçici bir çözümle idare edilebilir | Bir süre elle yapılabilir mi? |
| Could have (Olabilir) | İstenen ama etkisi daha az olan özellikler | Süre daralırsa ilk bunu mu çıkarırız? |
| Won’t have (Bu sefer yok) | Bu sürümde yapılmayacağı açıkça kararlaştırılanlar | Yazılı olarak kapsam dışı mı? |
Aynı kaynak, “Must have” işlerin toplam eforun yaklaşık %60’ını geçmemesini ve “Could have” işlerden yaklaşık %20’lik bir yedek havuz tutulmasını öneriyor. Bu, sabit fiyat projelerde hem bütçeyi hem teslim tarihini korumanın pratik bir yoludur. Bütçe sınırlıysa düşük bütçeyle MVP rehberimiz kapsamı daraltmanıza yardım eder.
Özellikleri kullanıcı hikâyesi olarak yazın
“Randevu modülü” gibi tek kelimelik başlıklar, her firmanın kafasında başka bir şey canlandırır. Kullanıcı hikâyesi ise kimin, neyi, neden istediğini söyler. Atlassian’ın önerdiği kalıp şöyle: “[Kullanıcı] olarak [şunu yapmak] istiyorum, böylece [şu fayda].” Agile Alliance da iyi bir kullanıcı hikâyesinin bağımsız, küçük ve test edilebilir olmasını öneren INVEST kontrol listesine atıf yapar. Her hikâyeye bir iki cümlelik “tamam sayılması için” kriteri eklerseniz, brifiniz aynı zamanda kabul testlerinin taslağı olur.
Yazılım proje brifinde sık yapılan 7 hata
- “Facebook gibi bir şey”: Büyük bir ürünü örnek göstermek, hangi kısmını istediğinizi söylemedikçe kapsamı belirsizleştirir.
- Her şeyin zorunlu olması: Önceliklendirme yoksa teklif de en pahalı senaryoya göre gelir.
- Bütçeyi saklamak: Ekip kapsamı bütçenize göre şekillendiremez; teklifler çok dağınık gelir.
- Entegrasyonları unutmak: Ödeme, muhasebe veya ERP bağlantısı sonradan çıkınca hem süre hem fiyat değişir.
- İçeriği hesaba katmamak: Metin, görsel ve veri aktarımı çoğu zaman projeyi en çok geciktiren şeydir.
- Teknoloji dayatmak: Gerekçesi yoksa teknolojiyi ekibe bırakın; siz problemi ve ihtiyacı anlatın.
- Karar vericiyi belirtmemek: Onaylar gecikirse proje de gecikir.
İyi bir ekip size hangi soruları geri sormalı?
Brifinizi gönderdikten sonra hiç soru sormadan fiyat veren bir firma, büyük ihtimalle kapsamı tahmin ediyordur. İyi bir ekip genellikle şunları sorar: Bu özelliği kim, ne sıklıkla kullanacak? Bu iş bugün nasıl yapılıyor? İlk sürüm için hangi özellik olmasa da yayına çıkabiliriz? Hangi sistemlerle konuşması gerekiyor ve bu sistemlerin API erişimi var mı? Yayından sonra bakım ve geliştirmeyi kim üstlenecek? Bu sorular, sabit fiyat bir teklifin sağlam temele oturduğunun işaretidir.
Brifi kaç firmaya ve nasıl göndermeli?
Aynı yazılım proje brifini 3–5 firmaya göndermek genellikle yeterlidir; daha fazlası, cevapları karşılaştırmayı zorlaştırır. Brifi PDF veya paylaşılan belge olarak gönderin, örnek ekran görüntülerini ve varsa mevcut Excel dosyalarını ekleyin. Gelen soruları ve cevaplarınızı tüm firmalarla paylaşırsanız herkes aynı bilgiyle fiyat verir. Proje brifi şablonu üzerinde yaptığınız değişiklikleri de tarihli olarak saklayın; anlaşma aşamasında hangi kapsamın fiyatlandığı böylece tartışmasız olur.
Sonuç: iyi bir yazılım proje brifi neyi değiştirir?
İyi bir yazılım proje brifi, teklifleri karşılaştırılabilir kılar, sabit fiyat almayı mümkün hale getirir ve proje boyunca “bu dahil miydi?” tartışmalarını azaltır. Mükemmel olması gerekmiyor: hedefinizi, kullanıcılarınızı, zorunlu özelliklerinizi, entegrasyonları, bütçe aralığını ve tarihi net yazmanız yeterli. Gerisini iyi bir ekip doğru sorularla tamamlar.
Özetle
- Teklifler arasındaki büyük farkların çoğu, firmaların farklı kapsamları fiyatlamasından kaynaklanır.
- İyi bir brif 14 başlığı kapsar ve 2–4 sayfayı geçmez.
- Özellikleri kullanıcı hikâyesi olarak yazın ve MoSCoW ile önceliklendirin; “Must have” eforun yaklaşık %60’ını geçmesin.
- Bütçe aralığını, entegrasyonları ve içerik sorumluluğunu mutlaka yazın.
- Hiç soru sormadan fiyat veren firmalara karşı dikkatli olun.
Sık sorulan sorular
Yazılım proje brifi ne kadar uzun olmalı?
Çoğu proje için 2–4 sayfa yeterlidir. Uzunluktan çok netlik önemlidir: hedef, kullanıcılar, zorunlu özellikler, entegrasyonlar, bütçe aralığı ve tarih açıkça yazılmış olmalı.
Bütçemi brifte yazmalı mıyım?
Evet, en azından bir aralık olarak. Bütçe aralığı, ekibin kapsamı size uygun şekilde önermesini sağlar; aksi halde teklifler birbirinden çok farklı senaryolara göre hazırlanır.
Teknik bilgim yok, yine de brif yazabilir miyim?
Evet. Brif teknik bir belge değildir; işinizi, problemi ve kullanıcıların ne yapmak istediğini anlatır. Teknoloji seçimini ve teknik detayları ekip önerir.
Brif ile teknik şartname aynı şey mi?
Hayır. Brif, teklif almak için ihtiyacı anlatan kısa bir belgedir. Teknik şartname ise genellikle anlaşmadan sonra, ekran akışları, veri yapısı ve kabul kriterleriyle birlikte ekiple beraber hazırlanır.
Proje brifi şablonu her proje için kullanılabilir mi?
Evet. Web sitesi, web uygulaması, mobil uygulama veya iç yazılım fark etmez; başlıklar aynıdır. Sadece platformlar ve entegrasyonlar bölümü projeye göre değişir.
Sabit fiyat teklif almak için brif yeterli mi?
Net bir brif çoğu zaman sabit fiyat teklif için yeterlidir. Belirsiz noktalar kalırsa ekip, önce kısa bir keşif aşaması veya tıklanabilir prototip önerebilir; bu da kapsamı netleştirir.
Brifiniz hazır mı? Bize gönderin, bir iş günü içinde kapsam, süre ve sabit fiyatla dönelim; eksik kalan noktaları da birlikte tamamlayalım. Neler yaptığımızı hizmetler ve fiyatlar sayfamızda görebilirsiniz.
