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

Roadmap ของวันนี้

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

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

เหตุผลทั้งสองนั้นถูกต้องและเข้าใจได้ น่าเสียดายที่พวกเขาตั้งอยู่บนสมมติฐานที่ผิดพลาด ทำให้การฝึกทั้งหมดไร้ค่า — หรือแย่กว่านั้น

สมมติฐานที่ผิดพลาด #1 — สามารถคาดการณ์ความพยายามล่วงหน้าได้

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

สมมติฐานที่ผิดพลาด #2 — สามารถทราบค่าล่วงหน้าได้

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

และนั่นไม่ได้บ่งบอกว่าการนวดตัวเลขนั้นง่ายเพียงใดเมื่อผู้จัดการมีแรงจูงใจให้โครงการสัตว์เลี้ยงของพวกเขาได้รับการอนุมัติ

สมมติฐานที่ผิดพลาด #3 — สิ่งที่เราสร้างขึ้นสร้างมูลค่า

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

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

สมมติฐานที่ผิดพลาด #4 — การสร้างมูลค่าเกิดขึ้นในขณะที่เปิดตัวครั้งแรก

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

ให้สภาพแวดล้อมเป็นตัวกำหนดแนวทางของคุณ

จนถึงตอนนี้ เราพบรายการสมมติฐานที่ Product Roadmaps ขึ้นอยู่กับ - สมมติฐานที่การตรวจสอบอย่างใกล้ชิดไม่ได้มีเหตุผลในความเป็นจริง ในฐานะที่เป็นนักคิดธรรมดาๆ ที่มีแนวโน้มการลดทอน สมองของฉันต้องการแก้ปัญหาทันทีด้วยสมมติฐานแต่ละข้อ ทีละข้อ — อาจโดยการเพิ่มกระบวนการ โครงสร้าง และแนวทาง นั่นไม่ใช่สิ่งที่ผู้จัดการทำใช่ไหม น่าเศร้าที่ปฏิกิริยาแรกนั้นมีพื้นฐานมาจากวิธีการคิดแบบกลไกแบบเดียวกับที่นำ Product Roadmaps มาให้เราตั้งแต่แรก — แต่ [ป้อนข้อความอ้างอิงของ Einstein ที่จำเป็น] “ เราไม่สามารถแก้ปัญหาของเราด้วยระดับความคิดเดียวกับที่สร้างปัญหาขึ้นมาได้ ” ความคิดเชิงกลไกต้องไป สิ่งใหม่ต้องเข้ามาแทนที่

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

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

เราต้องถอยออกมาหนึ่งก้าว ทำความเข้าใจว่าเหตุใด Product Roadmaps, SAFe และ Waterfall โดยทั่วไปจึงวางอยู่บนสมมติฐานเหล่านั้น และเหตุใดการพัฒนาผลิตภัณฑ์จึงละเมิดสมมติฐานเหล่านั้น สิ่งนี้จะไม่เพียงสอนเราถึงบางสิ่งที่สำคัญเกี่ยวกับแผนงานและการพัฒนาผลิตภัณฑ์ แต่ยังบอกใบ้ถึงหนทางข้างหน้าอีกด้วย

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

สภาพแวดล้อมที่ชัดเจน

เมื่อเดินไปตามถนน คุณสังเกตเห็นว่าเชือกผูกรองเท้าของคุณหลุดออกแล้ว คุณก้มลง ผูกเงื่อน และเดินหน้าต่อไป แก้ไขปัญหา. คุณมาถึงทางแยกถนนและเห็นรถแล่นไปตามถนน คุณรอให้รถผ่านคุณและข้ามถนนอย่างปลอดภัย แก้ไขปัญหา.

สิ่งที่เกิดขึ้นมีสองตัวอย่างปัญหาที่เห็นได้ชัดเจน สิ่งเหล่านี้เรียบง่ายโดยเนื้อแท้ ดังนั้นเมื่อคุณสังเกตเห็นว่าเกิดอะไรขึ้น คุณสามารถดำเนินการได้ทันที แก้ไขปัญหา. ไม่มีอะไรแฟนซีที่นั่น สถานการณ์นับไม่ถ้วนในชีวิตเป็นเช่นนี้ ปัญหาเล็กๆ น้อยๆ ที่เราแทบไม่สังเกตเห็นในตอนแรก เรา (เกือบจะไม่รู้ตัว) จัดหมวดหมู่สถานการณ์ จากนั้น (โดยไม่รู้ตัว) ใช้แนวทางปฏิบัติที่ดีที่สุดที่รู้จักกันดี

