See the original English version of this article here
Eric Higgins (ผู้เขียนบทความนี้) ก็คล้ายกับคนส่วนใหญ่ที่เล่นเกม Tetris ซึ่งเป็นเกมยอดนิยมเกมหนึ่ง และเขาก็เปรียบเทียบเกมนี้กับ Technical Debt (หนี้ทางเทคนิค) ได้อย่างน่าสนใจ เนื่องจากเขาและทีมงานมีประสบการณ์ตรงจากการที่ต้องแก้ Bug ที่มีมูลค่าถึง 1 ล้านเหรียญต่อปี ว่าแต่เรื่องราวเป็นอย่างไร มาติดตามกันได้เลย
ในบริษัทผลิต Software โดยทั่วไป Product และ Project Managers (PMs) จะทำงานร่วมกับ Software Developer เพื่อจัดลำดับความสำคัญของ Code ที่จะถูกเขียนและส่งให้กับลูกค้าต่อไป ซึ่งการที่สามารถเคลียร์แถวของ Tetris ให้หายไปได้ก็เหมือนกับการจัดส่ง Feature ดังนั้น การจัดส่ง Feature ที่มีความซับซ้อน ก็ต้องใช้จำนวนแถวที่มากขึ้นเช่นกัน
บ่อยครั้งที่ความต้องการทางธุรกิจ (Feature ใหม่, Product ใหม่) จะนำไปสู่การต้องเลือกอย่างใดอย่างหนึ่งระหว่าง “Code” (hacks, shortcuts) เพื่อให้สามารถจัดส่งได้ตรงตามเวลา หรือ “การเปลี่ยนแปลง Product Strategy” ซึ่งอาจจะเกิดปัญหาเรื่องการไม่ Compatible กับการ Design ในช่วงก่อนหน้านี้ จะต้องใช้ความพยายามเพิ่มขึ้นในการ Migrate ลูกค้าหรือการ Support ต่างๆ ทั้ง Logic “ใหม่” และ “เก่า”
โดยสถานการณ์เช่นนี้ ถือเป็นการสร้าง Technical Debt ภายใน Product Code ซึ่งช่องว่างที่อยู่ในเกม Tetris ก็เปรียบเหมือน Technical Debt นั่นเอง
แทบจะทุก Code ล้วนมี Technical Debt ซึ่งนั่นเป็นเรื่องปกติ คุณสามารถเล่นเกม Tetris ต่อไปด้วยการเติมช่องว่างเล็กๆ เหล่านั้นให้เต็มทั้งแถว
การมี Technical Debt ที่มากเกินไป จะไปขัดขวางเรื่องการแก้ไข Feature หรือ Bug ต่างๆ จากการจัดส่งในช่วงระยะเวลาที่เหมาะสม นี่ไม่ใช่ปัญหาที่สามารถแก้ไขได้ด้วยการเพิ่มจำนวน Developer หรือเปลี่ยนตัว Developer ที่มีอยู่ การที่มันถูกเรียกว่า Technical Debt ก็เพราะเมื่อถึงจุดหนึ่ง คุณอาจจะต้องมีการ “จ่าย” บางอย่างออกไป ซึ่งอาจะเป็นตัวเงินหรือเวลาที่ล่าช้าออกไป
การที่คุณรีบจ่าย Technical Debt จะช่วยเพิ่มความสามารถทางการแข่งขันได้ มันช่วยให้คุณยังอยู่ในเกม เช่นเดียวกับการทำธุรกิจ ยิ่งคุณเล่นเกม Tetris ไปก็จะเริ่มเจอความยากขึ้นเรื่อยๆ ชิ้นส่วนต่างๆ เคลื่อนที่เร็วขึ้นและยากที่คุณจะเปลี่ยนรูปร่างหรือหาจุดที่จะให้มันลงได้ทัน
เช่นเดียวกับการทำธุรกิจ คุณจะไม่มีวันชนะเกม Tetris ได้ ไม่มีจุดสิ้นสุดที่แท้จริง คุณเพียงแค่ควบคุมว่า คุณจะแพ้มันเร็วมากน้อยแค่ไหนเท่านั้นเอง การที่คุณปล่อยให้เกิดช่องว่างในเกม Tetris มากเกินไป ก็จะทำให้คุณแพ้เร็วขึ้นเท่านั้น
Bug ครั้งนี้มีมูลค่าถึง 1 ล้านเหรียญ
เมื่อไม่นานมานี้ ทีมของ Eric ได้รับมอบหมายให้ Update เกี่ยวกับ Logic ของการเรียกเก็บเงินและการออกใบแจ้งหนี้(ใบ Invoice) ใน Product Code ของบริษัท เพื่อให้รองรับกับแผนการกำหนดราคา (Pricing Plan) ใหม่, Payment Processor ใหม่ รวมทั้งปรับปรุง Workflow ของการเรียกเก็บเงินให้ดีขึ้นกว่าเดิม รายละเอียดบางอย่างยังคงอยู่ในการตัดสินใจของทีม Product ดังนั้น ทีมของ Eric จึงใช้เวลาไปกับการดูในเชิงลึกของ Code เพราะเชื่อว่าสิ่งนี้จะช่วยทำให้เกิดความเข้าใจมากขึ้น เพื่อที่ทีมของ Eric จะได้ประเมินได้อย่างถูกต้องเกี่ยวกับความสามารถในการแก้ไขความเปลี่ยนเปลงมัน ได้อย่างครบถ้วนสมบูรณ์
จุดประสงค์หลักๆ ของ Code ที่ทีมของเขาศึกษา คือการตรวจสอบ Account ของลูกค้าทุกราย คำนวณว่าลูกค้าเหล่านั้นต้องจ่ายเท่าไร และส่งไปที่ API ของการออก Invoice ซึ่ง Code ถูกเขียนไว้อย่างชัดเจนด้วยความระมัดระวังและด้วยความตั้งใจ แต่พบว่ามันไม่ค่อยยุ่งเหยิงแต่ก็ไม่ค่อยยืดหยุ่น เป็น Function ที่มีขนาดใหญ่มาก แต่ไม่มีการ Test ใดๆ มี Log อยู่น้อยมาก และแทบไม่มี Document ใดๆ เลย ดูเหมือนจะมีการสุ่มบางอย่างที่อธิบายไม่ได้อยู่ด้วย Code นี้ถูกเขียนขึ้นเมื่อ 5 ปีก่อนโดยหนึ่งในผู้ร่วมก่อตั้งบริษัท มีการเปลี่ยนแปลงเพียงครั้งเดียวจากพนักงานคนแรกที่ตอนนี้ไม่ได้อยู่ในบริษัทแล้ว
แล้วมันเป็นปัญหาจริงๆ เหรอ? ใบ Invoice กำลังจะถูกส่งออกไป บริษัทกำลังจะได้เงิน และไม่มีข้อบ่งชี้ถึงปัญหาใดๆ ทั้งหมดนี้อาจเป็นการชักนำให้ทีมของเขาไม่ต้องทำการ Refactor แต่ทีมของ Eric ก็รู้ว่าจะมีการเปลี่ยนแปลงครั้งใหญ่เกิดขึ้น เพราะ Function นี้ไม่สามารถ Scalable ได้ตามความต้องการของบริษัท และบริษัทสามารถก้าวไปข้างหน้าได้เร็วขึ้นหาก Function นี้ถูกทำให้ง่ายขึ้น
ทีมของ Eric ได้ทำการปรับโครงสร้างของ Function ใหม่ภายในการทำ Sprint เพียงครั้งเดียวและเพิ่ม Log ที่มีความจำเป็นให้มากขึ้น ซึ่งนั่นคือสิ่งที่ทีมของเขาพบว่า ควรต้องแก้ไข แต่จู่ๆ ก็มีคนจากฝ่ายบัญชีเดินมาที่โต๊ะทำงานพวกเขาแล้วถามว่า ทำไมจำนวนใบ Invoice ถึงมีจำนวนเพิ่มขึ้นอย่างไม่คาดคิดมาก่อน? มีลูกค้าบางรายที่บริษัทไม่ได้ออกใบ Invoice หรือนี่คือผลของการสุ่มแบบแปลกๆ ที่ว่า? มันได้ซ่อนรูปแบบบางอย่างที่ควรจะแจ้งเตือนบริษัทเกี่ยวกับลูกค้าที่ไม่ได้ถูกเรียกเก็บเงิน และเมื่อได้มีการประมาณการแล้วพบว่า ใบ Invoice ที่ไม่ได้ออกจากระบบ มีมูลค่ารวมมากกว่า 1 ล้านเหรียญต่อปี เลยทีเดียว
การรีบจ่ายหนี้(Technical Debt) อาจไม่ได้ประสบความสำเร็จเสมอไป
Eric หวังว่าเขาจะสามารถให้คำแนะนำที่ดีเหล่านี้ได้เกี่ยวกับเรื่อง Technical Debt แต่น่าเสียดายที่คำตอบคือ มันค่อนข้างซับซ้อนและเกี่ยวข้องกับการสร้างสมดุลกับเรื่องอื่นๆ อยู่ด้วยเสมอ นั่นคือ คุณสามารถมี Code ที่ Clean และผ่านการ Test มากมายมาเป็นอย่างดีแล้ว แต่คุณก็อาจมีลูกค้าที่ไม่ได้ชำระเงินให้คุณ ในทางกลับกัน บริษัทของคุณอาจมีการใช้ Code ที่แสนจะยุ่งเหยิง แต่มันดันทำให้ลูกค้าของคุณพึงพอใจและสร้างรายได้ให้กับบริษัทอย่างมากมายเป็นกอบเป็นกำ นี่แหละคือสิ่งที่คุณต้องสร้างสมดุลให้เหมาะสมให้ได้
แต่ไม่ว่าจะด้วยวิธีใดก็ตาม Product Owner และ Developer ควรแบ่งปันความเข้าใจร่วมกันว่า Technical Debt คืออะไร อีกทั้งควรรู้ด้วยว่าเราไม่สามารถหลีกเลี่ยงมันได้ไปตลอด เช่นเดียวกับเกม Tetris ที่คุณจะไม่มีทางสามารถเอาชนะ Software ได้
ISM Technology Recruitment Ltd. (#1 Tech Recruiter in Thailand) เราเชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ เปิดทำการกว่า 28 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย หากคุณเป็นคน IT ที่อยากทำงานท้าทายและร่วมงานกับองค์กรชั้นนำ สามารถฝากประวัติการทำงาน (Resume) ของคุณไว้กับ ISM ได้ที่ https://www.ismtech.net/submit-your-resume แล้วคุณจะพบว่าอนาคตและโอกาสก้าวหน้ากำลังรอคุณอยู่
Source: https://medium.com/