วันนี้ทางทีมมีคุยกันเรื่อง Technical Debt หรือหนี้เชิงเทคนิค
แน่นอนว่า ที่มาที่ไปนั้น เพื่อทำให้เข้าใจว่า
สิ่งที่สายงานเชิงเทคนิคในการพัฒนา software อธิบายในมุมมองของการเงิน
เพื่อให้เข้าใจมากยิ่งขึ้น
ว่าสิ่งที่ทำลงไป มันก่อนให้เกิดหนี้หรือไม่ ?
แน่นอนว่า ตามลักษณะของหนี้ย่อมไม่ได้มาแบบฟรี ๆ
แต่มาพร้อมกับเงินต้น และ ดอกเบี้ย
หนี้อาจจะเกิดขึ้นได้ง่าย ๆ
คำถามคือ คุณจ่ายคืนไหน
ดังนั้นถ้าเราไม่จ่ายหนี้ดอกมันก็จะแบ่งบาน
จนสุดท้ายอาจจะทำให้ลูกหนี้มีปัญหาขึ้นมาได้
กลับมาดูการพัฒนา software บ้าง มันมีหนี้ที่เราสร้างขึ้นมา
ทั้งตั้งใจและไม่ตั้งใจหรือไม่ ?
เนื่องจากหนี้เหล่านี้ มันคือ ค่าใช้จ่ายที่เรามองไม่ค่อยเห็นเมื่อมันมีจำนวนน้อย ๆ
แต่เมื่อมันเยอะขึ้นตามเวลา หรือ ตามความใหญ่ของระบบ
กลับก่อให้เกิดปัญหามากมายตามมา
Technical Debt มันคือ trade-off ระหว่างคำว่า quality กับ speed
เช่น
- งานต้องเสร็จ เพราะว่าใกล้ deadline แล้ว
- งานด่วนนะ ต้องรีบทำ
- ลูกค้าบอกว่าขอเร็ว ๆ ดี ๆ ถูก ๆ !!
ส่วนใหญ่มักจะเอยด้วย
การเพิ่มเวลาในการส่งมอบ
หรือ โรคเลื่อนหรือหนักมาก ๆ คือ เกิดความผิดพลาดบน production
แถมคนที่เจอก่อนคือ ลูกค้า นั่นเอง
ในเชิงการเงินนั้น Technical Debt ประกอบไปด้วย
- Principal (เงินต้น) คือ effort ที่ใช้ในการแก้ไข code/module/architecture ที่แย่
- Interest (ดอกเบี้ย) คือ เวลาที่ทีมพัฒนาและส่งมอบที่ใช้มากขึ้นเรื่อย ๆ จาก Principal นั่นเอง
ตัวอย่างของ Technical Debt ที่พบเจอบ่อย ๆ
- ความซับซ้อนของ code, module และ architecture ที่สูงขึ้นเรื่อย ๆ
- ขาด Integration test ที่ดีและเพียงพอ ให้เรามั่นใจ
- เกิด duplication ขึ้นมาเยอะมาก ๆ
- ขาด Automation build, test ละ deploy ที่ดีและเพียงพอ
แต่อย่าลืมว่า หนี้มีทั้งหนี้ที่ดีและไม่ดี
บางคนบอกว่า มีหนี้เพื่อให้ได้สิ่งที่ดีกว่ากลับมาก
แต่หนี้บางอย่าง เป็นหนี้ที่แย่ คือ หนี้ไม่ก่อให้เกิดรายได้
แต่เป็นหนี้เพื่อให้ได้ในสิ่งที่ต้องการตอนนี้เท่านั้นเอง
บางครั้ง code ที่แย่ architecture ที่แย่ ก็อาจจะไม่ใช่หนี้เสียก็ได้
บางครั้ง code ที่ดี architect ที่ดี อาจจะเป็นหนี้เสียก็ได้
ผลกระทบที่เกิดจาก Technical Debt มีอะไรบ้าง ?
ยิ่งทำระบบยิ่งแย่
ระบบล่มบ่อยทุกครั้งที่ deliver
ความพึงพอใจของลูกค้าลดลงเรื่อย ๆ
ประสิทธิภาพการทำงานโดยรวมของระบบลงลงอย่างต่อเนื่อง
ดังนั้นยิ่งส่งผลต่อลูกค้าที่ทางลบมากเท่าไร
คุณค่าของสิ่งที่ทำยิ่งน้อยลง
หนึ่งในตัวอย่างคือ feature ที่ไม่ถูกใช้งานเยอะขึ้นเรื่อย ๆ
เราต้องใช้เวลาในการคิด พัฒนา ทดสอบ deploy ทำเอกสาร กลับไม่มีคนใช้งาน
แต่ทีมพัฒนาต้อง maintain feature เหล่านี้
ยิ่งพัฒนา ยิ่งเพิ่ม feature การพัฒนา ส่งมอบยิ่งช้าลง
เพียงการพัฒนาก็ยากอยู่แล้ว
แต่ต้องมาแก้ไขหรือปรับปรุงระบบเดิมให้ทำงานได้
ให้ทำงานถูกต้อง และปรับปรุงให้ดีขึ้น
คำถามคือ เวลามีจำกัด คุณจะเลือกทำอะไร ?
แก้ไขที่เดียว แต่กระทบต่อการทำงานส่วนอื่น ๆ อีกมากมาย แบบนี้เกิดบ่อยไหม ?
เสียเวลาไป debug อีก Debug แล้วก็หาไม่เจอ แก้ไขยิ่งลำบาก
ยิ่งหนี้เยอะ ยิ่งก่อให้เกิดปัญหาหรือไม่นะ ?
ขาดเรื่องของ Transparency
แต่ละคนรู้รายละเอียดในบางเรื่อง
แถมไม่ share ความรู้เหล่านั้นให้คนอื่น ๆ
ไม่ว่าจะเหตุผลใด ๆ ก็ตาม
ทำให้เกิดปัญหาในการ estimation เวลาของการทำงาน ทั้งมากไปหรือน้อยไป
บางครั้งสิ่งเล็ก ๆ ที่เรียกว่า งานงอก จะเยอะมาก ๆ
หรือเรื่องที่ถูกซ่อนเอาไว้มากมาย
และกว่าจะรู้ว่าขาดอะไรไปต้องใช้เวลานาน
หรือต้องเกิดปัญหาขึ้นมาก่อน ถึงจะรู้ !!
สิ่งที่สร้างขึ้นมานั้น มันตรงตามที่ต้องการหรือคาดหวังหรือไม่ ?
ใช้เวลานานหรือไม่ ? กว่าจะรู้ ?
ดังนั้นถ้าเราได้ feedback ที่เร็ว จากคนที่ถูกต้อง
น่าจะทำให้เรื่องของ Transparency ดีขึ้นอย่างมาก
แต่ปัจจุบันเป็นอย่างไร จึงส่งผลให้การพัฒนามีปัญหา
ส่งผลให้ทีมพัฒนาขนาดแรงบันดาลใจในการพัฒนา
จะทำให้ดีไปทำไม
ทำดีก็แค่เสมอตัว ทำแย่ก็โดนด่า
ดังนั้นทำแย่ ๆ ไปเลย
ทำให้เสร็จ ๆ ไปเลยดีกว่า
ยังไงก็โดนด่าอยู่แล้ว
หนักกว่านั้นเจอปัญาจากที่ผ่านมาทั้งหมด
ยิ่งทำให้หมดกำลังใจในการทำงาน
แค่ทำให้มันเสร็จ ๆ ไปก็ยากอยู่แล้ว
จะปรับให้ดีขึ้น ? อย่าหวัง
แม้แต่จะทำการ estimation ไว้เผื่อมาก ๆ แล้ว
ก็ยังส่งมอบไม่ได้ตามเวลาเลย
ยังไม่พอเวลาโดยรวมก็เพิ่มเรื่อย ๆ ทั้ง
- การออกแบบที่นานขึ้น
- การพัฒนาที่มากขึ้น จำนวนคนมากขึ้น
- การทดสอบยากขึ้นเรื่อย จนถึงทดสอบไม่ครบ
- การดูแลรักษายาก
- ทางทีม operation ยิ่งลำบากเข้าไปอีก
- จำนวน bug ที่สูงขึ้นเรื่อยๆ
- การโบ้ยความผิดมักโยนไปให้คนอื่น ที่ไม่ใช่ตนเองมากขึ้น ที่สำคัญมักจะหาคนผิดมารับผิดชอบ มากกว่าแก้ไขปัญหาและปรับปรุงให้ดีขึ้น
ดังนั้นเรากลับมาดูสิว่า ระบบงานของเราเป็นอย่างไร ?
มีอะไรที่ส่งผลต่อการส่งมอบในเชิงลบหรือไม่
ทำการวัดผลและเก็บข้อมูล
รวมทั้งถึงสภาพจิตใจของทีมด้วยว่าเป็นอย่างไร
ต้องสร้างสมดุลระหว่าง output กับ outcome
จากนั้นต้องรีบแก้ไขสิ่งต่าง ๆ ที่ส่งผลในเชิงลบให้ดีขึ้นอย่างต่อเนื่อง
การวัดผลการปรับปรุง อาจจะมองในมุมต่าง ๆ ดังนี้
- การส่งมอบระบบงานที่สม่ำเสมอ ทั้งเพิ่ม feature, แก้ไข bug, regression test
- จำนวนของการทำงานแบบอัตโนมัติที่เพิ่มมากขึ้น นั่นคือลดงานที่ทำซ้ำ ๆ ลงไป ทั้งการ build, test, deploy
- ลดความซับซ้อนของ code, module, architecture ของระบบงานลง
- ลดจำนวน bug/defect/issue ลงไป
ลองปรับปรุงกันดูครับ
Reference Websites