Product Ownership
Product Ownership ในที่นี้ไม่ได้เกี่ยวอะไรกับ Product Owner แต่จะหมายถึงความรู้สึกในความเป็นเจ้าของใน product
เมื่อประมาณ 10 กว่าปีก่อน ผมเคยฝึกให้ตัวเองมีความรู้สึกในความเป็นเจ้าของใน product ที่ทำด้วยวิธีสมมติว่าตัวเองมีความเป็นเจ้าของอย่างเต็มเปี่ยม มี passion อันท่วมท้นต่อ product ที่ตัวเองทำ แต่ท้ายที่สุดมันก็ไม่สำเร็จ ความเป็นเจ้าของที่เกิดขึ้น มันเกิดขึ้นมาแค่ในตัว source code ที่ตัวเองเขียนเท่านั้น แต่ไม่ได้เกิดขึ้นกับ ในตัว product เลยแม้แต่นิดเดียว ความรู้สึกในตอนนั้นคือ Product owner บอกมาเลย อยากได้อะไรแบบไหน เดี๋ยวทำให้ แต่ถ้าให้ต้องมารับผิดชอบกับรายได้ที่ได้มาจาก product อันนั้น ก็รู้สึกไม่ค่อยดีเท่าไหร่
เมื่อไม่นานที่ผ่านมาได้มีโอกาสมาทบทวนเรื่องนี้อีกครั้งหนึ่งจากคำถามที่มีคนถามมาว่า อยากให้ทีมมี ownership ใน product ที่ทำอยู่ มันทำยังไงได้บ้าง คำตอบที่ผมตอบไปผ่านบทสนทนากับคู่สนทนาค่อนข้างยาว พอจะสรุปได้ประมาณนี้
เราจะรู้สึกถึงความเป็นเจ้าของสิ่งของนั้น ๆ ตอนที่เราต้องลำบาก “ทำอะไรสักอย่าง” เพื่อให้ได้มันมา ประเด็นมันอยู่ตรง ทำอะไรสักอย่าง ที่สำคัญคือ การที่จะทำอะไรนั้น ต้องลำบากด้วย ถ้าเราซื้อตุ๊กตามาตัวหนึ่ง แต่เป็นเงินที่ได้จากพ่อแม่ เมื่อเทียบกับตุ๊กตาที่ซื้อมาด้วยเงินที่เราหามาด้วยน้ำพักน้ำแรงของตัวเอง ความรู้สึกถึงความเป็นเจ้าของ มันก็จะไม่เท่ากัน
ในการพัฒนา product ก็เช่นกัน เราให้โอกาสทีมในการมีส่วนร่วมในการออกความคิดในการออกแบบ product ขนาดไหน เช่น เรากำลังแก้ปัญหาอะไร product มันควรมีฟีเจอร์อะไรเพื่อแก้ปัญหานั้น ๆ มันเป็นส่วนประกอบของ product เพื่อสร้างคุณค่าของ product ขึ้นมา ส่วน source code มันเป็นเพียงทำให้ไอเดียนั้นมันเป็นรูปเป็นร่างเท่านั้น ถึงตรงนี้เราจะเห็นได้ว่า ownership ถูกแบ่งเป็น 2 ส่วน คือ ส่วนที่ประกอบกันเป็น product (features) กับ ส่วนที่ทำให้ product เป็นรูปเป็นร่าง (source code + design) และแน่นอนทีมจะรู้สึกหวงแหน source code มาก เพราะเพื่อที่จะสร้าง product เขาใช้ความคิด และความสามารถที่มีมาพัฒนาให้ product มันเกิดขึ้นจริงได้ ดังนั้นทีมจึงมี ownership เต็ม ๆ กับตรงนี้
ดังนั้นเราน่าจะพอเห็นแสงสว่างได้ว่า เราจะต้องทำยังไงต่อ นั่นคือ การที่จะเปิดโอกาสให้ทีมมามีส่วนร่วมในการออกแบบ product จะช่วยให้ทีมมี ownership ใน product มากขึ้น โดยเฉพาะเมื่อ product นั้นถูกส่งมอบออกไปแก้ปัญหาให้ลูกค้าได้ ทีมย่อมมีความรู้สึกภาคภูมิใจ และอยากจะทำให้ product มันมีคุณค่ามากขึ้น เมื่อวันที่ทีมเจอว่า product ของตัวเองมี bug ก็จะรู้สึกอยากที่จะรีบแก้ไข เพราะเข้าใจถึงความลำบากของผู้ใช้ที่ต้องเจอเมื่อ product ไม่สามารถแก้ไขปัญหาของเขาได้
Delegation Model
ทีมควรส่วนร่วมในการออกความคิดแค่ไหนนั้น มันขึ้นอยู่กับความสำคัญของแต่ละเรื่อง เราสามารถใช้ Delegation model ใน Management 3.0 มาเป็นเครื่องมือช่วยตัดสินใจได้ว่า เราจะให้ทีมมีส่วนร่วมแค่ไหนดี
Delegation model ในทีนี้มันคือเครื่องมือในการกระจายอำนาจการตัดสินใจและความรับผิดชอบไปยังทีม เพื่อเพิ่มความมีส่วนร่วม เพิ่มความเป็นเจ้าของ และเพิ่มความคล่องตัวในการทำงาน โดยตัว Delegation model มันจะแบ่งออกเป็น 7 ขั้น ตามนี้
- บอก (Tell): ผู้มีอำนาจเดิมเป็นผู้ตัดสินใจไว้เรียบร้อยแล้วว่าจะทำอะไรยังไง ทีมมีหน้าที่ทำตามที่บอกเท่านั้น ทีมไม่มีอำนาจในการตัดสินใจอะไร
- ขาย (Sell): ผู้มีอำนาจเดิมมีตัดสินใจไว้เรียบร้อยแล้วว่าจะทำอะไรยังไง แต่ผู้มีอำนาจนั้นจะไปพยายามชักชวนโน้มน้าวให้ทีมเห็นด้วย แต่การตัดสินใจยังอยู่ที่ผู้มีอำนาจอยู่ดี
- ปรึกษา (Consult): ผู้มีอำนาจมาปรึกษาทีมเพื่อขอข้อมูลเพิ่มก่อนตัดสินใจ แต่ยังคงเป็นผู้ตัดสินใจขั้นสุดท้ายอยู่ดี
- ตกลง (Agree): ผู้มีอำนาจและทีมหาข้อตกลงตัดสินใจร่วมกัน อำนาจการตัดสินใจระหว่างผู้มีอำนาจกับทีมจะเท่า ๆ กัน
- แนะนำ (Advice): ทีมเป็นผู้ตัดสินใจ โดยผู้มีอำนาจจะคอยช่วยแนะนำเท่านั้น ไม่ได้ชักจูง หรือสร้าง Bias อะไรเพื่อเบี่ยงเบนการตัดสินใจ
- สอบถาม (Inquire): ทีมเป็นผู้ตัดสินใจ ผู้มีอำนาจอาจจะสอบถามถึงผลการตัดสินใจ แต่ไม่ไปเปลี่ยนผลการตัดสินใจที่เกิดขึ้นแล้ว
- มอบหมาย (Delegate): ทีมเป็นผู้ตัดสินใจได้โดยอิสระ โดยไม่มีผู้มีอำนาจเข้ามาแทรกแซง หรือยุ่งเกี่ยว
เราจะเห็นได้ว่า แต่ละขั้นก็มีส่วนที่ทำให้เกิดความรู้สึกเป็นเจ้าของและความรับผิดชอบได้ไม่เท่ากัน เราแค่ต้องเลือกตามความสำคัญของงาน แต่แน่นอนว่า ถ้ามันเป็นเรื่องที่ท้าทายที่จะให้ทีมเข้ามามีส่วนร่วม การ delegate การตัดสินใจจึงเป็นเพียงส่วนหนึ่งของการสร้าง ownership เท่านั้น
Aligned Autonomy
เมื่อเราให้อำนาจในการตัดสินใจกับทีม ถ้าเราปล่อยให้ทีมตัดสินใจกันโดยไม่บอกอะไรเลย ทีมอาจจะหลงทางว่าควรทำอะไร เพื่ออะไร ดังนั้นสิ่งสำคัญคือการกำหนด Goal ให้ชัดเจนว่า เราต้องการอะไร (ระวัง!! ความต้องการ กับ วิธีการ ไม่เหมือนกัน) และปล่อยให้ทีมได้มีโอกาสคิดหาวิธีการในการตอบสนองต่อความต้องการนั้นกันเองก็พอ
ลองดูอนิเมชั่นจาก Henrik Kniberg ข้างล่างนี้น่าจะทำให้เข้าใจได้มากขึ้น
Psychological Safety
Business value ที่ทีมพยายามส่งมอบ แน่นอน หลาย ๆ ครั้งไม่ใช่เรื่องง่าย โอกาสผิดพลาดก็ย่อมมีเป็นธรรมดา เมื่อสิ่งที่ส่งมอบไม่สามารถแก้ไขปัญหาได้จริง สิ่งที่ควรเกิดขึ้นไม่ใช่การหาคนผิด ผู้มีอำนาจไม่ควรมากดดัน มิเช่นนั้น ใครจะกล้าออกความเห็น หรือมีส่วนร่วมในการตัดสินใจอีก สิ่งที่ควรทำคือการร่วมกันยอมรับ แก้ไข และปรับปรุงให้ดีขึ้น สร้างพื้นที่ที่จะให้ล้มได้ ค้นหาวิธีที่จะทำอย่างไรให้ล้มแล้วเจ็มตัวน้อยที่สุดเพื่อที่จะทำให้ลุกได้เร็ว (Resilience)
เครื่องมือทั้ง 3 เป็นของที่ผมเอาไปเล่าให้คู่สนทนาผมฟังในตอนนั้น หวังว่าจะเป็นประโยชน์สำหรับทุกคนเช่นกัน
