มีบทสนทนาหนึ่งที่แทบทุกคนเคยเจอ คือ Software Engineer เดินมาบอกว่า "ระบบส่วนนี้เขียนไว้แย่มาก ขอเวลา refactor หน่อย" แล้ว Product Owner ก็ตอบกลับด้วยสายตาที่แปลว่า "แล้วมันกระทบลูกค้าตรงไหน เรามี features ต้องส่งอีกเพียบ"

ปัญหาไม่ได้อยู่ที่ใครถูกใครผิด แต่อยู่ที่ทั้ง 2 ฝ่ายกำลังพูดกันคนละภาษา ฝ่ายหนึ่งพูดภาษาของโค๊ด อีกฝ่ายพูดภาษาของธุรกิจ ตราบใดที่หนี้ทางเทคนิคยังถูกเล่าในฐานะ "ความสวยงามของโค้ด" มันจะแพ้ features ที่จับต้องได้เสมอ ทางออก คือ การแปลมันให้อยู่ในภาษาที่ฝ่าย business แคร์อยู่แล้ว นั่นคือ...

เงิน เวลา และ โอกาส

บทความนี้จะพาไปดูวิธีทำสิ่งนั้นแบบเป็นขั้นเป็นตอน

ทำไมต้องแปล ไม่ใช่แค่ขอ

หัวใจของการสื่อสาร technical debt คือ การเลิกขอให้คนอื่น "เชื่อใจ" ว่ามันสำคัญ แล้วหันมาแสดงให้เห็นว่ามันสำคัญ ในภาษาที่เขาใช้ในการตัดสินใจอยู่ทุกวัน

เพราะจริงๆ แล้ว PO กับ EM ไม่ได้มีเป้าหมายที่ขัดกันเลย PO อยากได้ feature เพราะอยากให้ product เติบโต ส่วน EM อยากแก้ระบบก็เพราะรู้ว่าถ้าไม่แก้ ต่อไป features จะออกช้าลงและพังบ่อยขึ้น ทั้งคู่ต้องการสิ่งเดียวกัน คือ "ส่งของได้เร็วและมั่นคง" งานของ EM จึงไม่ใช่การเอาชนะ PO แต่ คือ การดึงบทสนทนาออกจาก "ของฉันสำคัญกว่า" ไปสู่คำถามที่ว่า "อะไรให้ผลตอบแทนสูงสุดต่อเป้าหมายร่วมในตอนนี้"

ลองนึกภาพดูว่า ถ้าเราออก features ใหม่ แต่ server down ทั้งๆ ที่ยังไม่ทันได้ lead ลูกค้าเข้ามาใช้งานมากนัก มันก็ทำให้ business value ไม่สามารถเกิดขึ้นได้จริงตามที่คิดไว้

จับคู่ภาษาทางเทคนิคเข้ากับความเสี่ยงทางธุรกิจ

ก้าวแรกคือการมองให้ออกว่าหนี้แต่ละก้อนไปตกอยู่ในความเสี่ยงทางธุรกิจกลุ่มไหน หนี้ทางเทคนิคเกือบทั้งหมดจะเข้าได้กับหนึ่งใน 5 กลุ่มนี้ พร้อมตัววัดที่ใช้พูดกับฝ่ายธุรกิจได้เลย

เห็นได้ว่าทุกช่องด้านขวาคือสิ่งที่ผู้บริหารและ PO เข้าใจทันที โดยไม่ต้องรู้เรื่องโค้ดเลย นี่คือสะพานที่เราต้องสร้าง

เราควรแปลงสิ่งนี้เป็นตัวเลขที่สามารถวัดค่าได้

ตัวอย่าง

ถ้าเราทำ feature นี้โดยที่ไม่ refactor ส่วนนี้ก่อน จะทำให้ server รองรับการทำงานที่เพิ่มขึ้น และทำให้ cost ของ server เพิ่มขึ้นอีก 50% (คิดเป็นเงิน +100,000 ต่อเดือน) แต่ถ้าหากแก้ไขจุดนี้ก่อน cost ที่เพิ่มขึ้นจะอยู่ที่ 10% เป็นต้น

เมื่อผู้บริหารและ PO ได้ฟังแล้ว พวกเขาจะมีข้อมูลในมุม business ให้ trade-off ได้ทันที ว่าควรทำสิ่งไหนก่อน

ใส่ตัวเลขให้มัน ช่วยทำให้ PO เชื่อ

การจับคู่กลุ่มความเสี่ยงยังไม่พอ สิ่งที่เปลี่ยนใจคนได้จริง คือ ตัวเลข และการประเมินแบบคร่าวๆ ที่ยังดีกว่าการไม่มีตัวเลขเลยมาก

สูตรง่ายๆ ที่ใช้ได้กับหนี้แทบทุกก้อน คือ เทียบ ต้นทุนของการปล่อยไว้ กับ ต้นทุนของการแก้ โดยต้นทุนของการปล่อยไว้คำนวณจาก

💡
Carrying cost = frequency of impact × cost per occurrence
  • Frequency of impact: ความถี่ของผลกระทบ
  • Cost per occurrence: ต้นทุนต่อครั้ง

ส่วนต้นทุนของการแก้ คือ เวลาของ engineer ที่ต้องลงไป

ลองดูตัวอย่างการเล่าใน 3 มุม (ตัวเลขด้านล่างเป็นเพียงตัวอย่างสมมติเพื่อให้เห็นวิธีเล่า)

