Yazılım projesi brief'i nasıl yazılır? Teklif istemeden önce doldurulacak şablon

Yazılım projesi brief'i nedir, teklif ve SOW'dan farkı ne?

Yazılım projesi brief'i, birinden teklif istemeden önce yazdığınız belgedir. Hangi problemi yaşadığınızı, kimin yaşadığını, çözüldüğünü nasıl anlayacağınızı, elinizde neyin olduğunu, neyi henüz bilmediğinizi ve cevapta ne görmek istediğinizi söyler. Bir özellik listesi değildir, bir şartname de değildir. Teklif ve kapsam belgesi (SOW) karşılığında tedarikçinin yazdığı belgelerdir; yani brief, zincirde yalnızca sizin iyi yazabileceğiniz tek belgedir.

Bu yazı ilk satırı anlatıyor. Gelen cevabı nasıl okuyacağınız, bir kapsam belgesi şablonuyla birlikte, yazılım teklifi nasıl okunur yazısında. İş ister özel yazılım ister mobil uygulama olsun, brief'in on başlığı aynıdır; yalnızca mobil uygulamaya özgü kararlar aşağıda ayrı bir bölümde.

Yazılım projesi brief'inin on başlığı

Her başlığın altına bir ya da iki cümle yazın. Yalnızca beşini yazabiliyorsanız 1, 2, 3, 5 ve 10'u yazın: işin çoğunu onlar yapar.

1. Problem ve kimin problemi. Bugün ne ters gidiyor, kimin için, hangi durumlarda? "Bir uygulamaya ihtiyacımız var" bir problem değildir.
2. Kullanıcılar ve ilk kullanım. Onu ilk kim açıyor, hangi anda, ne yapmak için? Diğer kullanıcılar sonra gelebilir.
3. Çalıştığını nasıl anlayacaksınız. Bir ila üç gözlemlenebilir sonuç; bir yabancının kontrol edebileceği biçimde yazılmış. Özellik listesi değil.
4. Bugün ne var. Mevcut süreç, tablolar, sistemler, ekran görüntüleri, varsa önceki kod.
5. Neyi biliyorsunuz, neyi bilmiyorsunuz. İki liste: karar verilenler ve açık olanlar. Tahmin yürütmek yerine "bilmiyoruz" yazın; brief'te gizlenen bir tahmin, tekliften sonra sabit bir varsayıma dönüşür.
6. Kısıtlar. Platformlar, entegrasyonlar, ilgili veri, diller, düzenleme, erişilebilirlik, güvenlik çıtası ve varsa bir son tarih ile nedeni.
7. Hâlihazırda elinizde olan hesaplar ve varlıklar. Alan adı, bulut, mağaza hesapları, marka dosyaları, veri ve her birinin kimin adına olduğu.
8. Zaman ve para sınırları. Neyin sabit olduğu (bir etkinlik, bir yatırım tarihi) ve neyin esneyebileceği. Bir aralık yazmak istiyorsanız yazın; istemiyorsanız bunu belirtin.
9. Karar nasıl verilecek. Kim karar verir, sorulara kim cevap verir ve teklifleri hangi ölçütlerle karşılaştıracaksınız.
10. Cevapta ne görmek istiyorsunuz. Cevapta beklediğiniz başlıklar: varsayımlar, kapsam dışı kalanlar, sorular, bir değişikliğin nasıl ele alınacağı, her hesabın kimin adına açılacağı.

Sıra bilerek böyle. 1'den 3'e kadar olan başlıklar sonucu tarif eder ve tedarikçinin oraya ulaşmak için bir yol önermesine izin verir; 4'ten 7'ye kadar olanlar zemini tarif eder; 8'den 10'a kadar olanlar nasıl seçeceğinizi anlatır. Ekranlarla ve modüllerle başlayan bir brief, tedarikçiye iyileştirecek hiçbir şey bırakmaz.

Zayıf satır, güçlü satır

Tablo, bir brief'teki yaygın bir satırın gerçekten teklif verilebilecek biçimde nasıl yeniden yazılabileceğini gösteriyor. Güçlü satırlar uyarlanacak örneklerdir, kopyalanacak metin değil.

"İşe yaradı"yı brief'e nasıl yazarsınız

