Cila është kostoja e një ideje?A janë ato të vlefshme, apo janë asgjë para zbatimit? Menaxhimi i zhvillimit të produktit është ndërtuar mbi idetë dhe hipotezat. Një ekip i produktit duhet të reagojë shpejt ndaj çdo kërkese të tregut ose luhatjeve. Çdo vendim duhet të merret për të rritur vlerën e produktit, të ardhurat ose kapitalizimin. Ndërkohë, procesi i hetimit duhet të bëhet me burime minimale. Hipotezat në këtë shkretëtirë mund të lidhen me aspekte të ndryshme: Strategjitë e reja të marketingut karakteristika të reja. Përshtatja për tregje të reja ose nisma. Investimi për krijimin e një produkti të ri nga zero. Megjithatë, pavarësisht nga shumëllojshmëria e supozimeve, analiza retrospektive mund të tregojë se e gjithë mbivendosja e ideve në një niche të produktit nuk është e pafundme. Idetë mund të zhvillohen në shënime personale ose biseda të kompanisë pa një sistem, dhe pas rotacionit të anëtarëve të ekipit, ekipi do të ofrojë të njëjtën hetim pa marrë parasysh përvojën e mëparshme. Këto ide kërkojnë një kornizë të duhur për të ruajtur, akumuluar dhe ofruar njohuri për tregun, pavarësisht nga ndryshimet në ekipin ose rritjen e kompanisë. Ky sistem i vlefshëm dëshmon se idetë kushtojnë shumë dhe mund të ndihmojë menaxherët e produktit për të kursyer kohë dhe burime të kompanisë. IdeaOps për zhvillimin e produktit Termi "IdeaOps" si një kornizë e produktit u prezantua për herë të parë për mua në shfaqjen "Businesses Rebellious" nga Katherine R. Lieber në episodin podcast "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. Në këtë artikull unë ndaj përvojën time personale të zhvillimit të produktit që plotëson idenë e terminit origjinal. 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 Në këtë artikull unë ndaj përvojën time personale të zhvillimit të produktit që plotëson idenë e terminit origjinal. Thelbi i kornizës është realizimi se çdo hipotezë është një asetet e kompanisë. Ky asetet duhet të ketë një pronar, të gjithë kontekstin e idesë, artefakte që janë krijuar gjatë procesit të hetimit, lidhjet me asetet e tjera dhe gjendjen e vendimit. rekomandimet e përshkruara më poshtë do të zbulojnë nevojën e një procesi ku është shumë e rëndësishme jo vetëm për të fiksuar në miratimin ose refuzimin e hipotezës, por për të treguar të gjithë procesin e gjurmimit me historinë e të menduarit, kohën e shpenzuar dhe rezultatet e ndërprera. As with any other framework, the main aspects will be introduced in the article: Si të ndërtojmë procesin e mbledhjes së ideve. Si të ruani idetë Si të zbatohet korniza Si të matni suksesin dhe vlerën e ndryshimeve How to build the process of idea gathering? Procesi ndjek rekomandime të zakonshme dhe të përdorura mirë për kërkesat e ardhshme të ndryshimit. Çdo ide duhet të kalojë nëpër një tubacion: Krijimi i Kontekst të të majtë. dëshmi të vlerësimin e Vendimi i Krijimi Çdo ide duhet të kapet brenda infrastrukturës së kompanisë sipas rregullave: For every idea or request, a unique ticket should be created Ndonjëherë një ide mund të jetë komplekse dhe kërkon një rishikim të vetë produktit ose qasjes së tregut. Është e nevojshme të mësosh ekipin se si të shpërbëjë çdo hipotezë në përmirësime të vlefshme, por të ndara. Kjo mund të krijojë disa burokraci shtesë dhe të zvogëlojë numrin e ideve - nëse është e vështirë të formalizohet, disa anëtarë të ekipit mund të shmangin fiksimin e ideve. Në shembullin e tepruar më poshtë, unë ofroj një proces shpërbërjeje ku një ide si "Le të fitojmë disa miliona dollarë shtesë" është e madhe në thelbin e saj, por një sugjerim i padobishëm për procesin. Ticket should be created in unified software and available for other team members Menaxherët e produktit nga ekipe të ndryshme mund të mbajnë idetë e tyre të mbetura në hapësirat e tyre lokale ose madje edhe në aplikacionet private të shënimeve. është më mirë se mungesa e një mbeturi në të gjitha, por kjo çon në një shumëllojshmëri të formateve dhe mungesa e disponueshmërisë për të analizuar "fotografinë e madhe". Është më mirë të përdorni disa produkte të mëdha të korporatave ku është më e lehtë të lidhni artefakte gjatë hulumtimit të ideve, të tilla si Microsoft Azure DevOps ose Atlassian Jira (në varësi të proceseve të ekipit të zhvillimit). Software unifikuar duhet të përmbushë kërkesat: I disponueshëm për çdo anëtar të ekipit sipas llogarisë së korporatës. Gjithashtu ndihmon në menaxhimin e të drejtave dhe kontrollin gjatë rotacionit të ekipit. Për të përshtatur kornizën për nevojat e kompanisë, është e nevojshme të keni mundësinë për të krijuar fusha shtesë ose statuse të personalizuara. Siç u përmend më lart, idetë duhet të bëhen asetet e kompanisë.Kjo do të thotë mirëmbajtjen e duhur të magazinimit kryesor. Ticket should be named properly Për shkak se një ide / biletë është një asetet e kompanisë, ekipi duhet të mësojnë se si të klasifikojnë dhe ruajnë këto asete siç duhet (dhe disa këshilla do të jepen më poshtë). Gjatë krijimit të biletës, veçanërisht për kontribuesit jo-teknikë, emërimi mund të përjashtohet dhe mund të krijohen bileta të tilla si "Përmirësoni faqen e internetit". bileta mund të përshkruhet mirë në pjesën kontekstuale, por për ditarët e ardhshëm është e nevojshme të jepet informacion shtesë në titull. Ticket title should be unique and include the main suggestion. Bileta nuk duhet të përfshijë fraza jargon ose shkurtime të paqarta që të jenë të kuptueshme për ekipet e ndryshme. Titulli i biletës duhet të ndërtohet nga struktura: Për të bërë XXX në YYY për të ndryshuar ZZZ; me fjalë të tjera, përmbajnë objektin, subjektin dhe rezultatin. Megjithatë, në jetën reale, kjo rregull mund të tingëllojë utopike; kjo është arsyeja pse rrjedha e punës e biletës duhet të përfshijë korrigjimet e emrit gjatë hetimit. Shembull me kompaninë fiktive "PaperGone": Përmirësoni faqen e internetit -> ". Rishikoni skenarin e pagesës në faqen e internetit "PaperGone" për të rregulluar krijimin e detyrueshëm të llogarisë në check-out Këtu ne po synojmë disa aspekte nga fillimi: Është e nevojshme për të rregulluar faqen e internetit "PaperGone" (sepse ne mund të kemi disa faqe interneti dhe është mirë për të gjetur atë të saktë nga fillimi). Kërkesa është për përmirësimin e procesit të pagesës. Titulli tregon problemin me krijimin e tepërt të llogarisë gjatë pagesës. Context Bileta duhet të përfshijë një përshkrim se pse ekipi i produktit duhet të përpunojë sugjerimin.Në varësi të proceseve të kompanisë, artefakte kontekstuale mund të jenë të nevojshme ose opsionale. List of possible context information: Përshkrimi i përgjithshëm: Për çfarë bëhet fjalë? Mund të përmbajë informacione për ndryshimet e tregut, kërkesat e klientëve ose shkaktarë të tjerë. Burimet: kopje të letrave të klientëve, intervistave, raporteve ose lajmeve nga burime publike. Historitë e përdoruesve (nëse është e përshtatshme): për të zbuluar audiencën e synuar dhe skenarët për të përmirësuar. Sa më i detajuar të jetë konteksti, aq më shumë ka gjasa që ekipi i ideve të marrë një vendim pozitiv gjatë hetimit. Links That's one of the main features of the IdeaOps framework. Every new hypothesis should be analysed based on previous experience. Before the investigation process, it’s necessary to look for relative or similar tickets. Për biletën “Rilindja e skenarit të pagesës në faqen e internetit “PaperGone” për të rregulluar krijimin e detyrueshëm të llogarisë në pagesë” ekipi duhet të kërkojë kërkesa të tjera në lidhje me faqen e internetit PaperGone. Ndoshta vitin e kaluar ekipi i shitjeve bëri të njëjtën pyetje, por ne morëm një vendim se krijimi i llogarisë gjatë procesit të pagesës është i detyrueshëm. Ose edhe ne kishim një kërkesë të përfunduar “Shto krijimin e llogarisë për çdo proces blerjeje në faqen e internetit “PaperGone”. Dhe ne mund të mos kemi asnjë nga anëtarët e ekipit në dispozicion të cilët janë përgjegjës për zbatimin, për të pyetur pse kemi miratuar një vendim të tillë. In any case, relative tickets or changes should be added to the new one to start the hypothesis check. These links should not abort the investigation for the ticket, because the market situation may have changed; the suggestion still has to be revised. However, the quality of the research will be drastically improved with an understanding of the whole story. Natyrisht, është e mundur që bileta është krejtësisht unike dhe nuk ka të bëjë me asgjë më parë. ose korniza u krijua jo shumë kohë më parë dhe nuk ka të dhëna në dispozicion. Evidence Gjatë fazës së “Evidencës”, ekipi duhet të ofrojë një hetim bazuar në informacione të lidhura dhe sugjerime aktuale.Idetë e lidhura, të abortuara mund të duken krejtësisht të ndryshme me hipoteza të reja dhe, së bashku, të sjellin një imazh të tërë të ri në fokus. Kjo fazë duhet të sigurojë artefakte të tilla si: Minutat e takimeve me diskutime për zbatimin me palët e interesuara, klientët, klientët potencialë dhe zhvilluesit. hulumtimit të tregut. Ndërfaqja e mock-ups Prova e konceptit (POC) ose rezultatet e testimit A / B. Është e rëndësishme të krijohet një proces vlerësimi dhe të mblidhen të dhëna për kohën e shpenzuar duke punuar në çdo artefakt, pavarësisht nga vendimi për këtë biletë të veçantë, të dhënat e tilla mund të japin njohuri të vlefshme për burimet që duhet të shpenzohen në hetime të ngjashme. Estimation Ekipi duhet të japë një vlerësim të bazuar në prova në disa aspekte: 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. Koha dhe paratë Sa orë nga secili lloj specialist duhet të shpenzojmë për të zbatuar sugjerimin? The idea should go through an estimation process and the total has to be attached to the ticket. Rreziqet Cilat janë rreziqet tona për të zbatuar ose përjashtuar këtë ide? Ndoshta do të humbasim një klient kyç nëse vendosim të mos e zbatojmë këtë tipar. Ose ndoshta po humbasim para çdo ditë me një skenar pagesash që nuk funksionon në faqen tonë të internetit. Disa ide gjithashtu mund të kthehen prapa - ekipi mund të zbatojë një tipar të ri dhe të marrë të ardhura shtesë, por do të ketë probleme me performancën dhe stabilitetin. Ky informacion gjithashtu mund të jetë i dobishëm në të ardhmen gjatë diskutimit se pse një ide e tillë e madhe nuk është zbatuar në produkt. 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. Ka shumë qasje për prioritet, por më e thjeshtë është më mirë, kështu që e mirë e vjetër RFC 2119 punon mirë. Referencë : Clegg, D. (1994). Metoda e rastit Fast-Track: Një qasje RAD. Bradner, S. (1997). Fjalë kyçe për përdorim në RFCs për të treguar nivelet e kërkesave (RFC 2119). Internet Engineering Task Force. Në dispozicion në: https://www.rfc-editor.org/rfc/rfc2119. References: Clegg, D. (1994). Metoda e rastit Fast-Track: Një qasje RAD. Bradner, S. (1997). Fjalë kyçe për përdorim në RFCs për të treguar nivelet e kërkesave (RFC 2119). Internet Engineering Task Force. Në dispozicion në: https://www.rfc-editor.org/rfc/rfc2119. https://www.rfc-editor.org/rfc/rfc2119 Vendimi Faza e rezultateve, bazuar në analizat dhe artefaktet e mëparshme, është faza më e rëndësishme për IdeaOps. Ka disa opsione për mënyrën se si çdo kërkesë mund të përfundojë: Ne do ta bëjmë këtë – është e nevojshme të shkruajmë pse tingëllon si një ide fitimprurëse dhe çfarë na ndihmon të marrim vendimin e duhur. 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. It’s nice, and there is some interest for our company, but not right now – when should we come back to this request so as not to abandon it in a gigantic backlog? What is wrong right now that makes it impossible to make a positive decision? Është mirë nëse e kombinojmë atë me një kërkesë tjetër – le të ndërtojmë një plan për ta rishikuar atë me një kërkesë shtesë dhe formën e këtij procesi. Sigurisht, ka më shumë skenarë, por në këtë artikull dua të tregoj një shembull të të menduarit: Çdo kërkesë duhet të përpunohet gjatë gjithë tubacionit dhe duhet të ketë një rezultat të duhur për të treguar anëtarëve të tjerë aktual ose të ardhshëm të ekipit mënyrën e miratimit të vendimit. Çdo kërkesë duhet të përpunohet gjatë gjithë tubacionit dhe duhet të ketë një rezultat të duhur për të treguar anëtarëve të tjerë aktual ose të ardhshëm të ekipit mënyrën e miratimit të vendimit. People can make mistakes or adopt the wrong decision according to the situation and their knowledge. This process obliges them to document this decision and helps the company to revise and learn based on these requests later. Si të mbledhim idetë Ne kemi mbuluar hapat bazë të kornizës, por për përdorimin e duhur të një backlog të kërkesave të përgjithshme është e nevojshme të ndërtojmë një sistem ruajtjeje që ndihmon çdo anëtar të ekipit të gjejë çdo ide aktive ose të arkivuar në një kohë minimale. Mënyra më e mirë për ta arritur këtë është të prerë të dhënat nëpërmjet një sërë filtrash dhe parametrave. Është shumë e rëndësishme të ruani të gjitha idetë në një hapësirë të unifikuar, të arritshme për ekipe të ndryshme. Teknikisht, është e mundur të përdorni çdo softuer tabelash si ruajtje për kërkesa / ide dhe t'i filtroni ato duke përdorur atributet në kolona, por është më e lehtë dhe më e menaxhueshme të përdorni një produkt të madh për punën në ekip Every request may have different dimensions: produkteve të Domeneve të biznesit Rreziku i biznesit. Funksionaliteti i produktit Request Stage. Burimi i Sa më shumë filtra të jenë në dispozicion për backlog-in e ideve, aq më shumë anëtarë të ekipit me përvojë dhe mënyra të ndryshme të të menduarit mund të lundrojnë nëpër të. Lista e dimensioneve nuk është e plotë dhe ofron vetëm një shembull të mënyrave të shpërbërjes. Unë rekomandoj të organizoni disa sesione të brainstorm për të zbuluar të gjitha filtrat e përshtatshëm për backlog-in dhe për të rinovuar ato herë pas here. Gjithashtu, është e nevojshme të vendosni rregulla për shtimin e opsioneve të filtrit dhe caktimin e një roli të administratorit. Çdo opsion duhet të përbëhet nga një listë e mbyllur e artikujve; përndryshe, e gjithë struktura do të rrëzohet. Çdo aspekt mund të zbulohet si një grup i filtrave; kompleksiteti varet nga një produkt dhe struktura e kompanisë. Product Kompanitë mund të zhvillojnë disa produkte ose gjenerata të produkteve, kështu që çdo biletë duhet të lidhet me produktin, ose platformën e gjenerimit të produktit.Blloku mund të përbëhet nga emrat e produktit: Faqja e internetit, Produkti 1 për SaaS, Produkti 2 për On-Prem, etj. In an earlier example, we mentioned a fictional request, " " në kompaninë PaperGone, kështu që unë do të jap parametrat teorikisht të mundshme për futjen e saktë të kësaj kërkese. Rishikoni skenarin e pagesës në faqen e internetit "PaperGone" për të rregulluar krijimin e detyrueshëm të llogarisë në check-out Domain biznesi Ky atribut duhet të ndihmojë në gjetjen e personit përgjegjës për të përpunuar kërkesën.A është kjo ide për përmirësimet e marketingut, apo është e lidhur me problemet tona në onboarding?A është ajo për funksionalitetin shtesë të produktit që na ndihmon të promovojmë klientët aktual?Domaini i biznesit është një atribut kryesor për të drejtuar kërkesat përmes departamenteve dhe menaxherëve të ndryshëm.Shembuj: Shitje, Marketing, Mbështetje për klientët, Kontabilitet, Zhvillim, QA, etj. Rreziku i biznesit Every request may cover a different company risk. Some of them may reveal architectural flaws in product infrastructure, or something connected with sales and competitors. The author of the request should realise what the most suitable option is. This dimension is about possible problems in something: sales (cannot sell without it), upselling (cannot grow current accounts without it), security (potential exploit concern), competitors (something that we don’t have), legal (our agreement forms are not so good). Product functionality Për të rritur produkte komplekse, është e nevojshme të dini se çfarë jeni duke menaxhuar. produktet e një kompanie përbëhen nga dhjetëra karakteristika, dhe kërkesat e reja mund të jenë përmirësime për disa prej tyre ose të lidhura me diçka ekzistuese. Mënyra për të arritur këtë dekompozim është përshkruar në artikull - "https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition". Mënyra për të arritur këtë dekompozim është përshkruar në artikull - "https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition". Request stage Helps to locate the current status of a request according to the IdeaOps workflow. An example of the stage structure: I ri - askush nuk e ka përpunuar kërkesën. Për të vlerësuar - kërkesa kalon nëpër fazat e Lidhjeve, Provat, Vlerësimet. 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. Angazhuar - faza e zhvillimit, e cila kërkon është në procesin e realizimit. Mbyllur - faza përfundimtare për të treguar përfundimin e kërkesës. Sigurisht, në varësi të procesit, është e mundur të zgjerohet struktura e fazave për të pasqyruar procesin në një mënyrë më të detajuar, por është gjithmonë e nevojshme të gjendet një ekuilibër midis transparencës dhe burokracisë së tepruar. Source Ide mund të krijohen nga aktorë të ndryshëm, dhe koha e përpunimit mund të ndryshojë në varësi të burimit. Për shembull: Pjesëmarrësit, Klientët, Shitjet, Inxhinierët e Mbështetjes së Klientit, Zhvilluesit. Ky sistem i parametrave ndihmon për të gjetur çdo kërkesë të re ose të kaluar me kohë minimale; megjithatë, në të njëjtën kohë, ajo mund të jetë një pengesë për anëtarët e ekipit sepse komplikon mënyrën se si idetë ndahen. How to implement the framework Si me çdo teori, pjesa më e komplikuar është integrimi i kornizës IdeaOps në proceset e përditshme të një kompanie.Natyrisht, proceset duhet të përshtaten, rishikohen, ose vetëm pjesërisht të përdoren në përputhje me strukturën e kompanisë, por ideja e përgjithshme është që të ndihmojë për të siguruar përpunimin më të mirë të biletave se sa kishte më parë, dhe madje edhe një pjesë e kornizës do ta bëjë këtë mirë. Megjithatë, në çdo kompani, ekziston një listë e mbyllur e pengesave që duhet të merren me to. Askush nuk e di se si dhe pse të krijojë bileta në "rrugën e duhur". There’s a lot of discussions in meetings or via messengers that are not reflected in the idea work item. Disa burime nuk mund të sigurojnë të dhëna të strukturuara përmes një sistemi të centralizuar të backlog. Let’s cover them step by step. Mësoni anëtarët e ekipit se si të punojnë me një backlog të përgjithshëm Krijoni një biletë kërkesë template dhe jepni një shembull. Modelet mund të përshkruhen në dokumentacionin e kompanisë ose madje të zhvillohen në softuer (Atlassian Jira ose Microsoft Azure DevOps janë të përkryer me ta). Pjesët e punës të kërkimit të ri duhet të përbëhen nga fushat dhe parametrat e nevojshme me shënime të kërkuara dhe të panevojshme, kështu që mund të jetë e pamundur të përjashtohet të dhënat e rëndësishme. The examples should establish the standards of naming and content structure. Publikoni idetë / kërkesat e rrjedhës së punës, në mënyrë që të gjithë të kuptojnë se çfarë do të thotë çdo fazë. Transmetoni një mesazh se ky template është e vetmja mënyrë për të paraqitur kërkesën. opsionalisht, nëse struktura e ekipit nuk është e komplikuar, ajo mund të justifikohet përmes një takimi. 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 Është e natyrshme të diskutohet tema në mesazhe, përmes email-it ose në takime, sepse është e shpejtë dhe e frytshme. megjithatë, ideja e një kornize për të ruajtur të gjitha të dhënat në një vend, për të qenë në gjendje të hyni në të dhënat përsëri dhe përsëri, për të mësuar dhe analizuar atë, është e rëndësishme. 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. Për çdo takim rreth kërkesës, duhet të krijohen minuta takimi.Në epokën e asistentëve të AI, kjo nuk është aq e komplikuar dhe ndihmon shumë në analizat e mëtejshme. Çdo kërkesë në çdo fazë duhet t'i caktohet një anëtari të ekipit i cili do të jetë përgjegjës për fiksimin e të gjitha artefakteve të rëndësishme.Po, disa negociata ende mund të humbasin në diskutime private, por ekzistenca e një facilitatorit të përgjithshëm për çdo kërkesë ndihmon në drejtimin e të dhënave në ruajtje. Zgjidhja e skenarëve kufitarë Ka gjithmonë skenarë ku një sistem i centralizuar i backlog nuk funksionon. Ndoshta kjo është një kërkesë nga një pronar shumë i zënë i aksioneve, ose partnerët që nuk mund të kenë qasje në sistemin e brendshëm. Dhe kjo është në rregull. Ekipi thjesht duhet të zbulojë të gjitha këto skenarë dhe të gjejë një mënyrë se si t'i drejtojë ato në ato standarde. The requests from a stock owner should be processed by one of the product leads in X time. This role has to create the request and collect the necessary data by themselves. Kërkesat e partnerëve duhet të përpunohen nga menaxherët e llogarisë ose mbështetja teknike, në varësi të rolit të partnerëve. Si zakonisht në krijimin e proceseve të reja, është e rëndësishme të dokumentohen dhe të deklarohen të gjitha hapat në dokumentet publike për të rregulluar marrëveshjet dhe detajet e vogla. Metoda e suksesit Implementation of the new process requires a lot of time and effort, so a few metrics could help to track its adoption. Kohëzgjatja e njohjes Një nga objektivat kryesore të kornizës IdeaOps është përpunimi i ideve nga fillimi i tyre deri në një vendim të analizuar.Kjo metrikë tregon numrin e ditëve nga krijimi deri në arritjen e një nga gjendjet e vendimit dhe ndihmon për të zbuluar qëllimet e mëposhtme organizative: Shpejtësia e përgjigjeve për klientët ose palët e interesuara në ekipe të ndryshme. Number of stuck responses whose processing time exceeds the established limits. Tregohet marrëdhënia midis plotësisë dhe cilësisë së të dhënave të ofruara fillimisht dhe kohës së nevojshme për të përpunuar një kërkesë. Indirekt tregon se si prania e kërkesave të lidhura me vlerësimet e dhënë më parë në ide të ngjashme përshpejton marrjen e vendimeve. Koha e shpenzuar metrikë 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. Niveli i mbulimit Tregohet plotësia e backlog kërkesës. është e nevojshme për të rritur nivelin metrike me kërkesa të reja dhe të vjetra për të arritur një bazë ideale të propozimeve. What has to be dealt with Gjatë adoptimit, disa probleme duhet të kapërcehen: Anëtarët e ekipit duhet të dinë se përdorimi i hapësirave personale për shënime është një praktikë e keqe, e cila çon në humbjen e të dhënave të rëndësishme të kompanisë. Nëse ndonjë Artifakt Proof of Concept është krijuar ose një ide është vlerësuar, të gjitha numrat që lidhen me punën e përfunduar dhe aktivitetet e ardhshme duhet të përfshihen në kërkesë. Një vendim pa një përshkrim nuk ndihmon në të ardhmen.Një ide e refuzuar mund të përpunohet dhe të konsiderohet nga të gjitha anët, por pa një konkluzion të duhur, është thjesht një humbje kohe.Ideja e ardhshme e ngjashme do të kërkojë të njëjtën sasi kohe për përpunim, sepse rezultatet e mëparshme nuk tregojnë arsyen e vërtetë të refuzimit, kështu që kompania do të humbasë vazhdimisht para, veçanërisht nëse struktura e ekipit ndryshon me kalimin e kohës. The adoption manager has to provide regular reviews of closed and stuck requests to improve the process. Konkludimi Korniza e propozuar IdeaOps është një mënyrë idealiste për të përpunuar një sasi të madhe të të dhënave të ndryshme dhe nganjëherë të pakuptueshme në një strukturë të menaxhueshme. Ajo kërkon punë të koordinuar mirë në ekip ku çdo anëtar e kupton se çdo pjesë e të dhënave dhe vendimi është diçka më e madhe, që një ditë mund të ndihmojë për të arritur lartësi të reja për biznesin dhe për të përmirësuar situatën e përgjithshme të kompanisë. Pasi të përpunohen siç duhet, dhe madje edhe të refuzohen, një propozim i parëndësishëm nga një nga klientët mund të përfshihet në një ndryshim të përgjithshëm në strategjinë e produktit, sepse përmban një analizë të qartë të situatës, vlerësime dhe disa konkluzione të zgjuar se pse nuk ishte e rëndësishme Puna në katalogun e ideve është po aq e rëndësishme sa puna në të ardhurat, dhe është në dorë të çdo kompanie të ndjekë rrugën për ta përmirësuar atë.
