November 18, 2017

Agile High Performing Team ลักษณะของทีมงาน ที่มีประสิทธิภาพในรูปแบบ Agile

เมื่อครั้งที่แล้วผมได้พูดถึงลักษณะของโครงการ Agile ไปแล้ว ครั้งนี้ผมจะอธิบายถึงลักษณะของทีมงานใน Agile Project หนึ่งใน Agile Value คือ “Individual Interaction over Process and Tools” นั่นคือ Agile Project ให้ความสำคัญกับคนมากกว่ากระบวนการขั้นตอนของการทำงาน ถึงแม้ว่า Agile จะเน้นการปฏิบัติตามกระบวนการขั้นตอน เช่น Iteration, Backlog, และ Retrospectives แต่สิ่งที่ Agile มองว่าสำคัญที่สุดคือคน คือถ้าเลือกระหว่างกระบวนการที่ดีที่สุด กับคนที่มีประสิทธิภาพที่สุด Agile จะเลือกคนมาก่อนกระบวนการ โดยประเด็นนี้สอดคล้องกับงานวิจัยโดย COCOMO II ที่ระบุว่าปัจจัยด้านคนมีความสำคัญกว่ากระบวนการอย่างน้อยสิบเท่า นั่นคือ การที่ได้คนที่ดีมีคุณภาพมาทำงานสำคัญกว่าขั้นตอนของการทำงานที่ดีอย่างมาก

 

ใน Agile Project ทีมงานจะเน้นทีมงานขนาดเล็ก มีทีมงานไม่เกิน 12 คน เพื่อสามารถให้ทีมงานสามารถทำงานและติดต่อสื่อสารกันได้อย่างมีประสิทธิภาพ โดยการติดต่อสื่อสารเน้นการทำงานในลักษณะ Face-to-Face ถ้าโครงการขนาดใหญ่อาจต้องมีการแบ่งทีมงานออกมาเป็นทีมขนาดเล็กหลายๆ ทีม เพื่อง่ายต่อการทำงานและประสานงาน ทีมงานใน Agile ควรมี Complementary Skills นั่นคือทีมงานแต่ละคนอาจไม่จำเป็นต้องมีความชำนาญทุกอย่าง แต่ทีมงานแต่ละคนสามารถทำงานทดแทนกันได้เป็นลักษณะ Cross-Functional ที่สามารถสลับสับเปลี่ยนบทบาทกันได้ นอกจากนี้ทีมงานต้องมีเป้าหมายเหมือนกัน เป้าหมายของโครงการที่ดีควรเป็นไปในทิศทางเดียวกันกับเป้าหมายของทีมงานแต่ละคน และทีมงานควรเห็นเป้าหมายเหมือนกัน (แต่ไม่จำเป็นต้องเห็นด้วยในวิธีการที่อาจแตกต่างกันได้) นอกจากนี้ ทีมงานทุกคนควรมีการ Share Ownership ในผลลัพธ์ของโครงการ นั่นคือความรับผิดชอบต่อผลลัพธ์ที่ออกมาในโครงการร่วมกัน 

ใน Agile Project เน้นการทำงานในรูปแบบ Generalizing Specialists ที่ทีมงานต้องสามารถมีความเชี่ยวชาญได้หลายอย่างและสามารถทำงานได้หลากหลายบทบาท การทำงานในรูปแบบนี้แตกต่างจาก Traditional Specialists ซึ่งคือผู้เชี่ยวชาญที่เก่งด้านใดด้านหนึ่ง ซึ่งการใช้ผู้เชี่ยวชาญที่ทำงานได้ด้านเดียวส่งผลต่อการทำงานที่สามารถติดปัญหาได้ เช่น เวลาที่งานต้องเปลี่ยนมือจากผู้เชี่ยวชาญคนหนึ่งไปยังผู้เชี่ยวชาญอีกคนหนึ่ง (Hand off) ส่งผลต่อการเสียเวลาในการส่งมอบงาน นอกจากนี้ การทำงานในลักษณะการส่งต่อส่งผลให้มีการเกิดปัญหา (Bottleneck) และก่อให้เกิดการ Delay ของงานได้ การทำงานในลักษณะ Generalizing Specialists เน้นการทำงานเป็นทีม เช่น การทำงานระหว่าง Tester กับ Coder เพื่อช่วยกันแก้ปัญหาและมี Throughput (ปริมาณงาน) ที่มากกว่าการทำงานในลักษณะที่ต้องมีการส่งต่อจากคนหนึ่งสู่อีกคนหนึ่ง (Linear) 

 

