giriiş

Bu makale , uzun yıllardır Ürün Sahibi (PO) olarak kullandığım pratik ipuçları ve tekniklerle ilgili önceki bir makalenin devamı niteliğindedir . Değerli makalede, genel deneyimimi 6 kovaya ayırdım:

1. Özelliklerin tasarımı (önceki makalede ele alınmıştır )

2. İşin Önceliklendirilmesi

3. Ürün İş Listesi oluşturma ve sürdürme

4. Paydaş Yönetimi

5. Ekip Yönetimi

6. Ürün Metrikleri Tasarımı ve Yönetimi

Bu yazı için, İşin Önceliklendirilmesine ve Ürün İş Listesi oluşturmaya ve sürdürmeye odaklanacağım. Diğer konuları bir sonraki yazıda ele almaya çalışacağım.

İşin Önceliklendirilmesi

Elinizde bir ihtiyaç listesi olduğunda, hangi işin ne zaman yapılacağını belirlemek için bu listenin önceliklendirmesini yapmak son derece önemlidir. Yeni ve deneyimli PO'ları ayıran şey, önceliklendirmenin ne kadar iyi yapıldığıdır.

Benim durumumda, ürün sahipliği yapmaya başladığımda, önceliklendirme konusunda gerçekten kötüydüm. Eskiden ilginç bulduğum işe öncelik verirdim. Eskiden, bence kullanıcıların ürünü kullanma şeklini değiştirecek pahalı (çabalı) özelliklere öncelik verirdim. "Özelliğin" "oyun değiştirici" olacağından veya üründe devrim yaratacağından her zaman emindim.

Kıdemli bir PO'dan veya Ürün Yöneticisinden rehberlik veya akıl hocalığı burada işe yarar. Birinin fikirlerini tartışabilecekleri iyi ve yardımcı bir Proje Yöneticisi veya akıl hocası varsa, bu gerçekten yardımcı olur. "Oyunun kurallarını değiştireceğini" düşündükleri pek çok fikrin muhtemelen daha sonra yapılabileceğini veya bazı durumlarda son kullanıcıların buna ihtiyacı olmadığını fark edebilecekler. Fikirlerinizi başkalarıyla, özellikle de fikrinize katılmayanlarla tartışmak her zaman yardımcı olur. Bu, sizi geri bildirim almaya ve siloda düşünmemeye zorladığı için yardımcı olur.

Zor yoldan öğrenmek

Benim için, neyi yanlış yaptığımı zor yoldan öğrenmek zorunda kaldım. Son kullanıcıların gerçekten istediği veya bir süredir istediği özellikler yerine "havalı" ve sevdiğim özellikleri oluşturmaya öncelik verdim. Benim gibi yeni PO'lara çok fazla alan tanıyan bir Kıdemli Direktörün altında çalıştığım için çok şanslıydım. Ürünlere tamamen sahip olmalarına izin verir ve ürünlerle ilgili neredeyse tüm kararları bırakırdı. Bu, PO'ların çok fazla özgürlüğe sahip olmasına ve daha fazla inisiyatif almasına yol açtı. Aynı zamanda birçok hata yapmalarına da yol açtı. Ve benim gibi, hepsi hatalarından ders aldılar ve çok daha iyi PO'lar oldular.

Önceliklendirmeye geri dön. Yıllar geçtikçe, görünüşte "havalı" özelliklere öncelik vermenin son derece aptalca olduğunu fark ettim. Daha önce de belirttiğim gibi, harika bir özelliğin son kullanıcı tarafından sıfır benimsenmesi olabilir. Kullanım ölçümleri kontrol edildiğinde birden çok "harika" özelliğin çok kötü performans göstermesinden sonra bunu zor yoldan öğrendim. Ancak, görünüşte "sıkıcı" görünen bir özelliği uyguladığımız durumlarda, kullanım ölçütlerinde ve son kullanıcıların beğenisinde önemli bir artış gördük.

Önemli Öğrenimler ve Çıkarımlar

1. Ürün yol haritasının belirlenmiş olduğu bir ekipteyseniz ve üst yönetim tarafından belirlenen öncelikleriniz varsa o önceliklere bağlı özellikler ön planda gelir.
2. Örneğin benim durumumda, ürünün şirket içinden bulut hareketine geçişi, ürün yol haritasında sabitlenen ve tanımlanan bir şeydir ve belirlenen zaman çizelgesi ve öncelikler dahilinde çalışmamız gerekiyordu.
3. Kendinize, düşündüğünüz yeni özelliğin uygulamak istediğiniz "harika" bir şey mi yoksa gerçek bir son kullanıcı gereksinimi mi olduğunu sorun. Bu konuda dürüst ol. Kendine yalan söylemek de kolaydır. Geçmişte yaptım.
4. Bu yeni geliştirmeyi oluşturmak için harcanan çaba nedir? Diğer takımlara bağımlılığı var mı? Diğer ekip, yeni özellikle ilgili işi almak için bant genişliğine sahip olacak mı?
5. Özelliğinizin öncelik sırasını doğrulamak için gerçek zamanlı verilerle gelin. Dürüst olun ve veriler beklediğinizle uyuşmuyorsa fikrinizi değiştirmeye hazır olun. Çoğu zaman veriler beklentilerinizi karşılamaz.
6. Uygulamanız gereken birden fazla özelliğiniz olması durumunda, başlamak için sağlam bir nokta, değişiklikten kaç son kullanıcının etkilendiğidir. Ayrıca, kaç kullanıcı bu özelliği istedi?
7. İnsanlarla konuş
8. Bazen gereksinimler konusunda dar görüşlü olabilirsiniz. Önceliklendirmenizi mümkün olduğunca diğer/kıdemli PO'larla ve kendi ekip üyelerinizle doğrulayın. Geri bildirimlerini alın. Birden fazla görüş almaktan korkmayın
9. Ekibinizin tüm üyeleriyle tartışın. Ürünle günlük olarak çalışırlar ve genellikle ürünü iyi anlarlar. Neyin önemli neyin önemsiz olduğuna dair fikirler sizi hoş bir şekilde şaşırtacak.
10. Yıllar geçtikçe, ekibinizle yaklaşan özellikleri tartışmanın, genellikle hem destekleyici hem de çelişkili birden fazla görüş duyduğunuz için önceliklendirmede size yardımcı olduğunu keşfettim.