สภาพแวดล้อมที่วุ่นวาย

เร็วเข้า! ไฟไหม้ตึก! คุณวิ่งไปที่ประตู ถูกบล็อก! ควันลอยเต็มห้อง รีบพังหน้าต่างแล้วหนีไปทางนั้น!

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

บางทีอาจเป็นโชคดีของเรา ที่เราแทบไม่เจอสถานการณ์ที่วุ่นวาย จริงๆ

สภาพแวดล้อมที่ซับซ้อน

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

ยกตัวอย่างแอร์บัสสร้าง A350 ใหม่ มันเป็นเครื่องบินขนาดใหญ่ และการสร้างเครื่องบินขึ้นมานั้นเป็นความพยายามครั้งสำคัญ การสร้างเครื่องบินเป็นสิ่งที่ตรงกันข้ามกับการสร้างปีกส่วนประกอบทุกชิ้นมีตำแหน่งที่กำหนดไว้ล่วงหน้าซึ่งคุณสามารถดูได้ในพิมพ์เขียว ตั้งแต่ปี 2010 จนถึงปัจจุบัน แอร์บัสได้สร้างเครื่องบิน A350 จำนวน 522 ลำ พวกเขารู้ดีว่ากำลังทำอะไรอยู่และต้องใช้เวลานานแค่ไหน และเมื่อทำเสร็จแล้ว คุณก็สามารถบินได้จริงๆ จนถึงตอนนี้ ฝูงบิน A350 ทั่วโลกดำเนินการไปแล้วกว่า 934,000 เที่ยวบินโดยปราศจากอุบัติเหตุ

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

ความซับซ้อนอาจเป็นเรื่องยาก แต่ก็คาดเดาได้ด้วยเช่นกัน ดังนั้นจึงต้องมีการวางแผน นี่คือโลกที่โรดแมปเปล่งประกาย

สภาพแวดล้อมที่ซับซ้อน

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

ข้อแตกต่างประการหนึ่งที่สร้างความแตกต่างคือมีสิ่งที่ไม่สามารถรู้ล่วงหน้าได้ ดังนั้นคุณต้องคิดให้ออกในขณะที่คุณดำเนินการ ตัวอย่างที่ชัดเจนที่สุดคือลูกค้าจะชอบไหม? คุณไม่สามารถรู้ล่วงหน้าได้ สิ่งสำคัญคือคุณสามารถคิดออกได้เร็วแค่ไหน (และราคาถูก)

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

ซับซ้อนหรือซับซ้อนเพียง?

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

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

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

Cynefin — นำทุกอย่างมารวมกัน

จากข้อมูลของ Cynefin แบบจำลองสภาพแวดล้อมการตัดสินใจที่ได้รับความนิยม สิ่งเหล่านี้คือสภาพแวดล้อมสี่ประเภทที่เราอาจพบ: ชัดเจนวุ่นวาย ซับซ้อนและซับซ้อน อย่างที่เราเพิ่งคุยกันไป สถานการณ์ในการตัดสินใจต่างกันตรงที่ความง่ายในการถอดรหัส — ฉันได้สรุปสภาพแวดล้อมสี่ประเภทไว้ด้านล่าง

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

ปัญหาจะเกิดขึ้นเมื่อใดก็ตามที่วิธีการ ที่เราใช้ไม่ตรงกับสถานการณ์ที่เราอยู่ ด้วยเหตุนี้ ใน Cynefin จึงเรียกพื้นที่ระหว่างสี่ประเภทนั้นว่าDisorder

ปัญหาที่แท้จริงของ Roadmaps

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

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

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

จะแก้ไขโรดแม็ปอย่างไร?

ในการหาทางไปข้างหน้า เราต้องคำนึงถึงสองสิ่งที่เราได้พูดคุยกันจนถึงตอนนี้:

1. Product Roadmaps มีไว้เพื่อตอบสนองวัตถุประสงค์สำคัญสองประการ: ให้ผู้จัดการวางแผนสำหรับอนาคตและสร้างความมั่นใจว่าทีมทำงานในสิ่งที่สำคัญที่สุด ทางเลือกอื่นที่เราเสนอต้องเป็นไปตามวัตถุประสงค์เหล่านี้

