Keşif sizi yanlış şeyi geliştirmekten kurtarır.
Bir fikri kanıta dayalı bir karara dönüştüren yapılandırılmış bir sprint: doğrulanmış problem, test edilmiş konsept, maliyetlendirilmiş plan — ya da durmak için belgelenmiş bir gerekçe.
- Çerçeveleme
- Araştırma
- Prototip ve test
- Karar
“Dur” bir başarı sonucudur.
En pahalı yazılım, kimsenin ihtiyaç duymadığı yazılımdır. Keşif, kararın riskini azaltır: gerçek kullanıcılarla görüşülür, konsept prototiplenip test edilir, fizibilite ve maliyet onu geliştirecek mühendisler tarafından tahmin edilir — hepsi de bir geliştirme bütçesi taahhüt edilmeden önce.
Başarısız geliştirmelerin çoğu, kimsenin yanlışlayamayacağı bir iş gerekçesiyle onaylandı. Problem bir toplantıda hafızadan anlatıldı, kullanıcıları en son şikâyet eden kişi temsil etti ve tahmin, sonucuyla yaşamak zorunda kalacak birinden değil bir şablondan geldi. Yapılandırılmış çalışma bu üçünün de yerini alır: hatırlanan değil gözlemlenen problem, onu kullanacak kişilerin önüne konmuş bir konsept ve teslimatın sahibi olacak mühendislerin ürettiği bir maliyet aralığı. Çıktı, yönetim kuruluna savunabileceğiniz bir karardır — devam etmeme kararı da dâhil.
Doğrulanmış bir hayır bir keşif sprintine, doğrulanmamış bir evet bütün bir geliştirmeye mal olur.
Dört iş kolu, tek karar.
Sırayla değil paralel ilerlerler — prototip test edilirken araştırma hâlâ sürüyordur ve fizibilite çalışması en baştan başlar, çünkü en zor kısıtlar genellikle kimsenin kontrol etmediği teknik kısıtlardır.
Problem doğrulama
Yapılandırılmış görüşmeler ve iş akışı gözlemi — problem gerçekten var mı, kimde var, çözmenin değeri ne? İşi yapan kişilerle, aynı soru setini kullanarak konuşuruz; böylece yanıtlar anekdot olarak aktarılmak yerine karşılaştırılabilir. Mümkün olduğunda işi yapılırken izler ve adımları sayarız, çünkü bir sürecin nasıl anlatıldığı ile nasıl yürütüldüğü arasındaki fark, ürün fırsatlarının çoğunun bulunduğu yerdir.
Konsept prototipleme
Gerçek kullanıcılarla test edilen tıklanabilir prototipler — mühendislikten önce kanıt. Prototip bilinçli olarak dardır: konseptin bir değeri olup olmadığını belirleyen iki ya da üç anı, katılımcının gerçekçilik düzeyine değil fikre tepki vereceği kadar iyi kurgularız. Her turu sizin tarafınızdan biri izler, çünkü tek bir oturumu gören bir paydaş sonrasında farklı tartışır.
Fizibilite ve mimari
AI-native mühendisler entegrasyonu, veriyi ve riski değerlendirir — tahmin, teslimatın sahibi olacak kişilerden gelir. API dokümantasyonunu okur, gerçekte elinizde olan veriye bakar ve ürünün bağımlı olacağı sistemler üzerinde süre sınırlı spike'lar yürütürler. Ortaya çıkan mimari taslak, önemsiz kısımlarda bilinçli olarak kaba, risk taşıyan kısımlarda ise nettir.
Karar paketi
Kapsam, maliyet aralığı, zaman çizelgesi, riskler ve başarı metrikleri — bir bütçe kararının kâğıt üzerinde ihtiyaç duyduğu her şey. Odada bulunmayan biri tarafından okunmak üzere yazılır: kanıt, öneri, değerlendirilen alternatifler ve önerinin yanlış olması için nelerin doğru olması gerektiği. Hiçbiri dâhil olmak üzere herhangi bir tedarikçiyle kullanılabilir.
İş günlük olarak nasıl yürür?
Süresi sınırlı, tarihi sizinle birlikte belirlenir.
Keşif, kendisine verilen zamanı doldurmak üzere genişler; bu yüzden ona zaman vermiyoruz. Sprintin süresi sınırlıdır; süresi ve fiyatı baştan sizinle birlikte belirlenir ve karar oturumu çalışma başlamadan takvime alınır. Bu kısıt göründüğünden fazlasını yapar: araştırmayı gerçekten kararı değiştiren varsayımlara odaklanmaya zorlar, prototipi önemli anlarla sınırlı tutar ve paydaşlarınıza gündemde sürekli duran bir madde yerine bir tarih verir. Sizin tarafınızdan bir karar verici, kullanıcılara erişim ve bir teknik muhatap gerekir.
- Başlamadan önce üzerinde anlaşılan süre, fiyat ve tanımlı çıktılar
- En baştan takvime alınan karar oturumu ve adı belirlenmiş katılımcılar
- 01Çerçeveleme
- 02Araştırma
- 03Prototip ve test
- 04Karar
Dört aşama
Çok sayıda görüşme, tek bir kendinden emin görüşü yener.
Araştırma planı en başta yazılır ve kiminle neden konuşmamız gerektiğini adıyla belirtir: işi yapanlar, işi denetleyenler, istisnaları devralan kişi ve problemi başka bir yolla çözmüş en az bir kişi. Görüşmeler aynı yapıyı izler; böylece bulgular yalnızca alıntılanmaz, sayılabilir. Nihai paketteki her iddia bir oturuma kadar izlenebilir ve oturumların birbiriyle çeliştiği yerlerde bunları rahat bir ortalamada buluşturmak yerine durumu olduğu gibi belirtiriz.
- Önceden anlaşılmış bir katılımcı planı — segmentler, roller ve her birinin listede olma gerekçesi
- Yapılandırılmış görüşmeler; işin izlenebildiği her yerde iş akışı gözlemiyle birlikte
- Kanıtı ekli olarak yazılan bulgular — hipotezle çelişenler dâhil
Tahmin, onu geliştirecek kişilerden gelir.
İşi teslim etmeyecek biri tarafından üretilen bir tahmin, iyimserlik öngörüsüdür. Bizimki, geliştirmenin sahibi olacak mühendisler tarafından ve ilgili sistemlere dokunduktan sonra yapılır. Bu genellikle süre sınırlı spike'lar demektir: veriyi kayıt sisteminden hiç çıkarabiliyor muyuz, iş ortağının API'si gerçekte ne döndürüyor, geçmiş verinin ne kadarı kullanılabilir, tepe yük nasıl görünüyor. Mimari taslak, maliyeti belirleyecek iki ya da üç kararı ve bunları netleştirmek için neyi öğrenmemiz gerektiğini ortaya koyar.
- Dokümantasyon incelemesi değil, gerçek sistemler üzerinde süre sınırlı spike'lar
- Açıkça ifade edilmiş entegrasyon ve veri riskleri, her bilinmeyenin maliyetiyle birlikte
- Alt ve üst sınırını belirleyen varsayımlar yanına yazılmış bir maliyet aralığı
Yazıldığı toplantıdan sonra da ayakta kalan bir paket.
Karar paketi, aylar sonra planın hâlâ geçerli olup olmadığına karar veren biri tarafından okunmak üzere yazılır. İçinde kanıtlanmış hâliyle problem, konsept ve nasıl test edildiği, fizibilite bulguları, ekip yapısı ve zaman çizelgesiyle maliyetlendirilmiş bir plan, sahipleriyle birlikte riskler, işe yaradığını size söyleyecek başarı metrikleri ve yazılı bir öneri yer alır. Öneri geliştirme yönündeyse kapsam, ilk sürüm kanıt üretecek şekilde belirlenir — MVP hizmetimiz de tam olarak burada devralır.
- Aralık olarak fiyatlanmış seçenekler; her birinde neyin kapsamda, neyin bilinçli olarak kapsam dışında olduğuyla
- Renk kodlu bir tablo değil, sahibi ve önlemi olan riskler
- Geliştirmeden önce tanımlanmış başarı metrikleri; böylece sonuç anlatılmak yerine değerlendirilebilir
Üç farklı son ve hepsi işe yarar.
Geliştirin — ilk dilim de burada.
Problem gerçek, konsept testte iyi sonuç verdi ve fizibilite çalışması planın şeklini değiştirecek hiçbir şey bulmadı. Paket; kapsamı belirlenmiş bir ilk sürümü, bir ekip yapısını, bir zaman çizelgesini ve işe yarayıp yaramadığını size söyleyecek metrikleri devreder. Fizibilite değerlendirmesini aynı mühendisler yaptığı için teslimat yeniden keşif aşaması olmadan başlar — spike'lar, mimari taslak ve riskler zaten yazılıdır.
- Kalan en riskli varsayım etrafında kapsamı belirlenmiş bir ilk sürüm
- Teslimatı yapacak kişilerce maliyetlendirilmiş ekip yapısı ve zaman çizelgesi
- Kod yazılmadan önce üzerinde anlaşılmış başarı metrikleri ve ölçüm planı
Problem gerçek; ancak cevap bu değildi.
Bir sprint net bir evetle de net bir hayırla da bitmeyebilir. Araştırma çözmeye değer bir problemi doğrular ama konsept testte kötü sonuç verir; ya da fizibilite çalışması, fikrin pahalı kısmının kullanıcıların en az önemsediği kısım olduğunu bulur. Paket, bunun yerine kanıtın neyi desteklediğini söyler — çoğu zaman daha küçük bir geliştirme, bir süreç değişikliği ya da farklı bir ilk kullanıcı grubu — ve aynı maliyetlendirme disiplinini yeni kapsama uygular.
- Gözden geçirilmiş konsept ve onu yeniden yönlendiren somut kanıt
- Neyin neden çıkarıldığı; böylece karar sonradan sessizce yeniden açılmaz
- Eskisine indirim değil, yeni kapsama göre yeniden maliyetlendirilmiş bir plan
Geliştirmemek için belgelenmiş bir gerekçe.
Keşiflerin bir kısmı burada biter ve bu, getirisi en yüksek sonuç olabilir. Problem nadir çıkar, ya kurumun sahip olduğu bir şeyle zaten çözülmüştür, ya çözmenin maliyetinden daha az değerlidir, ya da hiçbir yazılımın ortadan kaldıramayacağı bir kısıtla engellenmiştir. Paket, kanıtı ve gerekçeyi kayda geçirir; böylece bir koşul değiştiğinde fikir yeniden değerlendirilebilir — ileride aynı varsayımlarla ve bu çalışmanın hafızası olmadan yeniden ortaya çıkmak yerine.
- Durma gerekçesinin kanıtı; açıkça ifade edilmiş ve oturumlara dayandırılabilir
- Yeniden ele almayı değerli kılacak koşul
- Araştırmanın gerçekten desteklediği daha küçük ve daha ucuz eylemler
Bir keşif sprinti ya da doğrudan geliştirmeye.
Dört aşama ve karar oturumu şimdiden takvimde.
Çerçeveleme
Paydaş uyumu: problem hipotezi, kullanıcılar ve hangi kanıtın fikirleri değiştireceği. Hipotezi yanlışlanabilir bir biçimde yazar, araştırma katılımcılarını belirler ve karar ölçütlerini kararı verecek kişiyle birlikte netleştiririz. Fizibilite spike'ları paralelde başlar, çünkü çözülmesi en uzun süren şey teknik bilinmeyenlerdir.
Araştırma
Kullanıcı görüşmeleri ve sistem incelemesi — problem, toplantılarda hatırlandığı gibi değil, gerçekte olduğu gibi. Görüşme oturumları, işin izlenebildiği yerlerde iş akışı gözlemi ve ürünün bağımlı olacağı sistemlerle verinin incelenmesi. Bulgular rapora saklanmak yerine geldikçe paylaşılır; böylece konsept erkenden ilerlemeye başlayabilir.
Prototip ve test
Konsept kurgulanır ve kullanıcıların önüne konur; fizibilite paralelde değerlendirilir. Prototip, konseptin değerini belirleyen anları kapsar ve her oturumu sizin tarafınızdan biri izler. Mühendisler spike'ları tamamlar ve bunları bir mimari taslağa, bir risk listesine ve maliyet aralığının arkasındaki varsayımlara dönüştürür.
Karar
Bulgular, prototip sonuçları ve maliyetlendirilmiş plan — devam / pivot / dur kararı için sunulur. Oturum bir sunum değil, bir çalışma toplantısıdır: öneri, arkasındaki kanıt ve değerlendirilen alternatiflerle birlikte masadadır. Karar ne olursa olsun yazılı paketle ayrılırsınız.
Karar ne olursa olsun elinizde kalanlar.
- Görüşme kanıtlarıyla araştırma bulguları
- Test edilmiş prototip ve kullanılabilirlik sonuçları
- Teknik fizibilite değerlendirmesi ve mimari taslak
- Ekip yapısı ve zaman çizelgesiyle maliyetlendirilmiş teslimat planı
- Devam / pivot / dur önerisi — yazılı olarak
- Sahipleriyle birlikte risk listesi ve her rakamın arkasındaki varsayımlar
- Başarı metrikleri ve lansmandan sonra nasıl ölçülecekleri
Bunun doğru karar olduğu durumlar.
Kimsenin test etmediği bir varsayım üzerine ciddi bir bütçe taahhüt edilmek üzereyse, şirket içindeki iki taraf ne geliştirileceği konusunda anlaşamıyor ve bir çalıştay daha değil kanıt istiyorsa ya da fikir gerçek durumu bilinmeyen sistem ve verilere bağlıysa keşfi seçin. Ayrıca geliştirmeyi satın almayla karşılaştırmanın bir yoludur, çünkü aynı sprint her ikisini de fiyatlandırır. Bir MVP ya da özel geliştirme öncesinde doğal olarak yürür ve konsept testten geçtiğinde UX / UI tasarımı ile birlikte ilerler.
Karar zaten verilmiş ve bütçelenmişse, kurum yalnızca teyit istiyorsa doğru karar değildir — bu bir keşif sprinti değil, bir incelemedir ve onun yerine bunu öneririz. Kapsamı kullanıcı ihtiyacından değil mevzuattan belirlenen, uyum odaklı bir geliştirme için de doğru karar değildir. Ve gerçek kullanıcılara ulaşamıyorsak işe yaramaz: işi yapan kişilere erişim olmadan sprint, yalnızca daha iyi biçimlendirilmiş bir görüş üretir.
Sık sorulan sorular
Bu hizmetin genellikle götürdüğü yerler.
Ne geliştirdiğinizi anlatın.
Bugün elinizde ne olduğunu ve neye ihtiyacınız olduğunu anlatın. Bir mühendis okur ve nasıl yaklaşacağımızı yazılı olarak iletir.