เคล็ดลับสำหรับผู้จัดการผลิตภัณฑ์: เชื่อมโยง Backlog ของผลิตภัณฑ์กับ Product Vision

หนึ่งในความท้าทายอย่างต่อเนื่องสำหรับทีมพัฒนาแบบ Agile ที่ใช้ผลิตภัณฑ์เป็นหลักคือการทำแผนที่สิ่งที่พวกเขากำลังทำ 'ตอนนี้' กับสิ่งที่ผลิตภัณฑ์ควรจะมีรูปร่างขึ้นในอีก 2-3 ปีข้างหน้า

มันไม่ได้เกี่ยวกับทีมที่ไม่รู้ว่าพวกเขากำลังทำอะไรอยู่แต่เกี่ยวกับข้อเท็จจริงที่ว่าพวกเขาอาจจดจ่อกับงานในแต่ละวันมากเกินไป ซึ่งมักจะบ่อนทำลายความอ่อนไหวของผลกระทบของงาน 'ปัจจุบัน' ในภาพ รวม การตัดสินใจหรือทางเลือกระหว่างการดำเนินการในปัจจุบันอาจมีผลกระทบอย่างมากในอนาคต โดยเฉพาะอย่างยิ่งเมื่อผลิตภัณฑ์มีการพัฒนา

มาดูตัวอย่างชีวิตจริงกัน

ฉันเป็นส่วนหนึ่งของทีมที่คล่องตัวซึ่งพยายาม แนะนำบริการแปลข้อความสำหรับเนื้อหาไซต์ มีการตัดสินใจและใช้เครื่องมือแปลด้วยคอมพิวเตอร์ของบริษัทอื่น อย่างไรก็ตาม แผนงานผลิตภัณฑ์ได้กล่าวถึงในท้ายที่สุดว่า ในอนาคต ผู้ใช้ควรสามารถแก้ไขและจัดเตรียมการแปลตามบริบทของตนเองได้ ซึ่งหมายความว่าความ สามารถในการแปลควรมีปัญญาประดิษฐ์ เพื่อให้สามารถเรียนรู้ได้เองโดยอิงจากคำติชม
จากการพัฒนานี้ ทางเลือกที่ทำขึ้นจึงไม่เหมาะ ดังนั้นจึงจำเป็นต้องทำใหม่ในระดับที่ยุติธรรม เนื่องจากภาพรวมไม่ได้เชื่อมโยงกับสิ่งที่ทีมเปรียวได้รับมอบหมายในการวิ่ง

อาจมีคนโต้แย้งได้ว่าทีมต่างๆ สามารถใช้ความพยายามอย่างมีสติในการรับข้อมูลนี้ แต่ประเด็นก็คือ เหตุใดจึงไม่สามารถบันทึกเป้าหมาย 'ระยะยาว' เหล่านี้ไว้ในเครื่องมือและแดชบอร์ดที่คล่องตัวที่มีอยู่ได้

ทีมที่คล่องตัวดำเนินงานที่กำหนดไว้อย่างดีและเฉพาะเจาะจงในวัฏจักรการพัฒนา แต่นั่นหมายความว่ามันต้องแลกมาด้วยค่าใช้จ่ายในการไม่สนใจวิวัฒนาการผลิตภัณฑ์หรือไม่? ไม่ ฉันไม่คิดอย่างนั้น

จากสิ่งที่ฉันรู้ ไม่มีเครื่องมือหรือกรอบงานด่วนใด ๆ ที่สนับสนุนหรือแนะนำข้อมูลนี้ให้กับทีมที่คล่องตัว ในการทำงานประจำวันของพวกเขา แต่สามารถสร้างมุมมองดังกล่าวในมุมมองที่มีอยู่ได้หรือไม่ คุ้มค่าที่จะลอง? มาดูกันว่าเราจะทำได้อย่างไร

