โมเดลทีม Squad ของ Spotify นั้นล้มเหลว
(jeremiahlee.com)<p>"แม้แต่ Spotify เองก็ไม่ได้ใช้ 'the Spotify model' อย่าคุณใช้มันเลย"<br />
เอกสารไวต์เปเปอร์ "Scaling Agile" ของ Spotify ที่โด่งดังในปี 2012 เป็นเพียงความมุ่งหวังของพวกเขา และไม่เคยถูกนำไปใช้จริงอย่างสมบูรณ์<br />
แม้ไวต์เปเปอร์จะต่างจากความเป็นจริง แต่เพราะมันมีประโยชน์ต่อการรับคนเข้าทำงานจึงถูกปล่อยไว้แบบนั้น และผู้เขียนจึงบันทึกเรื่องนี้ไว้หลังลาออกเพื่อแก้ความเข้าใจผิด<br />
บทความนี้อธิบายอย่างละเอียดว่าโมเดลนั้นผิดพลาดตรงไหน สิ่งที่เรียนรู้ได้จากความผิดพลาดของ Spotify และโมเดลอื่นที่แนะนำแทน<br />
<br />
ผู้ร่วมเขียนไวต์เปเปอร์ฉบับนั้นและ Agile coach ของ Spotify เคยบอกคนนอกมานานแล้วว่าอย่าทำตามสิ่งนี้<br />
"แม้แต่ตอนที่เราเขียนไวต์เปเปอร์ เราก็ไม่ได้ทำแบบนั้นอยู่แล้ว มันเป็นเพียงความทะเยอทะยานบางส่วนและการคาดเดาเท่านั้น ผู้คนกลับพยายามอย่างหนักที่จะทำตามสิ่งที่ไม่มีอยู่จริง"<br />
<br />
ทำไมมันถึงทำงานได้ไม่ดี?<br />
<br />
1. การบริหารแบบเมทริกซ์ไปแก้ปัญหาที่ผิด (Wrong Problem)<br />
<br />
ทีม agile แบบ full-stack ทำงานได้ดีอยู่แล้ว แต่การบริหารในรูปแบบเมทริกซ์กลับสร้างปัญหาเพิ่มมากขึ้น<br />
→ ทีมของ Spotify มีโครงสร้างที่คงอยู่ยาวนานอยู่แล้ว ดังนั้นข้อดีเรื่องไม่ต้องเปลี่ยนผู้จัดการเมื่อย้ายทีมจึงมีประโยชน์จำกัดมาก<br />
→ ผู้จัดการสายวิศวกรรมรับผิดชอบเพียงระดับการพัฒนาอาชีพ แต่ไม่ได้ช่วยเรื่องทักษะความสัมพันธ์ระหว่างบุคคลและด้านอื่น ๆ<br />
→ ไม่มีผู้จัดการคนเดียวที่ดูแลวิศวกรทั้งหมดของแต่ละทีม คนที่ทำหน้าที่คล้าย mini-CEO อย่าง product manager จึงไม่มีคู่เทียบแบบ mini-CTO นั่นหมายความว่าไม่มีใครรับผิดชอบการสนับสนุนทีมเทคนิคหรือการต่อรองลำดับความสำคัญ หากเกิดความเห็นไม่ตรงกันภายในทีมเทคนิค product manager ต้องไปเจรจากับวิศวกรทุกคนเอง ถ้ายังไม่จบ ก็ต้องไปเจรจากับ engineering manager ฝั่ง backend/web/mobile อย่างน้อย 3 คน หรือ escalate ไปถึงหัวหน้าฝ่ายวิศวกรรมของแผนก<br />
<br />
[ สิ่งที่เรียนรู้ได้จากความผิดพลาดของ Spotify ]<br />
→ โดยทั่วไปในทีม product-design-tech จะมีวิศวกรมากกว่า จึงควรมีผู้จัดการที่ดูแลวิศวกรทั้งหมดเพื่อให้มีเส้นทางสำหรับการ escalate เมื่อเกิดความขัดแย้งภายในทีม<br />
→ product manager ควรมีเพื่อนร่วมงานระดับเท่าเทียมสำหรับคุยเรื่องเทคนิคได้ เช่นเดียวกับความสัมพันธ์ระหว่าง CEO และ CTO <br />
<br />
2. พึ่งพาความเป็นอิสระของทีมมากเกินไป<br />
<br />
เมื่อบริษัทเล็ก แต่ละทีมจะทำงานได้หลากหลายขอบเขต และทีมที่เป็นเจ้าของงานหลักก็มักเปลี่ยนไปมาได้ <br />
เมื่อบริษัทใหญ่ขึ้น ความสามารถที่ซ้ำซ้อนกันในแต่ละทีมจะถูกรวมเป็นทีมใหม่เพื่อเพิ่มประสิทธิภาพ <br />
เมื่อมีจำนวนทีมมากขึ้น โอกาสที่เจ้าของงานหลักจะเปลี่ยนก็ลดลง และแต่ละทีมก็สามารถคิดระยะยาวกับปัญหาที่ตนต้องแก้ได้มากขึ้น<br />
<br />
→ Spotify ไม่ได้กำหนดกระบวนการร่วมมาตรฐานสำหรับการทำงานข้ามทีม แต่ละทีมเข้าร่วมในแบบของตัวเอง ทำให้ผลิตภาพของทั้งองค์กรลดลง<br />
→ "Spotify model" ถูกสรุปขึ้นตอนที่บริษัทยังเล็กกว่ามาก ควรมีการสรุปเวอร์ชันถัดมา แต่กลับไม่มี จึงมีเพียงการพูดถึงความเป็นอิสระ ส่วนการทำงานร่วมกันระหว่างทีมไม่เคยถูกทำให้สมบูรณ์<br />
<br />
[ สิ่งที่เรียนรู้ได้จากความผิดพลาดของ Spotify ]<br />
→ ความเป็นอิสระต้องมาพร้อม alignment ลำดับความสำคัญของบริษัทควรถูกกำหนดโดยผู้บริหาร ความเป็นอิสระไม่ได้แปลว่าทีมจะทำอะไรก็ได้ตามใจ<br />
→ กระบวนการทำงานร่วมกันระหว่างทีมเป็นสิ่งจำเป็นอย่างยิ่ง ความเป็นอิสระไม่ได้แปลว่าปล่อยให้แต่ละทีมแก้ทุกปัญหาเองตามลำพัง<br />
→ วิธีประเมินความสำเร็จก็ควรถูกกำหนดโดยผู้บริหารด้วย เพื่อให้สามารถประสานลำดับความสำคัญของการทำงานข้ามทีมได้ <br />
→ ความเป็นอิสระต้องมาพร้อมความรับผิดชอบ Product Management ต้องรับผิดชอบต่อคุณค่าของผลิตภัณฑ์ แต่ละทีมมีหน้าที่ทำให้ส่วนที่เพิ่มเข้ามา “เสร็จสมบูรณ์” ทีมที่มีวุฒิภาวะต้องพิสูจน์ความเป็นอิสระของตนด้วยการแสดงให้เห็นถึงคุณค่าทางธุรกิจ ความเสี่ยง การเรียนรู้ และการเคลื่อนไหวที่เหมาะสมที่สุดสำหรับขั้นถัดไป<br />
<br />
"ถ้าจะให้ผมเลือกสิ่งเดียวที่อยากย้อนกลับไปแก้ที่ Spotify มันคือเราไม่ควรเน้นเรื่อง autonomy มากเกินไป" - Joakim Sunden อดีต Agile Coach ของ Spotify<br />
<br />
3. การทำงานร่วมกันเป็นเพียงความสามารถที่ถูกสมมติว่ามีอยู่<br />
<br />
แม้ Spotify จะเปิดให้แต่ละทีมควบคุมวิธีการทำงานของตนเองได้ แต่หลายคนกลับไม่มีความเข้าใจพื้นฐานเกี่ยวกับ agile เพียงพอ <br />
ผลคือแต่ละทีมต้องพยายามลองผิดลองถูก ปรับปรุงกระบวนการซ้ำ ๆ เพื่อหาชุดวิธีที่ช่วยให้งานออกมาดีขึ้น <br />
ไม่มีภาษากลางสำหรับประเมินปัญหาในกระบวนการ วิธีแก้ หรือการวัดผลอย่างมีประสิทธิภาพ ในความเป็นจริงมันไม่ใช่ agile ด้วยซ้ำ แต่เป็นเพียง "Not-Waterfall"<br />
<br />
Spotify มี "Agile coach" ที่คอยสอนและเสนอแนวทางปรับปรุงกระบวนการให้แต่ละทีม เจตนาดี แต่มีโค้ชไม่พอที่จะช่วยทุกทีม <br />
เวลาที่โค้ชแต่ละคนแบ่งให้กับทีมก็ไม่มากพอจะช่วยจนแต่ละทีมทำโปรเจกต์เสร็จและประเมินผลงานได้จริง สุดท้ายพวกเขาจึงไม่ได้รับผิดชอบอะไรเลย<br />
<br />
[ สิ่งที่เรียนรู้ได้จากความผิดพลาดของ Spotify ]<br />
→ การทำงานร่วมกันเป็นทักษะที่ต้องอาศัยความรู้และการฝึกฝน ผู้จัดการไม่ควรสมมติว่าผู้คนเข้าใจ agile practices ที่มีอยู่แล้ว<br />
→ เมื่อบริษัทใหญ่พอ แต่ละทีมต้องการองค์กรสนับสนุนที่ช่วยให้วางแผนภายในทีมและทำให้การทำงานข้ามทีมเกิดขึ้นได้ Program Management ควรรับผิดชอบต่อ planning process ส่วน Program Manager ที่ทำหน้าที่เต็มเวลาควรทำให้ทีมทำงานได้เหมือนที่ Product Manager และ Engineering Manager ต่างทำบทบาทของตนเองพร้อมทั้งร่วมมือกันได้ <br />
<br />
4. เมื่อตำนานถูกสร้างขึ้นแล้วจะเปลี่ยนยาก<br />
<br />
การที่ Agile Scrum เสนอคำอย่าง burndown หรือ sprint ก็เพราะต้องตั้งชื่อให้แนวคิดใหม่ที่ถูกนำเสนอ <br />
Spotify นำเสนอคำใหม่อย่าง Missions, Tribe, Squads, Chapter Lead ซึ่งสร้างภาพลวงว่า "เราสร้างสิ่งที่ต้องเลือกใช้คำพิเศษบางอย่างเท่านั้นถึงจะอธิบายได้" <br />
<br />
หากตัดคำพ้องที่ไม่จำเป็นเหล่านี้ออกไป Spotify model ก็เป็นเพียงกลุ่มของ "Cross-Functional Team" ที่มี autonomy มากเกินไปและมีโครงสร้างการจัดการที่อ่อนแอ <br />
หาก Spotify เรียกแนวคิดเหล่านี้ด้วยชื่อดั้งเดิมของมัน ตั้งแต่แรก เมื่อโมเดลนี้ล้มเหลว ผู้คนอาจมองว่านี่ไม่ใช่การเปลี่ยนอัตลักษณ์ทางวัฒนธรรม แต่เป็นการหากระบวนการภายในที่ทำงานได้ดีกว่าแทนก็ได้<br />
<br />
[ สิ่งที่เรียนรู้ได้จากความผิดพลาดของ Spotify ]<br />
→ ธุรกิจส่วนใหญ่รักษาพื้นที่ของนวัตกรรมได้เพียงไม่กี่ด้าน น้อยมากที่นวัตกรรมในกระบวนการภายในจะเป็นสิ่งที่สร้างความแตกต่างให้บริษัทในตลาดได้ การศึกษาประวัติที่ผ่านมาอาจช่วยให้ธุรกิจหาพื้นที่ที่เหมาะกับการสร้างนวัตกรรมมากกว่าเดิมได้<br />
→ จงเพิ่มประสิทธิภาพด้านความเข้าใจ เพื่อรักษาผลิตภาพขององค์กร ควรประเมินคุณค่าของทุกสิ่งใหม่ที่คนในองค์กรต้องเรียนรู้</p><p>*** ให้ทำแบบนี้แทน (แน่นอนว่าไม่มีทางลัด) <br />
<br />
เหตุผลที่คุณค้นหา Spotify model อาจเป็นเพราะต้องการออกแบบโครงสร้างทีมของคุณเอง แต่อย่าหยุดแค่นี้ จงศึกษาเพิ่มเติม<br />
มีบริษัทจำนวนมากที่ผ่านการทดสอบของเวลายาวนานกว่า Spotify และได้เขียนเรื่องนี้ไว้มากกว่า<br />
<br />
Spotify ในปี 2012 ไม่สามารถหาวิธีรักษาความเร็วและความคล่องตัวของทีมเล็กไว้ในองค์กรขนาดใหญ่ได้<br />
พวกเขาเองก็ต้องมองออกไปภายนอกเพื่อหาคำตอบที่ดีกว่าโมเดลตั้งต้นนี้ และคุณก็ควรทำเช่นกัน <br />
<br />
คำแนะนำของผู้เขียนเกี่ยวกับวิธีทำงานแบบอื่น<br />
<br />
- องค์กร product-development-design ของคุณมีคนมากกว่า 200 คนหรือไม่? ตอนที่ผมอยู่ Fitbit นั้น "Scaled Agile Framework" เหมาะมาก<br />
- ถ้าน้อยกว่า 200 คน ผมแนะนำ "Shape Up By Basecamp" สตาร์ตอัปถัดไปของผมก็ตั้งใจจะใช้โครงสร้างแบบนี้<br />
- ลองอ่านหนังสือ "Essential Scrum" และ "Team Topologies"</p>
4 ความคิดเห็น