3. başlık en zoru ve en yararlısıdır. Yazılım ekiplerinin pratiğinden iki fikir yardım eder. Scrum Guide, bir Ürün Hedefi'nin (Product Goal) "Scrum Takımı'nın planlama yaparken hedef alabileceği, ürünün gelecekteki bir durumunu tarif ettiğini" söyler ve Bitti Tanımı'nı (Definition of Done) "Artımın, ürün için gereken kalite ölçütlerini karşıladığı andaki durumunun resmî bir tanımı" olarak tanımlar (Scrum Guide, Kasım 2020; çeviri bize ait). Fikri ödünç almak için Scrum uygulamanız gerekmez: neyi hedeflediğinize dair bir cümle ve bir iş parçasına "bitti" demeden önce doğru olması gereken kısa bir koşullar listesi.

Joel Spolsky, işlevsel şartnameler hakkında yazarken bir brief için de aynen geçerli nedenler verir: "Bir şartnamenin en önemli işlevi programı tasarlamaktır" ve "Bir şartname yazdığınızda, programın nasıl çalışması gerektiğini yalnızca bir kez anlatmanız gerekir" (Spolsky; özgün metin İngilizce, çeviri bize ait). Brief yazmak, bir şeylere karar vermeye zorlandığınız ilk andır; yapımın ortasında değil, o zaman olması daha iyi.

Rakamsız yazılmış, gözlemlenebilir üç ölçüt örneği:

• "Şifresini unutan kullanıcı bize ulaşmadan erişimini geri alabilir."
• "Aynı anda iki kişinin aynı saat için yaptığı bir rezervasyon birine onaylanır, diğerine söylenir."
• "Personel dünkü siparişleri, geliştiriciden bir dışa aktarım istemeden listeden bulabilir."

Bir ölçüt, onu yazmamış biri tarafından kontrol edilemiyorsa henüz bir ölçüt değildir. Üzerinde anlaşılan ölçütlerin nasıl kabul maddelerine dönüştüğü, teklif rehberimizdeki SOW şablonunun 4. maddesinde.

Proje bir mobil uygulamaysa: brief'e yazılacak kararlar

Mobil uygulama, kodun dışında kalan ve kendi hazırlık süresi olan kararlar getirir. Brief'e tahmini değil, kararı yazın. Bu kararların doğurduğu kalemler mobil uygulama maliyeti yazısında; burada soru yalnızca brief'in ne söylemesi gerektiği.

Tablonun ötesinde brief; hesap kurulumunu ve kimlik doğrulamasını kimin yürüteceğini, gizlilik metnini kimin hazırlayacağını, reddedilen bir incelemeden sonra kimin düzeltip yeniden göndereceğini ve sonraki sürümleri kimin yayımlayacağını belirtmeli. Geliştirici hesabının kimin adına olacağı sorusuyla birlikte bunlar, mobil uygulama yaptırma sayfamızdaki beş sorudur. Mağaza kuralları değişir; harekete geçmeden önce resmî sayfaları yeniden açın.

Unutulan gereksinimler: erişilebilirlik, güvenlik, veri

Özelliğe benzemedikleri için kolayca dışarıda kalırlar. Bir temeli adlandıran brief, tedarikçinin ona göre teklif vermesini sağlar; "erişilebilir" ya da "güvenli" diyen brief sağlamaz.

Bu standartları derinlemesine bilmeniz gerekmez. "WCAG 2.2 [seçeceğiniz] düzeyini bekliyoruz" ya da "hangi güvenlik temeline göre çalıştığınızı belirtin" yazmak, konuşmayı başlatmaya yeter. Bir yasanın size uygulanıp uygulanmadığı ve hangi düzeyde uygulandığı bir avukata sorulacak sorudur.

Kopyalayabileceğiniz bir yazılım projesi brief şablonu

Aşağıdaki iskeleti kopyalayın, köşeli parantezleri doldurun ve konuştuğunuz her tedarikçiye, son başlığa cevap vermesini isteyen bir satırla birlikte gönderin.

Aynı şablonu, her yanıt için yazma alanı bırakılmış yazdırılabilir PDF ve köşeli parantezleri vurgulanmış düzenlenebilir Word dosyası olarak da indirebilirsiniz.

