7 ของเสียในการพัฒนาซอฟต์แวร์แบบลีนและวิธีการป้องกัน

การคิดกระบวนการแบบลีนจัดลำดับความสำคัญในการกำจัดและลดการรวบรวมของเสีย แม้จะมีแนวทาง "ลีน" ที่นำมาใช้โดยบริษัทขนาดใหญ่ แต่แนวทางปฏิบัติ "ของเสีย" ที่เป็นมาตรฐานยังคงมีอยู่เนื่องจาก "ลักษณะที่ชัดเจน" ลักษณะที่ฝังลึกในการปฏิบัติของมนุษย์และขององค์กรนั้นดื้อรั้นจนกว่าจะมีแนวทางที่เข้มงวด

ของเสียคืออะไร?

สิ่งใดก็ตามที่ต้องใช้ทรัพยากร/เวลาหรือความพยายามแต่ไม่ให้ผลลัพธ์ที่เกี่ยวข้องในประสิทธิภาพหรือรายได้จะเรียกว่า "ความสูญเปล่า"

ในที่สุด ขั้นตอน "การลดของเสีย" ได้รับการออกแบบและแนะนำเพื่อเพิ่มประสิทธิภาพและผลลัพธ์ของทีม

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

1. งานที่ทำเสร็จแล้วบางส่วน

หากงานก่อนหน้านี้ไม่เริ่มต้นใหม่ แสดงว่าความพยายามนั้นสูญเปล่า

งานใดๆ ที่จนแล้วเสร็จ/เสร็จสิ้นไม่ได้เพิ่มคุณค่าให้กับลูกค้า ดังนั้นจึงเป็นการเสียเวลาและความท้าทายในการบำรุงรักษารหัสหากถูกระงับ

ตัวอย่างร่วมสมัยคือเมื่อลูกค้าต้องการการปรับเปลี่ยนหรือคุณลักษณะพิเศษของผลิตภัณฑ์ ธุรกิจมุ่งมั่นที่จะทำให้เสร็จโดยด่วน ทีมพัฒนาต้องหยุดงานต่อเนื่องและปฏิบัติตามข้อกำหนด ในหน้าเดียวกัน หากงานก่อนหน้านี้ไม่เริ่มต้นใหม่ แสดงว่าต้องเสียความพยายามเปล่าๆ

หรือ

เอกสารที่ไม่ได้เข้ารหัส: ข้อกำหนดมีรายละเอียดอย่างละเอียดแต่ยังไม่มีการดำเนินการ

จะลดขยะนี้ได้อย่างไร?

• ควรเน้นที่ "การตกแต่ง" ไม่ใช่แค่ "การเริ่มต้น" ของโครงการ
• ลดอายุงานระหว่างดำเนินการ
• งดการรอสเปคแบบละเอียดทุกความต้องการจนกว่าทีมงานจะพร้อมดำเนินการตามความพยายาม (มันจะไม่เป็นเหตุให้สูญหาย)

2. กระบวนการพิเศษ

กระบวนการเพิ่มเติมหรือเอกสารที่ยังไม่ได้อ่านซึ่งไม่ได้สื่อถึงคุณค่าในทางปฏิบัติและยืดเวลาหรือความสำเร็จของตลาดผลิตภัณฑ์โดยไม่จำเป็นถือเป็นการสูญเปล่า

อย่างไรก็ตาม นโยบายทางธุรกิจมักกำหนดให้เอกสารดังกล่าวมีเอกสารจำนวนมากที่ยังไม่ได้อ่าน ความพยายามเหล่านั้นฟุ่มเฟือย

ตัวอย่างทั่วไป:

• รายละเอียดเอกสารที่ไม่จำเป็น
• การจัดการหรือการวางแผนเพิ่มเติมโดยไม่ต้องดำเนินการ

จะลดได้อย่างไร?

องค์กรสามารถแยกแยะความแตกต่างระหว่างสาเหตุ/ความพยายามที่สูญเสียไปและสิ่งที่นำคุณค่ามาสู่ตารางได้ การมุ่งเน้นควรอยู่ที่การสร้างผลลัพธ์ที่มีความหมายและความพยายามของช่องทางในการทำงานที่ "มีคุณภาพ" มากขึ้นโดยการจำกัดงาน "ปริมาณ"

3. คุณสมบัติพิเศษ

คุณลักษณะหรือคุณลักษณะที่มีมูลค่าต่ำใดๆ ที่เพิ่มสำหรับ/โดยลูกค้าแต่ไม่ได้ร้องขอ/ไม่ได้มีส่วนทำให้รายได้เพิ่มขึ้นเป็นการเปลืองแรงเปล่า

ธุรกิจทำให้เกิดข้อผิดพลาดในการพัฒนานี้เมื่อพวกเขาเพิ่มคุณสมบัติที่จะไม่ได้ใช้หรือออกกำลังกายมากนัก คุณลักษณะใหม่นี้ไม่ได้ใช้งานจริงและเพิ่มความซับซ้อนของแอปพลิเคชัน

