People Management and Team Organization

1. People Management and Team Organization Seree Chinodom seree@buu.ac.th

2. การจัดการเพื่อสร้างซอฟต์แวร์การจัดการเพื่อสร้างซอฟต์แวร์ • ในหน่วยงานที่สร้างซอฟต์แวร์ประกอบด้วยคนหลายทักษะเพื่อทำงานร่วมกันเช่นนักโปรแกรม นักวิเคราะห์ นักออกแบบ ผู้เชี่ยวชาญที่เป็นเจ้าของงานและผู้เกี่ยวข้องอื่น ๆ โดยคนเหล่านี้ต้องทำงานเป็นทีม • การจัดโครงสร้างของทีมขึ้นอยู่กับองค์ประกอบ • จำนวนคนในทีม • ประสบการณ์ของแต่ละคน • ประเภทโครงการ • ความแตกต่างระหว่างบุคคลที่เกี่ยวข้อง • รูปแบบการทำงานของแต่ละคน องค์ประกอบเหล่านี้มีผลกระทบต่อรูปแบบของการบริหารและการจัดการโครงการ

3. การจัดการเพื่อสร้างซอฟต์แวร์(2)การจัดการเพื่อสร้างซอฟต์แวร์(2) • การพัฒนาซอฟต์แวร์ขนาดใหญ่ จะประกอบด้วยงานหลายๆลักษณะ สิ่งที่สำคัญยิ่งที่ผู้บริหารจะต้องรับผิดชอบคือการประสานงานระหว่างกลุ่มบุคคลที่ทำงานต่างประเภทกัน ให้สามารถผลิตผลงานตามที่กำหนดได้ • การประสานงานสามารถทำได้หลายแบบ แต่ละแบบจะมีอิทธิพลหรือแรงผักดันจากภายในและภายนอกเป็นตัวแปร ที่ทำให้การประสานงานมีรูปแบบที่ต่างกัน • แรงผลักดันภายใน เกิดจากคุณลักษณะของโครงการเอง • แรงผลักดันภายนอก เกิดจากสิ่งแวดล้อมภายนอกองค์กร

4. การจัดการเพื่อสร้างซอฟต์แวร์(3)การจัดการเพื่อสร้างซอฟต์แวร์(3) • การพัฒนาซอฟต์แวร์จำเป็นต้องทำงานเป็นทีม สมาชิกในทีมต้องประสานงาน สื่อสารการตัดสินใจ • โครงงานเล็กๆอาจประกอบด้วยสมาชิก 2 - 3 คน โครงงานใหญ่ๆจำนวนคนจะเพิ่มตามไปด้วยทำให้การบริหารยาก • ถ้าทีมงานใหญ่เกินไป การประสานงานทำได้ยาก ควรแบ่งเป็นทีมย่อย ๆโดยเร็ว

5. การจัดการบุคลากร(People Management) • ทีมงานประกอบด้วยบุคคลหลายกลุ่มที่มีความสามารถเฉพาะด้าน หลากหลายสไตล์ในการทำงาน ผู้บริหารต้องทำทุกวิถีทางให้แต่ละคนทำงานร่วมกันได้ และให้จุดมุ่งหมายของแต่ละคนประสบผลสำเร็จ • วัตถุประสงค์ของโครงการจะต้องกำหนดไว้แต่แรกและต้องชี้แจงให้สมาชิกทุกคนในทีมเข้าใจอย่างแจ่มชัด • ระหว่างโครงการกำลังกำลังพัฒนาจะต้องมีการประเมินผลตลอดเวลา กิจกรรมบางอย่างวัดปริมาณความก้าวหน้ายาก • ตัวบ่งชี้ที่สำคัญในการพัฒนาซอฟต์แวร์มักจะกำหนดโดยจำนวนคำสั่ง(line of code)ที่ส่งให้ลูกค้าที่เขียนโดยนักโปรแกรม 1 คนในหนึ่งเดือน(Per man-month)

6. อันตรายของการใช้วิธีนี้คือแต่ละคนพยายามที่จะเขียนคำสั่งให้มาก ๆ • เนื่องจากค่าใช้จ่ายในการพัฒนาซอฟต์แวร์นั้นขึ้นกับจำนวนคำสั่ง การเขียนโปรแกรมสั้น ๆหรือการใช้ส่วนของโปรแกรมที่มีอยู่(Reuse)จะช่วยลดค่าใช้จ่าย

