Railway แพลตฟอร์มโครงสร้างพื้นฐานคลาวด์ที่มีผู้ใช้งาน 1.7 ล้านคน ได้แบ่งปันเส้นทางการเปลี่ยนแปลงจากวิธีการวางแผนแบบดั้งเดิม หลังจากต่อสู้กับกระบวนการที่เต็มไปด้วยพิธีรีตองซึ่งสร้างความสับสนมากกว่าความชัดเจน การพัฒนาแนวทางของบริษัทในช่วง 18 เดือนจาก OKRs สู่แนวทาง Problem Driven Development ในปัจจุบัน ให้ข้อมูลเชิงลึกว่าทำไมบริษัทเทคโนโลยีหลายแห่งจึงพบว่าการวางแผนรายไตรมาสน่าหงุดหงิดและไม่มีประสิทธิภาพ
โครงสร้างองค์กรของ Railway:
- Product Team: วิศวกรรมสำหรับฟีเจอร์ UI และ Terminal
- Platform Team: การพัฒนาโครงสร้างพื้นฐานและ API
- Logistics Team: ฟังก์ชันด้านการสนับสนุน การตลาด และการขาย
- ขนาดทีมทั้งหมด: 27 คน
- ฐานผู้ใช้: ลูกค้ามากกว่า 1.7 ล้านคน
การทดลอง OKR ที่ล้มเหลว
เช่นเดียวกับสตาร์ทอัพที่กำลังเติบโตหลายแห่ง Railway เริ่มต้นหันไปใช้ Objectives and Key Results (OKRs) เมื่อพวกเขาต้องการประสานงานทีมที่ขยายตัว บริษัทอ่านหนังสือที่แนะนำอย่างขยันขันแข็งและนำกรอบการทำงานมาใช้ แต่ค้นพบอย่างรวดเร็วว่า OKRs ทำงานได้ดีกว่าในสภาพแวดล้อมโรงงานมากกว่าสภาพแวดล้อมการพัฒนาซอฟต์แวร์ กรอบการทำงานนี้เก่งในเป้าหมายที่เป็นรูปธรรมและแบ่งแยกได้ชัดเจน แต่ดิ้นรนกับงานวิศวกรรมที่ต้องใช้ความคิดสร้างสรรค์และวัตถุประสงค์ที่ไม่จำกัดเช่นการเพิ่มอัตราการแปลง
ทีมพบว่าตัวเองใช้เวลาไปกับการถกเถียงว่าอะไรถือเป็น OKR ที่ถูกต้องมากกว่าการตัดสินใจว่าจะสร้างอะไร การวางแผนแบบแสดงออกนี้กินรอบการทำงานของวิศวกรรมที่มีค่า ขณะเดียวกันก็สร้างความไม่ยืดหยุ่นที่ทำให้การปรับเปลี่ยนทิศทางกลางคันเป็นไปไม่ได้เกือบจะเลย การสนทนาในชุมชนเผยให้เห็นว่านี่ไม่ใช่เรื่องเฉพาะของ Railway - องค์กรหลายแห่งต่อสู้กับปัญหาคล้ายกันเมื่อนำกระบวนการที่ออกแบบมาสำหรับโรงงานไปใช้กับงานความรู้ที่ต้องใช้ความคิดสร้างสรรค์
จากโปรเจกต์สู่ปัญหา
โซลูชันของ Railway พลิกการวางแผนแบบดั้งเดิมกลับหัว แทนที่จะขอให้ทีมเสนอโซลูชัน ตอนนี้พวกเขาเน้นเฉพาะการอธิบายปัญหาอย่างชัดเจน การเปลี่ยนแปลงนี้ขจัดความผูกพันทางอารมณ์ที่นักพัฒนามักจะมีต่อโซลูชันที่พวกเขาเสนอ และป้องกันการมุ่งมั่นก่อนกำหนดต่อแนวทางเฉพาะก่อนที่จะเข้าใจว่าต้องแก้ไขอะไร
การเน้นที่ปัญหาไม่ใช่โซลูชันเป็นแนวปฏิบัติมาตรฐาน ดูเหมือนว่าผู้เขียนเลือกแนวคิดนามธรรมบางอย่างของบริษัทใหญ่และกระบวนการวางแผนที่ขับเคลื่อนด้วยกระบวนการ
กระบวนการรายไตรมาสสี่วันของพวกเขาแบ่งออกเป็นระยะที่แตกต่างกัน: การรวบรวมปัญหา การจัดลำดับความสำคัญโดยทีมอิสระ การแก้ไขการพึ่งพาอาศัยกัน และการมุ่งมั่นต่อสาธารณะ หลังจากมุ่งมั่นที่จะแก้ไขปัญหาเฉพาะเท่านั้น พวกเขาจึงเริ่มเขียนข้อกำหนดทางเทคนิคและกำหนดแนวทางการดำเนินงาน
กระบวนการวางแผนสี่วันของ Railway:
- วันที่ 1: ทีมต่างๆ ป้อนปัญหาอย่างอิสระ (ไม่มีการแก้ไขปัญหา)
- วันที่ 2: การประชุมทีมแบบปิดเพื่อจัดลำดับความสำคัญ (P0/P1/P2)
- วันที่ 3: การแก้ไขการพึ่งพาข้ามทีมและการยืนยันความสามารถ
- วันที่ 4: การให้คำมั่นสัญญาต่อสาธารณะและการมอบหมาย DRI (บุคคลที่รับผิดชอบโดยตรง)
การตรวจสอบความจริงของความสามารถ
องค์ประกอบสำคัญหนึ่งที่ทำให้แนวทางของ Railway แตกต่างคือการเน้นการวางแผนความสามารถอย่างซื่อสัตย์ ก่อนที่จะสรุปข้อผูกมัด พวกเขาประเมินภาระงานปัจจุบัน การเวรเฝ้าระวัง และเหตุการณ์ในชีวิตที่จะมาถึงเช่นการลาคลอด หากพวกเขาระบุปัญหาสำคัญแปดข้อแต่มีความสามารถเพียงห้าข้อ พวกเขาจะตัดสินใจอย่างชัดเจนว่าอะไรลดลำดับความสำคัญหรือต้องจ้างบทบาทใดเพิ่มเติม
แนวทางที่อิงกับความเป็นจริงนี้แก้ไขคำวิจารณ์ทั่วไปในชุมชนเกี่ยวกับการมุ่งมั่นต่องานก่อนที่จะเข้าใจความซับซ้อนของการดำเนินงาน แม้ว่าบางคนจะโต้แย้งว่านี่สร้างปัญหา draw the rest of the owl แต่วัฒนธรรมวิศวกรรมอิสระของ Railway อนุญาตให้ปรับเปลี่ยนกลางไตรมาสเมื่อปัญหาพิสูจน์ว่าซับซ้อนกว่าที่ประเมินไว้เริ่มแรก
ระดับความสำคัญที่ใช้:
- P0: ความเสี่ยงต่อการดำรงอยู่ของบริษัท - ต้องส่งมอบ
- P1: ต้องส่งมอบในไตรมาสนี้
- P2: ดีถ้ามี
ความสงสัยของชุมชนและคำถามที่กว้างขึ้น
ชุมชนนักพัฒนายังคงแบ่งแยกเกี่ยวกับแนวทางของ Railway บางคนสงสัยว่าการวางแผนรายไตรมาสเองเป็นปัญหาพื้นฐานหรือไม่ โดยเฉพาะสำหรับบริษัทที่ยังคงแสวงหาความเหมาะสมระหว่างผลิตภัณฑ์และตลาด ซึ่งแผนสามเดือนอาจล้าสมัยภายในสัปดาห์ คนอื่นๆ รับรู้แนวทางนี้เป็นรูปแบบหนึ่งของแนวปฏิบัติการจัดการผลิตภัณฑ์ที่มีอยู่แล้วเช่น opportunity solution trees โดยชี้ให้เห็นว่า Railway อาจค้นพบวิธีการที่มีอยู่แล้วใหม่มากกว่าการประดิษฐ์สิ่งใหม่ทั้งหมด
การสนทนาเน้นความตึงเครียดที่ลึกกว่าในการพัฒนาซอฟต์แวร์ระหว่างความจำเป็นในการประสานงานในระดับใหญ่และธรรมชาติที่คาดเดาไม่ได้โดยแท้จริงของงานเทคนิคที่ต้องใช้ความคิดสร้างสรรค์ ดังที่สมาชิกชุมชนคนหนึ่งกล่าวไว้ ความท้าทายที่แท้จริงมักจะไม่ใช่กระบวนการวางแผนเอง แต่เป็นปัจจัยขององค์กรเช่นแรงจูงใจที่ไม่สอดคล้องกันและการขาดความเข้าใจข้ามหน้าที่
ประสบการณ์ของ Railway แสดงให้เห็นว่าการวางแผนที่มีประสิทธิภาพไม่ใช่เรื่องของการหากรอบการทำงานที่สมบูรณ์แบบ แต่เป็นเรื่องของการสร้างกระบวนการที่เข้ากับจิตวิทยาและรูปแบบการทำงานของทีม การเน้นปัญหามากกว่าโซลูชัน การจัดลำดับความสำคัญโดยอิสระก่อนการเจรจา และการประเมินความสามารถอย่างซื่อสัตย์ของพวกเขา เสนอทางเลือกที่ปฏิบัติได้สำหรับทีมที่ดิ้นรนกับแนวทางการวางแผนแบบดั้งเดิม ว่าวิธีการนี้จะขยายขนาดเกินทีม 27 คนปัจจุบันของพวกเขาหรือไม่ยังต้องติดตาม แต่ความเต็มใจที่จะปรับปรุงและแบ่งปันบทเรียนที่ได้เรียนรู้มีส่วนสนับสนุนข้อมูลที่มีค่าต่อการสนทนาต่อเนื่องเกี่ยวกับการวางแผนการพัฒนาซอฟต์แวร์ที่มีประสิทธิภาพ
อ้างอิง: Why most product planning is bad and what to do about it