Yazılım Projesi Brifi Nasıl Hazırlanır?
Net bir brif, haftalarca süren yazışmaları önler ve daha doğru maliyet tahminleri sağlar. Neleri eklemeniz gerektiğini ve neleri rahatlıkla dışarıda bırakabileceğinizi anlattık.
Proje brifi, ne geliştirmek istediğinizi ve nedenini anlatan kısa bir belgedir. İyi bir brif yazmak için teknik bilgiye ihtiyacınız yok. Önemli olan, geliştirme ekibinin doğru soruları sorabilmesi ve size gerçekçi bir tahmin verebilmesi için hedeflerinizi, kullanıcılarınızı ve kısıtlarınızı yeterince iyi anlayabilmesidir.
1. Çözümle değil, sorunla başlayın
Bugünkü durumu ve neyin işlemediğini anlatın. "Müşteriler sipariş durumunu öğrenmek için bizi arıyor ve bu, destek ekibimizin zamanının çoğunu alıyor" ifadesi, "bir uygulamaya ihtiyacımız var" demekten çok daha faydalıdır. Sorun net olduğunda ekip, onu çözen en basit yolu önerebilir; bu çözüm bazen beklediğinizden daha küçüktür.
2. Ürünü kimlerin kullanacağını anlatın
Ürünü kullanacak kişi gruplarını sıralayın: müşteriler, çalışanlar, yöneticiler, iş ortakları. Her biri için ne yapmaları gerektiğini ve bunu hangi koşullarda yapacaklarını not edin: şantiyede telefondan mı, ofiste masaüstü bilgisayardan mı, ara sıra mı yoksa her gün mü?
3. Olmazsa olmaz özellikleri listeleyin
İlk sürümün onlarsız yayına alınamayacağı özellikleri yazın. Ardından, ileride eklenmesi güzel olacak özellikleri ayrı bir liste halinde belirtin. Bu ikisini ayırmak, maliyeti ve yayına çıkış süresini kontrol altında tutmanın en etkili yoludur.
4. Örnekler paylaşın
Beğendiğiniz (ya da beğenmediğiniz) ürünlerin bağlantıları ve nedenine dair tek bir cümle bile çok değerlidir. Örnekler, tasarım ve davranışa ilişkin beklentileri uzun açıklamalardan çok daha hızlı aktarır.
5. Mevcut sistemlerden ve verilerden bahsedin
Yeni ürünün birlikte çalışması gereken bir muhasebe yazılımı, CRM, randevu aracı ya da elektronik tablolar kullanıyor musunuz? Taşınması gereken mevcut veriler var mı? Gizli karmaşıklık çoğu zaman entegrasyonlarda saklıdır; bu yüzden bunları baştan belirtin.
6. Kısıtlar konusunda açık olun
Hedeflediğiniz yayın tarihini, bütçe aralığınızı ve desteklenecek diller, erişilebilirlik ihtiyaçları ya da sektörel düzenlemeler gibi gereksinimleri paylaşın. Bütçe aralığı bir taahhüt değildir; ekibin ideal bir yaklaşım yerine size uygun olanı önermesine yardımcı olur.
7. Başarının nasıl görüneceğini tanımlayın
Projenin işe yaradığını nasıl anlayacaksınız? Daha az destek araması, daha fazla çevrim içi randevu, elle veri girişine harcanan zamanın azalması? Ölçülebilir bir hedef, proje boyunca kararların odaklı kalmasını sağlar.
Dışarıda bırakabilecekleriniz
Teknoloji seçmeniz, veritabanı tasarlamanız ya da ayrıntılı teknik şartnameler yazmanız gerekmez. Bunlar geliştirme ekibinin işidir ve iyi ekipler keşif aşamasında bunları sizinle birlikte netleştirir.
Basit bir şablon
- Arka plan: kim olduğunuz ve projenin ne hakkında olduğu
- Sorun: bugün neyin işlemediği
- Kullanıcılar: ürünü kimlerin ve nasıl kullanacağı
- Olmazsa olmaz özellikler ve sonraki özellikler
- Örnekler: beğendiğiniz ürünler ve nedenleri
- Mevcut sistemler ve veriler
- Kısıtlar: zaman planı, bütçe aralığı, diller, düzenlemeler
- Başarı: sonucu nasıl ölçeceğiniz
Bu başlıkları kapsayan tek sayfalık bir brif bile, bir geliştirme ekibiyle yapacağınız ilk görüşmeyi çok daha verimli hale getirir.