termékmenedzser vs Terméktulajdonos

Ez egy érdekes kérdés, amely időt vesz igénybe a kicsomagoláshoz. Nézzük meg, honnan származnak ezek a kifejezések és tudományágak, és hogyan magyarázzák meg őket a közös keretek.,

amikor elkezdtem a karrieremet, üzleti elemzőnek hívtak. Nagyon kevés “üzleti elemzést” végeztem, mivel a hagyományos informatikai vállalatokban néztük meg. Őszintén szólva, nagyon keveset tettem abból, amit most Termékmenedzsmentként tanítok. Feladatom volt, hogy összegyűjtsem az értékesítési követelményeket, megoldást találjak, megtervezhessem, majd a specifikációs dokumentumot a fejlesztésre szállítsam.

üzleti elemzőnek neveztek, miközben bankoknál és más pénzügyi szolgáltató vállalatoknál dolgoztam. Addig nem hívtak Termékmenedzsernek, amíg ki nem léptem belőle, és egy startupban landoltam., Ugyanaz volt a munka, amit korábban csináltam, de most más neve volt. Tetszett ez a név. Úgy tűnt, hogy a” termékmenedzser ” komoly hatással van rá, és amikor megnéztem a völgy más tech cégeit, egyértelmű karrierutat láttam számomra, míg az üzleti elemzők minden cégnél eltérőek voltak.

csak évekkel később hallottam a Terméktulajdonos kifejezésről. Amikor először hallottam a kifejezést, megkérdeztem valakit, hogy mit jelent. Azt mondták nekem, hogy ugyanaz, mint egy termékmenedzser, de ez egy kifejezés, amelyet a Scrumban használnak., Évek óta használjuk a Scrum – ot, de még mindig Termékmenedzsernek hívtak, tehát az a tény, hogy felcserélhetők lennének, értelme volt számomra. Ezt követően ritkán gondoltam rá.

Ez addig volt, amíg az első tapasztalatom nem volt a biztonságos keretrendszert használó vállalat Termékmenedzsmentjének oktatása. Egy nagyon nagy banknak csináltam egy műhelyt, amikor az egyik résztvevő beállt.

” arra tanít minket, hogy beszéljünk a felhasználókkal, de Terméktulajdonos vagyok. A termékmenedzser minden felhasználóval beszél, és elmondja, mik a követelmények., Minden időmet azzal töltöm, hogy felhasználói történeteket írok ki ezekből, és együtt dolgozom a csapattal, hogy végrehajtsam a megoldást. Össze vagyok zavarodva.”

Ez az, amikor elkezdtem ásni a különbségeket a két szerep között, és hogyan tanítják őket a különböző filozófiák. Annak érdekében, hogy megértsük, hogyan jutottunk ide

a termékmenedzsment 1931-re vezethető vissza. A Hewlett Packard volt az egyik első technológiai vállalat, amely az 1940-es években termékeivel valósította meg ezt a munkát., A Szilícium-völgy legtöbb vállalatának már a kezdetektől voltak termékmenedzserei, és sok barátom, akik a 80-as, 90-es években ott dolgoztak, valóban termékmenedzserek voltak. Tehát ez a fegyelem nem új, de gyorsan fejlődik, mivel egyre több vállalat kezd átállni a szoftverszervezetekbe, és elkezdi strukturálni magát a termékek körül.

Scrum közvetlenül az agilis Manifesto 2001-es írása előtt jelent meg a helyszínen. Bevezette a Terméktulajdonos fogalmát. Ez egy olyan személy volt, aki proxy volt az ügyfél számára, és elmondta a fejlesztőknek, hogy milyen követelményeket kell építeni., Az első napokban, amikor ezeknek a folyamatoknak az alkotói közül sokan tanácsadóként dolgoztak a vállalatokban, a termék tulajdonosa volt az ügyfél — egy belső személy az üzletben, aki a csapattal ülne, és rangsorolná a munka elmaradását. Valójában a Scrum Alliance által tanúsított Scrum Terméktulajdonos Tanúsításukra vonatkozó 2017. évi tanulási célok azt állítják: “Tanítsd meg, hogy a Terméktulajdonos szerepét általában az ügyfél vagy az ügyfél képviselője, például egy termékmenedzser játssza.,”