เราจะเริ่มต้นด้วยสิ่งประดิษฐ์ทั่วไปใน Agile – Product Backlog
จากข้อมูลของ SCRUM Institute งานในมือคือรายการสิ่งที่ต้องทำในโครงการ สิ่งเหล่านี้อาจรวมถึงการปรับปรุงและ/หรือข้อบกพร่องอย่างใดอย่างหนึ่ง รายการลำดับเลขไม่มีประโยชน์เว้นแต่ทีมจะรู้ว่าโครงสร้างลำดับความสำคัญของรายการคืออะไร นี่คือที่ที่ เจ้าของผลิตภัณฑ์ เข้ามาซึ่งมีหน้าที่รับผิดชอบโดยรวมในการทำงานร่วมกับผู้มีส่วนได้ส่วนเสียเพื่อให้ได้ข้อกำหนดที่ชัดเจน แก้ไขการพึ่งพาระหว่างกัน และรับรายการที่มีลำดับความสำคัญสูงสำหรับรายการงานค้างของผลิตภัณฑ์

เป็นไปได้ว่าในระหว่างกระบวนการนี้ รายการงานที่มีขนาดใหญ่กว่าและต้องพึ่งพากันจะถูกแยกย่อยเป็นส่วนเล็กๆ เพื่อให้ง่ายต่อการพัฒนาสำหรับทีม รายการงานในมือของผลิตภัณฑ์เหล่านี้ถูกแบ่งออกเป็นชิ้นเล็ก ๆ และดำเนินการในรอบการวิ่งตั้งแต่สองถึงสี่สัปดาห์ เพื่อตอบองค์ประกอบ 'วิธี' ของการพัฒนาผลิตภัณฑ์

ในทางกลับกัน รายการสินค้าในมือที่ยังค้างอยู่จะถูกจับคู่กับ "ทิศเหนือจริง" ของผลิตภัณฑ์ซึ่งมักเรียกว่าเป็น วิสัยทัศน์ของผลิตภัณฑ์ นี่คือสถานะที่ต้องการของผลิตภัณฑ์ซึ่งมักจะได้รับจากการเผยแพร่หลายเวอร์ชันและเชื่อมโยงอย่างใกล้ชิดกับสิ่งที่ผู้ชมเป้าหมายหรือลูกค้าต้องการและคุณค่าที่มอบให้

ห่วงโซ่ขององค์ประกอบที่เชื่อมโยงทีมเปรียวกับลูกค้า (รวมถึงงานในมือและวิสัยทัศน์) สามารถแสดงเป็น:

การเชื่อมโยงระหว่างทีมที่คล่องตัวกับสิ่งที่ลูกค้าต้องการ...

เนื่องจากขาดมุมมองที่เชื่อมโยงการวิ่งอย่างรวดเร็วกับวิสัยทัศน์ของผลิตภัณฑ์ เจ้าของผลิตภัณฑ์มักจะเสี่ยงต่อการมุ่งความสนใจไปที่ส่วน 'อย่างไร' มากเกินไป และสูญเสียการมองเห็นเป้าหมายที่ใหญ่กว่าและสำคัญของ 'อะไร' ซึ่งสามารถนำไปสู่ เพื่อจัดลำดับความสำคัญที่ผิดพลาด

แนวทางที่ฉันพูดถึงในที่นี้คือการสร้างมุมมองที่เรียบง่ายแต่ทรงพลังที่เชื่อมโยงทั้งสององค์ประกอบ สิ่งนี้เรียกว่า Product Vision Matrix (PVM) วัตถุประสงค์คือเพื่อเชื่อมโยงวิสัยทัศน์ของผลิตภัณฑ์กับรายการการพัฒนาที่ละเอียด เมทริกซ์นี้กลายเป็นปัจจัยสำคัญในการวิเคราะห์ความคืบหน้าของทีมในส่วนที่เกี่ยวกับการพัฒนาผลิตภัณฑ์ นอกจากนี้ยังทำหน้าที่เป็น แดชบอร์ดผลิตภัณฑ์ สำหรับผู้บริหารระดับสูงขององค์กรและคอยโพสต์เกี่ยวกับความสำเร็จของเป้าหมายผลิตภัณฑ์

