Ürün Yönetimi Kavramlarını Açıklamak İçin Kullanılan En İyi 5 Diyagram

Ürün yöneticilerinin sorumlu olduğu ve sorumlu olduğu birçok şey vardır. Bir ürün yöneticisi yalnızca bir yol haritası oluşturarak strateji oluşturmakla yükümlü değildir, aynı zamanda yeni bir ürünün piyasaya sürülme döngüsünü arada gelen her şeyle birlikte ekibe ifade etmesi gerekir.

Ayrıca, öncelikli görevlerin nasıl belirleneceğini ve ekibi buna göre nasıl yöneteceklerini bilme konusunda uzmanlığa sahip olmaları gerekmektedir. Sadece bu değil, aynı zamanda mobil ürün yöneticilerine, bir ürüne (mobil uygulamaya) eklenen özelliklerin ve bunların müşterinin hedefleriyle uyumlu olup olmadığının analiz edilmesi sorumluluğu da verilir.

Sonuç olarak, bir ürünle ilgili her süreç, aktivite ve karar, mobil ürün yöneticisi tarafından senkronize edilir ve hizalanır. Bu ürün yöneticilerinin KRA'larını elde etmelerine yardımcı olan şey, belirli bir dizi beceridir .

Şimdi, açıkçası, belirli ürün yönetimi fikirlerini ekip üyelerine açıklamaları gerekecek, böylece hepsi aynı sayfada olacak. Ancak merak edilecek şey, tüm ürün yönetimi kavramlarını ve temel fikirleri nasıl açıklıyorlar ?

Ürün yöneticileri için birkaç faydalı diyagramın işe yaradığını düşünüyorum . Bu diyagramların ne olduğunu ve mobil ürün yöneticileri tarafından nasıl ve ne zaman kullanıldığını bilmekle ilgileniyorsanız, sonuna kadar bağlı kalın.

Şema 1 – İletişim darboğazları

Bir yönetici olarak ekibinizde neler olup bittiğinin ve ekip üyelerinin görevlerini nasıl yönettiğinin farkında olmanız gerektiği anlaşılmaktadır. Ancak herhangi bir kişinin her iletişim ve karara dahil olması gülünçtür – bir kişi her şeyi kendi başına halledemez, değil mi? Heyet bu yüzden icat edilmedi mi?

Şimdi, tüm önemli takımlar arası/ekip içi konuşmalara dahil olmak istemeniz doğaldır, ancak bir şey üzerinde düşünmeniz gerekiyor - gerekli mi? Diğer sorumluluklarınızı bir kenara bırakarak yapmanız gereken bir şey mi?

Cevap - ekibin size bağlı olmayan iletişim yeteneğine sahip olup olmadığını analiz edin. Ve eğer öyleyse, akıcı iletişim gibi önemli şeylerin yalnızca size bağlı olmadığından emin olmak için bazı bilinçli kararlar almanız gerekir. Söz konusu durumu etkili bir şekilde açıklayabilecek bir diyagram aşağıda verilmiştir.

Diyelim ki, bir Web Mühendisinin Ürün Analisti ile bir konuyu tartışması gerekiyor ve ardından PA, bu konuda iOS geliştiricisi ile bir şeyler tartışması gerektiğini söylüyor. Şimdi, Web Mühendisi, PM'ye bağımlı olmak yerine (soldaki resimde gösterildiği gibi) ideal olarak PA ve iOS geliştiricisine doğrudan yaklaşmalıdır.

Soldaki diyagram, ekibin diğer ekiplerin diğer üyeleriyle iletişim kurmak için ürün yöneticisine bağımlılığını gösterir - bu, iş akışını olumsuz yönde etkileyen ve yavaşlatan bir şeydir. Sağda ise bağımlı olmayan, gereksiz temas noktalarını anında ortadan kaldıran verimli bir iletişim akışını gösteren diyagram yer almaktadır.

Diyagram 2: Şelale vs çevik