2. Product Roadmaps ถือว่าโลกมีความซับซ้อนและล้มเหลวในการตั้งค่าที่ซับซ้อน ทางเลือกอื่นที่เราเสนอต้องเหมาะสมกับสภาพแวดล้อมที่ซับซ้อน

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

หลักการ #1 — ให้ทีมหาทางออก

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

ยิ่งมีลำดับชั้นของบริษัทสูงเท่าไร ก็ยิ่งห่างไกลจากปัญหามากเท่านั้น ยิ่งทำการทดลองจริงน้อยลง และยิ่งมีข้อมูลเชิงลึกน้อยลงในการตัดสินใจที่จะทำ คนเหล่านี้มักเชื่อว่าพวกเขาควรบอกทีมว่าควรแก้ไขปัญหาที่กำหนดอย่างไร นี่คือความผิดพลาด (ยิ่งไปกว่านั้น ผู้นำที่เรียกว่าบางคนไม่ได้บอกทีมด้วยซ้ำว่างานของพวกเขาตั้งใจจะแก้ปัญหาใด)

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

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

หลักการ #2 — ผลลัพธ์เหนือผลลัพธ์

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

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

หน้าที่ของผู้นำคือการเลือกเป้าหมายที่คุ้มค่า งานของทีมคือการหาทางไปที่นั่น ดังนั้นเราจึงทำให้มั่นใจว่าทีมทำงานในสิ่งที่สำคัญที่สุดโดยไม่ต้องกำหนดคุณสมบัติ

หลักการ #3 — กล่องเวลาเกินวันครบกำหนด

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

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

หลักการ #4 — ให้เวลาทำซ้ำ

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

แผนงานตามผลลัพธ์

เมื่อรวมหลักการทั้ง 4 ข้อเข้าด้วยกันแล้ว เราจะได้แนวคิดที่ดีว่าแผนงานควรมีลักษณะอย่างไรใน สภาพแวดล้อม ที่ซับซ้อนโดยพื้นฐานแล้ว แผนงานของผลิตภัณฑ์ควรมีลักษณะอย่างไร

1. ให้ทีมงานตรวจสอบวิธีการแก้ปัญหา

2. มอบหมายผลลัพธ์ทางธุรกิจให้ทีมบรรลุ

3. Time-box ความพยายามในการปรับปรุงผลลัพธ์ที่กำหนด

4. อนุญาตให้ทีมทำซ้ำ

พูดอีกอย่างคือ ปฏิเสธ เราต้องละทิ้งบางสิ่งที่เราทำเป็นประจำ

1. หยุดบอกทีมว่าปัญหาควรแก้ไขอย่างไร (เช่น การจัดการแบบย่อยๆ)

2. หยุดกำหนดคุณสมบัติให้กับทีม

3. หยุดใช้กำหนดเวลา — ใช้วันครบกำหนดเมื่อจำเป็นเท่านั้น

4.หยุดวางแผนการทำงานของทีมล่วงหน้ามากกว่าสองสามเดือน

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

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

จูโซ นิซูลา

ที่ปรึกษา Netlight เฮลซิงกิ

อ่านเพิ่มเติม

ความคิดมากมายในโพสต์ข้างต้นมาจากที่อื่นนอกเหนือจากในหัวของฉัน นอกเหนือจากประสบการณ์อันมีค่ากว่า 7 ปีในการให้คำปรึกษาและการสนทนาเชิงลึกมากมายกับเพื่อนร่วมงาน Netlight ของฉันแล้ว ฉันยังได้ประโยชน์อย่างมากจากหนังสือ พอดแคสต์ การบรรยาย และแหล่งข้อมูลอื่นๆ เหล่านี้รวมถึง:

แรงบันดาลใจจาก Marty Cagan
Escaping the Build Trap โดย Melissa Perri พอด
คาสต์ Product Thinking พอด
คาสต์ Product Experience พอดคาสต์ ของ
Lenny
จดหมายข่าว ของ Lenny
Radical Focus โดย Christina Wodtke
Art of Action โดย Stephen Bungay
การนำเสนอของ Bruce Maccarthy
Black Swan โดย Nassim Nicholas Taleb
The Cynefin Framework