Fikrinizi kapsama dönüştürmek: bir uygulama işine nereden başlanır?

"Bir uygulama yaptırmak istiyorum" cümlesi bir başlangıçtır, ama bir teklif isteği değildir. Bir yazılım ekibi bu cümleyle iki kişiye aynı fiyatı ya da aynı süreyi veremez, çünkü cümlenin içinde ne yapılacağı yok. Bu yazıda fikri, bir ekibin gerçekten üzerinde çalışabileceği bir kapsama çevirmenin yolunu anlatıyoruz.

Kapsam nedir, fikirden farkı ne?

Fikir bir yöndür: "Randevuları telefondan almak yerine bir yere toplayalım." Kapsam ise sınırdır: kim kullanacak, hangi ekranlar olacak, ilk sürümde neler var, neler yok. Fikir büyüyebilir, kapsam yazılıdır ve herkes aynı şeye bakar.

Kapsamı yazmanın faydası basittir: iş başlamadan önce anlaşmazlıkları kâğıt üzerinde bulursunuz. Kâğıt üzerinde bir anlaşmazlığı çözmek kolaydır; yazılım yazıldıktan sonra çözmek zordur.

Beş soru

Aşağıdaki sorular her ürün için işe yarar. Cevapları birkaç cümleyi geçmesin.

1. Bu ürünü kim kullanacak?

"Herkes" cevabı tasarımı da yazılımı da belirsiz bırakır. Önce en önemli tek kullanıcıyı seçin: sizin müşteriniz mi, çalışanınız mı, siz mi? Birden fazla kullanıcı türü varsa (örneğin müşteri ve yönetici) ikisini ayrı ayrı yazın.

2. Hangi sorunu çözüyor?

Sorunu şu kalıpla yazmayı deneyin: "Şu anda ... yapıyoruz, bu yüzden ... oluyor." Örneğin: "Şu anda randevuları telefonla alıp deftere yazıyoruz, bu yüzden çift randevu oluyor." Çözümü değil, bugünkü durumu yazmak, sonradan "bu özellik gerçekten gerekli miydi?" sorusuna cevap verir.

3. Kullanıcı ilk sürümde hangi işi yapabilmeli?

Buraya özellik listesi değil, kullanıcının bitirmek istediği işi yazın: "Müşteri boş saati görüp randevu alabilmeli." Bir iş, birkaç ekrandan oluşur; ekranları sonra çıkarırız. Üç ila beş iş çoğu ilk sürüm için yeterlidir.

4. İlk sürümde neler olmayacak?

En çok atlanan ve en çok işe yarayan sorudur. "Şimdilik yok" listesi, kapsamın sessizce büyümesini engeller. Ödeme, çoklu dil, mobil uygulama, raporlar: aklınıza gelen ama ilk kullanıcıyı denemek için şart olmayan her şeyi bu listeye yazın. Liste bir vazgeçme değil, erteleme kaydıdır. Bu konuyu ayrıca bir MVP'de neyi kesersiniz yazısında işledik.

5. Başarıyı nasıl anlayacaksınız?

Ölçülebilir olması gerekmez ama gözlemlenebilir olmalı: "Bir ay içinde randevuların çoğu telefon yerine bu ekrandan girilsin." Başarı ölçütü yoksa ürün bitince "oldu mu, olmadı mı" tartışması başlar.

Cevaplar bir belgeye dönüşünce ne olur?

Beş soruya verdiğiniz cevaplar, bir sayfalık kapsam belgesinin iskeletidir. Bu belgeyle şunları yapabilirsiniz:

• Farklı ekiplerden karşılaştırılabilir teklifler isteyebilirsiniz; herkes aynı metne bakar.
• Bir ekiple çalışmaya başladığınızda, gereksinim belgesinin (PRD) ilk taslağı hazır olur.
• Sonradan gelen "şunu da ekleyelim" taleplerini belgeyle karşılaştırıp bilinçli karar verirsiniz.

Belge bir sözleşme ya da taahhüt değildir; bir konuşma zemini olarak düşünün. Bizde de her iş, yazılı gereksinim belgesiyle başlar; tasarım, yazılım ve QA aşamaları o belgeye göre ilerler. Bu düzeni nasıl çalışıyoruz sayfasında ayrıntılı anlattık.

Sık yapılan üç hata

Çözümle başlamak. "Bir mobil uygulama istiyorum" yerine "müşterilerimin randevu almasını istiyorum" demek, web ya da mobil kararını sonraya bırakır ve doğru karar için bilgi verir.

Her şeyi ilk sürüme yüklemek. İlk sürümün görevi, fikri gerçek kullanıcıyla denemektir; eksiksiz bir ürün olmak değildir.

Kullanıcıyla konuşmadan yazmak. Cevapların çoğu bir iki kullanıcıyla yapılacak kısa bir konuşmadan çıkar. Fikri yalnızca kendi kafanızda kurmayın; olası bir kullanıcıya "bunu şimdi nasıl yapıyorsun?" diye sorun.

Kapsam Sihirbazı bu işi kolaylaştırır

Bu beş soruyu boş bir belgeye yazmak zor olabilir. Bu yüzden Kapsam Sihirbazı'nı yaptık: fikrinizi adım adım sorularla anlatırsınız, sonunda kapsam belgenizi indirirsiniz. Ücretsizdir; belgeyi indirmek sizi bir şeye bağlamaz, başka bir ekiple de kullanabilirsiniz. Nasıl kullanılacağını Kapsam Sihirbazı nasıl kullanılır yazısında anlattık.

Küçük bir örnek

Diyelim ki bir kuaför, randevuları telefonla alıp deftere yazıyor. Beş soruya kısa cevaplar (varsayımsal bir örnektir) şöyle olabilir:

• Kim: Salon sahibi ve müşteriler.
• Sorun: Telefonla alınan randevular deftere yanlış geçince çift randevu oluyor.
• İlk sürümde: Müşteri boş saati görüp randevu alır; salon sahibi günün listesini görür.
• Yok: Ödeme, puanlama, kampanya kodu.
• Başarı: Bir ay içinde randevuların çoğu bu ekrandan girilir.

Bu beş satır, bir ekibe "bunun için teklif verin" demek için yeterli bir başlangıçtır. Hâlâ boşlukları vardır; onları birlikte konuşarak kapatırız. Önemli olan, konuşmanın boş sayfadan değil yazılı bir metinden başlamasıdır.

Özet

• Fikir bir yöndür, kapsam yazılı bir sınırdır.
• Beş soru: kim, hangi sorun, ilk sürümde hangi iş, neler yok, başarı nasıl anlaşılır.
• "Şimdilik yok" listesi kapsamı korur.
• Belge, teklifleri karşılaştırılabilir kılar ve işin başlangıcını hızlandırır.

Fikrinizi kapsama çevirdiyseniz ya da yardım isterseniz, teklif alabilirsiniz.