7. กลไกการประสานงาน(Coordination mechanisms) • Mintzberg แบ่งรูปแบบการจัดองค์กรออกเป็น 5 แบบ แต่ละแบบจะสะท้อนถึงองค์ประกอบและสิ่งแวดล้อมขององค์กร (1) Simple structure • เป็นโครงสร้างแบบง่าย มีผู้จัดการรับผิดชอบ 1-2 คน มีคนหลักหนึ่งคนรับผิดชอบทุกอย่าง • กลไกการประสานงาน เรียกว่าการตรวจตราโดยตรง(Direct Supervision) • กลไกแบบนี้มีในองค์กรที่ตั้งใหม่และมีขนาดเล็ก การติดต่อประสารงานไม่มีพิธีรีตรองและไม่เป็นทางการ

8. กลไกการประสานงาน (2) Machine Bureaucracy • เมื่อขอบเขตและเนื้อหาของงานมีความชัดเจน การทำงานก็มักทำตามคำสั่งหรือขั้นตอนที่กำหนดไว้ชัดเจนล่วงหน้า • การติดต่ออย่างมีพิธีการและความเชี่ยวชาญเฉพาะด้านจะมีเพียงเล็กน้อย • การประสานงานจะผ่านกระบวนการที่เป็นมาตราฐานของระบบงานเอง(Standardization of work processes)

9. กลไกการประสานงาน (3)Divisionalized form • เป็นการจัดองค์กรที่แต่ละแผนกหรือแต่ละโครงการได้รับอำนาจในการดำเนินการเอง การตัดสินใจเป็นความรับผิดชอบของแผนก • การประสานงานกระทำผ่านมาตราฐานของผลงานที่ทำ(Standardization of work output) • การควบคุมทำโดยประเมินผลงานเป็นระยะๆ

10. กลไกการประสานงาน (4) Professional bureaucracy • ถ้าผลลัพธ์และเนื้องานกำหนดแน่นอนและชัดเจนไม่ได้ การประสานงานต้องทำโดยประสบการณ์และความเชี่ยวชาญของผู้ปกิบัติ(Standardization of worker skills) ผู้ปกิบัติมีอิสระในการทำงานตามทีตนเองเห็นสมควร (5) Adhocracy • ในโครงการใหญ่หรือโครงการที่ต้องใช้แนวคิดและวิธีการใหม่ๆเสมอ การแบ่งความรับผิดชอบจะแบ่งตามกลุ่มของผู้เชี่ยวชาญแต่ละด้าน • การประสานงานจะทำโดย Mutual Adjustment

11. รูปแบบการจัดการและการบริหาร(Management styles) • ทฤษฎีการจัดการของ Raddin เน้นว่ารูปแบบหรือสไตล์การบริหารและการจัดการจะขึ้นอยู่กับองค์ประกอบภายในเป็นหลัก Raddin กำหนดความแตกต่างของการจัดการบุคคลออกเป็น 2 มิติคือ (1) Relation directedness เกี่ยวข้องกับความตั้งใจของแต่ละบุคคลและความสัมพันธ์ของตนเองกับบุคคลอื่นภายในองค์กร (2) Task directedness เกี่ยวข้องกับความตั้งใจต่อผลลัพธ์ที่จะทำให้สำเร็จและวิถีทางที่ผลลัพธ์จะได้นำไปสู่ความสำเร็จ

12. Task directedness Relation Directedness

13. (1) Separation style • เหมาะสมกับงานที่ปฏิบัติประจำวัน(Routine) • ประสิทธิภาพในการทำงานถือเป็นสำคัญ ผู้บริหารทำหน้าที่เป็นผู้บังคับบัญชาที่ยึดกฏ ระเบียบและวิธีปฏิบัติที่เคร่งครัด • รุปแบบนี้คล้ายกับ Machine Burcaucracy ของ Mintzberge

14. (2) Relation style • เหมาะสมที่สุดกับงานที่บุคลากรไดัรับแรงจูงใจ(กระตุ้น) ให้ทำงานร่วมกันและต้องได้รับการอบรม • งานที่ทำอยู่ภายใต้ความรับผิดชอบแต่ละคนและไม่เป็นงานประจำ แต่เป็นงานที่มีการเปลี่ยนแปลงและต้องใช้ความสามารถเฉพาะด้าน • รูปแบบนี้คล้ายกับแบบ Adhocracy ของ Mintzberg

15. (3) Commitment Style • เป็นรูปแบบที่เหมาะสมกับการทำงานภายใต้ความกดดัน คล้ายคลึงกับแบบProfessional bureaucracy ของ Mintzberg

