Bir projeyi bir haftalık ilk sürüme indirmek

“Herkes için proje platformu” yerine “Küçük ekiplerin gelen müşteri sorularını kaybetmeden takip edebileceği bir liste” düşünün. İlk örnekte ürünün sınırı görünmez; ikincide bir kayıt, durum ve sorumlu ilişkisi vardır. Kullanıcının bugünkü yöntemini de yazın. İş zaten bir defterle çözülüyorsa yeni araç hangi sürtünmeyi azaltacak? Daha çok özellik, bu soruya verilmiş bir yanıt değildir.

Örnek akışınız şöyle olabilir: Kullanıcı kayıt ekler, listede görür, durumunu değiştirir ve daha sonra tekrar açar. Bu akıştaki dört adımı çalışır hale getirmek, on boş ekran tasarlamaktan daha öğreticidir. Hata durumlarını da düşünün: Zorunlu alan boşsa ne olur, kayıt bulunamazsa ne gösterilir, kullanıcının erişimi yoksa ne yapılır? Arayüz çiziminde her kutunun altına tek bir eylem yazın.

İlk sürümün olmazsa olmazlarını kısa tutun. Kayıt kaybolmamalı, yetkisiz kişi özel kayda ulaşmamalı, kullanıcı yaptığı işlemin sonucunu görmeli. Renk temasını değiştirmek veya gelişmiş raporlar ilk işin tamamlanması için gerekmiyorsa sonraya bırakılabilir. Ancak güvenli veri saklama gibi temel ihtiyaçları “sonra ekleriz” listesine atmayın. Kapsam azaltmak, ürünün temel sözünü daha dar ve daha açık hale getirmektir.

İlk gün kullanıcı ve akış netleşsin. İkinci gün veri alanları ve ekran taslağı hazırlansın. Sonraki iki gün akış uygulansın. Beşinci gün gerçekçi örneklerle test yapılsın. Altıncı gün bulunan sorunlar giderilsin; son gün birkaç kullanıcıdan geri bildirim alınsın. Günler ekip kapasitenize göre değişebilir. Her günün çıktısını dosya sayısıyla değil, gösterilebilir bir davranışla tanımlayın. Bu, ilerlemeyi daha dürüst biçimde görünür yapar.

GitHub Issues ve Projects gibi araçlar, işleri görevler halinde ayırıp durumlarını izlemeye yardım eder. Aynı düzeni basit bir tabloda da kurabilirsiniz. Her görevde amaç, sorumlu, bitiş ölçütü ve engel alanı bulunsun. “Üyelik tamamlandı” yerine “Kayıt, giriş, çıkış ve hatalı parola akışı test edildi” yazın. Bir görevin tamamlanmış sayılması için hangi kanıtın gerektiğini önceden belirlemek, son gün sürprizlerini azaltır.

Kullanıcıya bütün düğmeleri anlatmak yerine bir iş verin ve nerede takıldığını izleyin. “Bu ekran güzel mi?” sorusu yerine “Şu kaydı ekleyip durumunu değiştirebilir misin?” daha somut geri bildirim sağlar. Gerçek müşteri verisi kullanmak gerekmiyorsa temsili veriyle ilerleyin. Deneme sonunda yalnızca beğenileri değil, yanlış anlaşılmaları ve tamamlanamayan işleri kaydedin. Sonraki sürümün sırasını bu gözlemler belirlesin. Forumda projenizi paylaşırken neyin çalıştığını, neyin planlandığını ve hangi konuda yardım istediğinizi açıkça yazın.