İyi bir yazılım projesi brief'i nasıl hazırlanır?

Bir proje brief'i teknik bir şartname olmak zorunda değil. İlk amacı, çözmek istediğiniz ihtiyacı karşı tarafa anlaşılır biçimde aktarmaktır. Şu beş soruyla başlayabilirsiniz.

1. Bugün ne zor geliyor?

İstediğiniz ekranları sıralamak yerine mevcut süreci anlatın. Örneğin: “Sipariş bilgilerini farklı dosyalarda tutuyoruz ve hangi kaydın güncel olduğunu anlamak zorlaşıyor.” Böyle bir açıklama, neden değişime ihtiyaç duyulduğunu gösterir.

2. Kim kullanacak?

Uygulamayı kullanacak kişilerin görevlerini yazın. Operasyon sorumlusu, yönetici ve müşteri farklı bilgilere ihtiyaç duyabilir. Teknik bilgi düzeyleri ve hangi cihazları kullandıkları da tasarım kararlarını etkiler.

3. İlk sürümde mutlaka ne olmalı?

İstekleri “ilk sürüm için gerekli” ve “sonraki aşamada değerlendirilebilir” olarak ayırın. Bu ayrım kapsamı konuşmayı kolaylaştırır. Bir sipariş uygulamasında kayıt oluşturma temel ihtiyaçken gelişmiş raporlar sonraki aşamaya bırakılabilir; karar sizin iş akışınıza bağlıdır.

4. Hangi bilgiler ve araçlar zaten var?

Kullandığınız dosyaları, mevcut uygulamaları ve veri kaynaklarını listeleyin. Gerçek müşteri bilgisi veya parola paylaşmak yerine, anonimleştirilmiş örneklerle veri yapısını anlatın. Entegrasyon gerekiyorsa ilgili aracın adını ve erişilebilir dokümantasyonunu belirtin.

5. Tamamlandığını nasıl anlayacağız?

Somut bir kabul örneği yazın: “Yetkili kullanıcı bir sipariş oluşturabilmeli ve ekip aynı siparişin durumunu görebilmeli.” Bütçe beklentisi, tercih edilen takvim ve kararı kimin vereceği de ilk görüşmede konuşulmalıdır.

Küçük bir başlangıç şablonu

• Mevcut sorun:
• Kullanacak kişiler:
• İlk sürümde gerekli işler:
• Kullanılan araçlar ve veriler:
• Kabul örneği:
• Tercih edilen zaman planı:

Her yanıtı baştan bilmeniz gerekmez. Açık kalan noktaları belirtmek de brief'in bir parçasıdır. İyi bir başlangıç, soruları birlikte netleştirmeye alan bırakır.