ถ้าเราวัดความสำเร็จกันที่ Scope/Quality, Schedule และ Resource แล้วหละก็ Traditional Software Development Project ส่วนใหญ่ไม่ประสบความสำเร็จ จากกราฟจะเห็นว่า 29% ล้มเหลวแบบที่ว่า Deliver อะไรออกมาไม่ได้เลย ในขณะที่อีก 57% นั้นลูกผีลูกคน อาจจะ Scope ไม่ครบ คุณภาพไม่ได้ ส่งมอบล่าช้า หรือใช้งบประมาณเกินที่กำหนด
ว่ากันตามตรงนะ สิ่งที่มองเห็นได้ชัดเจนที่สุดของคำว่าโปรเจกต์ที่ล้มเหลวในสายตาคนทั่วไปคือ “โปรเจกต์ที่ส่งมอบได้ไม่ตรงเวลา” … เห็นๆเลยว่าเราแคร์กันมากในเรื่องนี้
- ไหน ของดูหน่อยว่า End Date คือวันที่เท่าไร … ไม่เคยสนใจว่าต้องใช้งบประมาณเท่าไร
- ตอนนี้โปรเจกต์เป็นยังไง On Plan มั้ย? … ไม่เห็นเคยถามว่า Requirement จะได้ครบมั้ย
- ตอนวัดผลการทำงานของทีมก็ดูที่ On Time Project Delivery … ไม่เห็นสนใจว่าที่ทำไปจะถูกใจลูกค้าแค่ไหน
เมื่อเป็นแบบนี้มีอยู่สองอย่างที่คนในระดับ Manager ขึ้นไป (รวมทั้งตัว Project Manager เองด้วย) จะพยายามทำคือ
- โปรเจกต์นี้ห้ามดีเลย์
- ถ้ามันมีแนวโน้มจะดีเลย์ … ก็ต้องห้ามไม่ให้มันดีเลย์ด้วยการเพิ่มคนเข้าไปในโปรเจกต์นั้น จากหนึ่งเป็นสอง เป็นสาม เป็นสิบ
สุดท้าย แม่มดีเลย์หนักกว่าเก่า ฮ่าๆๆ ที่เป็นแบบนี้มันมีเหตุผลทางวิทยาศาสตร์มารองรับนะ
Brooks’s Law
“Adding manpower to a late software project makes it later., Frederick P. Brooks, Jr.”
“การเพิ่มคนเข้าไปในโปรเจกต์ที่ช้าจะทำให้มันยิ่งช้ากว่าเดิม โดย เฟเดอริก พี. บรู๊กส์, จูเนียร์”
คุณเฟเดอริกเปรียบเทียบได้เห็นภาพมากว่า “Nine women can’t make a baby in one month.” ผู้หญิงเก้าคนไม่สามารถให้กำเนิดลูกได้ในหนึ่งเดือน … มันเหมือนกับการทำ Software เลย ที่เป็นแบบนี้คุณเฟเดอริกวิเคราะห์ไว้สามสาเหตุ
- เราเข้าใจผิดว่า “คน (Men)” และ “เวลา (Month)” เป็นเรื่องที่แลกเปลี่ยนกันได้
- เราเข้าใจผิดว่างาน Software Development เป็นงานที่แบ่งแยกกันแบบเด็ดขาดได้ (Partitionable Tasks)
- และเราลืมเรื่องการสื่อสารระหว่างการทำงานไปซึ่งข้อนี้สำคัญมาก
ถ้าเราทำงานที่สามารถแบ่งแยกกันแบบเด็ดขาดสมบูรณ์ได้และไม่ต้องการการสื่อสารกันเลยระหว่างคนทำงาน ภาพที่ออกมาจะเป็นแบบนี้ … คนมาก งานเสร็จเร็วขึ้น
งาน Software Development มันไม่ใช่แบบนี้อยู่แล้วเพราะมันแบ่งแยกแบบเด็ดขาดไม่ได้หรอก ทุกงานมีความสัมพันธ์กันหมด ดังนั้นรูปเลยมีโอกาสจะออกมาเป็นแบบนี้ … คนมาก งานเสร็จช้าเท่าเดิม
หรือต่อให้เราโชคดีแบ่งงานแบบเด็ดขาดได้แต่สุดท้ายเราก็ต้องมีการสื่อสารกันระหว่างคนทำงานอยู่ดี ดังนั้นการเพิ่มคนเข้ามามากๆก็ไม่ได้ช่วยให้การทำงานเร็วขึ้นอย่างที่ฝันไว้เสมอไป … คนมาก งานเสร็จเร็วขึ้นนิดนึง
โชคร้ายหน่อยที่โลกแห่งความเป็นจริงของ Software Development Project มันอยู่ตรงนี้ การเพิ่มคนเข้ามาในโปรเจกต์จะทำให้เกิดภาระในการสื่อสารที่มากขึ้นเนื่องจาก (1) Training และ (2) Intercommunication … เด็กใหม่ทุกคนต้องได้รับการสอนงาน ไม่ว่าจะเรื่อง Technology, Code Base, Working Method, Goals, Strategies, Rules, และ Constraints เยอะแยะ คนที่มาสอนก็จะใครล่ะ? ก็คนที่ทำงานอยู่ก่อนในโปรเจกต์ มันกลายเป็นเสียเวลาไปสองเท่า
การสื่อสารระหว่างกัน (Intercommunication) ยิ่งนรกไปใหญ่ เพราะ Effort ที่เราต้องใช้นั้นจะเพิ่มเป็นทวีคูณตามจำนวนคนที่เราต้องร่วมงานและสื่อสารด้วย คุณเฟเดอริกให้สูตรคำนวณมาด้วย
Communication Effort (x times) = n(n-1)/2, where n = number of project team members
คนทำงานสามคนต้องใช้พลังในการสื่อสารมากกว่าคนทำงานสองคนถึงสามเท่า คนสี่คนใช้มากกว่าคนสองคนเป็นหกเท่า … แล้วคิดดูว่าถ้าเราทำงานกับคน 10 คนก็ปวดหัวอยู่แล้ว เพิ่มมาอีกสองคนจะยิ่งทำให้มันแย่ลงขนาดไหน
ภาพที่แท้จริงของการเพิ่มคนเข้ามาด้วยความหวังว่าจะทำให้โปรเจกต์เสร็จตรงเวลาหรือเร็วขึ้นนั้นเป็นแบบนี้ … คนมาก งานยิ่งเสร็จช้า
นับจากนี้ไป ขอให้คิดถึงเรื่องการเพิ่มคนเข้ามาระหว่างกลางโปรเจกต์เป็นทางเลือกสุดท้ายนะ … อืมมมม ไม่ดีกว่า
เลิกคิดไปเลยว่าการเพิ่มคนเข้ามาระหว่างทางเป็นทางเลือก!!!
ไปทำอย่างอื่นดีกว่า จะ Fixed-Date Release จะลด Scope การทำงาน จะ Deliver งานเป็น Phase หรืออะไรก็ได้ … อย่าเพิ่มคน มีแต่ตายกับตาย
ผมได้ข้อมูลนี้มาจากหนังสือชื่อ The Mythical Man-Month ของ Frederick P. Brooks, Jr. ซึ่งเป็นหนังสือที่ได้รับคำแนะนำเยอะมากๆ มากๆ สำหรับคนที่อยู่ในวงการ Software Development โดยเฉพาะอย่างยิ่งคนที่อยากทำงานในตำแหน่งผู้จัดการ
หนังสือเล่มนี้เขียนตั้งแต่ปีค.ศ. 1975 และแก้ไขเพิ่มเติมอีกทีตอนปีค.ศ. 1995 … แต่เนื้อหายังทันสมัยมาถึงทุกวันนี้ คุณเฟเดอริกสุดยอดเจงๆ