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

August 16, 2017 376

เมื่อครั้งที่แล้วผมได้พูดถึงลักษณะของโครงการ 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