İyi ürün yönetimi, bu 6 önemli tabloya güveniyorum
Tercüme Bürosu, bilim ve teknoloji, ticaret, işyeri, yaşam ve diğer alanlara odaklanan, yeni yabancı teknolojileri, yeni fikirleri ve yeni eğilimleri tanıtmaya odaklanan 36Kr'ın altındaki bir çeviri ekibidir.
Editörün notu: Her zaman iyi bir ürün yöneticisi olmanın gerçekten zor olduğunu duyarız. Bazen tasarımcılar veya mühendisler hakkında ürün yöneticilerinden şikayet eden hikayeler bile duyuyoruz. Aslında iyi bir ürün yönetimi işi yapmak için kişiler arası iletişim becerilerinin yanında verimlilik de çok önemlidir. Bu makalenin orijinal başlığı, Ürün Yönetimi kavramlarını açıklamak için kullandığım 6 diyagramdır Yazar Curtis Stanier, kıdemli bir ürün yöneticisi. Curtis yazıda, ürün yönetimi sürecinde iş verimliliğini artırmak için sıkça kullandığı 6 tabloyu paylaştı, umarım sizler için faydalı olur.
-
Önerilen Kaynaklar: Buffett, bu beceride ustalaşmanın servetinizi% 50 artırabileceğine inanıyor
Resim kaynağı: Pexels.com
Kişilerarası iletişimde, hepimiz bir fikir birliğine sahip olabiliriz: resimlerle açıkça ifade edilebilecek şeyi yazmamaya çalışın. Dürüst olmak gerekirse, grafiklerin önemi bunun çok ötesine geçiyor. Resimler sadece fikir birliğinizi artırmakla kalmaz, aynı zamanda yazı dilinin getirdiği karmaşıklığı ve göze çarpmayan bazı farklılıkları da azaltır.
Bu yazıda, ürün yönetimi fikirlerini tartışmak için günlük çalışmalarımda kullandığım 6 tabloyu sizlerle paylaşmayı umuyorum. Kendi çizdiğim bu grafikler sadece popüler olmakla kalmıyor, daha da önemlisi, insanların ilgili fikirleri hızlı ve kolay bir şekilde anlamalarını sağlıyor.
6 çizelge:
-
"Ürün Yöneticisi Darboğazı" diyagramı
-
"Görev akışı" grafiği
-
Klasik "Şelale ve Çeviklik" diyagramı
-
"Proje boyutu, risk ve liderlik katılımı" haritası
-
"Bilgi Çubuğu" grafiği?
-
"Segment Değeri" grafiği
İşinize yardımcı olduklarını düşünüyorsanız, tadını çıkarın.
Grafik 1: "Ürün Yöneticisi Darboğazı" grafiği
Birçok ürün yöneticisinin yaptığı en yaygın hatalardan birinin kendileri hakkında iyi hissetmek ve iş tartışmasının hiçbir bölümünü kaçırmamaları gerektiğini düşünmek olduğunu buldum. Bu tür düşüncelerle çalışmaya karşı gerçekten olumlu bir tutum olduğu anlaşılabilir bir durumdur. Sonuçta, bir ürün yöneticisisiniz Ürün geliştirme sürecinde kapsamlı olmak için, tüm yönleri de olabildiğince tam olarak anlamanız gerekir.
Ne yazık ki, bu yaklaşımın birçok bariz dezavantajı var.
Her şeyden önce, bu yaklaşım biraz pratik değil. Yakında yapacak çok işiniz olduğunu keşfedeceksiniz. Bunun sadece ekibin verimliliği üzerinde olumsuz bir etkisi olmayacak, aynı zamanda kendinize de belirli bir baskı uygulayacaktır. İnanın ben bu konuda geçmişten biriyim.
İkincisi, bu yaklaşım aynı zamanda ekip üyelerinin bağımsız çalışmalarına da zarar veriyor.
İyi ürün yöneticileri, ilgili işlere ne zaman dahil olacaklarını ve ne zaman yeniden vücutlarından çıkmaları gerektiğini bilirler. Tartışmalara nerede katılmak zorunda olmadıklarını bilirler. Ekip üyelerinin bağımsız çalışmalarına izin vermenin amacı, tüm yönlere olan bağımlılıklarını olabildiğince azaltmaktır.
Aşağıdaki diyagramda gösterilen durumda, soldaki resimde çalışma senaryosunu hayal edebilirsiniz.
Web tarafı geliştirme mühendisi, ürün yöneticisine geliştirilmesi gereken bir konsept ortaya koyar, böylece ürün yöneticisi konu hakkında ürün analisti ile iletişime geçer. Ürün analistleri, bu geliştirmenin iOS sistemi ile senkronize edilmesi gerektiğini söyledi. Daha sonra, ürün yöneticisi iOS sistem geliştirme mühendisleriyle iletişim kurmaya gitti, ilgili ayrıntıları topladı ve ardından açıklamak ve tartışmak için web tarafı mühendislerine geri bildirimde bulundu.
Bu çalışma şekli, sadece ürün yöneticisi için çok fazla gereksiz çalışmaya neden olmakla kalmadı, aynı zamanda web tarafı mühendislerinin ortaya çıkardığı sorunları çözme hızını ve verimliliğini de ihmal etti.
Buna karşılık, grafiğin sağ tarafındaki çalışma senaryosu örneğinde, web tarafı geliştirme mühendisi ürün analisti ile doğrudan iletişim kurabilir ve gereksinimleri ondan öğrenebilirse, iOS sistem geliştirme mühendisi ile doğrudan iletişim kurabilir. Bu işi bitirebilir.
Ayrıca bu iletişim şeklinin soldaki resme kıyasla çok fazla gereksiz iletişimi azalttığını göreceksiniz (yukarıdaki resimdeki kırmızı oka bakın).
Ek olarak, meslektaşların yukarıda belirtilen tablo örneğine dayanarak tartışması gereken birkaç başka içerik eklersek (yukarıdaki şekildeki yeşil ve mavi oklara bakın), bu simülasyon gerçek çalışma sahnesinde karşılaşılan gerçek durumla daha uyumludur. Ardından, ürün müdürünün her işe müdahale etmesi gerekiyorsa, iletişim kurması ve halletmesi gereken şeylerin sayısının önemli ölçüde artacağını ve her şeyin iletişim ilerlemesinin ürün yöneticisi aracılığıyla olması gerektiğini göreceksiniz. İletişim tamamlandı.
"Ürün Yöneticisi Darboğaz" diyagramı nasıl kullanılır?
İşyerinde her zaman çeşitli görevlerle meşgulseniz, o zaman durmalı ve ekip üyeleri arasındaki iletişimde bir sorun olup olmadığını düşünmelisiniz.
Kendinize şunu sorun: Her iletişime katılmanız gerekiyor mu? Tatildeyseniz, ekip üyelerinin çalışma ilerlemesi istikrarlı bir şekilde devam edecek mi, yoksa her yönde duracaklar mı? İkincisi ise, yapabileceğiniz tek şey siz olmadan ekip üyeleri arasındaki iletişimi nasıl geliştireceğinizi düşünmektir.
Grafik 2: "Küçük görev akışı" grafiği
Şahsen bu çizelgeyi çok beğendim, ekibin iş yükünü ve yapılan görevlerin büyüklüğünü anlamak ve analiz etmek için kullanılabilir. İster bir iş ortağı ister ürün ekibinin bir üyesi olsun, ürün lansmanları konusuna gelince, hepsi sürecin çok yavaş olduğunu ve aynı zamanda çok sinir bozucu olduğunu belirtti.
Bu sorunun nedeni genellikle yalnızca daha önemli görevlere odaklanmaktan kaynaklanır (yukarıdaki şekilde soldaki huni durumuna bakın).
Bu nedenle, ekip bir seferde yalnızca bir görevi tamamlayabilir. İş hedefimiz çok netse ve herhangi bir ayarlamaya gerek yoksa, o zaman bu yöntem kabul edilebilir. Ancak bu durum fiili işlerde de çok nadirdir. Şey delikten düştükten sonra, bu şeyin işe yaramadığını fark edersiniz, o zaman bu hatadan öğrenmek için daha fazla zaman ve deneyim harcamanız gerekebilir.
Çevik yöntemin küçük görev çalışma yöntemini savunmasının nedeni, değerin daha hızlı yansıtılabilmesi ve riskin nispeten düşük olmasıdır.
Sağdaki resimdeki huni nispeten daha fazla esnekliği yansıtabilir. Küçük görevler (mavi noktalar) huniden hızla geçebilir ve doğrulanabilir. Doğrulama başarılı olursa, daha fazla çaba harcayabiliriz (pembe noktalar). Aksi takdirde, nispeten az bir yatırımla tekrar yapmamız gerekir.
Her doğrulama, daha fazla yatırım yapmamızı sağlar. Bu şekilde, bir dizi küçük görev, bazı orta ölçekli görevler ve bazı büyük görevler tamamlanabilir; bu, yalnızca belirli riskleri azaltmakla kalmaz, aynı zamanda yatırım getirisini de artırır.
"Küçük görev akışı" grafiği nasıl kullanılır?
Geçen ay katıldığım görevlere tekrar bakın. Ölçek ve karmaşıklık açısından, bu görevler büyük görevlere mi ait yoksa çeşitli görev türlerini içeriyor mu? Küçük, orta ve büyük gibi bu görevleri işaretleyin ve ardından kendi dönüşüm huninizin nasıl görüneceğini düşünün.
Grafik 3: Klasik "Şelale ve Çeviklik" grafiği
Aslında, internette bununla ilgili birçok durum var. Sözde "şelale", ürün konseptinden, başlangıçtan, analizden, tasarımdan, geliştirmeden, yapımından, testinden ve piyasaya sürülmesinden yukarıdan aşağıya "şelale" uyumlu çalışma yöntemini gerçekten anlayabilir. Önceki görev tamamlanmadan açılmaz. Bir görev.
Bunun tersine, "çevik", ürünleri hızlı bir şekilde teslim etmenin zaman çizelgesi tabanlı bir yöntemi olarak anlaşılabilir.Ana işlevleri temel çerçeveye göre tamamlayabilir ve ardından ayrıntılı işlevleri iyileştirmek için sürekli yinelemeler yoluyla tamamlayabilir.
Ama burada vurgulamak istediğim şey verme süreci. Birçok ürün geliştirme ekibi için, üyelerin ekibin harcadığı zamanın aslında bir yatırım olduğunun farkına varmasını sağlamazlar.
Tüm ürün yöneticilerinin bağımsız ürün geliştirme kar tabloları varsa, genellikle personel giderlerinin tüm ekipteki en büyük gider olduğunu göreceklerdir. Bu nedenle, her durumda, karı (veya getiriyi) artırmak için tüm uygun fırsatları aramalıyız.
Ekip büyük bir güncelleme yayınladığında, kesinlikle hemen değerde bir artış görmek istersiniz. Ya da güncelleme işlemi sırasında bile, bu güncellemenin kesinlikle en mükemmel çözüm olduğunu ve hiçbir teknik arıza olmayacağını hayal etmeye başlıyorsunuz (ama gerçek imkansız).
Soldaki resim büyük bir güncellemedir, yatay eksen zamandır, sarı ok çabayı temsil eder ve mavi ok değerdir; Sağdaki resim küçük bir yinelemeli güncellemedir.
Soldaki resimde, büyük bir güncelleme için, ekip üyeleri çok fazla zaman harcama öncülünde herhangi bir değer göremeyebilirler.
Güncelleme sıklığını artırır ve her seferinde küçük güncellemeler başlatırsanız, ürün geliştirme güncellemelerini aşamalı olarak tamamlamış olursunuz. Böylelikle yatırımınız kısa sürede ödüllendirilecek ve sonuçta hatalarınızdan daha hızlı öğrenebilir ve değer artışını daha hızlı gerçekleştirebilirsiniz. Yakında, ürünün değer artışı ekibin katkısını aşacak ve bu da her ekibin çaba göstermesi gereken hedeflerden biri.
Klasik "Şelale ve Çeviklik" diyagramı nasıl kullanılır?
Genellikle bu tabloyu "sadece bir görev daha eklemenin" neden takımın çıkarına en iyi şekilde yaramayacağını açıklamak için kullanırım. Buna ek olarak, bu aynı zamanda kendinize ve ekibinize, ekibinizin rolünün iş üzerinde ne gibi bir etkisi olacağını düşünmenin etkili bir yoludur.
Grafik 4: "Program boyutu, risk ve liderlik katılımı" tablosu
Bu tablo söz konusu olduğunda, iki ana husus vardır.
Soldaki resim bir plan piramididir. Piramidin genişliği, bir seferde çözülmesi gerekebilecek çözümlerin sayısını temsil eder. Alt kısım en geniş olanıdır, bu da tartışılması ve karar verilmesi gereken seçenek sayısının en büyük olduğunu ve karşılık gelen seçeneğin riskinin nispeten düşük olduğunu kanıtlar. Piramidin en dar tepesi, tartışılacak seçenek sayısının en az olduğunu ve doğal olarak riskin en yüksek olduğunu kanıtlıyor.
Sağdaki resim, liderlik katılımını ölçen tersine çevrilmiş bir piramittir. Piramit ne kadar genişse, liderler için beklenen veya gereken katılım düzeyi o kadar yüksek olur. Bu durumda liderlere daha çok danışmalıyız. Piramit ne kadar dar olursa liderlerin katılımı o kadar düşük olur.
Bir ekip üyesi veya ürün yöneticisi olarak mümkün olduğunca çok sayıda küçük proje uygulamanız gerekir. Bu öğelerin riskleri genellikle yüksek değildir ve sürekli olarak optimize edilebilirler. Liderler bu konularda zaman ve çaba harcamak istemezler, aksi takdirde önemsizdirler.
Ancak, piramidin tepesindeki planı içeriyorsa, genellikle daha yüksek bir riski temsil eder. Örneğin, yeni ürünler piyasaya sürmeyi düşünün. Şu anda liderin müdahalesine ve desteğine ihtiyacınız var.
"Program boyutu, risk ve liderlik katılımı" haritası nasıl kullanılır?
İster lider ister ekip içeren bir durum olsun, bu tabloyu çok faydalı buluyorum. Anlaşılması basit ve kolaydır ve bize liderlerin neden belirli konularda öne çıkması gerektiğini ve neden zamanlarını veya diğer alanlarda deneyimlerini boşa harcamak zorunda olmadıklarını açıklar.
Grafik 5: "Bilgi Çubuğu" Grafiği
Bu tablo, ekibin operasyonel sağlığının üç ayda bir incelenmesinden sorumlu olan bir meslektaşımdan geliyor. Departmanların ve ekiplerin bilgi paylaşımı üzerindeki etkisini histogram formu aracılığıyla görselleştirmenin çok sezgisel ve kullanışlı bir yoludur.
Her açıdan çok yetkin olamayacağımızdan şüphe yok. Bununla birlikte, biraz bilginiz olmadığını biliyorsanız, o zaman birbirinizle olan değiş tokuşlara daha fazla dikkat edeceksiniz.
Ekip organizasyonu (veya bireysel) boyutu ve farkındalık arasındaki ilişkinin şeması. Dikey eksen yukarıdan aşağıya en yüksek ve en düşük bilinci yansıtır Yatay eksende en soldaki bireydir ve onu daha büyük ve daha büyük gruplar, yani küçük takımlar, büyük takımlar, diğer takımlar ve diğer bölümler izler.
Ekibin bir üyesi olarak yaptığınız işin tamamen farkında olmalısınız. Bu tür bir farkındalık, önceki grupta olduğunuzda azalacaktır ve daha büyük grupta, ilgili farkındalık en zayıf olana indirgenebilir.
"Bilgi histogramı" tablosu nasıl kullanılır?
Kendinize ve çevrenizdeki insanlara sık sık ekibinizin daha az verimli olabileceğini hatırlatın çünkü hiç kimse her açıdan çok yetenekli değildir. Ek olarak, takımda farklılıklar veya fikir çatışmaları varsa, bunun nedeni muhtemelen ilgili bilgi eksikliğinden kaynaklanmaktadır.Bu farklılıklar ve çatışmalar aslında kötü niyetli değildir.
Sergi 6: "Segment Değeri" Grafiği
Ürün çözümleri ve testleri hakkında ilgili kararlar verirken çoğu şirkete bakıldığında, en yaygın hatalardan biri, en iyiyi seçmek veya segmentlere ayırma optimizasyonu yerine ortalama bir etki sağlamak için tüm çözümleri optimize etmektir.
"Ortalamanın" olası çarpıklığıyla ilgili olarak, genellikle bu örneği bir örnek olarak kullanırım: Genel olarak konuşursak, insanların ortalama olarak iki bacağı biraz daha azdır (çünkü bazı insanların sadece bir bacağı vardır veya hiç bacağı yoktur, bu nedenle genel olarak konuşursak, Bu ortalama 2'den biraz daha az olacaktır).
Ürün geliştirme sürecinde, ilgili varsayımlar ve endişeler çok genişse, ekip üyelerinin yarattığı etkiyi kaçınılmaz olarak sınırlayacaktır. Bu, herkesi aynı anda rahatlatmak istiyorsanız, bu da gerçekçi değildir.
Aşağıdaki şekilde, en sağ sütundaki Durum 3'ün Z deneyi muhtemelen en yaygın durumdur.
Tablodaki üç durum, üç farklı varsayımsal deneye karşılık gelir. Durum 1'deki Deney X, etkinin iyileşmesini yansıtır; Orta durumdaki Deney Y, deneyin başarısızlığını yansıtırken, sağdaki Durum 3'teki Deney Z'nin özel bir etkisi yoktur.
Ancak, bu deneysel sonuçları daha ayrıntılı olarak incelerseniz, daha fazla fırsat veya kısıtlama bulabilirsiniz.
Birinci durumda, deney başarılı olmasına ve genel etki iyileştirilmesine rağmen, B bölümü aslında iyi çalışmadı. Bu durumda, B segmenti etkisinin neden iyi olmadığını daha iyi anlayacağım ve hatta ürün nihayet piyasaya sürüldüğünde doğrudan B segmentini kaldırmayı düşünebilirim.
Aynı şekilde, üçüncü durumda, genel etki önemli ölçüde değişmese de, B ve C bölümlerinin etkileri değişen derecelerde iyileşmiştir. Bu iki sonuç, A ve D segmentlerinin zayıf performansını da dengeledi. Ayrıca bunun arkasındaki nedenler hakkında daha fazla bilgi edinebilirsiniz.
"Segment değeri" haritası nasıl kullanılır?
Bir hipotez önerirken, genel olarak bundan bahsetmemelisiniz, ancak ilgili sonuçları daha fazla araştırmak ve arkasındaki fırsatları veya kusurları keşfetmek için mümkün olduğunca spesifik olmalısınız. Hipotez ve deneysel modeller için kıdemli ürün müdürü Rik Higham'ı şiddetle tavsiye ederim. Ayrıntılar için, lütfen EXPERIMENTATIONHUB web sitesinde Hipotez Kitinde arama yapın.
Ek olarak, hedef kitlenizi daha iyi anlamak için kullanıcı araştırması ve demografik veriler yardımıyla kullanıcı kişilikleri oluşturmak için kullanıcı deneyimi analisti Nikki Anderson'ı (Nikki Anderson) kullanabilirsiniz.
Çevirmen: Shunichi
