Jsou nápady cenné, nebo nejsou nic před realizací? Řízení vývoje produktu je postaveno na myšlenkách a předpokladech. Produktový tým by měl rychle reagovat na jakékoli požadavky nebo kolísání trhu. Jakékoli rozhodnutí by mělo být učiněno s cílem zvýšit hodnotu produktu, příjmy nebo kapitalizace. Mezitím by měl být proces vyšetřování proveden s minimálními zdroji. Hypotheses in this avalanche may be connected with different aspects: Nové marketingové strategie. Nové charakteristiky . Přizpůsobení se novým trhům nebo výklenkům. Výzkum vytváření nového produktu od nuly. Nicméně, navzdory rozmanitosti předpokladů, retrospektivní analýza může ukázat, že celý zásobník myšlenek v jedné produktové výklenku není nekonečný. Myšlenky mohou být vyvinuty v osobních poznámkách nebo firemních chatech bez systému a po rotaci členů týmu bude tým poskytovat stejné vyšetřování bez zohlednění předchozích zkušeností. Tyto myšlenky vyžadují správný rámec pro ukládání, hromadění a poskytování poznatků o trhu, bez ohledu na změny v růstu týmu nebo společnosti. Tento životaschopný systém dokazuje, že nápady stojí hodně a může pomoci produktovým manažerům ušetřit čas a zdroje společnosti. IdeaOps pro vývoj produktů Termín „IdeaOps“ jako produktový rámec mi byl poprvé představen v show „Rebellious Businesses“ od Katherine R. Lieber v epizodě podcast „Stop Bleeding Out Your Competitive Edge: Use IdeaOps To Start Capturing And Acting On Essential Innovations“ (02.02.2025). Odkaz: 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. V tomto článku se podělím o své osobní zkušenosti s vývojem produktů, které doplňují myšlenku původního termínu. Termín „IdeaOps“ jako produktový rámec mi byl poprvé představen v show „Rebellious Businesses“ od Katherine R. Lieber v epizodě podcastů „Stop Bleeding Out Your Competitive Edge: Use IdeaOps To Start Capturing And Acting On Essential Innovations“ (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 V tomto článku se podělím o své osobní zkušenosti s vývojem produktů, které doplňují myšlenku původního termínu. Jádrem rámce je uvědomění si, že každá hypotéza je aktivem společnosti. Toto jmění by mělo mít majitele, celý kontext myšlenky, artefakty, které byly vytvořeny během procesu vyšetřování, odkazy na jiné jmění a stav rozhodnutí.Další doporučení odhalí nutnost procesu, kde je velmi důležité nejen fixovat na přijetí nebo odmítnutí hypotézy, ale ukázat celý tracking proces s historií myšlení, časem stráveným a přerušovanými výsledky. Stejně jako u jakéhokoli jiného rámce budou hlavní aspekty uvedeny v článku: Jak vybudovat proces shromažďování nápadů. How to store the ideas. Jak tento rámec realizovat. Jak měřit úspěch a hodnotu změn. How to build the process of idea gathering? The process follows common and well-used recommendations for upcoming change requests. Every idea has to go through a pipeline: ve stvoření. v kontextu . na levici . Evidence. a odhadu. a rozhodnutí. stvoření Každá myšlenka musí být zachycena uvnitř infrastruktury společnosti podle pravidel: For every idea or request, a unique ticket should be created Sometimes an idea may be complex and require an overhaul of the product or market approach itself. It is necessary to teach the team how to decompose every hypothesis into valuable, but separable, improvements. This may create some additional bureaucracy and decrease the number of ideas – if it is hard to formalise, some team members may avoid idea fixation. In contrast, it helps to filter out raw suggestions that are hard to comprehend and estimate. During the process of establishing a framework, it is necessary to assess team compatibility to find the balance. V níže uvedeném přehnaném příkladu poskytuji proces rozkladu, kde je myšlenka jako „Získejme několik dalších milionů dolarů“ ve svém jádru skvělá, ale je to zbytečný návrh pro tento proces. Ticket should be created in unified software and available for other team members Produktoví manažeři z různých týmů mohou své nápady uchovávat ve svých vlastních místních prostorách nebo dokonce v soukromých poznámkových aplikacích.Je to lepší než absence backlogu vůbec, ale vede k nesčetným formátům a nedostupnosti k analýze „velkého obrazu“. During the framework adaptation, it’s crucial to establish a unified storage for any insights. It’s better to use some big corporate product where it's easier to link artefacts during idea investigation, such as Microsoft Azure DevOps or Atlassian Jira (depending on dev team processes). Unified software by měl splňovat tyto požadavky: Available for any team member by corporate account. It also helps with rights management and control during team rotation. Vhodné pro přizpůsobení.Pro přizpůsobení rámce potřebám společnosti je nutné mít možnost vytvořit další pole nebo vlastní stav. Jak již bylo zmíněno výše, myšlenky by se měly stát majetkem společnosti.To znamená správnou údržbu hlavního skladu. Ticket should be named properly Vzhledem k tomu, že myšlenka / jízdenka je aktivem společnosti, tým se musí naučit, jak tyto aktiva řádně klasifikovat a ukládat (a některé rady budou poskytnuty níže). Během vytváření lístku, zejména pro netechnické přispěvatele, může být vynecháno jmenování a mohou být vytvořeny lístky jako "Zlepšit webové stránky". lístek může být dobře popsán v kontextu, ale pro budoucí logy je nutné poskytnout další informace v názvu. Ticket title should be unique and include the main suggestion. Vstupenky by neměly obsahovat žargonové fráze nebo nejasné zkratky, aby byly srozumitelné pro různé týmy. Název lístku by měl být postaven podle struktury: Chcete-li XXX v YYY změnit ZZZ; jinými slovy, obsahují objekt, předmět a výsledek. Still, in real life, this rule may sound utopian; that's why ticket workflow should include naming corrections during investigation. Příklad s fiktivní společností "PaperGone": Zlepšit webové stránky -> » » » Přepracujte platební scénář na webových stránkách "PaperGone", abyste opravili povinné vytváření účtu při pokladně Zde se zaměřujeme na několik aspektů od začátku: Je nutné opravit webové stránky "PaperGone" (protože můžeme mít několik webových stránek a je hezké najít ten správný od začátku). Žádost se týká zlepšení platebního procesu. Název ukazuje problém s nadměrným vytvářením účtu během platby. Context Vstupenka by měla obsahovat popis toho, proč musí produktový tým zpracovat návrh.V závislosti na firemních procesech mohou být vyžadovány nebo volitelné kontextové artefakty. Seznam možných kontextových informací: Obecný popis: O čem je? Může obsahovat informace o změnách na trhu, požadavcích zákazníků nebo jiných spouštěčích. Zdroje: kopie dopisů zákazníků, rozhovorů, zpráv nebo zpráv z veřejných zdrojů. Příběhy uživatelů (pokud jsou k dispozici): odhalit cílové publikum a scénáře ke zlepšení. Čím podrobnější je kontext, tím je pravděpodobnější, že nápadový tým v průběhu vyšetřování učiní pozitivní rozhodnutí. Links To je jedna z hlavních vlastností rámce IdeaOps. Každá nová hypotéza by měla být analyzována na základě předchozích zkušeností. Před vyšetřovacím procesem je nutné hledat relativní nebo podobné vstupenky. Pro vstupenku „Přepracujte platební scénář na webových stránkách „PaperGone“ a opravte povinné vytváření účtu při pokladně“ by tým měl hledat další požadavky týkající se webových stránek PaperGone. Maybe last year the sales team asked the same question but we made a decision that account creation during the payment process is mandatory. Or even we had a completed request “Add account creation for every purchase process on “PaperGone” website”. And we may not have any of the team members available who are responsible for the implementation, to ask why we adopted such a decision. Or one of the teams tried to remove the mandatory account creation and the product team noticed the decrease of user data to send very important marketing emails and aborted the changes. Tyto odkazy by neměly přerušit šetření za lístek, protože se situace na trhu mohla změnit; návrh ještě musí být revidován. nicméně, kvalita výzkumu se dramaticky zlepší s porozuměním celému příběhu. Samozřejmě je možné, že jízdenka je zcela jedinečná a nesouvisí s ničím předtím.Nebo byl rámec vytvořen ne tak dávno a nejsou k dispozici žádné údaje.V tomto případě je nutné poskytnout správné přílohy a úplné informace v pozdějších fázích procesu jízdenky, aby se zlepšila práce v budoucnu. Evidence Během fáze „důkazů“ by tým měl poskytnout vyšetřování založené na souvisejících informacích a aktuálních návrzích.Připojené, potratené myšlenky mohou vypadat zcela odlišně s novými hypotézami a společně přinášejí do centra pozornosti celý nový obraz. Tato fáze by měla poskytovat artefakty, jako jsou: Schůzky s diskusemi o implementaci se zúčastněnými stranami, zákazníky, potenciálními zákazníky a vývojáři. Výzkum trhu . Interface mock-ups. Proof of Concept (POC) nebo výsledky A/B testů. Je důležité vytvořit proces hodnocení a shromáždit údaje o čase stráveném na práci na každém artefaktu. Bez ohledu na rozhodnutí o tomto konkrétním lístku mohou takové údaje poskytnout cenné poznatky o zdrojích, které musí být vynaloženy na podobná vyšetřování. Estimation Tým by měl poskytnout odhad založený na důkazech v několika aspektech: 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. Čas a peníze Kolik hodin každého druhu odborníka bychom měli strávit realizací návrhu? Myšlenka by měla projít procesem odhadu a součet musí být připojen k lístku. Rizika Jaké jsou naše rizika při implementaci nebo vynechání této myšlenky? Možná ztratíme klíčového klienta, pokud se rozhodneme tuto funkci neimplementovat. Nebo možná ztrácíme peníze každý den s nefunkčním platebním scénářem na našich webových stránkách. Některé myšlenky mohou také zpomalit - tým by mohl implementovat novou funkci a získat dodatečný příjem, ale bude mít problémy s výkonem a stabilitou. Tyto informace mohou být také užitečné v budoucnu během diskuse o tom, proč takový skvělý nápad nebyl implementován v produktu. Priority Jak důležitá je tato myšlenka pro produkt nebo podnik vůbec? Tento odhadový parametr je složitý a závisí na správnosti strategie produktu. Nicméně dobře poskytnutá fáze „důkazů“ může pomoci vypočítat prioritu na základě zavedených pravidel a zkoumaných údajů. Existuje mnoho přístupů k prioritě, ale jednodušší je lepší, takže dobrý starý RFC 2119 funguje dobře. O referencích : Clegg, D. (1994). Case Method Fast-Track: A RAD Approach. Bradner, S. (1997). Klíčová slova pro použití v RFC k označení požadavků úrovně (RFC 2119). Internet Engineering Task Force. K dispozici na: https://www.rfc-editor.org/rfc/rfc2119. References: Clegg, D. z roku 1994 O společnosti Addison-Wesley Case Method Fast-Track: A RAD Approach Bradner, S. z roku 1997 (RFC 2119). Internet Engineering Task Force. Available at: . Klíčová slova pro použití v RFC pro označení úrovní požadavků https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119 Rozhodnutí Výsledková fáze, založená na předchozích analýzách a artefaktech, je nejdůležitější fází pro IdeaOps. There are a few options for how each request may end: Uděláme to – je nutné napsat, proč to zní jako ziskový nápad a co nám pomáhá učinit správné rozhodnutí.Také tento komentář může být užitečný pro pozdější analýzu, pokud výsledek stál za to, co se očekávalo. 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. Je to hezké, a je tu nějaký zájem o naši společnost, ale ne právě teď – kdy bychom se měli vrátit k této žádosti, abychom ji neopustili v obrovském backlogu? Je dobré, když ji spojíme s jinou žádostí – pojďme si vytvořit plán, jak ji revidovat s další žádostí a formou tohoto procesu. Sure, there are more scenarios, but in this article I want to show an example of thinking: Každá žádost musí být zpracována v průběhu celého potrubí a musí mít správný výsledek, který ukáže ostatním současným nebo budoucím členům týmu, jak přijmout rozhodnutí. Každá žádost musí být zpracována v průběhu celého potrubí a musí mít správný výsledek, který ukáže ostatním současným nebo budoucím členům týmu, jak přijmout rozhodnutí. Lidé mohou dělat chyby nebo přijmout špatné rozhodnutí podle situace a jejich znalostí.Tento proces je zavazuje dokumentovat toto rozhodnutí a pomáhá společnosti revidovat a učit se na základě těchto žádostí později. Jak vytvářet nápady We have covered the basic steps of the framework, but for proper use of a general request backlog it’s necessary to build a storage system that helps any team member to find any active or archived idea in minimal time. The best way to achieve this is to slice data via a set of filters and parameters. It is highly important to store all ideas in a unified space, accessible for different teams. Technically, it’s possible to use any spreadsheet software as storage for requests/ideas and filter them using attributes in columns, but it is easier and more manageable to use a large product for teamwork such as Atlassian Jira or Microsoft Azure DevOps. These products can help to organise workflows, proper stage management and role-based access control. Každá žádost může mít různé rozměry: výrobku se. Business domain. Business risk. Product functionality. Žádost o fázi. z zdroje . The more filters are available for the idea backlog, the more team members with a variety of experience and ways of thinking may navigate through it. The list of dimensions isn’t complete and provides just an example of ways of decomposition. I recommend organising a few brainstorm sessions to reveal all suitable filters for the backlog and refresh them from time to time. Also, it’s necessary to establish rules for adding the filter options and assign an administrator role. Every option has to consist of a closed list of items; otherwise, the whole structure will fall apart. Každý aspekt může být odhalen jako skupina filtrů; složitost závisí na produktu a struktuře společnosti. Product Společnosti mohou vyvíjet několik produktů nebo generací produktů, takže jakýkoliv lístek by měl být připojen k produktu nebo platformě produkce. Tento blok může sestávat z názvů produktů: Webové stránky, Produkt 1 pro SaaS, Produkt 2 pro On-Prem atd. Nebo pomoci najít platformu: Frontend, Backend, iOS / iPadOS, Android. In an earlier example, we mentioned a fictional request, " " ve společnosti PaperGone, takže budu poskytovat teoreticky možné parametry pro správné zadání této žádosti. Přepracujte platební scénář na webových stránkách "PaperGone", abyste opravili povinné vytváření účtu při pokladně Podnikatelská doména This attribute should help to locate the responsible person to process the request. Is this idea about marketing improvements, or is it connected to our issues in onboarding? Or is it about additional product functionality that helps us to upsell current customers? The business domain is a core attribute to route requests through different departments and managers. Examples: Sales, Marketing, Customer Support, Accounting, Development, QA, etc. Podnikatelské riziko Každá žádost může pokrývat jiné riziko společnosti. Některé z nich mohou odhalit architektonické nedostatky v produktové infrastruktuře, nebo něco spojeného s prodejem a konkurenty. Autor žádosti by si měl uvědomit, jaká je nejvhodnější volba. Tato dimenze se týká možných problémů v něčem: prodeje (nemůže se bez něj prodávat), upselling (nemůže bez něj růst aktuální účty), bezpečnost (potenciální zneužívání obavy), konkurenti (něco, co nemáme), právní (naše formuláře dohody nejsou tak dobré). Product functionality Pro růst složitých produktů je nutné vědět, co řídíte. Produkty společnosti se skládají z desítek funkcí a nové požadavky mohou být vylepšení některých z nich nebo souvisejí s něčím stávajícím. Způsob, jak dosáhnout tohoto rozkladu je popsán v článku - "https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition". Způsob, jak dosáhnout tohoto rozkladu je popsán v článku - " ”. https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition Žádost o fázi Pomáhá najít aktuální stav žádosti podle pracovního postupu IdeaOps. An example of the stage structure: New - nobody has processed the request. Chcete-li odhadnout - žádost prochází linky, důkazy, odhady fáze. 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. Zavázaný - vývojová fáze, která vyžaduje, je v procesu realizace. Closed - the final stage to indicate the completion of the request. Sure, depending on the process, it’s possible to expand the stages structure to reflect the process in a more detailed way, but it’s always necessary to find a balance between transparency and excessive bureaucracy. Source The ideas may be created by different actors, and the processing time may vary depending on the source. For example: Stakeholders, Customers, Sales, Customer Support Engineers, Developers. Tento systém parametrů pomáhá najít jakékoliv nové nebo minulé požadavky s minimálním časem; nicméně současně může být překážkou pro členy týmu, protože komplikuje způsob, jakým jsou nápady sdíleny. Jak implementovat rámec As with any theory, the most complicated part is integrating the IdeaOps framework into a company's day-to-day processes. Obviously, processes should be adapted, revised, or only partially used according to the company structure, but the general idea is to help provide better ticket processing than there was previously, and even part of the framework will do this well. However, in any company, there’s a closed list of obstacles that have to be dealt with. Nobody knows how and why to create tickets in the “right way”. There’s a lot of discussions in meetings or via messengers that are not reflected in the idea work item. Some sources cannot provide structured data via a centralised backlog system. Pojďme je pokrýt krok za krokem. Teach team members how to work with a general backlog Vytvořte vstupenku na žádost o šablonu a uveďte příklad. Šablony by mohly být popsány v dokumentaci společnosti nebo dokonce vyvinuty v softwaru (Atlassian Jira nebo Microsoft Azure DevOps jsou s nimi dokonale v pořádku). Nové položky práce žádosti by měly sestávat z nezbytných polí a parametrů s požadovanými a nepotřebnými značkami, takže může být nemožné vynechat důležité údaje. Příklady by měly stanovit standardy pojmenování a struktury obsahu. Publish the idea/request workflow, so everyone can understand what each stage means. Broadcast a message that this template is the only way to submit the request. Optionally, if the team structure is not complicated, it can be justified via a meeting. 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. Adopční fáze odhalí desítky speciálních případů a po několika iteracích tým implementuje nový proces. Oprava komunikace mimo požadavek Je přirozené diskutovat o tématech v messengerech, prostřednictvím e-mailu nebo na schůzkách, protože je to rychlé a produktivní.Nicméně, myšlenka rámce pro ukládání všech dat na jednom místě, aby bylo možné znovu a znovu přistupovat k datům, učit se a analyzovat je, je důležitá. Každá schůzka nebo řetězec zpráv musí souviset s ID žádosti o vstupenku, takže později bude možné nalézt činnost na základě jedinečného identifikačního čísla žádosti. Pro každé setkání o žádosti musí být vytvořeny schůzky.V éře AI asistentů, to není tak složité a pomáhá hodně v další analýze. Každá žádost v každé fázi musí být přiřazena členovi týmu, který bude zodpovědný za upevnění všech významných artefaktů. Ano, některá jednání mohou být stále ztracena v soukromých diskusích, ale existence obecného facilitátora pro každou žádost pomáhá směrovat data do úložiště. Řešení hraničních scénářů Existují vždy scénáře, kdy centralizovaný systém backlogů nefunguje. Možná je to žádost od velmi zaneprázdněného akcionáře nebo partnerů, kteří nemají přístup k internímu systému. A to je v pořádku. Žádosti od akcionáře by měly být zpracovány jedním z produktů vedoucích v X čase.Tato role musí vytvořit žádost a shromažďovat potřebné údaje sami. Partners' requests should be processed by account managers or technical support, depending on the role of the partners. The team should choose the nearest starting point to begin the process. Jak je obvyklé při vytváření nových procesů, je důležité dokumentovat a deklarovat veškeré kroky ve veřejné dokumentaci, aby se stanovily dohody a drobné detaily. Úspěšná metrika Implementace nového procesu vyžaduje spoustu času a úsilí, takže několik ukazatelů by mohlo pomoci sledovat jeho přijetí. Time-to-insight Jedním z hlavních cílů rámce IdeaOps je zpracování myšlenek od jejich vzniku až po analyzované rozhodnutí.Tato metrika ukazuje počet dnů od vytvoření až po dosažení jednoho z rozhodovacích stavů a pomáhá odhalit následující organizační cíle: Speed of responses to customers or stakeholders across different teams. Number of stuck responses whose processing time exceeds the established limits. Shows the relationship between the completeness and quality of the initially provided data and the time it takes to process a request. That’s a great metric to justify additional fields or filters for the request. Nepřímo ukazuje, jak přítomnost souvisejících požadavků s dříve poskytnutými odhady na podobné nápady urychluje rozhodování. Čas strávený metrikou Understandable and correct requests should minimise the time a manager takes to process them. A “time-to-insight” metric is proposed to measure the overall processing time, which is related to the process itself. However, it's also important to measure the working time of the responsible manager who participated in this process. Of course, some ideas require weeks of investigation, while some are just about the colour of a button. But the average value per quarter or per year could still help to reveal improvements in time spent. If more and more requests have linked estimations and detailed decisions, it will affect the overall processing time per manager. Úroveň pokrytí 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. Co je třeba řešit Během adopce je třeba překonat několik problémů: Team members should know that using personal spaces for notes is a bad practice, which leads to the loss of important company data. If anything has to be documented, it should be done in the request. The same applies to meeting summaries. Pokud byl vytvořen nějaký artefakt Proof of Concept nebo byla odhadnuta nějaká myšlenka, všechny čísla týkající se dokončené práce a budoucích činností by měly být zahrnuty do žádosti. Rozhodnutí bez popisu nepomůže v budoucnu. odmítnutá myšlenka může být zpracována a zvážena ze všech stran, ale bez řádného závěru je to jen ztráta času. Další podobná myšlenka bude vyžadovat stejné množství času pro zpracování, protože předchozí výsledky neukazují skutečný důvod odmítnutí, takže společnost bude neustále ztrácet peníze, zejména pokud se struktura týmu časem změní. The adoption manager has to provide regular reviews of closed and stuck requests to improve the process. Závěr The proposed IdeaOps framework is an idealistic way to process a large amount of different and sometimes incomprehensible data into a manageable structure. It requires well-coordinated teamwork where every member understands that every piece of data and decision is something bigger, that one day may help to reach new heights for the business and improve the overall company situation. Once properly processed, and even rejected, a insignificant proposal from one of the customers may be included in a general change in product strategy, because it contains a clear analysis of the situation, estimates and some clever conclusions as to why it wasn’t important as a standalone improvement, but looks completely different in a new market situation. And if this decision was properly documented and reused, that means that any tiny idea is a real asset of the company and deserves to be processed and stored for the best times. Práce na katalogu nápadů je stejně důležitá jako práce na příjmech a je na každé společnosti, aby následovala cestu ke zlepšení.
