Értékes-e egy ötlet, vagy a megvalósítás előtt semmi? A termékfejlesztési menedzsment ötletek és feltételezések között épül fel. A termékcsapatnak gyorsan reagálnia kell a piaci igényekre vagy ingadozásokra. Bármely döntést a termék értékének, bevételeinek vagy tőkéjének növelése érdekében kell meghozni. Közben a vizsgálati folyamatot minimális erőforrásokkal kell elvégezni. Hypotheses in this avalanche may be connected with different aspects: Új marketing stratégiák. Az új jellemzők. Alkalmazkodás új piacokhoz vagy niche-ekhez. Investigation for creating a new product from scratch. Mindazonáltal a feltételezések sokfélesége ellenére a retrospektív elemzés azt mutathatja, hogy az ötletek teljes tartománya egy termékcsaládban nem végtelen. Az ötleteket személyes jegyzetekben vagy céges csevegésekben lehet fejleszteni rendszer nélkül, és a csapattagok rotációja után a csapat ugyanazt a vizsgálatot fogja nyújtani, anélkül, hogy figyelembe venné a korábbi tapasztalatokat. Ezek az ötletek megfelelő keretet igényelnek a piaci betekintés tárolásához, felhalmozásához és biztosításához, függetlenül a csapat vagy a vállalat növekedésében bekövetkező változásoktól. IdeaOps for product development The term “IdeaOps” as a product framework was first introduced for me in the show “Rebellious Businesses” by Katherine R. Lieber in the podcast episode “Stop Bleeding Out Your Competitive Edge: Use IdeaOps To Start Capturing And Acting On Essential Innovations” (02.02.2025). Link: . https://creators.spotify.com/pod/profile/katya052/episodes/Stop-Bleeding-Out-Your-Competitive-Edge-Use-IdeaOps-To-Start-Capturing-And-Acting-On-Essential-Innovations-e2u9jrk Ebben a cikkben megosztom a személyes termékfejlesztési tapasztalataimat, amely kiegészíti az eredeti kifejezés ötletét. Az „IdeaOps” kifejezést termékkeretrendszerként először Katherine R. Lieber „Rebellious Businesses” című műsorában mutattam be a „Stop Bleeding Out Your Competitive Edge: Use IdeaOps To Start Capturing And Acting On Essential Innovations” című podcast epizódban (02.02.2025). . https://creators.spotify.com/pod/profile/katya052/episodes/Stop-Bleeding-Out-Your-Competitive-Edge-Use-IdeaOps-To-Start-Capturing-And-Acting-On-Essential-Innovations-e2u9jrk Ebben a cikkben megosztom a személyes termékfejlesztési tapasztalataimat, amely kiegészíti az eredeti kifejezés ötletét. A keretrendszer lényege az a felismerés, hogy minden hipotézis a vállalat eszköze. Ennek az eszköznek egy tulajdonosnak kell lennie, az ötlet teljes kontextusának, a vizsgálati folyamat során létrehozott tárgyaknak, a más eszközökhöz fűződő kapcsolatoknak és a döntés állapotának.Az alábbi ajánlások feltárják egy olyan folyamat szükségességét, amelyben rendkívül fontos nemcsak a hipotézis elfogadására vagy elutasítására rögzíteni, hanem a teljes nyomon követési folyamatot a gondolkodás történetével, az eltöltött idővel és az intermitens eredményekkel. Mint minden más keretrendszer esetében, a cikkben bemutatjuk a főbb szempontokat: Hogyan építsük fel az ötletgyűjtés folyamatát. Hogyan tároljuk az ötleteket. Hogyan kell alkalmazni a keretet? Hogyan mérjük a változások sikerét és értékét? Hogyan épül fel az ötletgyűjtés folyamata? A folyamat a következő gyakori és jól használt ajánlásokat követi a közelgő változási kérelmekhez. Minden ötletnek egy csővezetéken kell áthaladnia: Creation. A kontextus. A baloldal. A bizonyíték. A becslés. A döntés. teremtés Minden ötletet a vállalat infrastruktúrájában kell rögzíteni a szabályok szerint: For every idea or request, a unique ticket should be created Néha egy ötlet összetett lehet, és megköveteli a termék vagy a piaci megközelítés felülvizsgálatát. Meg kell tanítani a csapatnak, hogyan lehet minden hipotéziset értékes, de elkülöníthető fejlesztésekre bontani. Ez további bürokráciát hozhat létre, és csökkenti az ötletek számát - ha nehéz formalizálni, egyes csapattagok elkerülhetik az ötlet rögzítését. Ezzel ellentétben segít szűrni az olyan nyers javaslatokat, amelyeket nehéz megérteni és becsülni. Az alábbi túlzásba ejtett példában egy bomlási folyamatot adok meg, ahol az olyan ötlet, mint a „Keressünk néhány extra millió dollárt” nagyszerű a magjában, de haszontalan javaslat a folyamathoz. Ticket should be created in unified software and available for other team members A különböző csapatok termékmenedzserei megtarthatják ötleteiket saját helyi terükben, vagy akár privát jegyzetalkalmazásokban is. Ez jobb, mint egyáltalán nincs backlog, de ez számos formátumhoz vezet, és nem áll rendelkezésre a „nagy kép” elemzéséhez. A keretrendszer-adaptáció során döntő fontosságú az egyesített tárhely létrehozása bármilyen betekintéshez. Jobb olyan nagyvállalati termékeket használni, ahol az ötletkutatás során könnyebb a tárgyakat összekapcsolni, mint például a Microsoft Azure DevOps vagy az Atlassian Jira (a fejlesztői csapat folyamataitól függően). Az egységes szoftvereknek meg kell felelniük az alábbi követelményeknek: Bármely csapattag számára elérhető a vállalati fiók alapján. Ezenkívül segít a jogkezelésben és az ellenőrzésben a csapat rotációja során. A keretrendszer vállalati igényekhez való igazításához lehetőséget kell biztosítani további mezők vagy egyéni állapotok létrehozására. A vállalat felügyelete. Mint már említettük, az ötleteknek a vállalat eszközeivé kell válniuk. Ticket should be named properly Mivel egy ötlet/jegy a vállalat eszköze, a csapatnak meg kell tanulnia, hogyan kell megfelelően osztályozni és tárolni ezeket az eszközöket (és néhány tanácsot az alábbiakban). A jegy létrehozása során, különösen a nem technikai hozzájárulók számára, el lehet hagyni a megnevezést, és létre lehet hozni olyan jegyet, mint a „Weboldal javítása”. A jegyet jól lehet leírni a kontextusban, de a jövőbeni naplók esetében további információkat kell megadni a címben. A címnek egyedinek kell lennie, és tartalmaznia kell a fő javaslatot. Ticket shouldn’t include jargon phrases or obscure abbreviations to be understandable for different teams. A jegy címét szerkezet szerint kell felépíteni: A XXX-t YYY-ben kell megváltoztatni ZZZ-ben; más szóval, tartalmaznia kell az objektumot, a tárgyat és az eredményt. Mégis, a valós életben ez a szabály utópikusnak tűnhet; ezért a jegy munkafolyamatnak tartalmaznia kell a vizsgálat során a nevek kijavítását. Példa a fiktív cég "PaperGone": Javítsa a weboldalt -> » » A "PaperGone" weboldal fizetési forgatókönyvének újratervezése a kötelező fiók létrehozásához a kifizetéskor A kezdetektől fogva néhány dolgot szeretnénk megfogalmazni: Meg kell javítani a "PaperGone" weboldalt (mert lehet, hogy van néhány weboldalunk, és jó, ha a kezdetektől megtaláljuk a helyes oldalt). A kérés a fizetési eljárás javításáról szól. A cím megmutatja a fizetési folyamat során a túlzott számla létrehozásával kapcsolatos problémát. Context A jegyzéknek tartalmaznia kell annak leírását, hogy miért kell a termékcsapatnak feldolgoznia a javaslatot.A vállalat folyamataitól függően a kontextus tárgyak szükségesek vagy opcionálisak lehetnek. A lehetséges kontextusinformációk listája: Általános leírás: Miről van szó? Tartalmazhat információkat a piaci változásokról, az ügyfelek kéréseiről vagy más kiváltó tényezőkről. Források: az ügyfelek leveleinek, interjúinak, jelentéseinek vagy híreinek másolata nyilvános forrásokból. Felhasználói történetek (ha vannak): a célközönség és a javításra szolgáló forgatókönyvek feltárása. Minél részletesebb a kontextus, annál valószínűbb, hogy az ötletcsapat a vizsgálat során pozitív döntést hoz. Links Ez az IdeaOps keretrendszer egyik fő jellemzője. Minden új hipotézist a korábbi tapasztalatok alapján kell elemezni. A „PaperGone” weboldalon a fizetési forgatókönyv átdolgozása a kötelező fiók létrehozásához a kifizetéskor” jegyen a csapatnak további kéréseket kell keresnie a PaperGone weboldalon. Talán tavaly az értékesítési csapat ugyanazt a kérdést tette fel, de úgy döntöttünk, hogy a fizetési folyamat során a fiók létrehozása kötelező. Vagy még egy befejezett kérésünk is volt: „A „PaperGone” webhelyen minden egyes vásárlási folyamathoz hozzáadjunk fiók létrehozását”. És lehet, hogy nem áll rendelkezésre a csapat egyik tagja, aki felelős a megvalósításért, hogy megkérdezzük, miért fogadtuk el ezt a döntést. Mindenesetre a viszonylagos jegyeket vagy változásokat hozzá kell adni az újhoz a hipotézis ellenőrzésének megkezdéséhez.Ezek a linkek nem szabad megszakítaniuk a jegy vizsgálatát, mert a piaci helyzet megváltozott; a javaslatot még felül kell vizsgálni. Természetesen lehetséges, hogy a jegy teljesen egyedi, és nem kapcsolódik semmihez korábban. Vagy a keret nem olyan régen jött létre, és nincsenek rendelkezésre álló adatok. Evidence A „bizonyítékok” szakaszában a csapatnak a kapcsolódó információk és a jelenlegi javaslatok alapján vizsgálatot kell végeznie.Kapcsolt, elavult ötletek teljesen eltérőek lehetnek az új hipotézisekkel, és együttesen egy teljesen új képet hozhatnak a középpontba. Ebben a szakaszban olyan tárgyakat kell biztosítani, mint: Találkozó jegyzőkönyvek a megvalósításról az érdekeltekkel, ügyfelekkel, potenciális ügyfelekkel és fejlesztőkkel folytatott megbeszélésekkel. A piackutatás. Interface mock-ups. Proof of Concept (POC) or results of A/B testing. Fontos, hogy létrehozzunk egy értékelési folyamatot, és adatokat gyűjtsünk az egyes tárgyakkal kapcsolatos munka során eltöltött időről.Függetlenül attól, hogy milyen döntés született az adott jegyről, az ilyen adatok értékes betekintést nyújthatnak a hasonló vizsgálatokra fordított erőforrásokra. Estimation A csapatnak bizonyítékokon alapuló becslést kell nyújtania néhány szempontból: Aspect Description Time and money How many hours of every kind of specialist should we spend to implement the suggestion? The idea should go through an estimation process and the total has to be attached to the ticket. Risks What are our risks to implement or omit this idea? Maybe we will lose a key client if we decide not to implement this feature. Or maybe we are losing money every day with a malfunctioning payment scenario on our website. Some ideas also may backfire - the team could implement a new feature and receive an additional revenue, but will have performance and stability issues. That’s why it’s necessary to investigate and document suggestions from different perspectives. This information also may be useful in the future during the discussion of why such a great idea wasn’t implemented in the product. Priority How important is this idea for the product or business at all? This estimation parameter is a tricky one and depends on the correctness of the product strategy. However, a well-provided “Evidence” stage may help to calculate the priority based on established rules and investigated data. There’re many approaches to priority, but simpler is better, so good old RFC 2119 works fine. Time and money Hány órát kell minden egyes szakembernek költenie a javaslat végrehajtására? The idea should go through an estimation process and the total has to be attached to the ticket. kockázatok Milyen kockázatokkal jár, ha megvalósítjuk vagy kihagyjuk ezt az elképzelést? Lehet, hogy elveszítünk egy kulcsfontosságú ügyfelet, ha úgy döntünk, hogy nem hajtjuk végre ezt a funkciót.Vagy talán minden nap pénzt veszítünk egy hibás fizetési forgatókönyvvel a weboldalunkon.Néhány ötlet is visszaléphet - a csapat új funkciót hajthat végre és további bevételt kaphat, de teljesítmény- és stabilitási problémákkal szembesül.Ezért szükséges különböző perspektívákból vizsgálni és dokumentálni a javaslatokat. This information also may be useful in the future during the discussion of why such a great idea wasn’t implemented in the product. prioritás Mennyire fontos ez az ötlet a terméknek vagy a vállalkozásnak egyáltalán? Ez a becslési paraméter bonyolult, és a termékstratégia helyességétől függ. Sok megközelítés létezik a prioritáshoz, de az egyszerűbb jobb, így a jó régi RFC 2119 jól működik. A hivatkozások: Clegg, D. (1994) Case Method Fast-Track: A RAD megközelítés Addison-Wesley Bradner, S. (1997). Kulcsszavak használata RFC-k jelezni követelményszint (RFC 2119). Internet Engineering Task Force. Elérhető: https://www.rfc-editor.org/rfc/rfc2119. References: Clegg, D. (1994) Case Method Fast-Track: A RAD megközelítés Addison-Wesley Bradner, S. (1997). (RFC 2119). Internet Engineering Task Force. Available at: . Key words for use in RFCs to Indicate Requirement Levels https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119 döntés The result stage, based on the previous analysis and artefacts, is the most important stage for IdeaOps. According to the framework, the result comment provides general insight for the future. There are a few options for how each request may end: Ezt meg fogjuk tenni - meg kell írni, hogy miért hangzik jövedelmező ötletnek, és mi segít a helyes döntés meghozatalában.Továbbá ez a megjegyzés hasznos lehet a későbbi elemzéshez, ha az eredmény megéri, amit vártunk. It’s definitely not worth it – okay, but why? Maybe some data were collected incorrectly, or the result value is low. Nevertheless, the product manager has to write a detailed opinion about the rejection. In some future requests, it may be revealed that this particular request was redundant, but if we rethink it in the big picture, the concerns of product managers may be solved. Jó, és van némi érdeklődés cégünk iránt, de nem most – mikor térjünk vissza ehhez a kéréshez, hogy ne hagyjuk el egy óriási hátrányban? Jó, ha egy másik kéréssel kombináljuk - készítsünk egy tervet annak felülvizsgálatára egy további kéréssel és ennek a folyamatnak a formájával. Természetesen több forgatókönyv is létezik, de ebben a cikkben szeretnék példát mutatni a gondolkodásra: Minden kérelmet az egész csővezetéken keresztül kell feldolgozni, és megfelelő eredményt kell kapnia, hogy megmutassa a többi jelenlegi vagy jövőbeli csapattagnak a döntés meghozatalának módját. Minden kérelmet az egész csővezetéken keresztül kell feldolgozni, és megfelelő eredményt kell kapnia, hogy megmutassa a többi jelenlegi vagy jövőbeli csapattagnak a döntés meghozatalának módját. Ez a folyamat arra kötelezi őket, hogy dokumentálják ezt a döntést, és segít a vállalatnak felülvizsgálni és tanulni ezen kérések alapján később. Hogyan készítsünk ötleteket A keretrendszer alapvető lépéseit fedeztük le, de az általános kérelmek visszaszorításának megfelelő használatához olyan tárolórendszert kell létrehozni, amely segít a csapat bármely tagjának, hogy minimális idő alatt megtalálja az aktív vagy archivált ötleteket. Ennek eléréséhez a legjobb módja az, ha az adatokat szűrők és paraméterek segítségével vágjuk le. Nagyon fontos, hogy az összes ötletet egy egységes térben tároljuk, különböző csapatok számára hozzáférhető. Műszaki szempontból bármilyen táblázatkezelő szoftvert használhatunk kérelmek / ötletek tárolására, és szűrjük őket oszlopokban lévő attribútumokkal, de könnyebb és kezelhetőbb egy nagy termék használata a csapatmunkahoz, például az Atlassian Jira vagy a Microsoft Azure DevOps. Ezek a Minden kérésnek eltérő méretei lehetnek: A termék. Business domain. Az üzleti kockázat. A termék funkcionalitása. A fázis kérése. A forrás. Minél több szűrő áll rendelkezésre az ötlet backlog számára, annál több tapasztalattal és gondolkodásmóddal rendelkező csapattag navigálhat rajta. A dimenziók listája nem teljes, és csak egy példa a bomlás módjaira. Javaslom, hogy szervezzen néhány brainstorm munkamenetet, hogy feltárja az összes megfelelő szűrőt a backlog számára, és időről időre frissítse őket. Ezenkívül meg kell állapítani a szűrőbeállítások hozzáadására vonatkozó szabályokat, és adminisztratív szerepet kell rendelni. Minden lehetőségnek zárt listából kell állnia; különben az egész struktúra összeomlik. Minden szempontot szűrők csoportjaként lehet nyilvánosságra hozni; a komplexitás a termék és a vállalat szerkezetétől függ. Termék A vállalatok néhány terméket vagy termékgenerációt fejlesztenek ki, így minden jegyet a termékhez vagy a termékgenerációs platformhoz kell csatlakoztatni. Ez a blokk a terméknevekből állhat: Weboldal, Termék 1 a SaaS számára, Termék 2 az On-Prem számára stb. Vagy segít a platform lokalizálásában: Frontend, Backend, iOS/iPadOS, Android. Egy korábbi példában említettünk egy kitalált kérelmet, " " in the PaperGone company, so I will provide theoretically possible parameters for the correct entry of this request. A "PaperGone" weboldal fizetési forgatókönyvének újratervezése a kötelező fiók létrehozásához a kifizetéskor Business domain Ez a tulajdonság segíthet megtalálni a kérés feldolgozásáért felelős személyt. Ez a marketing fejlesztésekkel kapcsolatos elképzelés, vagy kapcsolódik-e az onboarding problémáinkhoz? Vagy olyan további termékfunkciókról van szó, amelyek segítenek a meglévő ügyfelek elterjesztésében? Az üzleti tartomány a különböző osztályokon és vezetőkön keresztül irányuló kérelmek alapvető tulajdonsága. Példa: értékesítés, marketing, ügyfélszolgálat, számvitel, fejlesztés, QA stb. Üzleti kockázat Minden kérés különböző vállalati kockázatot fedezhet. Néhányan felfedhetik a termékinfrastruktúra építészeti hibáit, vagy valamit, ami az értékesítéssel és a versenytársakkal kapcsolatos. A kérés szerzőjének fel kell ismernie, hogy mi a legmegfelelőbb lehetőség. Ez a dimenzió valaminek a lehetséges problémáiról szól: értékesítés (nem tud eladni anélkül), értékesítés (nem tud növekedni jelenlegi számlák nélkül), biztonság (potenciális kihasználás aggodalom), versenytársak (valami, amit nem rendelkezünk), jogi (megállapodási formáink nem olyan jóak). Termék funkcionalitás Ahhoz, hogy összetett termékeket fejlesszenek ki, tudni kell, hogy mit kezelsz.A vállalat termékei több tucat funkcióból állnak, és az új kérések néhányuk javításai lehetnek, vagy valami létezőhöz kapcsolódnak.Sokat segít a bejövő ötletek rendezése a funkciók csatornáján keresztül, hogy megértsék a termék egyes részei iránti kereslet szintjét, vagy megtalálják a legproblémásabb területeket. A módja annak, hogy elérjék ezt a bomlás le van írva a cikkben - “https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition”. The way to achieve this decomposition is described in the article - “ ”. https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition Fázis kérése Segít megtalálni a kérés aktuális állapotát az IdeaOps munkafolyamat szerint. Példa a színpad szerkezetére: Új - senki nem dolgozta fel a kérést. A becsléshez - a kérés a linkek, a bizonyítékok, a becslés szakaszaiban megy keresztül. Decision stages: Approved - the team has decided to implement the request. Rejected - the team declined the request and provided an explanation of why the idea was rejected. Postponed - the team decided that it’s impossible to process the request in the current situation. Committed - the development stage, that requires is in the process of realisation. Zárva - a kérés befejezését jelző végső szakasz. Természetesen a folyamattól függően lehetőség van a szakaszok szerkezetének bővítésére, hogy részletesebben tükrözze a folyamatot, de mindig szükséges egyensúlyt találni az átláthatóság és a túlzott bürokrácia között. Source Az ötleteket különböző szereplők hozhatják létre, és a feldolgozási idő a forrás függvényében változhat, például: érdekeltek, ügyfelek, értékesítések, ügyfélszolgálati mérnökök, fejlesztők. This system of parameters helps to find any new or past request with minimal time; however, at the same time, it may be an obstacle for the team members because it complicates the way ideas are shared. The intricacy of the system should reflect the company structure, so my recommendation is to start with the easiest parameters and delve deeper according to the team's responses. How to implement the framework Mint minden elmélet esetében, a legbonyolultabb része az IdeaOps keretrendszer integrálása a vállalat mindennapi folyamataira. Nyilvánvaló, hogy a folyamatokat a vállalat szerkezetének megfelelően kell alkalmazni, felül kell vizsgálni, vagy csak részben kell használni, de az általános ötlet az, hogy segítsen jobb jegyfeldolgozást biztosítani, mint korábban volt, és még a keretrendszer egy része is jól fogja ezt tenni. However, in any company, there’s a closed list of obstacles that have to be dealt with. Senki sem tudja, hogyan és miért készítsen jegyet a „helyes módon”. Sok olyan megbeszélés van az értekezleteken vagy üzenetküldőkön keresztül, amelyek nem tükröződnek az ötlet munkaterületen. Egyes források nem tudnak strukturált adatokat szolgáltatni egy központosított backlog rendszeren keresztül. Let’s cover them step by step. Teach team members how to work with a general backlog Create a template request ticket and provide an example. Templates could be described in company documentation or even developed in the software (Atlassian Jira or Microsoft Azure DevOps are perfectly fine with them). Az új lekérdezés-munkaelemeknek a szükséges mezőkből és paraméterekből kell állniuk a szükséges és nem szükséges jelölésekkel, így lehetetlen kihagyni a fontos adatokat. The examples should establish the standards of naming and content structure. Tegye közzé az ötlet/kérelem munkafolyamatot, hogy mindenki megérthesse, mit jelent az egyes szakaszok. Üzenet küldése arról, hogy ez a sablon az egyetlen módja a kérés benyújtásának. Opcionálisan, ha a csapat szerkezete nem bonyolult, az értekezleten keresztül igazolható. Reject the requests that are not in line with the new process. Definitely, the most complicated stage of new process adoption, because it needs balance not to disrupt the company’s operations. For highly important and prompt requests, it’s fine to fix them yourself, showing them as examples. The adoption stage will reveal dozens of special cases, and after a few iterations, the team will implement the new process. Fix communication outside the request Természetes, hogy a témákat üzenetküldőkben, e-mailben vagy találkozókban vitatjuk meg, mert gyors és termékeny. Mindazonáltal fontos a keretrendszer elképzelése, amely az összes adatot egy helyen tárolja, hogy újra és újra hozzáférhessen az adatokhoz, megtanulhassa és elemezze azt. Every meeting or chain of messages has to be related to the request ticket ID, so later it will be possible to find the activity based on the unique identification number of the request. Az AI asszisztensek korában ez nem olyan bonyolult, és sokat segít a további elemzésben. Igen, egyes tárgyalások még mindig elveszhetnek a magánbeszélgetésekben, de minden egyes kéréshez egy általános facilitátor létezése segít az adatok tárolásra irányításában. Borderline forgatókönyvek Mindig vannak olyan forgatókönyvek, amikor egy központosított backlog rendszer nem működik. Talán ez egy nagyon elfoglalt részvénytulajdonos kérése, vagy a partnerek, akik nem tudnak hozzáférni a belső rendszerhez. És ez rendben van. A csapatnak csak fel kell tárnia ezeket a forgatókönyveket, és meg kell találnia a módját, hogyan lehet őket a szabványos rendszerekbe irányítani. A részvénytulajdonos kéréseit az egyik termékvezetőnek X időben kell feldolgoznia. A partnerek kéréseit a partnerek szerepétől függően a fiókkezelőknek vagy a technikai támogatásnak kell feldolgoznia.A csapatnak ki kell választania a folyamat megkezdéséhez legközelebbi kiindulási pontot. Mint mindig az új folyamatok létrehozásában, fontos dokumentálni és nyilvánosságra hozni a nyilvános dokumentáció minden lépését a megállapodások és a kis részletek rögzítéséhez. Sikeres metrikák Az új folyamat végrehajtása sok időt és erőfeszítést igényel, így néhány mutató segíthet nyomon követni annak elfogadását. Időszerű betekintés Az IdeaOps keretrendszer egyik fő célja az ötletek feldolgozása a kezdetektől az elemzett döntésig. Ez a mutató a létrehozástól a döntésállapotok egyikéig eltelt napok számát mutatja, és segít a következő szervezeti célok feltárásában: Speed of responses to customers or stakeholders across different teams. Number of stuck responses whose processing time exceeds the established limits. Megmutatja a kapcsolatot az eredetileg megadott adatok teljessége és minősége, valamint a kérés feldolgozásához szükséges idő között. Indirectly shows how the presence of related requests with previously provided estimates on similar ideas speeds up decision making. Az eltöltött idő metrikus Az érthető és helyes kéréseknek minimalizálniuk kell az időt, ameddig egy menedzser feldolgozza őket. A „idő-bevitel” metrikát a teljes feldolgozási idő mérésére javasolják, amely magához a folyamathoz kapcsolódik. Mindazonáltal az is fontos, hogy mérjük a felelős menedzser munkatartamát, aki részt vett ebben a folyamatban. Természetesen néhány ötlet hetekig tartó kutatást igényel, míg néhány csak egy gomb színét jelent. De a negyedév vagy év átlagos értéke még mindig segíthet felfedni az eltöltött idő javulását. Ha egyre több kérés kapcsolódik becslésekkel és részletes döntésekkel, ez befolyásolja a teljes feldolgozási időt menedzserenként. lefedettség szintje Shows the completeness of the request backlog. It’s necessary to raise the metric level with new and old requests to achieve an ideal base of proposals. Mivel kell foglalkozni During adoption, a few problems have to be overcome: A csapattagoknak tudniuk kell, hogy a jegyzetek személyes terének használata rossz gyakorlat, ami fontos vállalati adatok elvesztéséhez vezet. Ha valamit dokumentálni kell, azt a kérésben kell elvégezni. Ha létrehoztak egy koncepciós bizonyítékot, vagy egy ötletet becsültek, a befejezett munkához és a jövőbeli tevékenységekhez kapcsolódó összes számot bele kell foglalni a kérésbe. A leírás nélküli döntés nem segít a jövőben. Az elutasított ötletet minden oldalról feldolgozhatják és figyelembe veszik, de megfelelő következtetés nélkül csak időpocsékolás.A következő hasonló ötlet ugyanolyan időt igényel a feldolgozásra, mert a korábbi eredmények nem mutatják meg az elutasítás valódi okait, így a vállalat folyamatosan pénzt veszít, különösen akkor, ha a csapat szerkezete idővel változik. Az örökbefogadási menedzsernek rendszeresen felül kell vizsgálnia a zárt és rögzített kérelmeket a folyamat javítása érdekében. következtetés A javasolt IdeaOps keretrendszer ideális módja annak, hogy a különböző és néha érthetetlen adatok nagy mennyiségét egy kezelhető struktúrába feldolgozzuk. Jól összehangolt csapatmunka szükséges, ahol minden tag megérti, hogy minden adat és döntés nagyobb, hogy egy nap segíthet új magasságok elérésében az üzleti életben, és javítja a vállalat általános helyzetét. Miután megfelelően feldolgozták, sőt elutasították, az egyik ügyfél jelentéktelen javaslata szerepelhet a termékstratégia általános változásában, mert a helyzet egyértelmű elemzését, becsléseit és néhány okos következtetést tartalmaz arról, hogy miért nem volt fontos önálló fejlesztés, de teljesen más az új piaci helyzetben. És ha ezt a döntést megfelelően dokumentálták és újraf Az ötletkatalóguson való munka ugyanolyan fontos, mint a bevételeken való munka, és minden vállalat feladata, hogy kövesse a javítás útját.