16. (4) Integration Style • เหมาะสมกับงานที่มีผลลัพธ์ที่ไม่แน่นอน • ลักษณะงานจะเป็นแบบที่ต้องอาศัยการสำรวจ ทดลองและไม่ขึ้นแก่กัน การบริหารจะต้องคอยกระตุ้นและสร้างแรงจูงใจให้กับผู้ทำงาน

17. การจัดทีมงานเพื่อพัฒนาซอฟต์แวร์ (Team Organization) • โครงการพัฒนาซอฟต์แวร์ขนาดใหญ่ ต้องจัดเป็นทีมงาน ซึ่งประกอบไปด้วย • Project managers • Tester • Designers • Programmers • etc • บางคนอาจทำหลายหน้าที่สำหรับโครงงานขนาดเล็ก ส่วนโครงงานขนาดใหญ่จะทำหน้าที่เดียว • ทีมผู้ทดสอบจะต้องจะต้องเป็นคนละกลุ่มกับผู้พัฒนา • ทีมที่ประกันคุณภาพจะต้องไม่เกี่ยวข้องกับการพัฒนา

18. รูปแบบการจัดทีมเพื่อพัฒนาโครงการซอฟต์แวร์รูปแบบการจัดทีมเพื่อพัฒนาโครงการซอฟต์แวร์ (1) Hierarchical organization T D E A B C Subsystem A Subsystem B Subsystem C QA Testing

19. Hierarchical organization • การจัดทีมแบบ Hierarchy รูปสี่เหลี่ยมแทน Subteam หรือทีมย่อยที่ปฏิบัติงานจริงตามงานที่ได้รับมอบหมาย วงกลมแทนผู้จัดการ • จัดแบ่งเป็น 2 ระดับ ในระดับล่างแต่ละทีมจะรับผิดชอบงานที่แตกต่างกันของโครงการ ผู้จัดการแต่ละคนมีหน้าที่ประสานงานระหว่างสมาชิกภายในทีมของตนเอง ในระดับสูงขึ้น(T) การประสานงานกับทีมอื่นจะต้องทำในระดับนี้ • การจัดองค์การแบบนี้สะท้อนให้เห็นถึงภาพรวมของโครงการที่พัฒนา มีงานหลัก 3 ส่วน จึงต้องมีทีมย่อยพัฒนา 3 ทีมและมีทีมประกันคุณภาพและทดสอบ

20. Hierarchical organization • ผู้ที่อยู่ในระดับสูงของ Hierarchy มักจะไม่เกี่ยวข้องกับงานที่ปฏิบัติโดยตรง ดังนั้นแนวโน้มที่จะใช้กลไกการประสานงานแบบมาตราฐานเป็นหลักโดยการผนวกเอากฏหรือวิธีการเหมือนแบบ Machine bureaucracy หรือการวัดผลลัพธ์ ดังเช่นใน divisionalized configuration ในกรณีดังกล่าวแรงกดดันจากภายในและภายนอกอาจขัดแย้งกันได้ในระดับล่าง • จุดวิกฤติของการจัดทีมงานแบบHierarchy คือความแตกต่างหรือระยะห่างระหว่างระดับบนสุดและระดับล่างสุด

21. Hierarchical organization • ระดับล่าง : เราประสบปัญหาอย่างมากในการImplement โมดูล X • ระดับที่ 1 : มีปัญหาบางประการกับโมดูล X • ระดับที่ 2: มีความก้าวหน้าอย่างต่อเนื่อง ผมมองไม่เห็นว่ามีปัญหาอะไร • ระดับสูง : ทุกอย่างเป็นไปตามแผนที่วางไว้ ปัญหาที่เกิดในลักษณะนี้มักพบในทีมงานที่การรายงานกำหนดเป็นสายงานของการประเมินผล การปฏิบัติงานแต่ละระดับ ที่เกิดจากการแต่งเติมเพื่อให้ผลงานของตนออกมาดีแต่ถ้าข้อมูลเหล่านั้นผ่านไปกับบุคคลที่ไม่มีผลโดยตรงกับการประเมินแล้วข้อมูลที่ได้จะน่าเชื่อถือมากกว่า

22. 2. Matrix organization • ใช้ในองค์กรที่ไม่ได้พัฒนาซอฟต์แวร์เป็นงานหลัก แต่ซอฟต์แวร์เหมือนผลพลอยได้ • บุคลากรต่างแผนกกันจะถูกจัดให้ไปร่วมทีมพัฒนาด้วยกัน • การจัดองค์กรแบบนี้ยากที่จะควบคุมความก้าวหน้า พนักงานแต่ละคนต่างพยายามทำงานให้ถูกใจหัวหน้าหลายคน • องค์กรทีสร้างซอฟต์แวร์โดยตรงอาจจัดทีมงานแบบ Matrix organization ก็ได้ แต่ละกลุ่มหรือทีมย่อยจะมีขนาดเล็ก และมีความเชี่ยวชาญเฉพาะด้าน อาจมีมากกว่า 1 ทีมย่อยที่มีความเชี่ยวชาญแบบเดียวกัน