1. Problem ve kimin problemi. "Bugün [kim], [ne] yapmak zorunda ve bu [sonuca] yol açıyor. Bu [ne sıklıkla ya da hangi durumlarda] oluyor."
2. Kullanıcılar ve ilk kullanım. "İlk kullanıcı [rol]. Onu [hangi anda] [görevi] yapmak için açıyor. Diğer kullanıcılar: [roller]."
3. Çalıştığını nasıl anlayacağız. "[Gözlemlenebilir sonuç 1] ve [gözlemlenebilir sonuç 2] sağlandığında çalıştı sayacağız."
4. Bugün ne var. "Bu iş bugün [kâğıt, tablo, sistem] ile yapılıyor. [Belgeleri, ekran görüntülerini, erişimi] paylaşabiliriz."
5. Neyi biliyoruz, neyi bilmiyoruz. "Karar verilenler: [liste]. Açık ya da bilinmeyenler: [liste]. Hangi varsayımlarla çalıştığınızı söyleyin."
6. Kısıtlar. "Platformlar: [web, iOS, Android, diğer]. Bağlanması gerekenler: [sistemler]. Diller: [liste]. Veri ve gizlilik: [ne topluyoruz, kimden]. Erişilebilirlik: [WCAG 2.2 düzeyi ya da 'karar verilmedi']. Güvenlik temeli: [seçiminiz ya da 'lütfen önerin']. Bildiğimiz düzenleme: [liste ya da 'bilinmiyor']."
7. Hâlihazırda elimizde olan hesaplar ve varlıklar. "[Alan adı, bulut, mağaza hesapları, marka dosyaları, veri], [kimin] adına."
8. Zaman ve para sınırları. "Sabit: [tarih ve nedeni]. Esneyebilen: [ne]. Söyleyebileceğimiz harcama sınırı: [aralık ya da 'belirtilmedi']."
9. Nasıl karar vereceğiz. "[Rol] karar verir; [rol] sorularınızı genellikle [cevap sürenizde] yanıtlar. Teklifleri [ölçütlere] göre karşılaştıracağız."
10. Cevabınızda ne görmek istiyoruz. "Varsayımlarınız; kapsam dışı kalanlar; hâlâ sormak istedikleriniz; bir değişikliğin nasıl yazılıp fiyatlanacağı; her hesabın kimin adına açılacağı; iş sonunda elimizde ne kalacağı."

Bir oturumda yapabildiğinizi doldurun, gerisini "açık" bırakın. Dürüst bir "açık", uydurma bir cevaptan tedarikçiye daha çok yarar. Brief uzarsa korunacak başlıklar 1, 2, 3, 5 ve 10'dur.

Bir brief'te sık yapılan beş hata

1. Çözümü problemden önce yazmak. İlk paragraftaki ekranlar ve modüller, tedarikçiye iyileştirecek hiçbir şey bırakmaz. 1. başlıkla başlayın.
2. Bilmediğinizi gizlemek. Gizlenen bir tahmin, teklifte sabit bir varsayıma, sonra bir değişiklik talebine dönüşür. Bunun yerine bilinmeyenleri listeleyin.
3. "Olmazsa olmaz" ile "olsa iyi olur"u karıştırmak. 3. ve 6. başlıktaki her maddeyi olmazsa olmaz, olmalı ya da olabilir diye işaretleyin. Tedarikçi, hangisinin hangisi olduğunu bilirse makul bir ilk iş parçası önerebilir.
4. Zaten elinizde olanı yazmamak. Bugün var olan hesaplar, veri ve marka dosyaları neyin yapılması gerektiğini ve neyin gerekmediğini belirler; 7. başlık kısadır ve çoğu zaman belirleyicidir.
5. Birkaç kişinin tek belgede farklı brief yazması. Öncelikler çelişiyorsa brief gitmeden önce 9. başlıkta kimin karar verdiğini yazın; yoksa tedarikçi çelişkiyi alır ve tahmin etmek zorunda kalır.

Gönderdikten sonra: cevapları okumak

Bakılacak ilk şey geri gelen sorulardır. 5. başlığı, yani açık yazdığınız şeyleri soran bir tedarikçi brief'i okumuştur; soru sormadan fiyat döndüren okumamıştır. Sonra teklifin sonucunuzu kendi sözleriyle yeniden yazıp yazmadığına, varsayımlarını sıralayıp sıralamadığına, neyin kapsam dışı olduğunu söyleyip söylemediğine ve son başlığa cevap verip vermediğine bakın. Cevapların yan yana konabilmesi için her tedarikçiye aynı brief'i gönderin; kırmızı bayrak listesi ve karşılaştırma tablosu teklif rehberimizde, teklif karşılaştırma şablonu ise mobil uygulama maliyeti yazısında. Modeli ne olursa olsun tedarikçiye sorulacak sorular outsource rehberinde.

Biz bunu nasıl yapıyoruz

