아이디어의 비용은 무엇입니까?이 아이디어는 가치가 있습니까, 아니면 구현하기 전에 아무것도 아닙니까? 제품 개발 관리는 아이디어와 가설을 통해 구축됩니다. 제품 팀은 시장 요구 또는 변동에 신속하게 반응해야합니다. 제품 가치, 수익 또는 자본을 증가시키기 위해 모든 결정을 내려야합니다. 한편, 조사 과정은 최소한의 자원으로 수행되어야합니다. 이 사막의 가설은 다른 측면과 연결될 수 있다: Hypotheses in this avalanche may be connected with different aspects: New marketing strategies. 새로운 특징들 새로운 시장 또는 니치에 적응. 새로운 제품을 처음부터 만들기 위한 연구. 그럼에도 불구하고 가정의 다양성에도 불구하고, 추후 분석은 하나의 제품 틈새에있는 아이디어의 전체 백고가 무한하지 않음을 보여줄 수 있습니다. 아이디어는 시스템없이 개인 노트 또는 회사 채팅에서 개발 될 수 있으며 팀 구성원의 회전 후 팀은 이전 경험을 고려하지 않고 동일한 조사를 제공합니다.이 아이디어는 팀이나 회사 성장의 변화에 관계없이 시장에 대한 통찰력을 저장하고 축적하고 제공하는 적절한 프레임 워크가 필요합니다.이 실용적인 시스템은 아이디어가 많은 비용을 입증하고 제품 관리자가 시간과 회사 자원을 절약하는 데 도움이 될 수 있음을 증명합니다. 제품 개발을 위한 IdeaOps 제품 프레임 워크로서 "IdeaOps"이라는 용어는 Katherine R. Lieber의 쇼 "Rebellious Businesses"에서 처음으로 소개되었습니다. 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. 이 기사에서는 원래 용어의 아이디어를 보완하는 개인적인 제품 개발 경험을 공유합니다. 제품 프레임 워크로서의 "IdeaOps"이라는 용어는 Katherine R. Lieber의 쇼 "Rebellious Businesses"에서 처음으로 소개되었습니다. podcaster 에피소드 "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 이 기사에서는 원래 용어의 아이디어를 보완하는 개인적인 제품 개발 경험을 공유합니다. 프레임 워크의 핵심은 모든 가설이 회사의 자산이라는 것을 깨닫는 것입니다. 이 자산에는 소유자, 아이디어의 전체 맥락, 조사 과정에서 생성 된 유물, 다른 자산과 결정을위한 링크 및 상태가 있어야합니다.아래에 설명 된 권장 사항은 가정의 채택 또는 거부에 고정하는 것뿐만 아니라 전체 추적 과정을 생각의 역사, 시간과 간헐적 인 결과로 보여주는 과정의 필요성을 밝힐 것입니다. 다른 프레임 워크와 마찬가지로, 주요 측면은 기사에서 소개됩니다 : 아이디어 수집의 과정을 구축하는 방법. 아이디어를 저장하는 방법 프레임워크를 어떻게 구현할 것인가. 변화의 성공과 가치를 측정하는 방법 아이디어 수집의 과정을 어떻게 구축합니까? 이 과정은 다가오는 변경 요청에 대한 일반적이고 잘 사용된 권장 사항을 따릅니다.Every idea has to go through a pipeline: 창조의 컨텍스트 왼쪽 증거를 Estimation. 의사결정 창조 모든 아이디어는 규칙에 따라 회사 인프라 내에서 캡처해야합니다. 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. 아래의 과장된 예제에서 나는 "다른 몇 백만 달러를 벌자"와 같은 아이디어가 핵심적으로 훌륭하지만 그 과정에 대한 쓸모없는 제안을 제공하는 분해 프로세스를 제공합니다.그러나 고객의 여행에 문제가 있기 때문에 새로운 지불 작업 흐름에 대한 티켓을 만드는 것이 좋습니다. Ticket should be created in unified software and available for other team members 다른 팀의 제품 관리자는 자신의 로컬 공간이나 개인 노트 앱에서 아이디어를 백고로 유지할 수 있습니다.이것은 전혀 백고가없는 것보다 낫지만 "큰 그림"을 분석 할 수없는 수많은 형식으로 이어집니다. 프레임 워크 적응 중에 모든 통찰력에 대한 통합 저장소를 구축하는 것이 중요합니다.It is better to use some large corporate product where it is easier to link artifacts during idea investigation, such as Microsoft Azure DevOps or Atlassian Jira (develop team processes에 따라). 통합된 소프트웨어는 다음 요구 사항을 충족해야합니다: 회사 계정에 따라 모든 팀 멤버에게 사용할 수 있습니다.It also helps with rights management and control during team rotation. Suitable for customisation. For tailoring the framework to company needs, it’s necessary to have the opportunity to create additional fields or custom statuses. 앞서 언급했듯이 아이디어는 회사의 자산이 되어야 한다.그것은 주요 저장소의 적절한 유지 보수를 의미한다. Ticket should be named properly 아이디어 / 티켓이 회사의 자산이기 때문에 팀은 이러한 자산을 올바르게 분류하고 저장하는 방법을 배워야합니다 (아래에 몇 가지 조언이 제공됩니다). 티켓을 만드는 동안, 특히 비기술적 기여자에 대한 경우, 이름을 놓치고 "웹사이트 개선"과 같은 티켓을 만들 수 있습니다. 티켓은 컨텍스트 섹션에서 잘 설명 될 수 있지만, 미래의 로그에 대해 제목에 추가 정보를 제공하는 것이 필요합니다. 티켓 제목은 고유해야하며 주요 제안을 포함해야합니다. 티켓에는 다른 팀이 이해할 수 있도록 징조 문구나 어두운 약어가 포함되어서는 안됩니다. 티켓 제목은 구조에 의해 구축되어야합니다 : YYY에서 XXX를 만들려면 ZZZ를 변경하십시오; 즉, 개체, 주제 및 결과를 포함합니다. 그럼에도 불구하고 실제 생활에서이 규칙은 유토피아처럼 들릴 수 있습니다.이 때문에 티켓 작업 흐름은 수사 중에 명칭 수정을 포함해야합니다. 가상의 회사 "PaperGone"와의 예 : 웹사이트 개선하기 -> » “ 'PaperGone' 웹 사이트의 지불 시나리오를 다시 작성하여 체크 아웃시 필수 계좌 생성을 수정하십시오. Here we are targeting a few aspects from the beginning: "PaperGone"웹 사이트를 고칠 필요가 있습니다 (우리가 몇 개의 웹 사이트를 가질 수 있기 때문에 처음부터 올바른 사이트를 찾는 것이 좋습니다). The request is about improvement of the payment process. 제목은 지불 중 과도한 계좌 생성 문제를 보여줍니다. Context 티켓에는 제품 팀이 제안을 처리해야 하는 이유에 대한 설명이 포함되어야 합니다. 회사 프로세스에 따라 컨텍스트 아르테파크가 필요하거나 선택적일 수 있습니다. 가능한 컨텍스트 정보 목록: 일반적인 설명 : 그것은 무엇에 관한 것입니까? 왜 우리는 그것을 조사해야합니까? 시장 변화, 고객 요청 또는 기타 트리거에 관한 정보를 포함할 수 있습니다. 출처: 고객 편지, 인터뷰, 보고서 또는 공공 소스의 뉴스의 복사본. 사용자 스토리(사용 가능한 경우): 타겟 시청자 및 개선 시나리오를 공개합니다. 컨텍스트가 더 상세할수록 아이디어 팀이 조사 과정에서 긍정적 인 결정을 내릴 가능성이 높아집니다. Links 이것은 IdeaOps 프레임워크의 주요 기능 중 하나입니다.모든 새로운 가설은 이전의 경험을 바탕으로 분석되어야합니다.조사 과정 전에 관련 또는 유사한 티켓을 찾아야합니다. 티켓 “PaperGone 웹사이트에서 지불 시나리오를 다시 작성하여 체크 아웃시 필수 계좌 생성을 해결하십시오”에 대한 팀은 PaperGone 웹사이트에 대한 다른 요청을 검색해야합니다. 어쩌면 작년에 판매 팀이 같은 질문을 했지만 우리가 지불 프로세스 중 계정 생성이 의무적이라는 결정을 내렸을 수도 있습니다.또는 "PaperGone"웹 사이트의 모든 구매 프로세스에 대해 계정 생성을 추가"라는 완료 요청을 받았을 수도 있습니다.그리고 우리는 실행에 대한 책임이있는 팀 구성원 중 누구도 사용할 수 없으며, 왜 우리가 그러한 결정을 내렸는지 묻지 않을 수도 있습니다.또는 팀 중 하나가 의무 계정 생성을 제거하려고 시도했으며 제품 팀은 매우 중요한 마케팅 이메일을 보내고 변경 사항을 취소하기 위해 사용자 데이터의 감소를 알았습니다. 어쨌든 상대 티켓 또는 변경은 새로운 티켓에 추가되어야합니다.이 링크는 티켓에 대한 조사를 중단해서는 안되며, 시장 상황이 바뀌었을 수 있습니다.이 제안은 여전히 수정되어야합니다.그러나 전체 이야기를 이해하면 연구의 품질이 크게 향상됩니다. 물론 티켓이 완전히 독특하고 이전에 아무것도 관련이 없을 수도 있습니다.또는 프레임 워크는 오래 전에 설립되었으며 데이터가 없습니다.이 경우 티켓 프로세스의 나중 단계에서 적절한 첨부 파일과 완전한 정보를 제공하여 미래에 작업을 개선해야합니다. Evidence "증거"단계에서 팀은 관련 정보와 현재의 제안을 기반으로 한 조사를 제공해야합니다.연결 된, 낙태 된 아이디어는 새로운 가설과 완전히 다른 모습을 보일 수 있으며, 함께, 전체 새로운 그림을 초점을 맞출 수 있습니다. 이 단계는 다음과 같은 유물을 제공해야합니다 : Meeting minutes with discussions about implementation with stakeholders, customers, potential clients, and developers. 시장 연구 Interface mock-ups. Proof of Concept (POC) or results of A/B testing. 이 특정 티켓에 대한 결정에 상관없이, 그러한 데이터는 유사한 조사에 지출해야 하는 자원에 대한 귀중한 통찰력을 제공할 수 있습니다. Estimation 팀은 몇 가지 측면에서 증거를 기반으로 한 평가를 제공해야합니다. 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. 시간과 돈 각 종류의 전문가가 제안을 구현하기 위해 얼마나 많은 시간을 할애해야합니까? 아이디어는 추정 과정을 거쳐야하며 총액은 티켓에 첨부되어야합니다. Risks 이 아이디어를 실행하거나 무시하는 우리의 위험은 무엇입니까? 어쩌면 우리는이 기능을 구현하지 않기로 결정하면 핵심 클라이언트를 잃을 수도 있습니다.또는 어쩌면 우리는 웹 사이트에서 잘못된 지불 시나리오로 매일 돈을 잃고 있습니다.일부 아이디어는 또한 새로운 기능을 구현하고 추가 수입을받을 수 있습니다.하지만 성능과 안정성 문제가 있습니다.이 때문에 다른 관점에서 제안을 조사하고 문서화해야합니다. 이 정보는 또한 제품에 왜 그런 훌륭한 아이디어가 구현되지 않았는지 논의하는 동안 미래에 유용 할 수 있습니다. 우선순위 이 아이디어가 제품이나 비즈니스에 얼마나 중요한가?이 추정 매개 변수는 어려운 하나이며 제품 전략의 정확성에 따라 달라집니다.그러나 잘 제공된 "증거"단계는 확립된 규칙과 조사된 데이터를 기반으로 우선 순위를 계산하는 데 도움이 될 수 있습니다. 우선 순위에 대한 접근 방식은 많지만, 간단한 것이 더 좋으므로 좋은 오래된 RFC 2119은 잘 작동합니다. 참조 : Clegg, D. (1994). 케이스 방법 빠른 트랙 : RAD 접근. 브래드너, S. (1997). RFC에서 요구 수준을 나타내기 위해 사용하는 키워드 (RFC 2119). 인터넷 엔지니어링 작업 그룹. 사용할 수 있습니다: https://www.rfc-editor.org/rfc/rfc2119. References: Clegg, D. (1994). 케이스 방법 빠른 트랙 : RAD 접근. 브래드너 S. (1997년) (RFC 2119) 인터넷 엔지니어링 작업 그룹. . RFC에서 요구 수준을 나타내기 위해 사용하는 키워드 https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119 결정 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 can end: We will do this – it’s necessary to write why it sounds like a profitable idea and what helps us to make the right decision. Also, this comment may be useful for later analysis if the result was worth what was expected. It will help to reveal our misunderstandings and improve decision-making. 어쩌면 일부 데이터가 잘못 수집되었거나 결과 가치가 낮았을 수도 있습니다.그러나 제품 관리자는 거부에 대한 상세한 의견을 작성해야합니다.일부 미래의 요청에서이 특정 요청이 과도한 것으로 나타날 수 있지만, 큰 그림에서 다시 생각하면 제품 관리자의 우려가 해결 될 수 있습니다. 그것은 좋고, 우리 회사에 대한 관심이 있지만, 지금은 아닙니다 - 우리는이 요청에 언제 다시 돌아가서 거대한 좌절로 그것을 포기하지 않아야합니까? 다른 요청과 결합하면 좋습니다 - 추가 요청과이 프로세스의 형태로 그것을 수정하기위한 계획을 구축하자. 물론, 더 많은 시나리오가 있지만,이 기사에서 나는 생각의 예를 보여주고 싶습니다 : 모든 요청은 전체 파이프라인을 통해 처리되어야 하며 다른 현재 또는 미래 팀 구성원에게 결정을 채택하는 방법을 보여주는 적절한 결과를 가져야 합니다. 모든 요청은 전체 파이프라인을 통해 처리되어야 하며 다른 현재 또는 미래 팀 구성원에게 결정을 채택하는 방법을 보여주는 적절한 결과를 가져야 합니다. 사람들은 상황과 그들의 지식에 따라 실수를하거나 잘못된 결정을 내릴 수 있습니다.이 과정은 그들이이 결정을 문서화하도록 강요하고 회사가 나중에 이러한 요청에 근거하여 검토하고 배울 수 있도록 도와줍니다. How to store ideas 우리는 프레임워크의 기본 단계를 다루었지만 일반적인 요청 백록을 적절하게 사용하려면 팀 구성원이 최소한의 시간 내에 활성화된 아이디어를 찾을 수 있도록 도와주는 저장 시스템을 구축하는 것이 필요합니다.이를 달성하는 가장 좋은 방법은 필터와 매개 변수를 사용하여 데이터를 절단하는 것입니다. 모든 아이디어를 단일 공간에 저장하는 것이 매우 중요하며 다른 팀에 접근 할 수 있습니다. 기술적으로는 모든 태블릿 소프트웨어를 요청 / 아이디어의 저장소로 사용할 수 있으며 열에 속성을 사용하여 필터링 할 수 있지만 Atlassian Jira 또는 Microsoft Azure DevOps와 같은 팀 작업을위한 대형 제품을 사용하는 것이 더 쉽고 관리할 수 있습니다.이 제품은 작업 흐름, 적절한 단계 관리 및 역할 기반 액세스 각 요청은 다른 차원을 가질 수 있습니다 : Product. Business domain. 비즈니스 위험 제품의 기능성 단계 요청 출처 아이디어 백록에 대한 필터가 더 많을수록 다양한 경험과 사고 방식을 가진 팀 구성원들이 그것을 통해 탐색할 수 있습니다. 차원 목록은 완전하지 않으며 분해 방법의 예일뿐입니다. 나는 모든 적합한 필터를 공개하고 때때로 업데이트하기 위해 몇 번의 브레인스턴 세션을 구성하는 것이 좋습니다. 또한 필터 옵션을 추가하고 관리자 역할을 할당하는 규칙을 설정해야합니다. 각 옵션은 항목의 닫힌 목록으로 구성되어야합니다. 각 측면은 필터 그룹으로 공개 될 수 있습니다; 복잡성은 제품과 회사의 구조에 달려 있습니다. 제품 회사는 몇 가지 제품 또는 제품 세대를 개발할 수 있으므로 모든 티켓은 제품 또는 제품 생성 플랫폼에 연결되어야합니다.이 블록은 제품 이름으로 구성될 수 있습니다 : 웹 사이트, SaaS 용 제품 1, On-Prem 용 제품 2, 등 또는 플랫폼을 찾는 데 도움이됩니다 : Frontend, Backend, iOS / iPadOS, Android. 이전 예제에서 우리는 가상의 요청을 언급했습니다. " "PaperGone 회사에서, 그래서 나는 이 요청의 올바른 입력을위한 이론적으로 가능한 매개 변수를 제공 할 것입니다. 'PaperGone' 웹 사이트의 지불 시나리오를 다시 작성하여 체크 아웃시 필수 계좌 생성을 수정하십시오. Business domain 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. Business risk 각 요청은 다른 회사 위험을 다룰 수 있습니다.그들 중 일부는 제품 인프라의 건축적 결함, 또는 판매와 경쟁자와 관련된 무언가를 밝힐 수 있습니다.이 요청의 저자는 가장 적합한 옵션이 무엇인지 깨달아야합니다.이 차원은 무언가의 가능한 문제에 관한 것입니다 : 판매 (그것 없이 판매할 수 없습니다), 업셀링 (그것없이 현재 계좌를 성장할 수 없습니다), 보안 (잠재적 착취 우려), 경쟁자 (우리가 가지고 있지 않은 무언가), 법적 (우리의 계약 양식은 그렇게 좋지 않습니다). Product functionality 회사의 제품은 수십 가지 기능으로 구성되며, 새로운 요청은 그들 중 일부에 대한 개선이거나 기존의 무언가와 관련이있을 수 있습니다.이 제품의 일부 부분에 대한 수요 수준을 실현하거나 가장 문제가있는 영역을 찾기 위해 기능 을 통해 들어오는 아이디어를 정렬하는 데 도움이됩니다. The way to achieve this decomposition is described in the article - “ ”. https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition 이 분해를 달성하는 방법은 기사에서 설명됩니다 - " ”. https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition 요청 단계 IdeaOps 작업 흐름에 따라 요청의 현재 상태를 찾는 데 도움이 됩니다.Helps to locate the current status of a request according to the IdeaOps workflow. 단계 구조의 예 : 새로운 - 아무도 요청을 처리하지 않았습니다. To estimate - the request goes through Links, Evidence, Estimation stages. 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. 종료 - 요청의 완료를 나타내는 최종 단계. 물론, 프로세스에 따라 단계 구조를 확장하여 프로세스를보다 상세하게 반영 할 수 있지만 투명성과 과도한 관료주의 사이의 균형을 찾는 것이 항상 필요합니다. 출처 아이디어는 다른 배우들에 의해 생성될 수 있으며, 처리 시간은 출처에 따라 달라질 수 있습니다.예: Stakeholders, Customers, Sales, Customer Support Engineers, Developers. 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 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. 어떻게 그리고 왜 "옳은 방법"으로 티켓을 만드는지 아무도 모릅니다. 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. 그들을 단계별로 다루자. 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). 새로운 요청 작업 항목은 필요한 필드와 매개 변수와 필요한 및 불필요한 표시로 구성되어 있어 중요한 데이터를 놓칠 수 없을 수 있습니다. The examples should establish the standards of naming and content structure. 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. 채택 단계는 수십 개의 특별 사례를 드러낼 것이며, 몇 번의 반복 후에 팀은 새로운 과정을 구현할 것입니다. Fix communication outside the request It’s natural to discuss topics in messengers, via email or in meetings, because it’s fast and prolific. Nevertheless, the idea of a framework to store all data in one place, to be able to access data again and again, to learn and analyse it, is important. Still, there are a few ways to fix the process: 각 모임 또는 메시지 체인은 요청 티켓 ID와 관련되어 있어야 하므로 나중에 요청의 고유 식별 번호를 기반으로 활동을 찾을 수 있습니다. 요청에 관한 각 회의마다 회의 분기가 만들어져야 합니다.AI 조수의 시대에, 그것은 그렇게 복잡하지 않으며 더 많은 분석에 도움이됩니다. 각 단계의 각 요청은 모든 중요한 유물의 고정에 대한 책임이 있는 팀 멤버에게 할당되어야 합니다.예, 일부 협상은 여전히 개인 토론에서 잃어버릴 수 있지만, 각 요청에 대한 일반적인 촉진자의 존재는 데이터를 저장소로 안내하는 데 도움이 됩니다. Borderline 시나리오 해결 There are always scenarios where a centralised backlog system doesn’t work. Maybe that’s a request from a very busy stock owner, or the partners that cannot have access to the internal system. And that is okay. The team just has to reveal all these scenarios and find a way how to route them into the standard ones. As an example: 주식 소유자의 요청은 X 시간에 제품 리드 중 하나에 의해 처리되어야 합니다.이 역할은 요청을 생성하고 필요한 데이터를 스스로 수집해야 합니다. 파트너의 요청은 파트너의 역할에 따라 계정 관리자 또는 기술 지원에 의해 처리되어야 합니다.The team should choose the nearest starting point to start the process. As usual in establishing new processes, it is important to document and declare all steps in public documentation to fix agreements and small details. 성공 메트릭스 새로운 프로세스의 구현은 많은 시간과 노력이 필요하므로 몇 가지 매개 변수는 채택을 추적하는 데 도움이 될 수 있습니다. 시간의 통찰력 One of the major goals of the IdeaOps framework is to process ideas from their inception to an analysed decision. This metric shows the number of days from creation to reaching one of the decision states and helps to reveal the following organisational goals: 다른 팀에서 고객이나 이해 관계자에 대한 응답의 속도. 정해진 제한을 초과하는 처리 시간을 차지한 응답 수. 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. 간접적으로, 이전에 제공된 비슷한 아이디어에 대한 예상과 관련된 요청의 존재가 결정을 가속화하는 방법을 보여줍니다. 시간 낭비 metric 이해할 수 있고 올바른 요청은 관리자가 그들을 처리하는 데 걸리는 시간을 최소화해야 합니다. 전체적인 처리 시간을 측정하기 위해 "시간-to-insight" 메트릭이 제안되며, 이는 프로세스 자체와 관련이 있습니다. 그러나이 프로세스에 참여한 책임있는 관리자의 근무 시간을 측정하는 것이 중요합니다. 물론 일부 아이디어는 몇 주간의 조사가 필요하지만 일부는 단추의 색깔에 불과합니다. 그러나 분기 또는 연간 평균 값은 여전히 시간에 대한 개선을 드러낼 수 있습니다. 더 많은 요청이 연결된 추정과 상세한 결정을 가지고 있다면 매니저 당 전체적인 처리 시간에 영향을 미칩니다. 커버 레벨 요청 백록의 완전성을 보여줍니다.It is necessary to raise the metric level with new and old requests to an ideal base of proposals. 요청 백록의 완전성을 보여줍니다.It is necessary to raise the metric level with new and old requests to an ideal base of proposals. 무엇을 다루어야 하는가 입양 과정에서 몇 가지 문제를 극복해야합니다 : 팀원들은 메모를 위한 개인 공간을 사용하는 것이 나쁜 관행이라는 점을 알아야 하며, 이는 중요한 회사 데이터의 손실을 초래할 수 있다.무엇이든지 문서화되어야 한다면 요청에 있어야 한다. If any Proof of Concept artefact was created or an idea was estimated, all numbers related to completed work and future activities should be included in the request. Otherwise, this time may be lost and spent without reusability. 설명이없는 결정은 미래에 도움이되지 않습니다. 거부 된 아이디어는 모든 측면에서 처리되고 고려 될 수 있지만 적절한 결론이 없으면 시간 낭비 일뿐입니다.다음 유사한 아이디어는 과거의 결과가 거부의 진정한 이유를 보여주지 않기 때문에 처리하는 데 동일한 시간을 필요로 할 것입니다. 입양 매니저는 절차를 개선하기 위해 종료 및 붙어있는 요청에 대한 정기적 인 리뷰를 제공해야합니다. Conclusion 제안된 IdeaOps 프레임워크는 다양한 때로는 이해할 수없는 데이터의 대량을 관리 가능한 구조로 처리하는 이상적인 방법입니다.모든 구성원이 데이터와 결정의 각 조각이 더 큰 것이며, 언젠가는 비즈니스를위한 새로운 높이에 도달하고 회사의 전반적인 상황을 개선하는 데 도움이 될 수 있다는 것을 이해하는 잘 조정된 팀워크가 필요합니다.일단 적절하게 처리되거나 심지어는 거부되면 고객 중 한 명의 소중한 제안이 제품 전략의 일반적인 변화에 포함될 수 있습니다.이 제품에는 상황에 대한 명확한 분석, 추정 및 독립적 인 개선으로서 중요한 것이 아니라 새로운 시장 상황에서 완전히 다른 것처럼 보이는 이유에 대한 현명한 결론이 포함되어 있기 때문에이 결정이 적절하게 문서화되고 재사용되 아이디어 카탈로그에 대한 작업은 수익에 대한 작업만큼이나 중요하며, 각 회사가 그것을 향상시키는 길을 따라야합니다.
