การ Lean กระบวนการพัฒนาซอฟต์แวร์ #1 การกำจัดของเสีย

การ Lean กระบวนการพัฒนาซอฟต์แวร์ #1 การกำจัดของเสีย

 

 

ของเสียในกระบวนการซอฟต์แวร์มีเยอะแยะมากมาย ทั้งที่มองเห็น เช่น เอกสารที่ทำไว้แต่ไม่มีใครอ่าน โปรแกรมที่มี 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

แบ่งปันโดย : ซากุระ พุทธหล่อง

 958
ผู้เข้าชม
สร้างเว็บไซต์สำเร็จรูปฟรี ร้านค้าออนไลน์