สิ่งที่เป็นอยู่
Manager: “เรื่องเชื่อมต่อธนาคาร ABC จะเสร็จวันไหนครับ?”
Junior Developer: “น่าจะศุกร์หน้าค่ะ”
Manager: “ช้าไปอะครับ พี่บอกลูกค้าไปแล้วว่าเราจะจ่ายเงินผ่านธนาคาร ABC ได้วันศุกร์นี้ ถ้าเสร็จไม่ทันมีหวังลูกค้าไม่จ่ายเงินงวดที่เหลือแน่”
Junior Developer: “แต่หนูคิดว่าถ้าจะทำให้ดีมันต้องใช้เวลานิดนึงอะค่ะ เพราะว่า …”
Manager: “พี่ขอนะรอบนี้ ทำอะไรที่มันง่ายๆไปก่อนได้มั้ย พี่ไม่อยากมีปัญหากับลูกค้า รายใหญ่ซะด้วยครับ”
Junior Developer: “อ่อ ค่ะ”
Manager: “ได้นะ เสร็จศุกร์นี้เลยนะ”
Junior Developer: “ค่ะ”
สิ่งที่ควรจะเป็น
เหตุการณ์ที่เกิดขึ้นรายวัน บทสนทนาแบบนี้มักจบลงด้วยชัยชนะของผู้มีอำนาจมากกว่าซึ่งส่วนใหญ่ก็จะเป็นคนที่มาจากหน่วยงานธุรกิจ ด้วยความไม่รู้หรือความละเลยก็ตามแต่พวกเค้ากำลังก่อ “หนี้ทางเทคนิค” (Technical Debt) ขึ้นมา
“หนี้” โดยธรรมชาติคือการที่เรายอมแลกสิ่งที่ต้องการในระยะสั้นกับภาระที่ตามมาในระยะยาว เช่น การกู้เงิน เราได้เงินมาใช้วันนี้โดยแลกกับภาระทางการเงินที่ผูกพันในระยะยาว ความน่ากลัวของหนี้คือเราไม่ได้ใช้คืนแค่สิ่งที่เราได้มา แต่เราต้องจ่ายมากกว่านั้นในรูปแบบของ “ดอกเบี้ย” ที่เติบโตขึ้นทุกวันไม่ว่าเราจะจ่ายเงินต้นคืนหรือไม่ แล้วถ้าวันหนึ่งเราหมดปัญญาจ่ายหนี้เราก็จะ “ล้มละลาย”
ถ้าคุณ Manager ไม่รีบร้อนตัดบทไปซะก่อน … บทสนทนาข้างบนจะมีเนื้อหาเพิ่มเติมแบบนี้
- ทางเลือกที่หนึ่ง: 5 แต้ม (สำหรับระบบเชื่อมต่อธนาคาร ABC) ตอนนี้ หลังจากนั้น 21 แต้ม (เพื่อการทำ Refactoring ใน Sprint หน้า) แล้วหลังจากนั้น 1 แต้มสำหรับทุกๆการเชื่อมต่อกับธนาคารใหม่ๆ … ทางเลือกนี้จะทำให้เราส่งมอบงานให้ลูกค้าได้ตามเวลาและมีระบบที่ยืดหยุ่นเพียงพอเพื่อรองรับความต้องการในอนาคต
- ทางเลือกที่สอง: 21 แต้ม (สำหรับระบบเชื่อมต่อธนาคารที่สมบูรณ์) หลังจากนั้น 0 แต้มเลยสำหรับการเชื่อมต่อธนาคารใหม่ๆ … ทางเลือกนี้คือการยอมรับความเสี่ยงที่จะส่งงานล้าช้าแต่เราจะมีระบบที่สมบูรณ์แบบมากในการรองรับความต้องการในอนาคต
- ทางเลือกที่สาม: 5 แต้ม (สำหรับระบบเชื่อมต่อธนาคาร ABC) ไม่มีการทำ Refactoring ใดๆ การเชื่อมต่อกับธนาคารอื่นๆในอนาคตอาจจะเป็น 8, 13, 21 แต้ม จนถึงจุดหนึ่งที่โค๊ดมันไปไม่ได้แล้วก็ต้องมีการทำ Refactoring / Rearchitect ครั้งใหญ่ซึ่งตอนนั้นก็คงประมาณ 100+ แต้ม … ทางเลือกนี้เราจะส่งมอบงานได้ตรงเวลาแต่ต้องใช้เวลามากขึ้นเรื่อยๆกับการเชื่อมต่อธนาคารใหม่ๆ
ทางเลือกที่ดีที่สุดคือทางเลือกที่หนึ่งแต่ทางเลือกที่ได้รับความนิยมที่สุดคือทางเลือกที่สามเพราะสิ่งที่คุณ Manager ต้องการคืองานต้องเสร็จศุกร์นี้มันจึงเป็นทางเลือกเดียวที่เค้ามองเห็น … ช่างน่าเศร้าใจยิ่งนัก
เราจะทำอย่างไรเพื่อหลีกเลี่ยงทางเลือกที่สาม?
- ถามคุณ Manager ก่อนเลยว่า “พี่คะ พี่เข้าใจคำว่า ‘Technical Debt’ มั้ย?” ถ้าไม่เข้าใจก็อธิบายถึงผลกระทบให้เค้าฟังไป … สาเหตุหนึ่งที่ทำให้เรามีหนี้สินพะรุงพะรังก็เพราะคนที่มีอำนาจไม่เข้าใจคำว่า Technical Debt ไม่เข้าใจของผลกระทบที่จะตามมาของการตัดสินใจแบบลวกๆของเค้า และชอบคิดว่าอะไรๆก็ง่ายไปหมด
- จากข้อหนึ่ง … พยายามอย่าให้คุณ Manager มาคุยเรื่องแบบนี้กับ Junior Developer … น้องเค้ายังเด็ก หัวอ่อน ไม่กล้าเถียงผู้ใหญ่ (ฮ่าๆ) และอาจจะมีความเข้าใจและประสบการณ์ในโค๊ดไม่มากพอจะจัดการบทสนทนาเรื่องนี้ได้ดี เราต้องเป็นกำแพงให้ทีม เราต้องมีจุดยืนที่ชัดเจน
- ทุกครั้งก่อนที่เราจะก่อหนี้ เราต้องรู้ว่าเราจะใช้หนี้อย่างไรและเมื่อไร การเป็นหนี้ไม่ใช่เรื่องไม่ดีเสมอไปตราบใดที่เราพิจารณาอย่างรอบคอบและมีวินัยที่ดี มองการมี Technical Debt เหมือนเราเข้าครัวทำกับข้าว ช่วงที่หั่นผักหั่นเนื้อเราก็โอเคที่จะปล่อยให้มันมีขยะรกๆอยู่บนเขียงบ้าง แต่หลังจากผัดข้าวเสร็จเราก็เก็บล้างให้ครัวสะอาดเอี่ยมเหมือนเดิม … ประเด็นสำคัญที่สุดคือเราต้องมีวินัย
Technical Debt ก็ไม่ต่างจากการเป็นหนี้ทางการเงิน เริ่มต้นมันอาจจะไม่ใช่ภาระอะไรมากแต่ถ้าเราติดนิสัยก่อหนี้ยืมสินไปเรื่อยๆ ถึงวันนึงมันก็จะมาถึงทางตัน ซอฟต์แวร์ของเราก็จะล้มละลาย … อย่าปล่อยให้เป็นแบบนั้นเลยครับ