กฎซอฟต์แวร์ 80/20 มีบทบาทสำคัญ - 80% ของผู้ใช้ใช้คุณลักษณะเพียง 20% เท่านั้น ดังนั้นควรเน้นที่การทำให้ฟีเจอร์ 20% เหล่านี้เป็นอันดับต้นๆ เพื่อรักษาผู้ใช้ที่มีอยู่

รหัสเพิ่มเติมมีข้อเสีย:

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

จะลดขยะนี้ได้อย่างไร?
มุ่งเน้นที่การพัฒนาแบบวนซ้ำ ซึ่งหมายถึงระหว่างการเปิดตัวผลิตภัณฑ์เริ่มต้น สร้างคุณลักษณะหลักที่มีประสิทธิภาพ ซึ่งจะกำหนด USP ของแอปพลิเคชันของคุณ

มุ่งเน้นที่การทำให้ผลิตภัณฑ์ใช้งานได้จริงและยืนยันการเรียนรู้ถึงความก้าวหน้าอย่างต่อเนื่องของผลิตภัณฑ์ นอกจากนี้ ให้สร้างคุณลักษณะที่เหมาะสมตามการวิเคราะห์ตลาด พฤติกรรมผู้บริโภค และข้อเสนอแนะของคุณ

4. การสลับงาน

การมอบหมายงานหลายอย่างให้กับผู้คนเมื่อพวกเขาไม่สบายใจกับมัน และขัดขวางกระบวนการที่มีอยู่อาจใช้เวลานานมาก วิธีที่มีประสิทธิภาพที่สุดในการทำงานหนึ่งหรือสองอย่างให้เสร็จลุล่วงคือการทำให้เสร็จทีละงาน

ขณะสลับไปมาระหว่างงาน มีค่าใช้จ่ายเล็กน้อยในการปิดงานที่มีอยู่และรับโมเมนตัมในอีกงานหนึ่ง ซึ่งเรียกว่าการสลับบริบท และหากคุณคาดว่าจะมีการเปลี่ยนจากที่หนึ่งไปยังอีกที่หนึ่งอย่างต่อเนื่อง สวิตช์เนื้อหาเหล่านี้จะสะสมซึ่งทำให้ “ผลลัพธ์” หรือ “เวลาการส่งมอบ”

จะลดได้อย่างไร?

เรียบง่าย - ทีละอย่าง

• ลดการสลับเนื้อหา
• ลดการรบกวนหรือสิ่งรบกวนสมาธิให้น้อยที่สุด
• เลื่อนสิ่งที่ไม่สำคัญออกไป
• จัดสรรทรัพยากรเป็นโครงการครั้งละหนึ่งโครงการ

5. รอ/ล่าช้า

การพึ่งพาการอนุมัติควรกำหนดเวลาไว้เป็นหลักในระหว่างแผนงานผลิตภัณฑ์ หากไม่มีการจัดสรรช่วงเวลาเฉพาะ ให้เตรียมพร้อมสำหรับการตอบกลับและข้อเสนอแนะที่ล่าช้า ความล่าช้ายังทำให้ผู้บริโภคไม่รับรู้ถึงมูลค่าที่แท้จริงของผลิตภัณฑ์อีกด้วย แต่ในฐานะนักพัฒนาหรือนักออกแบบ คุณต้องรอการอนุมัติเกี่ยวกับงานที่ทำ ดังนั้นคุณจึงไม่สามารถหลีกเลี่ยงเวลาล่วงเลยไปได้เลย

คุณจะทำอย่างไรเพื่อลดสิ่งนี้

• เลือก/มอบหมายบางสิ่งขณะรอคำติชมที่มีอยู่
• จัดสรรเวลาในการป้อนข้อมูลและทบทวน
• พิจารณาการโทรด่วน สนทนาแบบเห็นหน้ากันแทนที่จะส่งอีเมลถึงการเปลี่ยนแปลง
• ข้อเสนอแนะปกติ

6. การเคลื่อนไหว

หากทีมพัฒนาหรือทีมวิจัยกระจัดกระจายไปกับข้อมูลที่ได้มาและไม่ได้ทำเครื่องหมาย/ติดป้ายกำกับอย่างเหมาะสม อาจต้องใช้เวลาชั่วนิรันดร์เพื่อขจัดความสับสนและการเข้ามา หากข้อมูลถูกใส่ผิดที่ทุกครั้งที่มีการส่งมอบ มันจะขัดขวางผลลัพธ์อย่างมาก

จะลดได้อย่างไร?

• การกำหนดป้ายกำกับหรือทรัพยากรที่ได้รับ
• ลดเวลาการตอบกลับ
• การทำงานร่วมกันแบบเห็นหน้า

7. ข้อบกพร่อง

ปริมาณของเสียที่เกิดจากข้อบกพร่อง = (ผลกระทบของข้อบกพร่อง) x (เวลาที่ตรวจไม่พบ)

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

คุณจะทำอย่างไรเพื่อลดสิ่งนี้

• การทดสอบทันที
• บูรณาการอย่างต่อเนื่อง
• ทดสอบผลิตภัณฑ์และเผยแพร่โดยเร็ว