23. Matrix organization • การจัดกลุ่มจัดตามความรู้ความสามารถของสมาชิกในกลุ่ม โครงการจะประกอบด้วยกลุ่มผู้เชี่ยวชาญเฉพาะด้านที่แตกต่างกัน แต่ละคนจะถูกจัดบนพื้นฐานของ 2 แกน แกนหนึ่งแทนความเชี่ยวชาญของแต่ละคน ส่วนอีกแกนหนึ่งแทนโครงการที่บุคคลนั้นถูกกำหนดให้ทำ

24. Matrix organization

25. 3. Chief Programmer Team • เสนอเมื่อปี ค.ศ. 1970 • องค์ประกอบหลักประกอบด้วยคน 3 คน • คนที่ 1 หัวหน้านักโปรแกรม (Chief programming)เป็นหัวหน้าทีมมีหน้าที่ในการออกแบบและ Implement ส่วนที่เป็นหัวใจสำคัญของระบบ • คนที่ 2 ผู้ช่วยหัวหน้านักโปรแกรม ทำหน้าที่ช่วยหรือบางครั้งก็ทำหน้าที่แทนหัวหน้านักโปรแกรม • คนที่ 3 คือบรรณารักษ์หรือธุรการที่จะทำหน้าที่รับผิดชอบของงานธุรการ งานบริหารและงานเอกสารทุกชนิด • นอกจาก 3 คนนี้แล้วอาจเพิ่มผู้เชี่ยวชาญเฉพาะด้านอีก 1-2 คนเข้าไปเป็นทีมของหัวหน้านักโปรแกรมก็ได้ การจัดทีมลักษณะนี้หัวหน้าทีมจะต้องมีความรู้ทางด้านเทคนิคและการบริหาร

26. หลักทั่วไปในการจัดรูปแบบของทีมงานหลักทั่วไปในการจัดรูปแบบของทีมงาน • จากการวิจัยถึงผลผลิตของโครงงานพัฒนาซอฟต์แวร์พบว่า องค์ประกอบที่เกี่ยวกับความสามารถของทีมงานจะมีผลอย่างมากต่อผลลัพธ์ที่ได้ องค์ประกอบที่สำคัญคือ • ศิลธรรม • การทำงานเป็นกลุ่ม • รูปแบบการจัดการ • การใช้ภาษาระดับสูง • การทำให้ผลผลิตไม่ซับซ้อน

27. หลักทั่วไปในการจัดรูปแบบของทีมงานหลักทั่วไปในการจัดรูปแบบของทีมงาน 1. ใช้คนน้อยแต่มีคุณภาพ 2. กำหนด จัดสรร และแบ่งงานให้เหมาะสมกับความสามารถของคนที่มี • ผู้ที่เก่งทางเทคนิคควรให้มีความก้าวหน้าทางเทคนิค ไม่ควรให้ทำหน้าที่ผู้บริหาร 3.องค์กรจะต้องดึงความสามารถเฉพาะด้านของบุคลากรที่มีประสบการณ์ออกมาให้มากที่สุด • บุคคลที่ทำงานในองค์กรนานย่อมมีความเชี่ยวชาญในด้านใดด้านหนึ่งโดยเฉพาะ • บุคลากรบางคนทำงาน4-5 ปีความรู้ความสามารถที่มีกลายเป็นเรื่องล้าสมัย บุคลากรประเภทนี้ไม่ควรจัดเข้าในทีมงานที่ต้องใช้เทคนิคหรือวิธีการใหม่ ๆ

28. หลักทั่วไปในการจัดรูปแบบของทีมงานหลักทั่วไปในการจัดรูปแบบของทีมงาน 4. เลือกสมาชิกที่สามารถสร้างความสมดุลและความกลมกลืนในทีมได้ • ไม่ใช่จัดทีมที่มีเฉพาะผู้เชียวชาญเพียง 2 - 3 คนแล้วถือว่าดี 5. ขจัดบุคคลที่ไม่เหมาะสมออกจากทีม • ถ้าพบว่าทีมงานไม่สามารทำงานประสานกันได้ เมื่อดูผลระยะหนึ่งแล้วไม่ดีขึ่น ก็ควรรีบจัดการขจัดออก ถ้าปล่อยไว้นานจะเกิอผลเสีย