ของเสียในกระบวนการซอฟต์แวร์มีเยอะแยะมากมาย ทั้งที่มองเห็น เช่น เอกสารที่ทำไว้แต่ไม่มีใครอ่าน โปรแกรมที่มี Bug ต้องเสียเวลาและค้นทุนมาแก้ไข หรือของเสียที่มองไม่เห็น เช่น เวลาประชุมที่ยาวนานและไร้ความหมาย การส่งงานให้หัวหน้าอนุมัตแต่หัวหน้าไม่มีความเชี่ยวชาญด้านนั้นเลย เวลาที่เสียไปกับการอ่านงานออกแบบที่ไม่เข้าใจ เป็นต้น สิ่งเหล่านี้เมื่อพอกพูนไว้มากๆ ก็ส่งผลกระทบโดยตรงทำให้มีต้นทุนในการทำงานที่สูงขึ้น จนถึงการเลื่อนวันส่งมอบงานที่สร้างความไม่พึงพอใจเป็นอย่างมากให้กับลูกค้า
กำจัดของเสีย
ในกระบวนการลดของเสียของ Toyota ได้มีการนิยามของเสียหลักๆ ไว้ 3 ตัว ได้แก่
- Muda สิ่งที่ทำแล้วไม่ก่อผล, ไม่ได้นำไปใช้ ถึงแม้ว่าจะดีขนาดไหนก็ตาม
- Mura สิ่งที่ทำแล้วไม่มีความสม่ำเสมอและไม่ได้ทำอย่างต่อเนื่อง
- Muri สิ่งที่ไม่มีเหตุผลหรือความจำเป็นที่จะทำ
ของเสียที่ควรกำจัด (Tom and Mary Poppendieck) ในกระบวนการพัฒนาซอฟต์แวร์
1. Coding หรือเอกสารที่ไม่จำเป็น
List รายการเอกสาร หรือสิ่งที่จะต้องทำในงานออกมาทั้งหมด, จัดลำดับความสำคัญ, สัดส่วนของเวลาที่ใช้ ในแต่ละส่วนงาน แล้วตัดทอนส่วนที่ใช้เวลานานแต่ไม่มีความจำเป็นออกหรือเลื่อนให้อยู่ลำดับท้ายๆ
2. เริ่มต้นงานใหม่ทั้งที่งานเก่าควรจะทำให้เสร็จ
จัดลำดับ Task ให้ชัดเจน, ระบุ Due Commitment แล้วทำแต่ละส่วนงานให้สำเร็จ และระบุเป็นข้อกำหนดว่า Taskลักษณะใดควรถูกจัดลำดับก่อน-หลัง, ชี้แจงให้ผู้ที่เกี่ยวข้องรับทราบและปฏิบัติอย่างเคร่งครัด
3. ความคลาดเคลื่อน, ล่าช้า ของกระบวนการพัฒนาซอฟต์แวร์
List รายการ WI ของการทำงานออกมา เขียน Blue Print ที่ดีที่สุด พร้อมระบุระยะเวลาที่ใช้ในแต่ละกระบวนการ ที่สามารถสร้างเอกสารหรือสิ่งที่จำเป็นออกมาเท่านั้น
4.ความไม่ชัดเจนในกระบวนการแก้ไขความต้องการ
ระบุเป็นข้อกำหนดในขั้นตอนการแก้ไขความต้องการ โดยอาจจะกำหนดเป็น Phase ของการยื่นคำร้องการแก้ไขความต้องการ, มีการประเมินผลกระทบของการแก้ไข และลำดับความสำคัญของการแก้ไขความต้องการ
5. การบริหารแบบหลายขั้นตอน
ตัดทอนกระบวนการที่มีความซับซ้อนแต่ไม่ได้ผลสรุป เช่น การอนุมัติต่างๆ ที่รวมการตัดสินใจไว้ที่คนๆ เดียว โดยที่กระจายอำนาจในการตัดสินใจและการรับผิดชอบ ให้กับทีมงาน หรือการลดการประชุมที่ไม่มีผลสรุป และไม่มีความชัดเจน
6. การสื่อสารและการตัดสินใจที่ล่าช้า
สร้างกระบวนการในการสื่อสารที่มีความรวดเร็วและชัดเจน, ถ้ามีการอนุมัติ หรือการตัดสินใจให้กำหนดระยะเวลาในการดำเนินการให้ชัดเจน การสื่อสารควรตรงไปตรงมา ไม่อ้อมค้อมที่จะต้องแปลคำพูดหรือถ้อยคำในหลายๆขั้นตอน
7. การทำงานที่เสร็จบางส่วน (ไม่ 100%)
การทำงานไม่ 100% ทำให้ต้องเสียเวลามานั่งแก้ไข และอาจจะกระทบส่วนอื่นไม่ให้สมบูรณ์ 100% เช่นเดียวกัน,ควรกำหนดบุคคล หรือผู้รับผิดชอบในการทวนสอบงานว่ามีความสมบูรณ์หรือไม่ โดยที่การทวนสอบงานนั้น ผู้ทำงานควรทำการทวนสอบมาแล้วระดับหนึ่งเพื่อลดภาระในงานที่อาจจะมีความล่าช้า
8. ข้อบกพร่อง และปัญหาเรื่องคุณภาพ
การปล่อยให้ Software เกิด Bug ทำให้ส่งผลกระทบในหลายๆด้าน เสียทั้งต้นทุน ความพึงพอใจ และโอกาสการทำงานในส่วนอื่นๆ ดังนั้นควรสร้างกระบวนการในการตรวจสอบคุณภาพให้ชัดเจน โดยที่กำหนดเป็นนโยบายในการลดปัญหาของ Software เช่น ต้องมี Bug น้อยกว่า 20% จากการทดสอบระบบ และปรับมาตรฐานให้ดีขึ้นในแต่ละรอบของการทดสอบ
9. การสลับ, เปลี่ยนงานบ่อยครั้ง
การสลับงานมีต้นทุนแฝงตามมาเสมอ เช่น การเรียนรู้งานใหม่, การจัดเก็บงานเก่าที่เสียโอกาส ดังนั้นในการสลับงานทุกครั้งให้ประเมินถึงความเหมาะสมด้วยว่า การสลับงานก่อประโยชน์อย่างไร ในกรณีที่เป็น Multitask ให้กำหนดระยะเวลาในการดำเนินงานอย่างชัดเจน และปฏิบัติอย่างเคร่งครัด
ข้อมูลจาก : ฐิติรัตน์ กิณเรศ
ที่มา : http://www.prosoftmycrm.com/Article/Detail/21400
แบ่งปันโดย : ซากุระ พุทธหล่อง
