Bir işletme aynı fikir için üç yazılım teklifi alıyor. Tekliflerden biri yalnızca ekranları, diğeri veri aktarımını, üçüncüsü bakım hizmetini de içeriyor. Rakamlar yan yana duruyor ama aslında üç farklı iş karşılaştırılıyor. Bu durumda sorun mutlaka fiyatlandırmada değildir; tekliflerin dayandığı ihtiyaç tanımı farklı olabilir.
Yazılım proje briefi, geliştirme ekibine verilecek ilk ortak çalışma belgesidir. İşin neden yapılacağını, kimlerin kullanacağını, hangi sınırlar içinde tamamlanacağını anlatır. Eksiksiz olması her düğmenin rengini belirlemek anlamına gelmez. Teklifi ve teslim kararını etkileyen önemli belirsizlikleri görünür kılması yeterlidir.
Bu rehberdeki senaryo ve hedefler örnektir; WebWizz müşterisine ait bir vaka veya gerçekleşmiş performans sonucu değildir. Kendi briefinizi yazarken aşağıdaki başlıkları mevcut sürecinizden alınan bilgilerle doldurabilirsiniz.
Önce çözmek istediğiniz işi tarif edin
“Bir yönetim paneli istiyoruz” cümlesi, hangi sorunun giderileceğini söylemez. Bunun yerine süreci başlangıç ve bitiş noktalarıyla anlatın: Talep nereden geliyor, kim işliyor, hangi bilgi tekrar giriliyor, işin tamamlandığı nasıl anlaşılıyor?
Örneğin bir teknik servis işletmesinde müşteri talepleri e-posta ve telefonla toplanıyor olabilir. Amaç, tüm talepleri ortak bir listede sorumlu kişiye atamak ve müşteriye verilen sözleri izlemektir. Bu tanım, projeyi genel bir panelden ölçülebilir bir iş akışına dönüştürür.
Başarı ölçüsünü ve başlangıç değerini ayırın
Talebin alınması ile sorumluya atanması arasındaki süreyi ölçebilirsiniz. Bugünkü değeri bilmiyorsanız briefin içine tahmin uydurmayın; “pilot öncesi bir hafta ölçülecek” yazın. Hedef belirlerken çalışma saatleri, iptal edilen talepler ve otomatik kayıtlar gibi hesaplama kurallarını da açıklayın.
Ölçümün sahibi belli olsun. Operasyon sorumlusu sürenin iş açısından anlamlı olduğunu doğrularken teknik ekip olayların nerede kaydedileceğini tarif edebilir. Böylece teslim sonunda iki taraf aynı göstergeye bakar.
Kullanıcıları görevleri ve yetkileriyle birlikte yazın
Yönetici, çalışan ve müşteri etiketleri tek başına yeterli değildir. Her rol için görebileceği kayıtları, değiştirebileceği alanları ve onaylayabileceği işlemleri belirtin. Şubeli bir işletmede “çalışan” yalnızca kendi şubesini mi görecek, yoksa bütün organizasyonu mu?
Kullanıcı hikâyelerini şu mantıkla kurabilirsiniz: “Servis sorumlusu olarak geciken talepleri görmek istiyorum; böylece yeniden görevlendirme yapabileyim.” GOV.UK rehberi de kullanıcı hikâyesinde kişiyi, ihtiyacı ve amacı birlikte tarif eder. GOV.UK: kullanıcı hikâyeleri.
Yetkiyi ekran listesiyle karıştırmayın. Bir düğmenin gizlenmesi, ilgili işlemin güvenli biçimde engellendiğini göstermez. Kritik erişim kararlarının sunucuda kontrol edilmesini ve yetkisiz isteklerin test edilmesini kabul koşullarına ekleyin. OWASP: yetkilendirme rehberi.
Kapsamı üç ayrı listeyle yönetin
İlk liste canlıya çıkış için zorunlu işleri içersin. İkinci listede sonraki sürümlere bırakılabilecek geliştirmeler bulunsun. Üçüncü liste ise bu teklifin dışında kalan işleri açıkça söylesin.
Örnek servis panelinde talep kaydı, sorumlu atama, durum takibi ve temel rapor ilk sürüme girebilir. Otomatik rota oluşturma sonraki sürüme bırakılabilir. Muhasebe programının değiştirilmesi ise kapsam dışında tutulabilir. Bunlar önerilen evrensel paketler değil, öncelik ayırma örnekleridir.
Her zorunlu özelliğin bir gerekçesi olsun. Gerekçe yazılamıyorsa özelliğin vazgeçilmezliği yeniden değerlendirilebilir. Ayrıca kapsam dışı bir işin mevcut sistem tarafından yürütülmeye devam edip etmeyeceğini belirtin; işin sahipsiz kalmasını önleyin.
Kabul ölçütleriyle “tamamlandı” kararını somutlaştırın
“Bildirim çalışacak” ifadesi farklı yorumlara açıktır. Daha belirgin bir ölçüt şöyle yazılabilir: “Talep başka bir çalışana atandığında yeni sorumlu uygulama içinde bildirim görür; atama geçmişinde eski sorumlu, yeni sorumlu ve işlem zamanı bulunur.”
E-posta da gerekiyorsa bunu ayrıca tarif edin. Gönderim hizmetinin isteği kabul etmesiyle mesajın alıcının gelen kutusuna ulaşması aynı olay değildir. Hata görünürlüğü, tekrar deneme sınırı ve yöneticinin başvuracağı kayıtlar briefte ayrı maddeler olabilir.
Normal akışın yanına istisnayı ekleyin
Bir kullanıcı formu iki kez gönderirse ne olur? Kaydın bağlı olduğu müşteri silinirse geçmiş nasıl korunur? İnternet kesildiğinde ekrandaki veri kaybolur mu? Kullanıcının görevi tamamlayamadığı durumlar, teklifin gerçek iş yükünü belirler.
Kabul ölçütlerini örnek veriyle ilişkilendirin. Aynı test verisiyle iki ekip de aynı sonuca ulaşabiliyorsa, teslim değerlendirmesindeki belirsizlik azalır. Testlerin kim tarafından, hangi ortamda yapılacağı da yazılı olsun.
Entegrasyon ve veri aktarımını ayrı iş kalemleri yapın
“CRM bağlantısı” yerine ürün adını, sürümünü, erişim yöntemini, aktarılacak alanları ve yönü yazın. Müşteri kaydını hangi sistem oluşturuyor? Adres güncellendiğinde diğer sistemdeki eski bilgi ne zaman değişiyor? Bağlantı kesilirse işlemi kim takip ediyor?
API belgeleri henüz yoksa bu durumu varsayım olarak işaretleyin. Geliştirme ekibinden, belgenin incelenmesinden önce verilen tahminin hangi koşullara bağlı olduğunu açıklamasını isteyin.
Eski Excel dosyaları taşınacaksa anonimleştirilmiş küçük bir örnek paylaşın. Sütun anlamları, yinelenen kayıtlar, zorunlu alanlar ve tarih biçimleri görülmeden veri aktarımını yalnızca dosya yükleme düğmesi sanmak kolaydır. Temizliği yapacak kişiyle taşıma sonucunu onaylayacak kişiyi ayrıca belirleyin.
Çalışma koşullarını ve teslim sorumluluğunu yazın
Kullanıcı sayısı, aynı anda beklenen işlem yoğunluğu, dosya boyutları ve kullanılacak cihazlar tasarımı etkileyebilir. “Hızlı olsun” yerine temsilî bir ekran, veri miktarı, test ortamı ve kabul edilecek süre tarif edin. Bu değerler ölçüm hedefidir; ölçmeden verilmiş performans garantisi değildir.
Alan adı, barındırma, bakım, izleme ve yedeklemenin sorumlusunu belirtin. Kaynak kodun, tasarım dosyalarının, yönetici erişiminin ve işletim belgelerinin teslim kapsamına girip girmediğini netleştirin. Üçüncü taraf hesaplarını kim açacak, yenilemeleri kim yönetecek soruları da burada cevaplanmalı.
Brief güncellendiğinde teklif nasıl değişecek?
Her önemli değişiklik için kısa bir karar kaydı tutun: talep, gerekçe, kapsam etkisi, takvim etkisi ve onaylayan kişi. Briefin sürüm tarihi görünür olsun. Teklif karşılaştırırken bütün tedarikçilerin aynı sürümü değerlendirdiğini doğrulayın.
Teklif öncesi uygulama kontrol listesi
- İş problemini mevcut akışla birlikte bir paragrafta yazın.
- Hedef göstergenin tanımını, veri kaynağını ve sahibini belirleyin.
- Kullanıcı rollerini örnek yetkilerle açıklayın.
- İlk sürüm, sonraki sürüm ve kapsam dışını ayırın.
- Kritik özelliklere test edilebilir kabul ölçütleri ekleyin.
- Entegrasyon belgelerini ve örnek veriyi iliştirin.
- Belirsiz konuları varsayım ve açık soru olarak kaydedin.
- Yayın, eğitim, bakım ve teslim sorumlularını belirtin.
- Tüm tekliflerin aynı brief sürümüne dayandığını kontrol edin.
WebWizz ile proje kapsamını değerlendirmek isterseniz bu belgeyi iletişim sayfası üzerinden paylaşabilirsiniz. İlk görüşmenin odağı, briefteki açık soruları ve uygulanabilir ilk sürümü netleştirmek olabilir.
Sık sorulan sorular
Brief hazırlamak için teknik bilgi gerekir mi?
Hayır. Günlük işi, kullanıcıyı ve beklenen sonucu anlatmanız yeterli bir başlangıçtır. Teknik kararlar ekip tarafından açılabilir; bilmediğiniz entegrasyon veya altyapı ayrıntılarını kesinmiş gibi yazmanız gerekmez.
Bütçeyi baştan paylaşmalı mıyım?
Bütçe aralığı ve takvim kısıtı, uygulanabilir kapsamın belirlenmesine yardımcı olabilir. Teklifte varsayımları, kapsam dışını ve sürekli giderleri ayrı görmek istediğinizi belirtin. Sadece toplam bedelle karşılaştırma yapmayın.
Brief ile ayrıntılı teknik şartname aynı şey mi?
Brief ihtiyacın ve sınırların ortak tanımını verir. Teknik şartname daha ayrıntılı mimari, arayüz ve işletim kararları içerebilir. Belgenin adı kadar hangi kararlara temel oluşturduğu önemlidir.
Başladıktan sonra yeni ihtiyaç çıkarsa ne olur?
Yeni ihtiyacı karar kaydına ekleyin; mevcut kapsamla ilişkisini değerlendirin. Ekip etkisini açıklamadan otomatik olarak ilk sürüme eklemeyin. Gerektiğinde daha düşük öncelikli bir işle yer değiştirebilir.