Ha megnézzük a Terméktulajdonos szerepét a legtöbb Scrum irodalomban, három fő feladatuk a következő:

• határozza meg a termék hátralékát, és hozzon létre cselekvőképes felhasználói történeteket a fejlesztő csapatok számára. (Aki létrehozza a felhasználó történetek változik attól függően, hogy Scrum képzés)
• Vőlegény pedig rangsorolni a munka a lemaradás.
• fogadja el a kitöltött felhasználói történeteket, hogy megbizonyosodjon arról, hogy a munka megfelel-e a kritériumoknak.,

míg a tanterv változik a tanárok és a szervezetek között, ezek azok a dolgok, amelyekre leginkább a két napos kurzusok során összpontosítanak a Terméktulajdonosok igazolására. Míg Scrum van egy csomó információt a folyamatok és rituálék, hogy mit kell tenni, mint egy termék tulajdonosa, hagy sok kérdést, amelyek fontosak a sikeres termékek megválaszolatlan. Ezek többnyire a ” honnan tudjuk, hogy a helyes dolgot építjük?”

itt jön be a termékmenedzsment., Egy jó termékmenedzser megtanítja, hogyan kell rangsorolni a munkát az egyértelmű eredményorientált célokkal szemben, hogyan lehet felfedezni és érvényesíteni a valódi ügyfél-és üzleti értéket, és milyen folyamatokra van szükség a termék piaci sikerének bizonytalanságának csökkentéséhez.

a termékmenedzsment ezen háttere nélkül valaki hatékonyan átmehet a Terméktulajdonos Scrum-ban betöltött szerepén, de soha nem lehet sikeres abban, hogy megbizonyosodjon arról, hogy a helyes dolgot építik-e.,

ha elveszi a Scrum csapatot, ha a Scrum-ot a szervezet folyamataként veszi el,akkor továbbra is termékmenedzser. A termékmenedzsment és a Scrum jól működik együtt, de a termékmenedzsment nem függ a Scrumtól. Bármilyen kerettel vagy folyamattal létezhet és léteznie kell.

nemrégiben volt egy Terméktulajdonosom, akinek a fejlesztőit a szervezet egy másik részébe költöztették, mert aggódtak, hogy már nem lehetnek termékszemély a cégnél. Az egész identitás látszólag csuklós, hogy egy csapat a fejlesztők.,

termékmenedzserként a szerepek és a felelősségek az Ön kontextusától és a termék színpadától függően változnak. Scrum Csapat vagy egy kisebb csapat nélkül, lehet, hogy több stratégiai és érvényesítési munkát végez a probléma felfedezésével egy olyan termékben, amelyet még nem határoztak meg. A Scrum Csapat, akkor lehet, hogy jobban összpontosított a megoldások végrehajtását. Mint egy menedzser a termék vezetők, lehet, hogy vezető stratégia egy nagyobb része a termék, coaching a csapatok, hogy felfedezzék, és végre is.,

a SAFe framework ezt másképp tanítja, és szerintem ez az egyik leggyengébb pont az egész keretben. A SAFe-ban a termékmenedzserek a Terméktulajdonosok vezetői, akik felelősek a külső interakciókért és a munkáért. Beszélnek a vásárlókkal, meghatározzák az építendő termékek követelményeit és alkalmazási körét, és ezt közlik a termék tulajdonosaival. A termék tulajdonosai belső felületűek, meghatározzák a megoldás összetevőit, valamint együttműködnek a fejlesztőkkel a szállításhoz.,

Már képzett, több tucat csapat, akik a Biztonságos, még soha nem láttam ilyen jól működik. A Terméktulajdonosok el vannak választva a felhasználóiktól, és képtelenek olyan hatékony megoldásokat létrehozni számukra, amelyek valóban megoldják a problémáikat, mert nem értik jól a problémákat., A termékmenedzserek lényegében a rájuk vonatkozó követelményeket vizionálják, és a csapatoknak nem szabad bizonyítaniuk, hogy ezek a helyes dolgok-e építeni vagy sem. Senki sem végez érvényesítési munkát.

