Çoğu işletme ve ürün lideri, Sonuç Yol Haritaları kavramını ve Ürün Stratejisini uygulanacak bir plana bağlamaya nasıl yardımcı olduklarını anlar . Ancak pratikte bu yaklaşıma geçmekte zorlanıyorlar.
Bunun bir nedeni, sonuçlarla dolu bir yol haritasının Agile geliştirme sürecine nasıl dönüştürüleceğinin belirsiz olmasıdır. Sonuçta, kod nihai olarak yazıldığında, bir tanım tarafından yönlendirilmesi gerekir. Sağ?
Not: Bu makalede Scrum'daki bazı terminoloji ve uygulamalardan yararlanıyorum . Ancak, bu yaklaşımdaki kavramlar Scrum'a özgü olarak görülmemelidir.
Tipik Bahar Planlama sürecine bir göz atan ekip, Ürün İş Listesindeki hangi öğelerin Sprint İş Listesine yerleştirilmesi gerektiğini düşünür. Ürün İş Listesi, ekip tarafından ulaşılması gereken öncelikli bir sonuç listesinden oluşur. Sprint İş Listesi, genel olarak Kullanıcı Hikayeleri açısından açıklanan, oluşturulacak bir işlevsellik tahmini içerir.
Sonuç Yol Haritasından Kullanıcı Hikayelerine nasıl geçilir?
Bir Sonuç Yol Haritasından çalışırken, bunun aslında Ürün İş Listesinde yer alan istenen sonuçlar için bir zaman ufku planlama yolu olduğunu görebiliriz.
Not: Uygulamada, Ürün İş Listesi, ekip tarafından yapılması gereken ek işleri içerir. Bu makale için basitleştiriyorum ve sadece Sonuçları dikkate alıyorum.
Vakaların büyük çoğunluğunda, istenen sonucu analiz etmek ve bunu başaracak kullanıcı hikayelerinin bir listesine hemen ulaşmak mümkün olmayacaktır. Sprint Planlama seansı bir günden daha kısa bir süreye sahip olacağından, bu işlerin bir kısmının önceden yapılması gerektiği açıktır.
Bu keşif çalışmasını Ürün İş Listesi ve Sprint İş Listesi arasına nasıl yerleştirebiliriz?
Çözüm oldukça mantıklı ve genellikle Dual Track Geliştirme olarak anılıyor . Jeff Patton, konsepti yaratma ve geliştirme konusunda büyük itibar görüyor ancak Desirée Sy'ye kredi veriyor . Kısacası, Ürün Ekibinin iki ayrı paralel çalışma akışı (1) Ürün Keşfi ve (2) Geliştirme ile uğraşması gerektiğini söylüyor.
Patton modelinde, Ürün Keşfi çalışması Fırsatlarla (örneğin fikirler, çözülecek problemler) başlar. Burada yapmamız gereken küçük ayar, istenen Sonuçlarla bir adım geri başlamaktır. Potansiyel Fırsatları belirlemek, daha sonra Ürün Keşfi yolunun gerekli bir parçası haline gelir.
Süreç, Ürün Ekibinin Öncelikli Ürün İstek Listesinden Sonuçları çekmesi ve olası çözümleri hızla belirlemek ve doğrulamak için keşif çalışması yapmasıdır.
Bu çalışmada Marty Çağan'ın Dört Büyük Riski konusunu ele alıyoruz .
Ürün Keşfi sürecindeki tüm yapılar, Geliştirme yolunun spesifikasyonunun bir parçası haline gelir.
Ek Notlar:
Bahar Planlaması oturumları artık Sprint İş Listesine girmek için Ürün İş Listesinden doğrulanmış fikirleri seçmekle sınırlı olacak. Şimdi, bir Sprint'e girerken, takım kodlayacakları şeyin değerine çok daha fazla güveniyor ve tasarımdaki riskleri azaltıyor.
Riskler azalırken tüm Ürün Ekibinin Geliştirme ile meşgul olmaya devam etmesi gerektiğini unutmamak önemlidir. Hiçbir Keşif süreci, Geliştirme sırasında ortaya çıkan her bilinmeyeni ele almaz.
Aşağıdaki şema, Yol Haritasından Tamamlanmış Hikayelerin Potansiyel Olarak Gönderilebilir Ürün Parçalarına kadar tüm süreci açıklamaktadır. Kısaca, Doğrulanmış Fikirler üretmek için İstenen Sonuçları çeken Ürün Keşfi sürecini göstermektedir. Buna paralel olarak, Ürün Ekibi, Bahar İş Listesinden alınmış, halihazırda doğrulanmış fikirler üzerinde Geliştirme çalışması da yapmaktadır.
Dikkat edilmesi gereken, bu süreç diyagramının Jeff Patton'ın konseptinden, ikisini karşılaştırıyorsanız, birkaç özel şekilde farklılık gösterdiğidir.
Scrum içinde geliştirme sürecini uygularken, değer akışı başına tek bir Ürün İş Listesi ve tek bir Sprint İş Listesi ile çalışma ihtiyacıyla bir şekilde sınırlı kalıyoruz. Çevik olma ruhunda, kullanılan araçların kısıtlamalarına ve ekip tercihlerine bağlı olarak bazı kuruluşların daha uygulanabilir bulabileceği alternatifler vardır.
Ürün İş Listesinde önceliklendirilen Sonuçlar ile Bahar Planlamasına girmeye hazır olan doğrulanmış fikirler arasında net bir farklılaşma olmasını sağlamak için üçüncü bir biriktirme listesi yapısı oluşturulabilir. Ben buna Validated Idea Backlog diyorum.
Doğrulanmış Fikir İş Listesinin iki potansiyel faydası vardır.
Birincisi, içindeki öğelerin ayrıntı düzeyinin Sonuçlar değil, Doğrulanmış Fikirler olacağıdır. Bir Sonuç birden fazla fikir birlikte çözülebileceğinden, bu, ekibin bunları bağımsız olarak yönetmesine yardımcı olacaktır.
İkinci olarak, bazı Doğrulanmış Fikirler birden çok Sonucu destekleyebilir. Bunları ayırarak, bazı araçlarda bu tür ilgili faydaları izlemek daha kolay hale gelebilir.
Bazı kuruluşlar, geliştirme süreci boyunca bir iş akışını yönetmek için Kanban yaklaşımına geçmektedir. Uygulamada bu, Bahar Planlaması gibi özel planlama etkinliği kilometre taşları olmayabileceği anlamına gelir ve bu da bir ara planlama biriktirme listesi yapısına olan ihtiyacı ortadan kaldırır.
Bu yaklaşım basitleştirir, süreç tanımını açıkça basitleştirebilir. Uygulamada, ekibin süreç içindeki işi nasıl izlemeyi tercih ettiğini desteklemek için Doğrulanmış Fikirler (İş Listesi) ile Potansiyel Olarak Gönderilebilir içerik arasında bir veya daha fazla ek süreç içi adım olacaktır.
Süreç içindeki işi yönetmek için Kanban sistemleriyle çalışanlar için, Ürün Keşfi ve Geliştirme çalışmasının paralel doğasını gözden kaçırmamak önemlidir. Kanban altında bile, bu iki aktivite izi, öğrenme döngülerini en aza indirmek için her zaman aynı anda gerçekleşmelidir.
Sonuç Yol Haritaları ilk bakışta mevcut Çevik geliştirme yaklaşımlarına hemen uymuyor gibi görünebilir. Ürün Ekiplerinin, yalnızca Sonuçların başlangıç noktası olduğu bir Bahar Planlama etkinliğinden geçemeyecek kadar çok bilinmeyenleri var.
Uygulamada, çok iyi bilinen Dual Track Geliştirme yaklaşımının iyi uyduğunu görebiliriz. Eşzamanlı Ürün Keşfi yolu, İstenen Sonuçları, Geliştirmenin en etkili olması gereken doğrulanmış fikirlere çevirmek için etkili bir yaklaşımdır.
Dahası, Ürün Keşfi bazı ayrı tasarım ekipleri tarafından değil Ürün Ekibi tarafından birlikte gerçekleştirildiğinden, zamanla daha yenilikçi çözümlerin ortaya çıkması muhtemeldir.
İlk olarak https://productstride.substack.com adresinde yayınlanmıştır .
Altı ay önce, Mercadona Tech'de kapasite dikeyinde Ürün Müdürü olarak yolculuğuma başladım. Ürün yönetimi bilimden çok bir sanattır ve herkesin bu alandaki yolculuğunun benzersiz olacağına inanıyorum.
Blockchain teknolojisi ve oyun sektörünün önde gelen yatırımcıları olan Paramount Capital, Sino Global Capital, Three Arrows Capital ve Merit Circle tarafından ortaklaşa yürütülen 6,4 milyon dolarlık özel bir turu duyurmaktan mutluluk duyuyoruz.
Amaç, algıya çok daha fazla netlik getiren bir şeye nasıl baktığınızı çerçevelemenin bir yoludur. “Amaç” dediğimde, bir kişinin başarmaya çalıştığı şeyi kastediyorum, ekibinizin bilmek istediği şeyi veya kuruluşunuzun yıl içinde neyi başarmayı umduğunu değil.
Fiyat, bir dolar rakamından çok daha fazlasıdır - bir değerin temsilidir ve bir ürünün para kazanıp kazanmayacağını belirlemede en kritik faktördür. Yine de, genellikle sonradan düşünülür, bir ürün geliştirildikten sonra son dakikada değerlendirilir.
Ürün yönetimi o kadar çok farklı beceri gerektirir ki büyük ihtimalle çalışanlarınız en azından bazılarında sizden daha tecrübelidir. Bu beceriler, ekibinizin başarmaya ihtiyaç duyduğu şeyin temelini oluşturduğunda kafa karıştırıcı hale gelebilir.
Onlarla mücadele etmenin ve projelerinizi ve akıl sağlığınızı yolda tutmanın 3 yolu Ellerinizi indirin, Ürün Yönetiminin en zor kısmı, sizden güneşi ve ayı bakımlı parmaklarının çırpışıyla teslim etmenizi bekleyen mantıksız yöneticilerle uğraşmaktır. Benim zamanımda her türden yaşadım.