เรื่องความช้า: เล่าได้ว่า "ทุก features ที่ต้องแตะ module นี้ เราจะใช้เวลาพัฒนาเพิ่มขึ้นเฉลี่ยราว 3 วัน และเดือนหนึ่งเราแตะมันประมาณ 5 ครั้ง เท่ากับเสียเวลาไปราว 15 วันต่อเดือน หรือเกือบหนึ่งคนเต็มเวลา" (เกือบเท่าเงินเดือนของ engineer หนึ่งคน)

เรื่องความพัง: เล่าได้ว่า "incident ที่มาจากส่วนนี้เกิดเดือนละ 3 ครั้ง ครั้งละ 2 ชั่วโมง แต่ละครั้งต้องดึง Engineer 3 คนมาแก้ และช่วงที่ระบบล่มก็กระทบรายได้ต่อชั่วโมงด้วย"

เรื่องโอกาสที่หายไป: มุมนี้ทรงพลังที่สุด เพราะมันเชื่อมตรงกับรายได้ เล่าได้ว่า "ลูกค้ารายนี้มีมูลค่าต่อปีสูง และต้องการ feature แบบนี้ แต่สถาปัตยกรรมปัจจุบันทำไม่ได้ถ้าไม่แก้ระบบนี้ก่อน"

พอต้นทุนของการ "ไม่แก้" มาวางอยู่ตรงหน้าเป็นตัวเลข การตัดสินใจจะพลิกจาก "แก้ระบบมันเสียเวลา" กลายเป็น "การไม่แก้ต่างหากที่แพงกว่า" ในทันที

จัดลำดับด้วยความน่าจะเป็นคูณผลกระทบ

หนี้ทุกก้อนไม่ได้สำคัญเท่ากัน และความผิดพลาดที่พบบ่อย คือ การเดินไปขอ "แก้ระบบทั้งหมด" ซึ่งฟังดูน่ากลัวและถูกปฏิเสธได้ง่าย ทางที่ดีกว่า คือให้คะแนนหนี้แต่ละก้อนบน 2 แกน

  • แกนแรก คือ โอกาสที่มันจะระเบิด (สูง / กลาง / ต่ำ)
  • แกนที่สอง คือ ผลกระทบเมื่อมันระเบิด (สูง / กลาง / ต่ำ)

ก้อนที่ทั้งโอกาสสูงและผลกระทบสูง คือ กลุ่มที่ต้องจ่ายเดี๋ยวนี้ ส่วนก้อนที่โอกาสต่ำและผลกระทบต่ำ ก็แค่ยอมรับมันไว้และบันทึกเป็นลายลักษณ์อักษรว่าเรารู้ตัวและเลือกที่จะยังไม่แก้

วิธีนี้ทำให้เราไม่ได้ขอทุกอย่างพร้อมกัน แต่ขอเฉพาะก้อนที่มีเหตุผลทางธุรกิจชัดที่สุดก่อน ซึ่ง PO เห็นด้วยได้ง่ายกว่ามาก

ตัวอย่างประโยคที่แปลงแล้ว

ความต่างระหว่างการสื่อสารที่ได้ผลกับไม่ได้ผล มักอยู่แค่การเลือกคำ ลองเทียบ 2 ประโยคนี้

ก่อนแปลง Engineer พูดว่า

ผมอยาก refactor ระบบ authentication เพราะมันเขียนไว้แย่มาก

หลังแปลง เปลี่ยนเป็น

ระบบ authentication ปัจจุบันเป็นต้นเหตุของ incident ส่วนใหญ่ในไตรมาสนี้ และทำให้ทุกฟีเจอร์ที่เกี่ยวกับ user ช้าลงเกือบเท่าตัว ถ้าเราลงทุนแก้สัก 2 sprint จะช่วยลด incident และทำให้ฟีเจอร์ที่เหลือใน roadmap ไตรมาสหน้าเดินเร็วขึ้น ผมเสนอให้กันเวลาไว้ใน sprint หน้า

สังเกตว่าประโยคหลังไม่มีคำว่า "โค้ดแย่" อยู่เลย มีแต่ผลกระทบที่วัดได้ และปิดท้ายด้วยข้อเสนอที่มีขอบเขตชัดเจน นี่คือรูปแบบที่ทำให้ฝ่ายธุรกิจฟังและตอบว่าได้

สรุป

technical debt จะกลายเป็นเรื่องที่ทุกคนบนโต๊ะแคร์ก็ต่อเมื่อเราเลิกเล่ามันในฐานะปัญหาของ engineer แล้วเล่ามันในฐานะความเสี่ยงของธุรกิจแทน

จำหลัก 3 ข้อไว้

  1. จับคู่หนี้แต่ละก้อนเข้ากับความเสี่ยงทางธุรกิจที่ PO เข้าใจ
  2. ใส่ตัวเลขต้นทุนของการปล่อยไว้ให้เห็นเป็นรูปธรรม
  3. จัดลำดับด้วยความน่าจะเป็นคูณผลกระทบ แล้วขอเฉพาะก้อนที่คุ้มที่สุดก่อน

เมื่อทำได้ครบ 3 ข้อ บทสนทนาจะเปลี่ยนจากการแย่งกันระหว่าง features กับระบบ ไปสู่การตัดสินใจร่วมกันบนภาษาเดียวกัน และนั่น คือ จุดที่ Engineering กับ Product Owner กลับมายืนอยู่ข้างเดียวกันอีกครั้ง