IdeaOps: ทําไมทุกคําขอเป็นสินทรัพย์ของ บริษัท ในการพัฒนาผลิตภัณฑ์

ค่าใช้จ่ายของความคิดคืออะไร? พวกเขามีคุณค่าหรือไม่หรือพวกเขาไม่มีอะไรก่อนที่จะดําเนินการ การจัดการการพัฒนาผลิตภัณฑ์ถูกสร้างขึ้นบนแนวคิดและ hypotheses ทีมผลิตภัณฑ์ควรตอบสนองอย่างรวดเร็วต่อความต้องการหรือการสั่นสะเทือนของตลาดใด ๆ การตัดสินใจใด ๆ ควรจะถูกทําเพื่อเพิ่มมูลค่าผลิตภัณฑ์รายได้หรือมูลค่าทุน ในขณะเดียวกันกระบวนการวิจัยควรจะทําด้วยทรัพยากรขั้นต่ํา ซึ่งหมายความว่าการหลั่งของแนวคิดในเวลาหรือการขาดทุนงบประมาณ hypotheses ในลาวน์นี้สามารถเชื่อมโยงกับแง่มุมที่แตกต่างกัน: กลยุทธ์การตลาดใหม่ ลักษณะใหม่ การปรับตัวให้เข้ากับตลาดหรือนิชใหม่ การวิจัยเพื่อสร้างผลิตภัณฑ์ใหม่จากจุดเริ่มต้น อย่างไรก็ตามแม้จะมีความหลากหลายของแนวโน้มการวิเคราะห์แบบย้อนกลับอาจแสดงให้เห็นว่าความอุดมสมบูรณ์ของแนวคิดในหนึ่งผลิตภัณฑ์ไม่สิ้นสุดได้ ความคิดอาจพัฒนาขึ้นในบันทึกส่วนบุคคลหรือการแชทของ บริษัท โดยไม่ต้องใช้ระบบและหลังจากการหมุนสมาชิกในทีมทีมทีมจะให้การสํารวจเดียวกันโดยไม่คํานึงถึงประสบการณ์ก่อนหน้านี้ แนวคิดเหล่านี้ต้องมีโครงสร้างที่เหมาะสมสําหรับการเก็บรวบรวมและให้ข้อมูลเกี่ยวกับตลาดโดยไม่คํานึงถึงการเปลี่ยนแปลงในการเติบโตของทีมหรือ บริษัท ระบบที่มีประสิทธิภาพนี้พิสูจน์ให้เห็นว่าแนวคิดมีค่าใช้จ่ายมากและอาจช่วยให้ผู้จัดการผลิตภัณฑ์ประหยัดเวลาและทรัพยากรของ บริษัท IdeaOps สําหรับการพัฒนาผลิตภัณฑ์ คําว่า “IdeaOps” เป็นกรอบผลิตภัณฑ์ถูกนํามาใช้ครั้งแรกสําหรับฉันในงานแสดง “Business Rebellious” โดย Katherine R. Lieber ในบท 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 ในบทความนี้ฉันแบ่งปันประสบการณ์การพัฒนาผลิตภัณฑ์ส่วนบุคคลของฉันซึ่งเสริมความคิดของคําศัพท์เดิม คําว่า “IdeaOps” เป็นกรอบผลิตภัณฑ์ครั้งแรกถูกนํามาใช้กับฉันในการแสดง “Businesses Rebellious” ของ Katherine R. Lieber ในส่วน 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 ในบทความนี้ฉันแบ่งปันประสบการณ์การพัฒนาผลิตภัณฑ์ส่วนบุคคลของฉันซึ่งเสริมความคิดของคําศัพท์เดิม หลักของกรอบคือการตระหนักถึงว่าทุก hypothesis เป็นสินทรัพย์ของ บริษัท สิ่งอํานวยความสะดวกนี้ควรมีเจ้าของทั้งหมดของแนวคิดสิ่งอํานวยความสะดวกที่สร้างขึ้นในระหว่างกระบวนการวิจัยการเชื่อมโยงกับสิ่งอํานวยความสะดวกอื่น ๆ และสถานะของการตัดสินใจ คําแนะนําที่อธิบายไว้ด้านล่างจะแสดงให้เห็นถึงความจําเป็นของกระบวนการที่มีความสําคัญอย่างมากไม่เพียง แต่ที่จะแก้ไขการยอมรับหรือปฏิเสธ hypothesis แต่ยังแสดงให้เห็นถึงกระบวนการติดตามทั้งหมดด้วยประวัติของความคิดเวลาที่ใช้จ่ายและผลลัพธ์ที่สม่ําเสมอ เช่นเดียวกับกรอบอื่น ๆ ชิ้นส่วนหลักจะนําเสนอในบทความ: วิธีการสร้างกระบวนการของการรวบรวมความคิด วิธีการจัดเก็บความคิด How to implement the framework. วิธีการวัดความสําเร็จและความคุ้มค่าของการเปลี่ยนแปลง วิธีการสร้างกระบวนการของการรวบรวมความคิด กระบวนการนี้ตามคําแนะนําทั่วไปและใช้กันอย่างดีสําหรับคําขอการเปลี่ยนแปลงในอนาคต แต่ละความคิดต้องผ่านท่อ: การสร้าง กรณี Links. หลักฐาน การประเมิน การตัดสินใจ การสร้าง ทุกความคิดต้องถูกจับภาพภายในโครงสร้างพื้นฐานของ บริษัท ตามกฎ: For every idea or request, a unique ticket should be created บางครั้งความคิดอาจมีความซับซ้อนและต้องมีการแก้ไขผลิตภัณฑ์หรือวิธีการตลาดเอง มันเป็นสิ่งจําเป็นที่จะสอนทีมงานวิธีการทําลายทุก hypothesis เป็นการปรับปรุงที่มีคุณค่า แต่สามารถแยกได้ สิ่งนี้อาจสร้างการอ้างอิงเพิ่มเติมและลดจํานวนความคิด - ถ้ามันเป็นเรื่องยากที่จะเป็นทางการบางสมาชิกของทีมอาจหลีกเลี่ยงการแก้ไขความคิด ในทางตรงกันข้ามมันช่วยในการกรองคําแนะนําดิบที่ยากที่จะเข้าใจและประเมิน ในระหว่างกระบวนการสร้างกรอบจําเป็นต้องประเมินความเข้ากันได้ของทีมเพื่อหาสมดุล ในตัวอย่างที่มากเกินไปด้านล่างฉันให้ขั้นตอนการทําลายซึ่งแนวคิดเช่น "ให้เราทําเงินหลายล้านดอลลาร์เพิ่มเติม" เป็นความคิดที่ยอดเยี่ยม แต่เป็นคําแนะนําที่ไม่พึงประสงค์สําหรับกระบวนการ อย่างไรก็ตามก็ดีที่จะสร้างตั๋วเกี่ยวกับกระบวนการชําระเงินใหม่เพราะเราได้สังเกตเห็นปัญหาเกี่ยวกับการเดินทางของลูกค้า นี่คือตั๋วของเรา Ticket should be created in unified software and available for other team members ผู้จัดการผลิตภัณฑ์จากทีมงานที่แตกต่างกันอาจเก็บความคิดของพวกเขาไว้ในพื้นที่ท้องถิ่นของตัวเองหรือแม้กระทั่งแอพบันทึกส่วนตัว มันดีกว่าการขาดการปิดผนึกทั้งหมด แต่นําไปสู่รูปแบบมากมายและไม่สามารถวิเคราะห์ "ภาพขนาดใหญ่" ได้ 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). ซอฟต์แวร์ร่วมกันควรตอบสนองความต้องการ: สามารถใช้ได้กับสมาชิกทีมใด ๆ โดยบัญชีองค์กร นอกจากนี้ยังช่วยในการจัดการสิทธิ์และการควบคุมระหว่างการหมุนของทีม เหมาะสําหรับการปรับแต่ง เพื่อปรับแต่งกรอบเพื่อตอบสนองความต้องการของ บริษัท จําเป็นต้องมีโอกาสในการสร้างฟิลด์เพิ่มเติมหรือสถานะที่กําหนดเอง ตรวจสอบโดย บริษัท ดังกล่าวข้างต้นความคิดควรกลายเป็นสินทรัพย์ของ บริษัท หมายความว่าการบํารุงรักษาที่เหมาะสมของคลังสินค้าหลัก Ticket should be named properly เนื่องจากความคิด / ตั๋วเป็นสินทรัพย์ของ บริษัท ทีมงานต้องเรียนรู้วิธีการจัดประเภทและจัดเก็บสินทรัพย์เหล่านี้อย่างถูกต้อง (และคําแนะนําบางอย่างจะให้ด้านล่าง) หนึ่งในพารามิเตอร์ที่สําคัญที่สุดคือชื่อ ในระหว่างการสร้างตั๋วโดยเฉพาะอย่างยิ่งสําหรับผู้มีส่วนร่วมที่ไม่ใช่ทางเทคนิคชื่ออาจถูกหลีกเลี่ยงและตั๋วเช่น "ปรับปรุงเว็บไซต์" อาจถูกสร้าง ตั๋วอาจถูกอธิบายอย่างดีในส่วนบรรทัดฐาน แต่สําหรับบันทึกในอนาคตจําเป็นต้องให้ข้อมูลเพิ่มเติมในชื่อ นั่นคือเหตุผลที่มันจะดีกว่าที่จะสร้างกฎบางอย่าง: ชื่อตั๋วควรเป็นเอกลักษณ์และรวมถึงคําแนะนําหลัก ตั๋วไม่ควรประกอบด้วยคําอธิบายหรือคําอธิบายที่ซับซ้อนเพื่อให้สามารถเข้าใจได้กับทีมที่แตกต่างกัน ชื่อตั๋วควรจะสร้างขึ้นตามโครงสร้าง: เพื่อ XXX ใน YYY เพื่อเปลี่ยน ZZZ; กล่าวอีกนัยหนึ่งมีวัตถุหัวข้อและผลลัพธ์ อย่างไรก็ตามในชีวิตจริงกฎนี้อาจดูเป็นยูทิลิตี้ นั่นคือเหตุผลที่กระบวนการทํางานของตั๋วควรรวมถึงการแก้ไขชื่อในระหว่างการตรวจสอบ ตัวอย่างที่มี บริษัท จินตนาการ "PaperGone": Improve the website -> " » ทําซ้ําสถานการณ์การชําระเงินบนเว็บไซต์ 'PaperGone' เพื่อแก้ไขการสร้างบัญชีที่บังคับเมื่อชําระเงิน ที่นี่เราจะมุ่งเน้นไปที่บางแง่มุมจากจุดเริ่มต้น: มันเป็นสิ่งจําเป็นที่จะแก้ไขเว็บไซต์ "PaperGone" (เพราะเราอาจมีเว็บไซต์ไม่กี่เว็บไซต์และมันเป็นสิ่งที่ดีที่จะค้นหาที่ถูกต้องจากจุดเริ่มต้น) คําขอเกี่ยวกับการปรับปรุงกระบวนการชําระเงิน ชื่อแสดงให้เห็นถึงปัญหาการสร้างบัญชีมากเกินไปในระหว่างการชําระเงิน Context ตั๋วควรมีคําอธิบายว่าทําไมทีมผลิตภัณฑ์ต้องประมวลผลข้อเสนอแนะ ขึ้นอยู่กับกระบวนการของ บริษัท artefacts กรณีอาจจําเป็นหรือเป็นตัวเลือก รายชื่อข้อมูลพื้นฐานที่เป็นไปได้: General description: what is it about? Why should we investigate it? May contain information about market changes, customer requests or other triggers. แหล่งที่มา: คัดลอกของจดหมายลูกค้าการสัมภาษณ์รายงานหรือข่าวจากแหล่งที่สาธารณะ User Stories (if applicable): to reveal target audience and scenarios to improve. ขั้นตอนที่รายละเอียดยิ่งขึ้นความน่าจะเป็นมากขึ้นที่ทีมงานความคิดจะดําเนินการเพื่อตัดสินใจเชิงบวกในระหว่างการตรวจสอบ Links นี่เป็นหนึ่งในคุณสมบัติหลักของกรอบ IdeaOps ทุก hypothesis ใหม่ควรจะวิเคราะห์ขึ้นอยู่กับประสบการณ์ก่อนหน้านี้ ก่อนกระบวนการวิจัยจําเป็นต้องมองหาตั๋วที่เกี่ยวข้องหรือคล้ายกัน สําหรับตั๋ว “รีไซเคิลสถานการณ์การชําระเงินบนเว็บไซต์ “PaperGone” เพื่อแก้ไขการสร้างบัญชีที่บังคับเมื่อทําการชําระเงิน” ทีมควรค้นหาคําขออื่น ๆ เกี่ยวกับเว็บไซต์ 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. ในกรณีใด ๆ ตั๋วที่เกี่ยวข้องหรือการเปลี่ยนแปลงควรจะถูกเพิ่มลงในใหม่เพื่อเริ่มต้นการตรวจสอบ hypothesis การเชื่อมโยงเหล่านี้ไม่ควรทําลายการสํารวจสําหรับตั๋วเพราะสถานการณ์ในตลาดอาจมีการเปลี่ยนแปลง ข้อเสนอแนะยังคงต้องมีการแก้ไข อย่างไรก็ตามคุณภาพของการวิจัยจะปรับปรุงอย่างมากด้วยความเข้าใจของเรื่องทั้งหมด แน่นอนว่ามันเป็นไปได้ว่าตั๋วเป็นเอกลักษณ์อย่างสมบูรณ์และไม่เกี่ยวข้องกับอะไรก่อน หรือกรอบได้รับการจัดตั้งไม่นานที่ผ่านมาและไม่มีข้อมูลที่มีอยู่ ในกรณีนี้จําเป็นต้องให้แถบแนบที่เหมาะสมและข้อมูลที่สมบูรณ์ในขั้นตอนหลังของกระบวนการของตั๋วเพื่อปรับปรุงการทํางานในอนาคต Evidence ในขั้นตอน "หลักฐาน" ทีมงานควรให้การสํารวจขึ้นอยู่กับข้อมูลที่เกี่ยวข้องและข้อเสนอแนะปัจจุบัน ความคิดที่เชื่อมโยงและล้มเหลวอาจดูแตกต่างกันอย่างสมบูรณ์ด้วย hypotheses ใหม่และร่วมกันนําภาพใหม่ทั้งหมดไปสู่ความสําคัญ ขั้นตอนนี้ควรให้ artefacts เช่น: โปรแกรมการประชุมที่มีการสนทนาเกี่ยวกับการใช้งานกับผู้มีส่วนร่วมลูกค้าลูกค้าลูกค้าและนักพัฒนา การวิจัยตลาด อินเตอร์เฟซ mock-ups Proof of Concept (POC) or results of A/B testing. มันเป็นสิ่งสําคัญที่จะสร้างกระบวนการประเมินและรวบรวมข้อมูลเกี่ยวกับเวลาที่ใช้ในการทํางานกับแต่ละสิ่งประดิษฐ์ ไม่ว่าการตัดสินใจเกี่ยวกับตั๋วนี้ข้อมูลดังกล่าวสามารถให้ความเข้าใจที่มีค่าเกี่ยวกับทรัพยากรที่ต้องใช้ในการตรวจสอบที่คล้ายคลึงกัน Estimation Team should provide estimation based on evidence in a few aspects: 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. เวลาและเงิน หลายชั่วโมงของแต่ละชนิดของผู้เชี่ยวชาญเราควรใช้เวลาในการประยุกต์ใช้คําแนะนํา The idea should go through an estimation process and the total has to be attached to the ticket. Risks ความเสี่ยงในการใช้หรือลืมความคิดนี้คืออะไร บางทีเราอาจสูญเสียลูกค้าที่สําคัญถ้าเราตัดสินใจที่จะไม่ใช้คุณลักษณะนี้ หรือบางทีเราจะสูญเสียเงินทุกวันด้วยสถานการณ์การชําระเงินที่ผิดปกติบนเว็บไซต์ของเรา ความคิดบางอย่างอาจกลับไฟ - ทีมงานอาจใช้คุณลักษณะใหม่และได้รับรายได้เพิ่มเติม แต่จะมีปัญหาเกี่ยวกับประสิทธิภาพและเสถียรภาพ นั่นคือเหตุผลที่จําเป็นต้องตรวจสอบและเอกสารข้อเสนอแนะจากมุมมองที่แตกต่างกัน ข้อมูลนี้อาจเป็นประโยชน์ในอนาคตในระหว่างการอภิปรายเกี่ยวกับเหตุผลที่ความคิดที่ยอดเยี่ยมเช่นนี้ไม่ได้ใช้ในผลิตภัณฑ์ ความสําคัญ ความสําคัญของแนวคิดนี้สําหรับผลิตภัณฑ์หรือธุรกิจทั้งหมดหรือไม่ พารามิเตอร์การประเมินนี้เป็นพารามิเตอร์ที่ยากลําบากและขึ้นอยู่กับความถูกต้องของกลยุทธ์ผลิตภัณฑ์ อย่างไรก็ตามขั้นตอน "หลักฐาน" ที่จัดให้ดีอาจช่วยในการคํานวณความสําคัญตามกฎที่กําหนดและข้อมูลที่ได้รับการตรวจสอบ There’re many approaches to priority, but simpler is better, so good old RFC 2119 works fine. คําอธิบาย: Clegg, D. (1994). Method Case Fast-Track: A RAD Approach. Addison-Wesley Bradner, S. (1997). คําสําคัญสําหรับการใช้งานใน RFCs เพื่อระบุระดับความต้องการ (RFC 2119). Internet Engineering Task Force. สามารถใช้ได้ที่: https://www.rfc-editor.org/rfc/rfc2119. References: Clegg, D. (1994). อดิสสัน-เวสเลย์ Case Method Fast-Track: A RAD Approach บาดเนอร์ S. (1997) (RFC 2119) ทีมงานวิศวกรรมอินเทอร์เน็ต สามารถใช้ได้ที่: . คําสําคัญสําหรับใช้ใน RFCs เพื่อระบุระดับความต้องการ https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119 การตัดสินใจ ขั้นตอนผลลัพธ์, ขึ้นอยู่กับการวิเคราะห์ก่อนหน้านี้และวัตถุประสงค์, เป็นขั้นตอนที่สําคัญที่สุดสําหรับ IdeaOps. ตามกรอบ, คําวิจารณ์ผลลัพธ์ให้มุมมองทั่วไปสําหรับอนาคต. มีตัวเลือกบางอย่างเกี่ยวกับวิธีที่แต่ละคําขออาจสิ้นสุดลง: เราจะทําเช่นนี้ - มันเป็นสิ่งจําเป็นที่จะเขียนว่าทําไมมันฟังดูเหมือนเป็นความคิดที่มีผลกําไรและสิ่งที่ช่วยให้เราตัดสินใจที่ถูกต้อง นอกจากนี้ความคิดเห็นนี้อาจเป็นประโยชน์สําหรับการวิเคราะห์ในภายหลังถ้าผลลัพธ์เป็นมูลค่าที่คาดหวัง มันจะช่วยเปิดเผยความเข้าใจผิดของเราและปรับปรุงการตัดสินใจ แน่นอนว่ามันไม่คุ้มค่า - ดี แต่ทําไม? บางทีข้อมูลบางอย่างถูกเก็บรวบรวมไม่ถูกต้องหรือค่าผลลัพธ์ต่ํา อย่างไรก็ตามผู้จัดการผลิตภัณฑ์ต้องเขียนความคิดเห็นรายละเอียดเกี่ยวกับการปฏิเสธ ในคําขอในอนาคตบางอย่างอาจแสดงให้เห็นว่าคําขอนี้เป็นเรื่องไม่จําเป็น แต่ถ้าเราคิดอีกครั้งในภาพใหญ่ความกังวลของผู้จัดการผลิตภัณฑ์อาจได้รับการแก้ไข มันดีและมีความสนใจบางอย่างสําหรับ บริษัท ของเรา แต่ไม่ในขณะนี้ - เมื่อเราควรกลับไปที่คําขอนี้เพื่อไม่ให้ทิ้งไว้ในความล้มเหลวขนาดใหญ่? สิ่งที่ไม่ถูกต้องในขณะนี้ที่ทําให้เป็นไปไม่ได้ที่จะตัดสินใจเชิงบวก It’s good if we combine it with another request – let’s build a plan to revise it with an additional request and the form of this process. แน่นอนว่ามีสถานการณ์อื่น ๆ แต่ในบทความนี้ฉันต้องการแสดงตัวอย่างของการคิด: ทุกคําขอต้องได้รับการประมวลผลตลอดท่อและควรมีผลที่เหมาะสมเพื่อแสดงให้สมาชิกในทีมปัจจุบันหรือในอนาคตคนอื่น ๆ วิธีการตัดสินใจ ทุกคําขอต้องได้รับการประมวลผลตลอดท่อและควรมีผลที่เหมาะสมเพื่อแสดงให้สมาชิกในทีมปัจจุบันหรือในอนาคตคนอื่น ๆ วิธีการตัดสินใจ ผู้คนอาจทําข้อผิดพลาดหรือตัดสินใจผิดขึ้นอยู่กับสถานการณ์และความรู้ของพวกเขา กระบวนการนี้บังคับให้พวกเขาจดหมายการตัดสินใจนี้และช่วยให้ บริษัท ตรวจสอบและเรียนรู้ตามคําขอเหล่านี้ในภายหลัง วิธีการสร้างความคิด เราได้ครอบคลุมขั้นตอนพื้นฐานของกรอบ แต่สําหรับการใช้งานที่เหมาะสมของ backlog คําขอทั่วไปจําเป็นต้องสร้างระบบจัดเก็บข้อมูลที่ช่วยให้สมาชิกทีมใด ๆ ค้นหาความคิดที่ใช้งานหรือจัดเก็บในเวลาที่ต่ําสุด วิธีที่ดีที่สุดในการทําเช่นนี้คือการตัดข้อมูลผ่านชุดตัวกรองและพารามิเตอร์ มันเป็นสิ่งสําคัญมากที่จะจัดเก็บความคิดทั้งหมดในพื้นที่เดียวที่สามารถเข้าถึงได้สําหรับทีมต่าง ๆ โดยทางเทคนิคมันเป็นไปได้ที่จะใช้ซอฟต์แวร์แผ่นงานใด ๆ เป็นการจัดเก็บสําหรับคําขอ / ความคิดและกรองพวกเขาโดยใช้คุณสมบัติในคอลัมน์ แต่ใช้งานผลิตภัณฑ์ขนาดใหญ่สําหรับงานทีมเช่น Atlassian Jira หรือ Microsoft Azure DevOps เป็นเรื่องง่ายและสามารถจัดการได้มากขึ้น ผลิตภัณฑ์เหล่านี้สามารถช่วยในการจัดระเบียบกระบวนการทํางานการจัดการขั้นตอนที่เหมาะสมและการควบคุมการเข้าถึงตามบทบาท ทุกคําขออาจมีขนาดที่แตกต่างกัน: Product. โดเมนธุรกิจ ความเสี่ยงทางธุรกิจ ฟังก์ชั่นของผลิตภัณฑ์ ขั้นตอนการร้องขอ แหล่งที่มา ตัวกรองมากขึ้นที่มีอยู่สําหรับ backlog ความคิดสมาชิกทีมที่มีประสบการณ์และความคิดที่แตกต่างกันมากขึ้นสามารถนําทางผ่านรายการมิติไม่สมบูรณ์และเป็นเพียงตัวอย่างของวิธีของการทําลาย ฉันขอแนะนําให้จัดระเบียบการบิดเบิร์มเซสชั่นไม่กี่ครั้งเพื่อเปิดเผยตัวกรองที่เหมาะสมทั้งหมดสําหรับ backlog และอัปเดตพวกเขาเป็นครั้งคราว นอกจากนี้ยังจําเป็นต้องกําหนดกฎสําหรับการเพิ่มตัวเลือกตัวกรองและกําหนดบทบาทผู้ดูแลระบบ ตัวเลือกแต่ละตัวต้องประกอบด้วยรายการที่ปิด; มิฉะนั้นโครงสร้างทั้งหมดจะแตกออก ลองสแกนผ่านตัวอย่างของขนาด ทุกแง่มุมอาจถูกเปิดเผยเป็นกลุ่มของตัวกรอง ความซับซ้อนขึ้นอยู่กับผลิตภัณฑ์และโครงสร้างของ บริษัท ผลิตภัณฑ์ Companies may develop few products or generations of products, so any ticket should be connected to the product, or platform of product generation. This block may consist of product names: Website, Product 1 for SaaS, Product 2 for On-Prem, etc. Or help to locate the platform: Frontend, Backend, iOS/iPadOS, Android. ในตัวอย่างก่อนหน้านี้เราได้กล่าวถึงคําขอจินตนาการ " in the PaperGone company, so I will provide theoretically possible parameters for the correct entry of this request. ทําซ้ําสถานการณ์การชําระเงินบนเว็บไซต์ 'PaperGone' เพื่อแก้ไขการสร้างบัญชีที่บังคับเมื่อชําระเงิน โดเมนธุรกิจ คุณสมบัตินี้ควรจะช่วยในการค้นหาผู้รับผิดชอบในการประมวลผลคําขอ เป็นความคิดเกี่ยวกับการปรับปรุงการตลาดหรือเกี่ยวข้องกับปัญหาของเราในการเข้าสู่ระบบหรือไม่ หรือเป็นเรื่องเกี่ยวกับฟังก์ชั่นผลิตภัณฑ์เพิ่มเติมที่ช่วยให้เราส่งเสริมลูกค้าปัจจุบันหรือไม่ โดเมนธุรกิจเป็นคุณสมบัติหลักในการส่งคําขอผ่านแผนกและผู้จัดการที่แตกต่างกัน ตัวอย่าง: การขาย, การตลาด, การสนับสนุนลูกค้า, การบัญชี, การพัฒนา, QA ฯลฯ ความเสี่ยงทางธุรกิจ แต่ละคําขออาจครอบคลุมความเสี่ยงของ บริษัท อื่น ๆ บางส่วนอาจแสดงข้อบกพร่องทางสถาปัตยกรรมในโครงสร้างพื้นฐานผลิตภัณฑ์หรือสิ่งที่เกี่ยวข้องกับการขายและคู่แข่ง ผู้เขียนคําขอควรตระหนักถึงตัวเลือกที่เหมาะสมที่สุด มิตินี้เป็นเรื่องเกี่ยวกับปัญหาที่เป็นไปได้ในบางสิ่งบางอย่าง: การขาย (ไม่สามารถขายได้โดยไม่มีมัน) การขาย (ไม่สามารถเติบโตบัญชีปัจจุบันได้โดยไม่มีมัน) ความปลอดภัย (ความกังวลเกี่ยวกับการใช้ประโยชน์ที่เป็นไปได้) ผู้แข่งขัน (บางสิ่งที่เราไม่มี) กฎหมาย (รูปแบบสัญญาของเราไม่ดี) ฟังก์ชั่นผลิตภัณฑ์ ในการเติบโตผลิตภัณฑ์ที่ซับซ้อนจําเป็นต้องรู้ว่าคุณจัดการอะไร ผลิตภัณฑ์ของ บริษัท ประกอบด้วยคุณสมบัติหลายสิบและคําขอใหม่อาจเป็นการปรับปรุงบางส่วนของพวกเขาหรือเกี่ยวข้องกับบางสิ่งที่มีอยู่ มันช่วยให้มากในการจัดเรียงความคิดที่มาผ่านทางฟันเล็ตคุณสมบัติเพื่อรับรู้ระดับความต้องการสําหรับบางส่วนของผลิตภัณฑ์หรือเพื่อหาพื้นที่ที่มีปัญหามากที่สุด วิธีที่จะบรรลุการทําลายนี้จะอธิบายไว้ในบทความ - “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 ตัวอย่างของโครงสร้างขั้นตอน: New - nobody has processed the request. เพื่อประเมิน - คําขอผ่านขั้นตอนการเชื่อมโยงหลักฐานการประเมิน 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. มุ่งมั่น - ขั้นตอนการพัฒนาที่ต้องการอยู่ในกระบวนการของการทําความเข้าใจ ปิด - ขั้นตอนสุดท้ายเพื่อแสดงให้เห็นถึงการเสร็จสิ้นการร้องขอ แน่นอนว่าขึ้นอยู่กับกระบวนการก็เป็นไปได้ที่จะขยายโครงสร้างขั้นตอนเพื่อสะท้อนถึงกระบวนการในรายละเอียดมากขึ้น แต่ก็เป็นสิ่งจําเป็นเสมอที่จะหาความสมดุลระหว่างความโปร่งใสและความจูงใจมากเกินไป แหล่งที่มา 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. 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. วิธีการใช้กรอบ 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. แหล่งที่มาบางอย่างไม่สามารถให้ข้อมูลแบบโครงสร้างได้ผ่านระบบ backlog แบบศูนย์กลาง ลองครอบคลุมพวกเขาขั้นตอนตามขั้นตอน สอนสมาชิกทีมวิธีการทํางานกับ backlog โดยทั่วไป สร้างตั๋วคําขอเทมเพลตและให้ตัวอย่าง แม่แบบสามารถอธิบายได้ในเอกสารของ บริษัท หรือแม้กระทั่งพัฒนาในซอฟต์แวร์ (Atlassian Jira หรือ Microsoft Azure DevOps ดีกับพวกเขา) รายการงานคําขอใหม่ควรประกอบด้วยฟิลด์และพารามิเตอร์ที่จําเป็นพร้อมกับเครื่องหมายที่จําเป็นและไม่จําเป็นเพื่อให้เป็นไปไม่ได้ที่จะพลาดข้อมูลที่สําคัญ ตัวอย่างควรกําหนดมาตรฐานของชื่อและโครงสร้างเนื้อหา Publish the idea/request workflow, so everyone can understand what each stage means. ส่งข้อความว่าเทมเพลตนี้เป็นวิธีเดียวในการส่งคําขอ ตัวเลือกถ้าโครงสร้างทีมไม่ซับซ้อนสามารถพิสูจน์ได้ผ่านการประชุม 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. ขั้นตอนการยอมรับจะเปิดเผยสิบกรณีพิเศษและหลังจากทําซ้ําเพียงไม่กี่ครั้งทีมงานจะใช้กระบวนการใหม่ แก้ไขการสื่อสารนอกคําขอ 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: 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. For every meeting about the request, meeting minutes have to be created. In the era of AI assistants, it’s not so complicated and helps a lot in further analysis. ทุกคําขอในแต่ละขั้นตอนต้องถูกกําหนดให้เป็นสมาชิกในทีมซึ่งจะรับผิดชอบในการแก้ไขสิ่งประดิษฐ์ที่สําคัญทั้งหมด ใช่การเจรจาบางอย่างยังคงอาจหายไปในการสนทนาส่วนตัว แต่การมีตัวช่วยทั่วไปสําหรับแต่ละคําขอจะช่วยให้ข้อมูลเข้าสู่การจัดเก็บ แก้ไขสถานการณ์ 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: 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. คําขอของพันธมิตรควรได้รับการประมวลผลโดยผู้จัดการบัญชีหรือฝ่ายสนับสนุนทางเทคนิคขึ้นอยู่กับบทบาทของพันธมิตร ทีมควรเลือกจุดเริ่มต้นที่ใกล้ที่สุดเพื่อเริ่มต้นกระบวนการ เช่นเดียวกับการสร้างกระบวนการใหม่ก็เป็นสิ่งสําคัญที่จะเอกสารและประกาศขั้นตอนทั้งหมดในเอกสารสาธารณะเพื่อแก้ไขข้อตกลงและรายละเอียดเล็ก ๆ Success metrics Implementation of the new process requires a lot of time and effort, so a few metrics could help to track its adoption. Time-to-insight หนึ่งในวัตถุประสงค์หลักของกรอบ IdeaOps คือการประมวลผลความคิดจากจุดเริ่มต้นจนถึงการตัดสินใจที่ได้รับการวิเคราะห์ เมทริกี้แสดงจํานวนวันตั้งแต่การสร้างจนถึงการเข้าถึงสถานะการตัดสินใจและช่วยเปิดเผยเป้าหมายทางองค์กรต่อไปนี้: ความเร็วในการตอบสนองให้กับลูกค้าหรือผู้มีส่วนร่วมในทีมต่างๆ จํานวนการตอบสนองที่ติดอยู่ซึ่งเวลาในการประมวลผลเกินขีด จํากัด ที่กําหนด 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. แสดงให้เห็นว่าการปรากฏตัวของคําขอที่เกี่ยวข้องที่มีการคาดการณ์ก่อนหน้านี้เกี่ยวกับความคิดที่คล้ายคลึงกันเร่งการตัดสินใจ เวลาใช้เมตริก คําขอที่เข้าใจได้และถูกต้องควรลดเวลาที่ผู้จัดการใช้ในการประมวลผลคําขอ หมายเลข “เวลาเข้าถึง” ถูกนําเสนอเพื่อวัดเวลาประมวลผลโดยรวมซึ่งเกี่ยวข้องกับกระบวนการเอง อย่างไรก็ตามยังเป็นสิ่งสําคัญที่จะวัดเวลาทํางานของผู้จัดการที่รับผิดชอบที่เข้าร่วมกระบวนการนี้ แน่นอนบางแนวคิดต้องมีการสํารวจเป็นสัปดาห์ในขณะที่บางประการเป็นเพียงสีของปุ่ม แต่ค่าเฉลี่ยต่อสี่เหลี่ยมหรือต่อปียังสามารถช่วยในการแสดงให้เห็นถึงการปรับปรุงในเวลาที่ใช้จ่าย หากคําขอมากขึ้นและมากขึ้นมีการประเมินและตัดสินใจรายละเอียดที่เกี่ยวข้องมันจะส่งผลต่อเวลาประมวลผลโดยรวมต่อผู้จัดการ Coverage Level แสดงให้เห็นถึงความสมบูรณ์ของ backlog คําขอ มันเป็นสิ่งจําเป็นที่จะเพิ่มระดับเมตริกด้วยคําขอใหม่และเก่าเพื่อให้บรรลุฐานการเสนอแนะที่เหมาะ สิ่งที่ต้องจัดการกับ ในระหว่างการ adoption จะต้องเอาชนะปัญหาบางอย่าง: 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. 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. A decision without a description doesn’t help in the future. A rejected idea may be processed and considered from all sides, but without a proper conclusion, it’s just a waste of time. The next similar idea will require the same amount of time for processing, because previous results don’t show the true reason for rejection, so the company will constantly lose money, especially if the team structure changes over time. ผู้จัดการการยอมรับต้องให้การตรวจสอบอย่างสม่ําเสมอของคําขอปิดและติดเพื่อปรับปรุงกระบวนการ ข้อสรุป กรอบ IdeaOps ที่นําเสนอเป็นวิธีที่เหมาะในการประมวลผลจํานวนมากของข้อมูลที่แตกต่างกันและบางครั้งไม่เข้าใจได้เป็นโครงสร้างที่สามารถจัดการได้ มันต้องมีการทํางานร่วมกันอย่างดีซึ่งแต่ละสมาชิกเข้าใจว่าแต่ละชิ้นของข้อมูลและการตัดสินใจเป็นสิ่งที่ใหญ่กว่าซึ่งในวันหนึ่งอาจช่วยให้ธุรกิจเข้าถึงระดับสูงใหม่และปรับปรุงสถานการณ์โดยรวมของ บริษัท เมื่อมีการประมวลผลอย่างถูกต้องและแม้กระทั่งปฏิเสธข้อเสนอที่ไม่สําคัญจากลูกค้าหนึ่งอาจรวมอยู่ในการเปลี่ยนแปลงโดยทั่วไปในกลยุทธ์ผลิตภัณฑ์เพราะมีวิเคราะห์ที่ชัดเจนของสถานการณ์ประมาณการและข้อสรุปที่ฉลาดบางอย่างเกี่ยวกับเหตุผลที่ว่าทําไมมันไม่ได้เป็นสิ่งสําคัญในการปรับปรุงที่เป็นอิสระ แต่ดูแตกต่างกันอย่างสมบูรณ์ในสถานการณ์ตลาดใหม่ และถ้าการตัดสินใจนี้ได้รับการบันทึกและนํามาใช้ใหม่อย่างถูกต้องหมายความว่าความคิดเล็กน้อยใด ๆ การทํางานเกี่ยวกับแคตตาล็อกความคิดเป็นสิ่งสําคัญเช่นเดียวกับการทํางานเกี่ยวกับรายได้และขึ้นอยู่กับ บริษัท แต่ละคนที่จะทําตามเส้นทางในการปรับปรุง