ในโครงการ Agile การมอบอำนาจให้กับทีมงานทำได้โดย วิธีการ Self-Organizing และ Self-Directing กระบวนการ Self-Organizing คือการมอบอำนาจให้ทีมงานทำการออกแบบและตัดสินใจการทำงานด้วยตัวเอง โดยผู้บริหารโครงการเพียงแค่อธิบายเป้าหมายของโครงการ (What) แต่ทีมงานเป็นคนที่กำหนดว่าการทำงานในการบรรลุเป้าหมายนั้นๆ ต้องทำอย่างไรบ้าง (How) รูปแบบ Self-Organizing ตรงกันข้ามกับการทำงานที่เป็นลักษณะ Command and Control ที่ Project Manager สั่งการรูปแบบการทำงานไปยังทีมงาน สำหรับ Self-Directing คือทีมงานมีอำนาจในการตัดสินใจแก้ปัญหาต่างๆ ได้เอง นอกจากนี้ Agile Team เน้นในการสร้างบรรยากาศการทำงานที่ทำให้ทีมงานมีความรู้สึกปลอดภัยต่อการทำผิดพลาด โดยมองที่ความผิดพลาดคือโอกาสของการเรียนรู้ ถ้าบรรยากาศการทำงานเป็นไปในลักษณะที่ทำให้ทีมงานไม่รู้สึกปลอดภัย มีความกลัวต่อการทำผิดพลาด ก็จะส่งผลให้มีงานไม่กล้าที่จะมีความคิดสร้างสรรค์ หรือมี Idea ใหม่ๆ ในการทำงาน ดังนั้นผู้บริหารควรสร้างบรรยากาศในการทำงานที่ทำให้ทีมงานกล้าที่จะทดลองสิ่งใหม่ๆ โดยไม่กังวลต่อความผิดพลาดที่อาจจะเกิดขึ้น มีการให้รางวัลต่อแนวคิดและการแก้ปัญหาในรูปแบบใหม่ๆ 

สุดท้ายความขัดแย้งในการทำงานเป็นเรื่องปกติที่เกิดขึ้น ถ้าเป็นความขัดแย้งในเรื่องความเห็นในการทำงานมิใช่เรื่องส่วนตัว ความขัดแย้งในการทำงานเป็นสิ่งที่ดีเพราะนำไปสู่ความคิดเห็นที่หลากหลาย ถ้าทีมงานไม่มีความขัดแย้งเลยแสดงว่าทีมงานไม่ Care ต่อผลของงานหรือทีมงานหลีกเลี่ยงความขัดแย้ง Constructive Disagreement คือความขัดแย้งด้านความคิดเห็นที่ก่อให้เกิดประโยชน์ต่อทีม เพราะ Constructive Disagreement นำไปสู่การตัดสินใจที่ดี และทีมงานให้การสนับสนุน (Buy-in) โดย Constructive Disagreement จะเริ่มจากความแตกต่างในด้านความคิดเห็น (Divergence) และหลังจากที่มีการอภิปรายโต้เถียงด้วยเหตุผลนำไปสู่ ข้อตกลงร่วมกัน (Convergence) ส่งผลให้การทำงานของทีมมีประสิทธิภาพมากยิ่งขึ้น

 

เรื่อง รองศาสตราจารย์ พ.ต.ต.ดร.ดนุวศิน เจริญ

 

Last modified on Wednesday, 16 August 2017 08:15