ตามชื่อที่แนะนำ PVM คือเมทริกซ์ที่คอลัมน์แสดงมิติข้อมูล (จากไมโครถึงมาโคร) ที่กำลังถูกจับ มาทำความเข้าใจ PVM ด้วยความช่วยเหลือของแอปสั่งอาหารซึ่งมีวิสัยทัศน์ในการมอบประสบการณ์อาหารแก่ผู้ใช้ และจุดเริ่มต้นคือการสั่งอาหาร เมทริกซ์ตัวอย่างมีลักษณะดังนี้:

Product Vision Matrix สามารถมีฟิลด์ต่อไปนี้:

• เวอร์ชันผลิตภัณฑ์: นี่คือเวอร์ชันของผลิตภัณฑ์ที่เป็นเป้าหมายการเปิดตัวอย่างเป็นทางการและมักเป็นสิ่งที่ลูกค้าได้รับ
• Big Rock Item: นี่คือหมวดหมู่หรือธีมที่เป็นของฟีเจอร์ด้วย รายการเหล่านี้ยังสามารถเป็นพื้นที่ความต้องการผลิตภัณฑ์ระยะยาวของวิสัยทัศน์ผลิตภัณฑ์
• คุณลักษณะ: นี่คือคุณลักษณะของผลิตภัณฑ์ที่กำลังพัฒนา คุณลักษณะนี้สามารถอยู่ในธีมเดียวหรือหลายธีม (รายการร็อคใหญ่)
• Sprint ID: นี่คือหมายเลขการวิ่งที่กำลังพัฒนาคุณสมบัติ
• สถานะการพัฒนา: ช่องนี้แสดงถึงความคืบหน้าของการพัฒนา (วางแผนแล้ว การออกแบบเสร็จสมบูรณ์ การพัฒนาเสร็จสมบูรณ์ ทดสอบแล้ว และเผยแพร่แล้ว)

โปรดทราบว่าโครงสร้างของเมทริกซ์เป็นตัวบ่งชี้ที่นี่ หนึ่งสามารถสร้างสรรค์มากขึ้นในการระบุคอลัมน์ที่สามารถจับภาพวิสัยทัศน์ของผลิตภัณฑ์

ข้อดีของแนวทางนี้คือการ มองเห็นที่ชัดเจนของสมาชิกในทีมแต่ละคนเกี่ยวกับเป้าหมายผลิตภัณฑ์โดยรวม สำหรับผลิตภัณฑ์ที่พัฒนาขึ้น สมาชิกในทีมควรมีความเข้าใจในภาพรวมมากขึ้น สิ่งนี้ไม่เพียงช่วยให้พวกเขามีส่วนร่วมอย่างมีประสิทธิภาพ แต่ยังช่วยให้พวกเขามีความรับผิดชอบมากขึ้น ผลลัพธ์ที่ได้คือทีมที่มุ่งเน้นและปรับตัวมากขึ้น ซึ่งมักจะจับจังหวะการเต้นของหัวใจลูกค้าอยู่เสมอ และตระหนักถึงความแตกต่างที่การวิ่งของพวกเขาสามารถสร้างขึ้นเพื่อนำไปสู่วิสัยทัศน์และความสำเร็จในท้ายที่สุดของผลิตภัณฑ์

ศึกษา หลักสูตรการจัดการผลิตภัณฑ์ ออนไลน์จากมหาวิทยาลัยชั้นนำของโลก รับ Masters, Executive PGP หรือ Advanced Certificate Programs เพื่อติดตามอาชีพของคุณอย่างรวดเร็ว

โครงการเด่นสำหรับคุณ: โครงการรับรองการคิดเชิงออกแบบจาก Duke CE