คุณโน้มน้าวผู้บริหารให้ลงทุนในการ refactor หรืออัปเกรดโครงสร้างพื้นฐานอย่างไร?

Question

Accepted Answer

ผู้บริหารไม่ได้ให้ทุนกับ "tech debt" — พวกเขาให้ทุนกับ **ผลลัพธ์** หน้าที่ของคุณคือแปลความเจ็บปวดทางวิศวกรรมภายในให้เป็นภาษาที่พวกเขาแคร์อยู่แล้ว ได้แก่ **ความเสี่ยง, ความเร็ว, ต้นทุน และเหตุการณ์** จงพูดด้วยผลลัพธ์ ไม่ใช่เรื่องภายใน

## แปล tech debt เป็นภาษาธุรกิจ

| ความจริงทางวิศวกรรม | กรอบเชิงธุรกิจ |
| --- | --- |
| โมดูล legacy ที่เปราะบาง | ความเสี่ยงต่อเหตุการณ์, โอกาสเกิด outage |
| build/deploy ช้า | ความเร็วที่สูญเสีย, time-to-market ที่ช้าลง |
| ไม่มี test coverage | อัตราข้อบกพร่องสูงขึ้น, ลูกค้าหนีหาย |
| งาน ops ที่ทำมือ | กำลังคนที่สูญเปล่า, เพดานการ scale |

## ทำให้ผลกระทบเป็นปริมาณ

การบ่นแบบคลุมเครือนั้นแพ้ ตัวเลขชนะ "พื้นที่นี้ก่อให้เกิดเหตุการณ์ราว 30% ของทั้งหมด และเพิ่มเวลาสองวันให้ทุกฟีเจอร์" คือสิ่งที่ขอทุนได้ ผูกมันเข้ากับ **เป้าหมายที่ผู้บริหารมีอยู่แล้ว** เช่น เป้าด้านความเสถียร, เส้นตายการเปิดตัว หรือเพดานต้นทุน

## เสนอแผนแบบเป็นขั้นๆ ที่มี ROI รองรับ

- **หลีกเลี่ยงการเขียนใหม่ทั้งก้อน** "หยุดทุกอย่างหกเดือน" แทบจะถูกปฏิเสธเสมอ และก็สมควรแล้ว — เพราะมันเสี่ยงสูงโดยไม่มีคุณค่าเพิ่มเป็นขั้นๆ
- เสนอ **การเดิมพันเล็กๆ ที่เรียงลำดับ** ซึ่งแต่ละครั้งให้ผลตอบแทนกลับมา "สองสัปดาห์ตรงนี้ลดเวลา deploy ลงครึ่งหนึ่ง"
- แสดง **ต้นทุนของการไม่ทำอะไร** — อะไรจะพัง, ช้าลง หรือแพงขึ้นหากไม่มีอะไรเปลี่ยน การไม่ทำอะไรคือทางเลือกที่มีป้ายราคา

## ทำไมจึงสำคัญ

วิศวกรที่ทำ business case ไม่เป็นจะได้แต่เฝ้าดูหนี้ทบต้นจนกระทั่งมันจุดชนวนวิกฤต — แล้วการแก้ก็เกิดขึ้นภายใต้แรงกดดัน ซึ่งเป็นเงื่อนไขที่เลวร้ายที่สุด tech lead ที่จัดกรอบการลงทุนในรูปของผลลัพธ์จะได้รับความเชื่อมั่นและงบประมาณในการแก้สิ่งต่างๆ *ก่อน* ที่มันจะพัง ซึ่งคือความแตกต่างระหว่างทีมที่ดับเพลิงอยู่ตลอดเวลากับทีมที่เร็วขึ้นอย่างสม่ำเสมอ

โมดูล legacy ที่เปราะบาง	ความเสี่ยงต่อเหตุการณ์, โอกาสเกิด outage
build/deploy ช้า	ความเร็วที่สูญเสีย, time-to-market ที่ช้าลง
ไม่มี test coverage	อัตราข้อบกพร่องสูงขึ้น, ลูกค้าหนีหาย
งาน ops ที่ทำมือ	กำลังคนที่สูญเปล่า, เพดานการ scale