sok érvet hallgattam, hogy a Terméktulajdonosoknak nincs ideje mindkét szerep elvégzésére. A jelenlegi helyzetben ez igaz. A Terméktulajdonosok, akikkel beszélek, heti 40 órát töltenek felhasználói történetek írásával. Ezen a ponton, meg kell kérdezned magadtól, ezek a felhasználói történetek még értékesek? Mik azok rangsorolása őket ellen? Honnan tudják, hogy megoldja a problémát?,

ha van egy ember, aki hetente ennyi időt tölt felhasználói történetek írásával, akkor minden héten beleesik az Építéscsapdába — összpontosítva a kiadott elemek mennyiségére, nem pedig a minőségre.

egy jó stratégiai keretrendszerrel és néhány kulcsfontosságú cél körül könyörtelen rangsorolással egy személy hatékonyan beszélhet az ügyfelekkel, megértheti problémáit, segíthet meghatározni a megoldásokat a csapattal. Még a vezérigazgató Scrum.org egyetért azzal, hogy ez lehet a helyzet, bár úgy tűnik, begrudgingly., A Scrum Inc azt is mondja, hogy a termék tulajdonosának ideje felét az ügyfelekkel kell beszélgetnie, a felét pedig a csapattal kell dolgoznia. Nem vagyok 100% – ban a fedélzeten ezzel a felosztással, de az irány jó. A külső és belső munka mennyisége a termék érettségétől és sikerességétől függően változik. Nem szabadna ezt a munkát egyszerre végeznie.,

tanítom a költségtérítést, hogy a Termék Vezetők a vezető szerep (VPs vagy a Termék Vezet, vagy középvezetők) koncentrálni meghatározó a jövőkép, stratégia a csapat alapján piackutatás, megértés, vállalati célok, stratégia, valamint a jelenlegi siker, hogy a termékek. A termékmenedzserek Scrum csapatok nélkül vagy kisebb csapatokkal (például egy UX tervező és egy fejlesztő) segítenek érvényesíteni és hozzájárulni a jövőbeli termékek stratégiájához. Miután érvényesítettük az irányt, nagyobb Scrum csapatokat hozunk létre ezen emberek körül, és megoldásokat építünk ki.,

fontos, hogy ezt a rugalmasságot a csapat mérete, valamint attól függően, hogy a színpadon a termék. Ha egy termékmenedzsernek egy nagy scrum Csapat lemaradását adja meg, hogy kitöltse, amíg discovery módban van, akkor ezt a lemaradást kitöltik. De azt is meg kell szakítani, hogy a munka folyjon a fejlesztőknek, és megpróbálja elvégezni a munkát az irány érvényesítése érdekében. Ennek eredményeként egyik sem lesz jól.

ha olyan termékeket szeretne létrehozni, amelyek értéket teremtenek vállalkozásai és ügyfelei számára, akkor jó termékkezelési alapokra van szüksége a vállalatában., Ha azt szeretnénk, egy karrier utat az emberek, meg kell adni nekik ezt az alapot, így nőnek több vezető szerepet. Tehát emlékeztesse az embereket, hogy mind termékmenedzserek. Lehet, hogy a legtöbb nap egy Terméktulajdonos szerepét játsszák egy Scrum csapatban, de még mindig szükségünk van rájuk, hogy termékmenedzserként gondolkodjanak, és igazolják, hogy a megfelelő dolgokat építjük.

— —

Melissa Perri a Produx Labs vezérigazgatója, egy tanácsadás, amely segít a szervezeteknek a jó termékmenedzsment és Termékvezetési gyakorlatok elsajátításában és elfogadásában., Online iskolát vezet termékmenedzsereknek a Product Institute-ban és a CPO Accelerator termékvezetőinek. A Harvard Business School adjunktusa.

ezt eredetileg közzétették melissaperri.com