İnternette Çevik ve Şelale yaklaşımı tartışmasına katılan birçok kaynak olmasına rağmen, ürün yönetimi ile ilgili olarak hala belirsiz bir kavram gibi görünebilir. Öyleyse belirsizlik sisini temizleyelim.

Genellikle mobil uygulama geliştirme maliyetinin, o ürünü geliştirmek için geçen saatlere göre hesaplandığı bilinmektedir.

Şimdi, o mobil uygulama geliştirme şirketinin ürün müdürü Şelale yaklaşımını kullanmayı seçerse (yani, ürünün büyük bir sürümü), bu, ürünün tek seferde piyasaya sürüleceği anlamına gelir.

Şimdi, bir ürün piyasaya sürüldüğünde anında hit olması bekleniyor - bu durumda bu kolay olmayacak, çünkü ürün aynı anda piyasaya sürüldü ve kesinlikle bazı sorunlara ev sahipliği yapıyor. Bu sürümden elde edecekleri değer, geliştiriciler tarafından yapılan yatırıma (zamana) eşdeğer olmayacaktır. Çünkü sorunları en baştan düzeltmeleri gerekecek.

Aksine, küçük sürümleri ve yinelemeleri destekleyen çevik yaklaşım, aynı anda hataları tespit edip düzelttiğiniz için anında değer sonuçları gösterecektir. Yukarıdaki şema, bu ürün yönetimi yaklaşımlarını seçmenin nihai sonucu arasındaki farkı açıkça göstermektedir .

Şema 3: Teslimat boyutunun temsili

Bir ürünü zamanında teslim etmek söz konusu olduğunda, tüm geliştirme sürecinin çok önemli bir parçasıdır . Kelimenin tam anlamıyla herhangi bir mobil uygulamanın geleceğini yapabilir veya bozabilir. Pazara sunma süresi çok uzunsa, başka bir uygulama pazarı ele geçirebilir ve söz konusu mobil uygulamayı boşuna kılabilir.

İşte bir uygulama geliştirirken alınan girişimlerin boyutlarının bir temsili –

Soldaki diyagram, yalnızca büyük projelerde (aynı anda büyük iş parçaları) çalışmakla ilgilenen teslimat boyutunun çıktısını gösterir. Bir ürünün sadece büyük projeleri üzerinde çalışmanın gelecekte bir noktada tıkanıklık yaratacağı kesinlikle açıktır, çünkü bu projeler daha fazla zaman, dikkat, kaynak vb. gerektirecektir. Ve eğer bir şeyler ters giderse, etkisi olacaktır. tüm süreç üzerinde yıkıcı, kaçınılmaz olarak pazara sunma süresini artırıyor.

{Ayrıca “ Proje Yöneticileri ve Ürün Yöneticileri: Fark, roller ve zorluklar ” başlıklı makalemizi de okuyun }

Sağdaki diyagram klasik bir "yapılacak" dır. Çevik yaklaşımı benimsemenin avantajları , ürün yönetimi sürecinde de bu aşamaya kadar inmiştir . Bu yaklaşım, Appinventiv'de de takip ettiğimiz bir şey olan büyük iş parçalarıyla (mavi) küçük görevleri gerçekleştirme karışımını savunur.

Şemada görüldüğü gibi, soldakinden farklı olarak, burada küçük iş parçaları (Pembe) huniden kolayca geçebilir (kolayca yapılabilir). Bunlar başarılı olursa, ürün yöneticileri bu fikirle (sarı daireler) devam edebilir ve tamamen yatırım yapabilir. Aksi takdirde, tekrar tekrar edebilir ve buna göre yatırım yapabilirler.

{“ Ürün yöneticilerinin hazırlaması gereken en önemli 10 belge ” hakkındaki bu kapsamlı ayrıntılı makaleye göz atın }

Şema 4: Liderlik katılımı düzeyi

Aşağıdaki şema, bu ürün yönetimi konseptini detaylandırmak için iki model içermektedir . Biri inisiyatif boyutunu, bir seferde yapılan işlerin sayısını ve bunlarla ilgili risk faktörünü gösteren solda, diğeri ise bu görevlere ve girişimlere karşılık gelen ürün yöneticilerinin (liderlik) katılım düzeyi ile ilgilidir.

