วันนี้ทางทีมมีคุยกันเรื่อง 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