Burada yalnızca sitemizde yazdığımızı tekrarlıyoruz. Her şey bir konuşmayla başlıyor: site üzerinden bir teklif talebi ya da bir görüşme. Ürünün ne yapması gerektiğini, kimin için olduğunu ve neyin iyi bir sonuç sayılacağını, iki taraf da aynı şeyi anlatana kadar konuşuyoruz. O resim netleşmeden hiçbir şey inşa edilmiyor. Sonra bunu yazıya döküyoruz: ne yapılacak, hangi sırayla ve ne kadara; iş başlamadan önce siz onaylıyorsunuz. Hazırlıklı gelmeniz gerekmez, çünkü ilk görüşme gerçek bir konuşmadır; böyle bir brief yalnızca onu keskinleştirir. Her proje, onayladığınız yazılı teklifle başlayan ücretli bir çalışmadır; kapsam, takvim ve maliyet herhangi bir ücretlendirme başlamadan önce yazılı olarak elinizdedir. Adımlar Süreç sayfasında, yaklaşım ise mobil uygulama yaptırma ve özel yazılım geliştirme sayfalarımızda. Elinizde bir brief ya da yalnızca bir fikir varsa projenizi anlatın.

Sık sorulan sorular

Yazılım projesi brief'i kaç sayfa olmalı?

Bir oturumda okunabilecek kadar kısa. Birer ya da ikişer cümlelik on başlık genelde bir konuşmayı başlatmaya yeter; 4. başlık için ekran görüntülerini ya da belgeleri anlatmak yerine ekleyin. Ölçü uzunluk değil: sonucun ve açık soruların net olup olmadığı.

Yazmak için teknik bilgi gerekir mi?

Hayır. 1'den 4'e kadar olan başlıklar işiniz, kullanıcılarınız ve mevcut süreciniz hakkındadır; bunları yalnızca siz bilirsiniz. 6. başlıkta platform ya da güvenlik yanına "lütfen önerin" yazabilirsiniz; tedarikçinin cevabı nasıl düşündüğü hakkında size bir şey söyler.

Bütçeyi brief'e yazmalı mıyım?

Bir rakam yazmak zorunda değilsiniz. Yarar sağlayan, neyin sabit neyin esnek olduğunu söylemektir: bir etkinliğin belirlediği tarih, bir fonun belirlediği sınır. Bir aralık verebiliyorsanız tedarikçi işi ona sığacak biçimde kapsamlayabilir; veremiyorsanız "belirtilmedi" yazın ve bütçenin neye bağlı olduğunu söyleyin. Kapsam, takvim ve maliyeti içeren yazılı bir teklif ondan sonra gelir.

Aynı brief'i birkaç şirkete gönderebilir miyim?

Evet, cevapları karşılaştırmanın sağlam bir yolu da budur, çünkü her cevap aynı sözcüklere karşılık verir. Her birinden son başlığa cevap vermesini isteyin ve cevapları beklentilerinize değil birbirine karşı okuyun. Karşılaştırma teklif rehberinde anlatılıyor.

Başlıkların çoğuna cevabım yoksa?

Bildiğinizi yazın, gerisini "açık" olarak işaretleyin. Hemen her şey açıksa ilk iş bir yapım değil, soruları netleştiren kısa ve kapsamlı bir adımdır; MVP geliştirme sayfamız, kapsamı tek bir ana akışa ve öğrenilecek tek bir şeye indirmeyi anlatır. Dürüst açık maddeleri olan bir brief yine de bir brief'tir.

Kaynaklar

Aşağıdaki sayfalar 9 Kasım 2026'da açılıp okundu. Mağaza kuralları ve standartlar zamanla değişir; harekete geçmeden önce resmî sayfaları yeniden açın.

• Apple: Program enrollment · App Store Review Guidelines (5.1.1, 4.2)
• Google Play Console Help: Requirements for new personal developer accounts · Google Play Console Help: Choose a developer account type · Data safety · Account deletion requirements
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2, 12 Aralık 2024 · OWASP Application Security Verification Standard 5.0.0, 30 Mayıs 2025 · OWASP Mobile Application Security Verification Standard
• The Scrum Guide, Kasım 2020 · Joel Spolsky, Painless Functional Specifications, Part 1: Why Bother?, 2 Ekim 2000

Buradakilerin hiçbiri hukuki danışmanlık değildir; size uygulanan bir yasa ya da sözleşme maddesi için bir avukata sorun.