Soldaki, ekip tarafından gerçekleştirilecek görevler/girişimler piramididir. Piramidin alt kısmı, aynı anda birçok görevin gerçekleştirildiği anlamına gelir ve sağdaki diyagram, düşük veya hiç riski olmayan bu önemsiz görevlere ilişkin katılım miktarını gösterir.

Piramidin en üstüne çıktıkça, görev sayısı azalırken, bu görevlerle ilişkili riskler de artar, burası ürün yöneticisine MUTLAKA DANIŞILMASI GEREKİR, oluşturulurken ise sadece bilgilendirilebilir. Bu diyagram, yalnızca mobil ürün yöneticilerine değil, aynı zamanda ekip üyelerine de ne zaman liderliğe güveneceklerini bilmelerinde yardımcı olacaktır.

Diyagram 5: Segmentasyon değerinin analizi

Kuruluşların takip etmeye alışık olduğu birkaç uygulama vardır. Bunlardan biri, bir segment yerine ortalamayı optimize etme alışkanlığıdır. Yani, iyileştirilmesi gereken belirli segmentler yerine ortalamaya odaklanma eğilimindedirler.

Hedeflerin ve hipotezlerin oldukça geniş olduğu durumlarda, ürün yöneticileri ve geliştirme ekiplerinin ürün üzerinden etki yaratması zorlaşıyor. Çünkü burada aynı anda çeşitli hedefleri yerine getirmeye çalışıyorsunuz ki bu hiç de mümkün değil.

Aşağıda verilenler gibi diyagramlar, hangilerinin diğerlerinin performansını etkilediğini belirlemek için her bir segmenti analiz etmenin bir yoludur. Bütün bunlar mevcut sorunları çözmek için.

Yukarıdaki diyagram, A, B, C ve D segmentleri ile 1,2 ve 3 numaralı üç varsayımsal deneyden oluşmaktadır. Üç deneyden ilk durumda, A segmentinde bir yükselme olmuş, ardından segment A'da bir azalma olmuştur. ikinci durumda ve üçüncü durumda değişiklik olmadan.

Bireysel olarak bakıldığında, 1. deneyde A segmenti, B segmenti hariç diğerleriyle iyi performans gösterdi. Şimdi, diyagram bu segmentteki düşüşü diğerlerine bitişik olarak vurgulamıştır. Bu, ürün yöneticilerinin, uzun vadede ortalamayı eninde sonunda iyileştirecek olan bu durumun nedenlerini bulmalarına yardımcı olabilir.

Benzer bir durum, A, C, D segmentlerinin önemli bir değişiklik gösteren muhalefet segmenti B'de düşük performans gösterdiği 3. deneyde ortaya çıkar. Yine, bir çalışma bunun olmasının nedenlerini açıklayacaktır.

Ürün yöneticileri için bu yararlı diyagramlar, ürün yöneticilerinin hangi sektörde faaliyet gösterdiğinden bağımsız olarak, kişinin ihtiyaçlarına göre kolayca özelleştirilebilir. Appinventiv söz konusu olduğunda, bu modellerin ekiplerimize süreci basitleştirmede ve şirketler arası açık iletişimi sürdürmede gerçekten yardımcı olduğunu düşünüyorum. /ekip içi.

Sıkça Sorulan Sorular

1. Ürün yönetimi çerçevesi nedir?

Tüm çerçeveler esasen ürün yönetimi yaşam döngüsünde kullanılan araçlardır . Ürün yönetimi fikirlerini ve kavramlarını göstermek ve diğer görevleri kolaylaştırmak gibi çeşitli amaçlar için kullanılırlar .

2. Ürün yönetim süreci nedir?

Ürün yönetimi süreci çeşitli aşamalardan oluşur. Fikir yönetimi, yol haritası oluşturma, spesifikasyonların eklenmesi ve belirlenmesi, önceliklendirme, teslimat, analitik ve kullanıcı geri bildirimini içerir.