ในช่วงที่ผ่านมา มีคนพูดถึงประเด็น เวลามีมูลค่าบ่อยมาก อาจเป็นเพราะ เร็วๆนี้ผู้ว่าชัชชาติได้พูดถึงกรณีมูลค่าของเวลาในการสร้างรถไฟความเร็วสูง ซึ่งก็ตรงกับการพัฒนาซอฟต์แวร์เช่นกัน
Sponsored by: https://codingugly.com, Tech Leadership Anti-Patterns
ลองมองย้อนกลับไปยังโปรเจคที่เกิดความล่าช้าในการส่งมอบกัน อะไรที่ทำให้ใช้เวลานาน บางโปรเจ็คใช้เวลามากขึ้นเป็นเท่าตัว คุณเคยลองวิเคราะห์หรือไม่ว่า เวลาที่เสียไป เสียไปกับอะไรบ้าง
จากบทความเรื่อง “Software Development Waste” ที่ตีพิมพ์ในวารสารวิชาการ International Conference on Software Engineering (ICSE) , 2017 ที่ได้เฝ้าดูการพัฒนาซอฟต์แวร์ 8 โปรเจ็คในระยะเวลา 2 ปีครึ่ง แล้วแยกแยะ waste ต่างๆ ในกระบวนการทำซอฟต์แวร์ ออกเป็นกรณีๆ ผมจึงคิดว่า มันน่าจะมีประโยชน์ในแง่ของ Checklist หากทีมใดจะนำไปใช้ เพื่อลด waste และเพิ่มประสิทธิภาพในการทำงาน ผมขอเริ่มกันเลยครับ
Waste#1 Product ที่ไม่มีใครต้องการ
เป็น waste ที่เสียไปในการสร้างสิ่งที่ไม่ถูกต้อง ใช้งานไม่ได้ ไม่ตอบโจทย์ กล่าวคือ เกิดจากการทำ product research ได้ไม่ดี ไม่มีการตรวจสอบกับ user หรือไม่สนใจ feedback ทั้งนี้รวมไปถึงการทำ feature ที่ไม่ได้เพิ่มมูลค่าให้ users และการไม่นำ stakeholders เข้ามาร่วมจัด priority ของ feature ที่จะทำ (หรือไม่ทำ) ตั้งแต่เนิ่นๆ ล้วนแล้วแต่ทำให้เกิดการสร้าง product ที่ไม่มีใครต้องการ
Waste#2 Backlog ขยะ
เป็น waste ที่เสียไปกับการจัดการ user stories หรือ tickets ที่ซ้ำซ้อน นำ tickets ที่ไม่สำคัญมาทำก่อน หรือ ไม่จัดให้แก้ bugs แต่เนิ่นๆ ทำให้ backlog เกิดความผันผวน กล่าวคือ developer บางคนทำหลายอย่างในเวลาเดียวกัน บางคนทำงานซ้ำซ้อน บางคนไม่มีงานหรือ user stories ที่พร้อมทำ เกิดความไม่สมดุลของ bugs vs features ใน sprint QA เทสระบบได้ล่าช้า สุดท้ายทำให้เกิดปัญหาด้านคุณภาพในที่สุด
Waste#3 Rework เป็นนิสัย
เป็น waste ที่เกิดจากการต้องรื้อโค้ดเขียนใหม่ใน feature ที่คิดว่าเสร็จไปแล้ว โดยสาเหตุนั้น อาจมาจากความเข้าใจผิด หรือ definition of done ไม่ชัดเจน ทำให้ทำออกมาแบบผิดๆ ทำมาแล้วเกิดบั๊กเยอะและขาดการ analyze root cause เลยทำให้บั๊กแก้ไม่หายจนต้องรื้อโค้ด การ rework อาจ รวมไปถึง technical debt ด้วย หากมีอยู่เยอะ ก็จะทำให้ไม่สามารถเขียนโค้ดแบบตรงไปตรงมาได้ ทำให้สุดท้ายก็ต้องรื้อเขียนใหม่
Waste#4 Over-engineering
เป็น waste ที่เกิดจากการเขียนโค้ด ที่ซับซ้อนเกินความจำเป็น และไม่พยายาม simplify มันแต่เนิ่นๆ ทั้งนี้รวมถึงการ design solution หรือ design หน้าจอ UI ดังนั้นให้คิดเสมอว่า user ไม่ต้องการอะไรที่ซับซ้อนหรอก การเขียนโค้ดที่ duplicate กัน (copy/paste) หรือการไม่ทำให้ ui component นำกลับมาใช้ซ้ำได้บ่อยๆ (reusability) ก็สามารถทำให้เกิดความซับซ้อนได้ ไม่ควร design ระบบอะไรที่ใหญ่ๆตั้งแต่แรก ควรเริ่มลงมือทำจากเล็กๆก่อน (most viable product)
Waste#5 ภาระทางปัญญา (cognitive load)
เป็น waste ที่เกิดจากการต้องใช้พลังในการคิดมากเกินความจำเป็น ไม่ว่าจะมาจากการที่มี tech debt เยอะ, มี feature ที่ใหญ่มาก, ไม่มีเครื่องมือทีเหมาะสมเพียงพอ, API, library หรือ framework ที่ซับซ้อนมาก, dev มีการสลับ feature ไปมาบ่อยๆ (context switching), หรือแม้กระทั่งการเขียนโค้ดที่ไม่ clean รกรุงรัง ล้วนแล้วแต่ทำให้เราต้องใช้พลังของสมองในการคิดมากจนเหนื่อยล้า ทำให้คิดช้าลง หรือเพิ่มเวลาในการคิดทำอะไรง่ายๆสักอย่าง เป็นต้น
Waste#6 ทุกข์ทางจิต (Psychological distress)
เป็น waste ที่เกิดจากความเครียดต่างๆ ที่เกิดขึ้นภายในทีม ทำให้งานออกมาไม่มีคุณภาพ เพราะไม่มีกระจิตกระใจในการทำงาน เสียขวัญและกำลังใจ นอกจากนี้ การเร่งรีบเขียนโค้ดอยู่ตลอดเวลา รวมไปถึงความขัดแย้งภายในทีม ล้วนแล้วแต่ทำให้งานที่ได้ออกมาไม่ดี เกิดความล่าช้าและ ไม่มีประสิทธิภาพ
Waste#7 การรอคอย (Waiting/multitasking)
เป็น waste ที่เกิดจากการว่างงาน อาจเป็นเพราะรออะไรบางอย่าง เช่นรอคน รอเครื่องมือ หรือรอ information บางครั้งการรอ unit test ที่รันนานๆ ก็ทำให้เกิด waste ได้ กล่าวคือ บางครั้งเราต้อง switch ไปทำอย่างอื่นรอ และการจะกลับมา แก้ไขโค้ด ก็ไม่ใช่ว่าจะทำได้ทันที อย่างที่เราทราบว่า multi tasking จะมี lose ในการ switch กลับไปกลับมา ในส่วนของการรอ environment นาน ขอแนะนำ dev ให้นำ docker container มาใช้งานในการ code, build, test, start และ debug เพื่อไม่ต้องรอ
Waste#8 องค์ความรู้หาย (Knowledge loss)
เป็น waste ที่เกิดจากการที่มีคนในทีมลาออก ทำให้ต้องเรียนรู้ใหม่อีกครั้ง ซึ่งองค์ความรู้บางอย่างก็อาจไม่สมบูรณ์ เมื่อเขียนโค้ดในส่วนนั้นๆ ก็จะเกิดความเข้าใจผิดได้ง่าย และไม่สมบูรณ์
Waste#9 สื่อสารอย่างไม่มีประสิทธิภาพ
เป็น waste ที่เกิดจากการสื่อสารไม่ครบถ้วน ผิดพลาด เข้าใจผิด ไม่ตรงจุด หรือไม่มีการสื่อสารเลยก็เป็นได้ เกิดจากขนาดของทีมที่ใหญ่เกินไป ทีมงานและ stakeholder กระจายตัวอยู่ตามที่ต่างๆ ไม่ได้ทำงานที่เดียวกัน ทำให้ไม่เข้าใจ process การทำงานของทีมอื่น การสื่อสารที่ไม่สมดุลย์ เช่นการสื่อสารทางเดียว ไม่มีการรับฟังความคิดเห็น มองข้าม retrospective มีการประชุมที่ไม่มีประสิทธิภาพ ไม่สนใจที่จะคุยเรื่อง blocker issues ของแต่ละวัน ประชุมนานเกินไป โดยเฉพาะ daily stand-ups ไม่ควรเกิน 15 นาที
สรุป
การพัฒนาซอฟท์แวร์เป็นกิจกรรมที่ซับซ้อนที่เต็มไปด้วยปัญหาในเชิงเทคนิค ที่แต่ละกิจกรรมจะเกี่ยวข้องกับผู้คนหลากหลายทักษะ และ disciplines การที่มีผู้คนในสังคมแบบนี้ จะมีโอกาสเกิด waste ได้ง่าย waste เป็นกิจกรรมที่สูญเสียไปในรูปแบบของเวลา เป็นเวลาที่ไม่ได้ก่อให้เกิด value กับใครเลย และความล่าช้าทำให้สูญเสียความสามารถในการแข่งขัน สูญเสีย time to market ดังนั้นหากเราทำความเข้าใจ waste ต่างๆ และพยายามหาทางแก้ไขมัน เราจะลดการสูญเสียได้ แล้วทีมงานจะมีเวลามาเพิ่ม value ให้กับ product ที่ตอบโจทย์ทุกคน …อย่างทันท่วงที