Standard Process กับ Self-Organizing Team
The Whats And Whys vs. The Hows
ไม่เข้าใจเหมือนกันว่าทำไมคนใหญ่คนโตถึงถามหาและพยายามสร้างแต่กระบวนการที่เป็นมาตรฐาน (Standardized Process) ยิบๆย่อยๆขึ้นมาเพื่อบังคับใช้กับทุกทีม เช่น
- ขอดู Product Backlog หน่อยว่าอยู่ใน JIRA มั้ย?
- ทีมเรา Record Bug ครบทุกตัวมั้ย? ต้องอยู่ใน JIRA ด้วยนะ
- ตอนนี้ทีมเรามี Velocity เท่าไร?
ทำไมหรอ? ถ้า Product Backlog ไม่อยู่ใน JIRA จะไม่เรียกว่า Product Backlog? ถ้า Record Bug ไม่ครบแปลว่าซอฟต์แวร์เราไม่มีคุณภาพ? แล้วจะอะไรนักหนากับ Velocity … แบบนี้โกหกว่าตอนนี้ Velocity ทีมเราคือ 100 แปลว่าทีมเราทำงานดีสุดในองค์กร แบบนี้ปะ? คือมันก็ไม่ใช่แบบนั้นซะทั้งหมด แล้วจะมาบังคับอะไรกับการทำงานในรายละเอียดของทีมหละครับ
ที่มันเป็นแบบนี้เพราะคนใหญ่คนโตยังไม่สามารถก้าวข้ามคำว่า “ผู้จัดการ” (Manager) ไปได้ อย่างที่ Jason Fried บอกไว้ในวิดีโอนี้ว่า
“Managers are basically people whose job it is to interrupt people. That’s pretty much managers are for. They are for interrupting people. They don’t really do a work so they have to make sure everyone else’s doing the work, which is an interruption.”
โชคไม่ดีที่ไอ้มาตรฐานยิบย่อยพวกนี้มันง่ายต่อการตรวจสอบว่าคนในทีมทำงานหรือไม่ แค่มี Product Backlog กับ Bug ใน JIRA พวกท่านผู้จัดการก็สบายใจนอนหลับฝันดีกันแล้ว ทีมงานของท่านทุกคนขยันขันแข็งอย่างที่ใจหวัง … คิดแล้วคันปากไม่อยากจะด่าแรงๆ ฮ่าๆ
อีกข้อก็น่าจะเป็นเรื่องข้ออ้างที่ติดปากท่านผู้จัดการทั้งหลายที่ว่า “ถ้าไม่มีมาตรฐานมันก็ตรวจสอบยากสิ” อืมมม จะว่าไปท่านก็พูดถูกแต่ก็ช่วยไม่ได้เพราะท่านคิดรูปแบบการตรวจสอบที่มันยุ่งยากซับซ้อนและบ้าบอขึ้นมาเองนี่หว่า เล่นนั่งนับ Bug ใน JIRA ว่ามีกี่ตัวเป็นหนึ่งในการตรวจสอบ อ่าว แบบนี้ไอ้ทีมที่ไม่ใช้ JIRA ไม่หมดอนาคตหรอ? ไร้สาระน่า คิดเยอะๆหน่อยว่ามาตรฐานที่ควรตรวจสอบหนะมันไม่ใช่ KPI ตกยุคแบบนี้
สุดท้ายคือพวกท่านไม่เข้าใจคำว่า Self-Organizing Team (ทีมที่จัดการตัวเอง) ซึ่งเป็นหนึ่งในจุดมุ่งหมายของการพัฒนาคนพัฒนาทีมด้วยหลักการ Agile Software Development สำหรับสิ่งสำคัญที่ Self-Organizing Team ต้องการคือ
- วิสัยทัศน์ที่ชัดเจนว่าท่านผู้จัดการต้องการอะไรและทำไมถึงเป็นเช่นนั้น ขอเรียกว่า What and Why
- อิสระในการทำงานและคิดหาทางในการทำให้ What and Why นั้นเป็นจริงขึ้นมา ขอเรียกว่า How
- กฎข้อบังคับและข้อจำกัดในการทำงาน ขอเรียกว่า Rules and Constraints
ปัญหามันอยู่ตรงนี้แหละ ท่านผู้จัดการส่วนใหญ่ (ร้อยละ 99) ไม่เคยสนใจ What and Why อะไรเลย อาจจะเพราะว่าแม้แต่ตัวเองก็ไม่รู้ว่าวิสัยทัศน์คืออะไรและทำแบบนั้นไปทำไม เราจึงสังเกตได้ง่ายๆว่า เมื่อไรก็ตามที่ถามคนในทีมว่า “เฮ้ น้องๆ Product Vision ของทีมน้องคืออะไรอะ?” … “เอ่อ Product Vision คืออะไรครับ?”
ไม่รู้ What and Why ไม่พอ ยังบ้า How แบบขึ้นสมอง บังคับทีมเข้าไปว่านี่คือวิธีการที่ถูกต้องที่ทุกคนต้องทำตามนะ ห้ามแตกแถว Product Backlog, Bug, JIRA, Velocity นี่คือ How ทั้งนั้น เมื่อท่านรู้แค่นี้ ท่านก็มีปัญญาวัดผลหรือตรวจสอบแค่ที่ระดับ How นี้แหละ … ความเจริญจึงไม่เกิดกับทีมและองค์กรของท่าน
วิธีแก้ปัญหาง่ายๆมีมั้ย? … มีครับ ก็หาท่านผู้จัดการที่เข้าใจว่าสิ่งที่ Self-Organization ทีมต้องการคืออะไร (ตามรูปข้างบน) เข้ามาทำงานแทนท่านผู้จัดการตกยุคซะ จบ
ผมเขียนบทความนี้เพราะอยากเปลี่ยนแปลงสิ่งที่เป็นอยู่ในอุตสาหกรรมการผลิตซอฟท์แวร์ให้ดีขึ้นตามความเชื่อและประสบการณ์ของผม ถ้าเพื่อนๆเชื่อในแนวทางเดียวกัน เรามาช่วยกันคนละไม้คนละมือทำให้สังคมของเราดีขึ้นครับ จะแชร์บทความนี้ผ่าน Social Network หรือจะแบ่งปันเรื่องราวนี้ให้คนที่นั่งข้างๆฟังบ้างก็ได้
The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson
อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ
