ความสิ้นเปลือง 7 (+1) อย่างในการพัฒนา software
Photo by Ariungoo Batzorig on Unsplash
เมื่ออาทิตย์ที่แล้วมีโอกาสได้ไปจัด workshop ให้กับลูกค้าที่ office เขาโดยในรอบนี้ระหว่างการเตรียม workshop เราก็มาคิดกันว่าจะเอา theme ไหนมาจับดีเพื่อให้เนื้อหาและกิจกรรมมันเป็นไปในทางเดียวกันให้ได้มากที่สุด ท้ายที่สุดเราก็นำเรื่องของ Lean principle มาพูด ทำให้เราได้เรียนรู้สิ่งใหม่ ๆ เปลี่ยนจากสิ่งที่เป็นแค่ buzzword ในหัวให้กลายเป็นสิ่งที่เราสามารถนำไปสอนและปรับใช้กับงานในชีวิตประจำวันได้ด้วย แต่ไม่ใช่ว่าทุกคนจะสัมผัสและเคยเข้าถึง Lean principle มาก่อน (แม้กระทั่งเราก่อนหน้านี้ยังไม่เคยเข้าถึงลึกเลย ฮ่า ๆๆ) ดังนั้นเราต้องเริ่มในสิ่งที่ทุกคนคุ้นเคยคือ Agile เพื่อประติดประต่อเรื่องให้ไปในทางเดียวกันได้
เริ่มที่ Agile ก่อน
จากหนังสือ Accelerate ซึ่งเป็นการสรุปผลจากงานวิจัยที่องค์กร DORA เกี่ยวกับองค์กรที่มีความสามารถในการปรับตัวเข้ากับความต้องการของลูกค้าได้สูง (high-performing) ว่าพวกเขามีหน้าตาเป็นยังไง ทำอะไรกันบ้าง ซึ่งสิ่งที่เค้าพบคือพวกเขาปรับปรุงและพัฒนาประสิทธิภาพการทำงานของพนักงานอย่างต่อเนื่องไม่เคยหยุดนิ่ง
The most important characteristic of high-performing teams is that they are never satisfied: they always strive to get better. High performers make improvement part of everybody’s daily work.
ประเด็นคือหลังจากปรับปรุงไปนอกจากพนักงานแล้วองค์กรจะได้อะไร แล้วจะเอาอะไรมาวัดว่ามันดีขึ้น ในงานวิจัยก็บอกต่อว่ามันวัดโดยใช้ 4-key metrics มีด้วยกัน 4 ข้อ
- Lead time for changes: ทีมของเราใช้เวลาตั้งแต่เริ่มนำงานเข้ามาจนกระทั่งส่งมอบถึงลูกค้าเท่าไร
- Deployment frequency: ทีมของเรา deploy ระบบงานบ่อยแค่ไหน
- Mean time to restore (MTTR): เมื่อระบบงานเกิดปัญหา เช่น service outage ทีมของเราใช้เวลาเท่าไรถึงในการแก้ไขให้ระบบกลับมาทำงานได้เหมือนเดิม
- Change fail percentage: เมื่อนำระบบงานขึ้น production มีโอกาสที่ระบบจะไม่สามารถ deploy ได้หรือเกิด major issue ขึ้นกี่เปอร์เซ็นต์
โดย 2 อันบนนั้นจะวัดเรื่องของความเร็ว (speed) และ 2 อันล่างจะวัดเรื่องของคุณภาพ (quality) สิ่งที่น่าสนใจของงานวิจัยคือองค์กรที่เป็น high-performing นั้นจะได้ต้่องทำได้ดีทั้ง speed และ quality! ทำไมมันยากขนาดนี้นะ เราเลือกทำอย่างใดอย่างนึงไม่ได้หรอ คำตอบคือไม่ได้โดยธรรมชาติ
หากเราเน้นที่ speed ผลที่ได้คือ quality ลด -> เกิดเป็น defect -> ทีมต้องกลับมาทำงานเดิมซ้ำซึ่งไม่ได้เพิ่ม business value -> เอาเวลาไปทำงานใหม่ได้น้อยลง -> speed ลด
หากเราเน้นที่ quality ผลที่ได้คือ speed ลด -> รู้ว่างาน quality ดีหรือไม่ดีได้ช้า -> ตอบไม่ได้ว่า quality ดีหรือเปล่า (ไม่นับรวมว่าลูกค้าไม่พอใจนะ)
จากกฏ Little’s law พบว่าเวลาและความเร็วมันมีความสัมพันธ์กันดังนี้
Little’s Law: improving the lead time by reducing WIP
ในทางคณิตศาสตร์ถ้าเราอยากจะให้คน ๆ นึงใช้เวลาอยู่ในคิวน้อยลง (lead time) ก็ต้องลด work-in-progress (WIP) ลง หรือเพิ่ม throughput (ส่งมอบให้เร็วขึ้น)
หากมี Defect เกิดขึ้น นั่นหมายความว่า WIP สูงขึ้นเพราะต้องไป rework -> lead time เพิ่มขึ้น -> ส่งมอบช้าลง
ดังนั้นในการพัฒนา software นั้น speed และ quality จะต้องไปด้วยกันเสมอ ไม่สามารถเปรียบเทียบหรือทำอย่างใดอย่างนึงได้ แต่โลกของความจริงคือการจะได้มาทั้ง 2 สิ่งจะต้องมีค่าใช้จ่าย ซึ่งก็คือการลงทุนใน 3 ด้านเพื่อเพิ่มประสิทธิภาพขององค์กร
- People ด้วยการเปลี่ยนแนวคิดในการพัฒนา software และการทำงานเป็นทีม
- Process ด้วยการเพิ่ม engineering practices ที่เอื้อให้การทำงานดีขึ้น ไม่ใช่ว่า งง กว่าเดิม!
- Tools ด้วยการนำเครื่องมือและ technology ที่เป็นตัวเสริมมากกว่าเป็นอุปสรรคซะเอง
เข้าเรื่อง 7 (+1) Wastes
ที่มาของ Lean คือ Toyota Production System (TPS) ซึ่งพูดถึงแนวคิดและแนวปฏิบัติในการผลิตรถยนต์ Toyota ให้ได้มีประสิทธิภาพ เนื่องจากว่าการเพิ่มประสิทธิภาพอย่างเดียวคงไม่พอ ในเวลาเดียวกันเราต้องลด “ความสิ้นเปลือง” ที่ไม่ได้ช่วยเพิ่มประสิทธิภาพหนำซ้ำยังไปลดลงอีกด้วย ซึ่ง Lean บอกไว้ว่ามันมีด้วยกัน 7 อย่าง (ไปอ่านล่าสุดมีข้อที่ 8 แล้วนะ) แต่เพื่อความเข้าใจง่าย ๆ เราจะปรับเนื้อหาให้มันเข้ากับการพัฒนา software ละกัน
1. Defects (and Rework)
- Bug ที่เกิดจาก requirement ที่ไม่ชัดเจนหรือถูก validate จาก user
- งาน design ที่ไม่ได้คำนึงถึงข้อจำกัดจนทำให้ต้องตีกลับ
- Production incident
- Test ที่ไม่ครอบคลุม
2. Waiting (and Delay)
- มี dependency ก่อนที่จะส่งงานมาให้เริ่มทำได้
- รอคน รอทีมอื่นทำงานให้เสร็จ
- รอการตัดสินใจ เช่น รอ feedback
- รอ build นาน, คอมพิวเตอร์ทำงานช้า, รอ end-to-end testing รันเสร็จ
- รอ approval จากการที่ไปขออนุญาตทำงานบางอย่าง
3. Overproduction
- ส่งมอบงานที่ยังไม่ได้จำเป็นในขณะนั้น
- ทำงานเผื่อเกินไป เกิดเป็น feature ที่ไม่มีคนใช้
- ต่างคนต่างทำงานของตัวเองให้เสร็จโดยไม่สนใจคนอื่นว่าจะติดปัญหาอะไร
- Focus แต่การแก้ปัญหาของตัวเองโดยไม่คำนึงว่าการแก้นั้นจะส่งผลกระทบต่อภาพรวมให้แย่ลงหรือไม่ (local optimization)
4. Work-in-progress (Inventory)
- งานที่เปิดแล้วไม่ปิด งานที่ค้างอยู่ในคิว ready to dev, ready to test เยอะ ๆ
- Focus ที่การให้คนไม่ว่างมีงานทำ (utilization) มากกว่าจำนวนงานที่เสร็จ (throughput)
- รู้สึกยุ่งอยู่ตลอดเวลาจนไม่มีเวลาไปพัฒนาระบบหรือตัวเอง
5. Motion (unnecessary actions)
- ประชุมเยอะเกินไปไม่มีประสิทธิภาพ
- ceremonies เยอะเกินไป
- เสียเวลาในการใช้คนทำงานเดิม ๆ ซ้ำ ๆ
- ข้อมูลบางอย่างเข้าไม่ถึง หาไม่ได้ ไม่มีคนให้ถาม
6. Context switching (Knowledge transportation)
- ต้องทำหลาย ๆ งานสลับไป-มา
- คนเดียวต้องทำหลายทีม
- มีการส่งต่องานไปต่างแผนก
- มีคนเข้า-ออกบ่อย ทีมไม่เสถียร จึงต้องใช้แรงในการ onboard-offboard
- เกิดการเปลี่ยน priority เนื่องจาก production incident งานแทรกฟ้าประทาน งานกรรมเก่า และการวางแผนที่ไม่ดี
7. Over processing (over-engineering)
- ขี่ช้างจับตั๊กแตน มีการ design ทั้งด้าน business หรือ technical ที่ไม่จำเป็น
- รู้สึกว่าเครื่องมือและ process เป็นอุปสรรคในการทำงานมากกว่าตัวช่วย
8. Underutilized talent (แถม!)
- ไม่สามารถลงมือทำงานได้เพราะขาดทักษะในการทำงาน
- ไม่สามารถทดลองไอเดียใหม่ ๆ ได้ ต้องรอไอเดียจาก “ผู้ใหญ่” อย่างเดียว
- ขาดความเข้าใจหรือคุ้นชินกับแนวคิดลัทธิการพัฒนา software ที่องค์กรใช้
หากเรานำงานของเรามากางออกในรูปแบบของ path to production แล้วเราจะเห็นได้ว่าตั้งแต่ต้นน้ำถึงปลายน้ำมีโอกาสที่จะเกิด “ความสิ้นเปลือง” ขึ้น จึงเป็นความรับผิดชอบของทุกส่วนในองค์กรและลูกค้าที่จะต้องช่วยกำจัดสิ่งเหล่านี้ออกไปเพื่อเพิ่มประสิทธิภาพในการพัฒนา software ได้อย่างต่อเนื่อง เร็ว และมีคุณภาพ