Ürün İş Listesi — Oluşturma ve Bakım



Ürün biriktirme listesinin oluşturulması ve sürdürülmesi, bir PO'nun önemli bir işlevidir. Takım için de önemli. PO'nun gelen özellik isteklerini kategorize edebileceği, gruplandırabileceği ve anlamlandırabileceği bir yer sağlar. Ekip için, ürünün geleceğinin yol haritası olarak hizmet eder.

Destanlar, Özellikler ve Kullanıcı Hikayeleri gibi birikmiş işlerin farklı seviyeleri vardır. Bazı PO'lar yalnızca Kullanıcı hikayelerini kullanırken, bazıları hem Özellikleri hem de Kullanıcı Hikayelerini kullanır. Benim durumumda, 3 seviyenin hepsiyle çalışırdım. Bu, ürünün Nedenini ve Nasılını tanımlamam konusunda bana çok daha iyi bir tutuş sağladı.

Ürünün Hikayesi

Destanlar, ürünün "hikayesini" temsil ettikleri için genel ürün birikiminin çok önemli bir parçasıdır. Bunları hikaye anlatmak ve ürünün mevcut vizyonunun ve uzun vadeli stratejisinin ne olduğunu göstermek için kullandım. Ayrıca Destanların, ürünün geçmişte kat ettiği yolu, şu an içinde bulunduğu yolculuğu ve ürünün geleceğini gösterecek şekilde bölünmesini sağladım. Ayrıca Özellikler ve Kullanıcı hikayeleri, bana "hikayeyi" daha ayrıntılı ayrıntılarla tanımlama esnekliği sağladı.

Önemli Öğrenimler ve Çıkarımlar

1. Oluşturduğunuz Destanların geniş bir kapsama sahip olduğundan ve gelecekteki özellikleri barındıracak şekilde iyi düşünüldüğünden emin olun. Bu, mevcut bir özelliğin önceliğinin değişmesi gibi durumlarda da yardımcı olur. Ya da ani bir yüksek öncelikli özelliğe uyum sağlama ihtiyacı.
2. Genel olarak gelen herhangi bir yeni gereksinim, önceden tanımlanmış destanlardan birine uymalıdır. Değilse, belki gereksinimi yeniden düşünün. Veya destanın anlatısına uyması için gerekliliği bozmayı/değiştirmeyi deneyin
3. Bazı durumlarda, herhangi bir destana uymayabilecek bazı gereksinimler alabilirsiniz. Bu durumda, belki bir biriktirme listesi destanı oluşturun ve gereksinimi buna bağlayın
4. Destanları kapatmak da önemlidir. Bir noktadan sonra diyelim ki bir destandaki özelliklerin %50'den fazlasını bitirdiniz, destana daha fazla özellik eklemeyin ve onun tamamlanmasına doğru ilerleyin. Uzun süre açık tutar ve ona özellikler eklemeye devam ederseniz, destan asla tamamlanmaz.
5. Ekip önemli bir kilometre taşına ulaştıktan sonra, ekiple her zaman ürün birikimi hakkında tartışırdım. Aşağıdaki avantajlara sahiptir:
6. Ekibe neler başardıklarını ve çalışmalarının ürünün genel başarısına nasıl katkıda bulunduğunu gösterme fırsatı verir.
7. Ekibe, belki birkaç aydır yaptıkları iş hakkında bir kapanış hissi verir.
8. Ekibe ürünün geleceği hakkında genel bir fikir verir ve yaklaşan bazı özellikler nelerdir?
9. Tüm ekip üyelerini aynı sayfada tutar. Diğer ürün ekibiyle veya daha yüksek yönetimle etkileşime girdiklerinde bile asla şaşırmayacaklar. Sırada ne olduğu konusunda her zaman görünürlüğe sahip olacaklar
10. Ekip içinde şeffaflığı teşvik eder ve sonunda ekip içinde güvene yol açar.

Lütfen bu ipuçları ve teknikler hakkındaki düşüncelerinizi bana bildirin. Mükemmel olmadıklarını ve kendilerini geliştirmek istediklerini biliyorum. Lütfen bana [email protected] adresinden bir e-posta göndermekten çekinmeyin.

Okuduğunuz için teşekkürler. Diğer noktalar için bir takip blog yazısı yazacağım. Bizi izlemeye devam edin!