(credit cover: ทีมงาน Agile66 https://www.facebook.com/groups/agile66/)
วันสุดท้ายของไตรมาสสองที่ผ่านมา ผมได้มีโอกาสเข้าร่วม session Virtual Agile Meetup#2 – ทีม ทีม ทีม จัดยังไงให้มีประสิทธิภาพ ทำจริงเจ็บจริง กับ Holacracy & Spotify Model ของคุณนอร์ท และคุณโน๊ต อำนวยการจัดงานโดย ทีมงาน Agile66 มีหลายประเด็นที่น่าสนใจ เลยสรุปตามที่ตัวเองรับรู้มาได้ประมาณนี้ครับ
Holacracy โดย คุณนอร์ท
ได้รับแรงบันดาลใจเบื้องต้นมาจากการอ่านหนังสือ Delivering Happiness โดย โทนี่ เช และมีโอกาสได้ไปรำเรียนเพิ่มเติมกับต้นตำหรับเลย คือ Brian J. Robertson ผู้แต่งหนังสือ Holacracy โดยเป็นคนไทย (และน่าจะเป็นหนึ่งเดียวที่เป็นชาว Asia) ในคลาสนั้น จึงเป็นจุดสังเกตว่า ด้วยกรอบความคิด วัฒนธรรมประเพณี ในกลุ่มประเทศ Asia นี้ มันมีการเอื้อเฟื้อต่อการทำ Holacracy อย่างมีประสิทธิภาพหรือไม่? มีข้อจำกัดในส่วนใดบ้าง?
(~ ผู้อ่านสามารถศึกษาข้อมูลเพิ่มเติมได้จาก Explore Holacracy — Holacracy ครับ ~)
ใจความหลักของ Holacracy คือการสืบค้นหา Tension (ปัญหา, อุปสรรค์, ข้อจำกัด ฯลฯ) ที่ค้างคาสะสม นำมาคุยกันในการประชุมอย่างเปิดเผย และทำการบริหารจัดการ เพื่อให้เกิด workflow ที่ดี และมองเห็นว่า บุคคลระดับหัวหน้า อาจเป็นหนึ่งในอุปสรรค์ของ workflow นั้นๆ ได้ จึงเลือกการที่
~
ไม่มีสายบังคับลำดับชั้น
ไม่มีบุคคลระดับหัวหน้า
ไม่มีป้ายกำหนดตำแหน่งบทบาทแปะไว้ที่ตัว
อยู่กันเป็น circle เป็นชุมชน ที่มี Lead link (ประมาณผู้ใหญ่บ้าน ผู้นำชุมชน), Rep Link, Facilitator คอยอำนวยความสะดวกให้การงานใดๆ สำเร็จลุล่วงไปได้
สมาชิกสามารถเลือกบทบาทหน้าที่ตามความต้องการ ความสนใจ ตามทักษะที่มี ได้เอง
~
ด้วยความอิสระในการตัดสินใจดังกล่าวนี้ มันก็ทำให้เกิดข้อสังเกตได้ว่า ถ้า
สมาชิกเลือกทำแต่สิ่งที่ใช่จากใจที่ชอบ
หรือ ฉันอยากจะทำทุกอย่าง (เหมือนศิลปินท่านนึงที่รักแฟนเพลงทุกคนเสมอๆ) แต่สำเร็จทุกอย่างมั้ยก็ไม่สามารถยืนยันได้
แม้แต่ การส่งต่องานจากสมาชิกที่มีความเข้าใจใน business ที่แตกต่างกันมากๆ
สิ่งเหล่านี้จะนำไปสู่การทำงานที่ไม่สร้าง outcome ที่ควรมีหรือไม่ ซึ่งเป็นส่วนที่ Lead link ต้องมาดูภาพรวมและคอยๆละล่อมๆ ให้เข้ารูปอีกทีหนึ่ง
Spotify Model โดย คุณโน้ต
ได้รับแรงบันดาลใจเบื้องต้นมาจากเนื้อหา Spotify Engineering Culture โดย Henrik Kniberg (~ ผู้อ่านสามารถศึกษาข้อมูลเพิ่มเติมได้จาก https://engineering.atspotify.com/2014/03/27/spotify-engineering-culture-part-1/ และ https://engineering.atspotify.com/2014/09/20/spotify-engineering-culture-part-2/ ครับ ~)
~
Chapter คือ กลุ่มของคนที่มี Skill และหน้าที่เหมือนกัน เช่น Backend Engineer, Frontend Engineer, Designer และอื่นๆ โดยมี Chapter Lead (Leader ในกลุ่มของ Skill ดังกล่าว) เป็นคนกำหนด Direction และทำประเมินสมาชิกใน Chapter
Squad คือ กลุ่มของสมาชิกที่มี Skill แตกต่างออกไปตามแต่ละ Chapter มารวมตัวกัน
Tribe คือ กลุ่มของ Squad ที่มีเป้าหมายในการทำ Product หรือ Feature ตาม Business ที่รับผิดชอบ
Guild คือ กลุ่มคนที่มีความสนใจใน domain หนึ่ง ที่ไม่จำเป็นว่าจะ ต้องตรงกับ Skill ที่สมาชิกในกลุ่มมี
~
จากโครงสร้างดังกล่าว มีจุดสังเกตที่น่าสนใจคือ กลุ่มคนที่อยู่ Chapter เดียวกันแต่ต่าง Squad มีโอกาสที่จะทำงานหนึ่งๆ ซ้ำกันได้ เช่น System Engineer ทำการเขียน Pipeline เพื่อใช้ใน Squad ของตัวเอง ซึ่ง Pipeline ที่ว่า อาจจะมีการทำซ้ำตั้งแต่เริ่ม ทำงานเหมือนกันเป๊ะๆ โดย System Engineer ใน Squad อื่นๆ
อีกประเด็นหนึ่งคือ ขนาดของ Chapter ที่มีโอกาสโตมากขึ้นตามธุรกิจที่ขยับขยาย (มีโอกาสที่ Chapter หนึ่งมีจำนวนสมาชิกไปถึง 50+ เลยทีเดียว) ความสามารถในการดูแลอย่างทั่วถึงของ Chapter Lead ทำได้อย่างลำบากพอสมควร และความเป็นไปได้ที่จำนวนสมาชิกภายใน Squad มีจำนวนมาก นำไปสู่ประเด็นความทั่วถึงในการปฏิสัมพันธ์ภายใน Squad เอง