- สิ่งที่จำเป็นเพื่อมองหนี้ทางเทคนิคเป็นเครื่องมือเชิงกลยุทธ์
- ตระหนักและแก้ไขสมมติฐานเชิงลบเกี่ยวกับหนี้ทางเทคนิค
- จัดประเภทหนี้ทางเทคนิค 6 แบบและรับมือให้แตกต่างกัน
- ประเมินขนาดของหนี้ทางเทคนิค
- วิธีจัดลำดับความสำคัญของหนี้ทางเทคนิค
How to Not Manage Tech Debt
- 4 สมมติฐานที่ทำให้บริหารหนี้ทางเทคนิคผิดพลาด
สมมติฐาน #1 : หนี้ทางเทคนิค = สิ่งไม่ดี
- ไม่ควรจัดหนี้ทางเทคนิคทั้งหมดว่าเป็น 'สิ่งไม่ดี'
- การตั้งชื่อให้แต่ละอย่าง วัดระดับความเจ็บปวด และจัดหมวดหมู่หนี้ทางเทคนิค จะดีกว่ามาก
- หนี้ทางเทคนิคบางอย่างเป็นสิ่งที่ควรมี และทุกทีมก็ควรมีหนี้ทางเทคนิค
- กรณีของ Twitter ที่ 'มีหนี้ทางเทคนิคที่ดี' : ใช้ public storage ก่อน แล้วจึงพัฒนา Manhattan ซึ่งเป็น distributed DB ของตนเอง
- คำถามเพื่อรับมือกับสมมติฐาน 'หนี้ทางเทคนิค = สิ่งไม่ดี'
- ถ้าเราสะสมหนี้ทางเทคนิคนี้ตอนนี้ แล้วค่อยแก้เดือนหน้า เราจะได้อะไร?
- ในสถานการณ์แบบไหนที่ผู้บริหารจะสนใจหนี้ทางเทคนิคนี้? เราควรส่งต่อข้อมูลแบบใดเพื่อช่วยให้ CTO ไป pitch กับผู้บริหารได้?
- initiative นี้จะเชื่อมไปสู่วิสัยทัศน์ที่ใหญ่ขึ้นหรือทิศทางเชิงกลยุทธ์ของบริษัทได้อย่างไร?
สมมติฐาน #2 : หนี้ทางเทคนิคทั้งหมด = งานซับซ้อน
- เช่นเดียวกับงานยากทุกประเภท ไม่ใช่แค่หนี้ทางเทคนิค มีหลายวิธีในการจัดการงานที่ซับซ้อน
- โดยเฉพาะในกรณีของหนี้ทางเทคนิค มีวิธีเข้าหางานแบบ Defined/Undefined
- Defined = งานมีจุดเริ่มต้นและจุดสิ้นสุด
- Undefined = งานมีจุดเริ่มต้น แต่จุดสิ้นสุดไม่ชัดเจน
- หากจะรับมือกับสมมติฐานว่าหนี้ทางเทคนิค = งานซับซ้อน
- ต้องทำให้ชัดก่อนว่าหนี้ทางเทคนิคที่อยู่ตรงหน้าเป็น Defined หรือ Undefined
- ถ้าเป็น Defined ให้เข้าใจเวลาที่คาดว่าจะใช้จนงานเสร็จ และเผื่อ buffer time ไว้เล็กน้อย
- ถ้าเป็น Undefined ให้ลิสต์ส่วนที่ยังไม่ชัดเจนและสื่อสารกับผู้มีส่วนได้ส่วนเสีย เพื่อให้เข้าใจว่าทำไมงานนี้จึงซับซ้อนและไม่มีวันจบที่ชัดเจน แล้วขอความเห็นว่าควรเดินหน้าต่ออย่างไรจึงจะดีที่สุด
- แบ่งหนี้ทางเทคนิคแบบ Undefined ออกเป็นงานย่อยที่ย่อยง่ายขึ้นเพื่อลดความซับซ้อน
- เมื่อเปลี่ยนจากงานใหญ่ที่ซับซ้อน ไปเป็นงานเล็กที่ยังซับซ้อนแต่ลงมือทำได้ ทีมจะมีแรงจูงใจมากขึ้นในการแก้หนี้ทางเทคนิคบางส่วนภายในช่วงเวลาที่กำหนดของ sprint/รายไตรมาส
- คำถามเพื่อรับมือกับสมมติฐาน 'หนี้ทางเทคนิค = งานซับซ้อน'
- มีสมมติฐานอะไรเกี่ยวกับระบบที่ผิดอยู่บ้าง?
- ถ้าดึงคนที่มีประสบการณ์หรือคุ้นเคยกับด้านนี้เข้ามา คำถามที่ต้องถามมีอะไรบ้าง?
- ทีมของเรามีคนและความรู้ที่เหมาะสมพอจะทำงานนี้หรือไม่? ถ้าไม่ เราควรพิจารณาจัดสรรข้อมูลหรือทรัพยากรใหม่อย่างไร และเมื่อไรจึงเหมาะที่สุดในการแก้ปัญหานี้?
- วิธีที่ดีที่สุดในการอธิบายความซับซ้อนของหนี้ทางเทคนิคนี้ให้คนที่ไม่เข้าใจเลยคืออะไร?
สมมติฐาน #3 : หนี้ทางเทคนิค ≠ งานผลิตภัณฑ์
- องค์กรมักจะชัดเจนว่างานผลิตภัณฑ์จะช่วยยกระดับ metric ของบริษัทอย่างไร
- แต่โดยมากกลับไม่มีการพูดถึงหนี้ทางเทคนิคในจุดนี้
- การแก้หนี้ทางเทคนิคให้ทันเวลา แม้จะวัดเชิงปริมาณได้ไม่ทันที ก็อาจสำคัญต่อการผลักดันการเติบโตของบริษัท
- หากจะรับมือกับสมมติฐานว่าหนี้ทางเทคนิค ≠ งานผลิตภัณฑ์
- แม้หนี้ทางเทคนิคบางด้านจะไม่เชื่อมกับ metric โดยตรง ก็ควรคิดให้กว้างว่ามันช่วยประสบการณ์ผู้ใช้/ประสบการณ์ผลิตภัณฑ์ด้านใดได้บ้าง
- แทนที่จะเน้นเฉพาะข้อดีทางเทคนิค ให้เน้นข้อดีต่อผู้ใช้และผลิตภัณฑ์ในระดับเท่าๆ กัน จะช่วยให้คนอื่นเข้าใจได้ง่ายว่าทำไมทีมจึงควรให้ความสำคัญกับงานนี้
- ควรใช้เวลาเพื่อให้แน่ใจว่า business lead และ tech lead เข้าใจตรงกัน (on the same page)
- คำถามเพื่อรับมือกับสมมติฐาน 'หนี้ทางเทคนิค ≠ งานผลิตภัณฑ์'
- เหตุผลที่สำคัญที่สุดเพียงข้อเดียวที่เราต้องทำงานนี้ตอนนี้คืออะไร?
- ใครบ้างที่ต้องเข้าใจผลกระทบของงานนี้? และทำไมพวกเขาจึงควรสนใจ?
- สิ่งที่ฉันต้องการจะสื่อคืออะไร? ตรงกับสิ่งที่ผู้มีส่วนได้ส่วนเสียอยากฟังหรือไม่? ถ้าไม่ เราจะแก้ปัญหาของพวกเขาได้อย่างไร?
- สำหรับฉันหรือทีม อะไรคือผลลัพธ์ที่ถือว่าใช้ได้ vs. ยอดเยี่ยม?
- เรากำลังสัญญาผลลัพธ์เกินจริงอยู่หรือไม่? เราสามารถแบ่งความคาดหวังของผลลัพธ์เป็นระดับยอดเยี่ยมกับดีได้หรือไม่?
สมมติฐาน #4 : ความเจ็บปวดของปัจเจก = ความเจ็บปวดขององค์กร
- วิศวกรที่อยู่ใกล้กับหนี้ทางเทคนิคมักพูดซ้ำๆ เป็นประจำว่าการจัดการหนี้ทางเทคนิคนั้นเจ็บปวดสำหรับพวกเขาโดยส่วนตัว
- พนักงานอาจรู้สึกเหมือนโลกกำลังจะแตก แต่คนอื่นๆ ในองค์กรไม่ได้รู้สึกเจ็บปวดแบบเดียวกัน
- เรื่องนี้พบได้บ่อยกับคนช่วงต้นของอาชีพ และมักเกิดจากการขาดบริบทเชิงกลยุทธ์ที่กว้างกว่า
- หากจะรับมือกับสมมติฐานว่าความเจ็บปวดของปัจเจก = ความเจ็บปวดขององค์กร
- เมื่อเจอพื้นที่ของหนี้ทางเทคนิคที่มีลำดับความสำคัญสูง ให้หยุดดูสักนิดว่านี่คือ pain point ระดับบุคคลหรือระดับองค์กร
โดยทั่วไป ปัญหาระดับองค์กรจะส่งผลโดยตรงต่อลูกค้าหรือธุรกิจไม่ทางใดก็ทางหนึ่ง
- ลองคิดจากมุมของคนที่มีบริบทองค์กรมากกว่าคุณ หรืออาจอธิบายให้คนจากทีมอื่นฟังก็ได้
- คำถามเพื่อรับมือกับสมมติฐาน 'ความเจ็บปวดของปัจเจก = ความเจ็บปวดขององค์กร'
- มีกี่ทีมที่จะได้ประโยชน์จากการจัดประเภทและแก้ไขหนี้ทางเทคนิคนี้?
- บริษัทเคยยอมรับหรือให้รางวัลคนที่รับงานหนี้ทางเทคนิคเมื่อไรบ้าง? ตอนนั้นเป็นหนี้ทางเทคนิคประเภทใด และทำไมจึงจำเป็นในเวลานั้น? พอจะเล่าได้ไหมว่าคนนั้นวางตำแหน่งของงานนั้นอย่างไร?
- ผู้จัดการวิศวกรรมของฉันเข้าใจคุณค่าของงานหนี้ทางเทคนิคหรือไม่? เขาจะช่วย advocate ผลงานของฉันในงานนี้ระหว่าง performance review หรือเปล่า?
หนี้ทางเทคนิค 6 ประเภท
- Maintenance debt (หนี้การบำรุงรักษา)
- เมื่อทีมตามการอัปเดตของเทคโนโลยีไม่ทัน
- รวมถึงการไม่ลบ dead code หลังเริ่มทดลอง/rollout ฟีเจอร์/ยกเลิกการ deploy ตลอดจนไม่อัปเดต library, ไม่ใส่คอมเมนต์กับโค้ดที่ต้องมีบริบท และไม่อัปเดตเอกสารเกี่ยวกับการตัดสินใจด้าน implementation
- ตัวอย่าง) ทดลองฟีเจอร์ 'log in with Spotify' แล้วภายหลังยกเลิก แต่ไม่ได้ลบโค้ดนั้นออก
- Developer efficiency debt (หนี้ประสิทธิภาพนักพัฒนา)
- เมื่อบริษัทไม่มีระบบทดสอบ ระบบ monitoring และระบบแจ้งเตือนที่เหมาะสมสำหรับผลิตภัณฑ์
- เป็นหนี้ประเภทที่พบได้บ่อย ซึ่ง workflow ด้านวิศวกรรมไม่มีประสิทธิภาพอย่างมาก การ deploy/build ใช้เวลาหลายชั่วโมงหรือหลายวัน และนักพัฒนาไม่สามารถตรวจพบปัญหาทางเทคนิคก่อนขึ้น production ได้
- ตัวอย่าง) องค์กรโตจาก 15 คนเป็น 50 คนภายใน 1 ปี ทำให้มีการทดลองมากเกินไป มี release แก้บั๊กที่พบใน production ค้างอยู่ 2-3 รุ่น การทดสอบใหม่สำหรับประสบการณ์การซื้อจึงยิ่งตามหลังไปอีก
- Stability debt (หนี้ด้านเสถียรภาพ)
- เมื่อหนี้ทางเทคนิคหลายรูปแบบสะสมในองค์กรจนกระทบเสถียรภาพของ infrastructure
- เกิดสถานการณ์ที่ไม่ได้บริหาร on-call ไว้ล่วงหน้า แต่ค่อยเรียกผู้เชี่ยวชาญเฉพาะทางภายหลังเมื่อมีปัญหา หรือสุดท้ายทั้งทีมต้องอยู่ on-call
- เรื่องนี้เป็นปัญหาใหญ่สำหรับวิศวกรและทีมเวร on-call แต่คนส่วนที่เหลือของบริษัทกลับแทบเป็นไปไม่ได้เลยที่จะเข้าใจและอธิบายปัญหา
- หนี้ด้านเสถียรภาพยังส่งผลต่อความน่าเชื่อถือของผลิตภัณฑ์ และทำให้เกิดปัญหาที่ลูกค้าต้องเผชิญ
- ตัวอย่าง) ทีม mobile มีนักพัฒนา iOS มากกว่า จึงให้ความสำคัญกับ iOS มากกว่าแอป Android ส่งผลให้แอป Android ขาด product guideline สำหรับ flow ที่สำคัญต่อธุรกิจ และยังมีโค้ดที่เปราะบาง (Kryptonite) ซึ่ง third party เคยพัฒนาไว้ในช่วงแรก ทำให้ผู้ใช้ Android crash เมื่อเข้าถึงฟีเจอร์เก่าๆ และคะแนนรีวิวใน Google Play แย่ลง
- Security debt (หนี้ด้านความปลอดภัย)
- เมื่อใช้เทคโนโลยีสแต็กที่มีช่องโหว่ด้านความปลอดภัย เช่น brute-force password attack หรือข้อมูลรั่วไหล
- หลายองค์กรมีหนี้ด้านความปลอดภัยเพราะมนุษย์นั้นวางแผนและประเมินเหตุการณ์ที่อาจเกิดขึ้น (หรืออาจไม่เกิดขึ้น) ได้ยาก
- ตัวอย่าง) ปัญหาในกระบวนการภายในบริษัททำให้อัปเดตไม่ทันเวลา จึงไม่สามารถ patch ช่องโหว่ที่รู้กันอยู่แล้วได้ นำไปสู่การรั่วไหลของข้อมูลส่วนตัวลูกค้า (ตั้งแต่บริษัทเล็กๆ ไปจนถึงบริษัทอย่าง Equifax ที่กระทบผู้คน 140 ล้านคน)
- Technical product debt (หนี้ผลิตภัณฑ์เชิงเทคนิค)
- เมื่อผลกระทบเชิงลบต่อผลิตภัณฑ์เริ่มมองเห็นได้ชัด
- เป็นหนี้ที่มองเห็นง่ายและเหมาะกับการแก้ที่สุด เพราะกระทบต่อผู้ใช้ และทุกทีมในองค์กรก็มองออกว่ามันกระทบต่อการขาย/รายได้
- ตัวอย่าง) ผู้ใช้ต้องรอหลายวินาทีเมื่อต้องทำบางอย่างในผลิตภัณฑ์ เรื่องนี้อาจเกิดจากหนี้หลายแบบ แต่ส่งผลต่อประสบการณ์หลักของผู้ใช้กับผลิตภัณฑ์
- Decision debt (หนี้จากการตัดสินใจ)
- คือการต้องจ่ายต้นทุนของการตัดสินใจทางเทคนิคในอดีต เพราะการตัดสินใจนั้นผิดไป X% หรือมีการ trade-off ด้านขอบเขต เวลา และทรัพยากร
- เป็นรูปแบบของหนี้ทางเทคนิคที่พบได้บ่อยที่สุด
- ตัวอย่าง) เว็บไซต์ใช้ third party สำหรับการทดลองบางอย่าง จากนั้นเติบโตอย่างมากเป็นเวลาหลายปีจนมีผู้ใช้หลายล้านคน ตอนนี้ทุกครั้งที่ต้องทำการทดลองที่ซับซ้อน ทั้งทีมเทคนิค ทีมข้อมูล และทีมผลิตภัณฑ์ต่างก็ลำบากกันหมด
นี่คือหนี้จากการตัดสินใจ เพราะทีมเคยตัดสินใจ trade-off ระหว่างการใช้ third party กับการพัฒนาเอง ซึ่งในเวลานั้นอาจเป็นทางเลือกที่ถูกต้อง แต่ตอนนี้เริ่มได้รับผลกระทบแล้ว
กำหนดขนาดของหนี้ทางเทคนิค : Acute vs Systemic
- เมื่อเข้าใจประเภทของหนี้ทางเทคนิคแล้ว ขั้นต่อไปคือต้องกำหนดขนาดของต้นทุนเพื่อเปรียบเทียบกับสิ่งที่จะได้กลับมา
- เมื่อทีมถามว่า 'เมื่อไรเราจะมีเวลาไปทำงานเรื่องหนี้ทางเทคนิค?' มักยากที่จะบอกว่ามันเล็กหรือใหญ่ในแง่ของเวลา ความคิด และความพยายาม
- หนี้ทางเทคนิคแบบ Acute
- เป็นหนี้ทางเทคนิคที่ค่อนข้างเล็ก
- ตัวอย่าง) เพื่อให้ส่งมอบฟีเจอร์ใหม่ได้ เราข้ามงานสำหรับแพลตฟอร์มหรือเบราว์เซอร์ที่มีผู้ใช้น้อยไปก่อน ถ้าไม่มีงานอื่นคั่น ก็สามารถเพิ่มกลับได้ง่ายภายใน 1 วัน
- หนี้ทางเทคนิคแบบ Systemic
- เป็นหนี้ทางเทคนิคขนาดใหญ่ไปจนถึงใหญ่มาก
- ตัวอย่าง) CTO/ผู้ก่อตั้งเคยตัดสินใจเกี่ยวกับผลิตภัณฑ์ (และโดยอ้อมคือเทคโนโลยี) เมื่อ 5 ปีก่อน และบริษัทก็เดินมาตามรากฐานนั้น หากจะเปลี่ยนตอนนี้จะกระทบหลายสิ่งหลายอย่าง
หนี้ทางเทคนิคแบบนี้แก้ได้ไม่ง่าย และอาจต้องใช้เวลาหลายเดือนถึงหลายปีในการเปลี่ยนแปลง
การจัดลำดับความสำคัญของหนี้ทางเทคนิคอย่างมีกลยุทธ์
- วิธีพิจารณาและประเมินอย่างยืดหยุ่น
- Confidence : มีโอกาสสูงแค่ไหนที่สิ่งนี้จะกลายเป็นปัญหาใหญ่? ต่ำ/สูง
- Time : สิ่งนี้จะกลายเป็นปัญหาเมื่อไร? ยังไม่เร่งด่วน/เร่งด่วน
- Impact to User : ถ้าไม่ทำ จะเกิดปัญหาด้านความเร็ว/คุณภาพที่กระทบประสบการณ์ผู้ใช้หรือไม่? ต่ำ/สูง
- Sequence : สิ่งนี้ขัดขวางการไปถึง milestone สำคัญหรือไม่? กระทบน้อย/บล็อก
- Accumulated debt : เราตัดสินใจสะสมหนี้ไปแล้วมากแค่ไหน? น้อย/มาก
พอร์ตโฟลิโอหนี้ทางเทคนิคเชิงกลยุทธ์ตามช่วงการเติบโตของบริษัท
- Traction :
- ก่อนถึง Product-Market fit
- ต้องตัดสินใจด้านวิศวกรรมโดยให้ความสำคัญกับความเร็วมากกว่าความถูกต้อง เสถียรภาพ และกระบวนการ จึงมีหนี้ประสิทธิภาพนักพัฒนาขนาดใหญ่
- โดยทั่วไปหมายถึงการเลือก full-stack framework อย่าง Django, Rails, PHP เป็นต้น เพื่อพัฒนาให้เร็ว
- Inflection :
- ช่วงที่เริ่มเห็นสัญญาณของ PMF และผลิตภัณฑ์เข้าสู่ลูปที่ขยายตัวได้
- ทีมเริ่มตระหนักว่าต้องมีบางกระบวนการ (ทำให้หนี้ประสิทธิภาพนักพัฒนาเริ่มถูกแก้) แต่เพราะยังต้องคอยหาสมดุลระหว่างกระบวนการภายในกับประสบการณ์ผู้ใช้ หนี้ผลิตภัณฑ์เชิงเทคนิคจึงเพิ่มขึ้น
- Scale :
- ช่วง hyper-growth ของบริษัท
- เมื่อเริ่มหาสมดุลระหว่าง practice/process ภายในกับประสบการณ์ผู้ใช้ได้ หนี้ผลิตภัณฑ์เชิงเทคนิคและหนี้ประสิทธิภาพนักพัฒนาจะเริ่มลดลงและทรงตัว
- แต่ผลจากการเติบโตอย่างรวดเร็วมาก ทำให้หนี้ด้านความปลอดภัย หนี้การบำรุงรักษา และหนี้จากการตัดสินใจเพิ่มขึ้น
- จะมีการเปลี่ยนแปลงและปรับแก้มากมายในเรื่อง test automation, ระบบ deploy, monitoring และ alerting, logging และ instrumentation, testing และ staging, ETL เป็นต้น
- Expansion :
- จุดเริ่มต้นของ saturation ธุรกิจเริ่มเติบโตเป็นผู้ใหญ่มากขึ้น
- เพราะมีโค้ดเก่าและการตัดสินใจเดิมสะสมอยู่มาก หนี้การบำรุงรักษาและหนี้จากการตัดสินใจจึงยังเพิ่มต่อเนื่อง
- ขณะเดียวกัน เมื่อทีมเริ่มมองหาโอกาสใหม่เพื่อการเติบโต หนี้ประสิทธิภาพนักพัฒนาก็เริ่มเพิ่มขึ้นอีกครั้ง
- ส่วนหนี้ผลิตภัณฑ์เชิงเทคนิค หนี้ด้านความปลอดภัย และหนี้ด้านเสถียรภาพ กำลังค่อยๆ เข้าสู่สมดุลหลังผ่านช่วงก่อนหน้า
เคล็ดลับในการบริหารพอร์ตโฟลิโอหนี้ทางเทคนิค
- กระบวนการเพื่อลดหนี้ทางเทคนิคที่กำลังก่อตัว
- แม้การสะสมหนี้ทางเทคนิคจะเป็นเรื่องเชิงกลยุทธ์ แต่บางครั้งการวางกระบวนการตั้งแต่ต้นเพื่อไม่ให้เกิดหนี้ทางเทคนิคเลยก็เป็นสิ่งที่ถูกต้องกว่า
- โดยเฉพาะในช่วง Inflection และ Scale ซึ่งเมื่อมีวิศวกรมากขึ้น หนี้ประสิทธิภาพนักพัฒนาควรลดลง
- เมื่อหนี้ประสิทธิภาพนักพัฒนาลดลง อาจถูกแทนที่ด้วยหนี้จากการตัดสินใจและหนี้การบำรุงรักษาที่เพิ่มขึ้น
- ตัวอย่างของกระบวนการเหล่านี้ เช่น code/PR review, มาตรฐาน monitoring, การอนุมัติจาก QA และการทบทวนด้านเทคนิค/การออกแบบ
- เครื่องมือเพื่อป้องกันการก่อตัวของหนี้บางประเภท
- การลงทุนกับเครื่องมือพื้นฐานอาจช่วยไม่ให้หนี้บางประเภทก่อตัวขึ้นได้
- สำคัญเป็นพิเศษในช่วง Scale สำหรับปัญหาความปลอดภัย (หนี้ด้านความปลอดภัย), การป้องกันบั๊กที่กระทบประสบการณ์ผู้ใช้ (หนี้ผลิตภัณฑ์เชิงเทคนิค), และความสม่ำเสมอของโค้ด (หนี้ประสิทธิภาพนักพัฒนา)
- ตัวอย่างเครื่องมือเหล่านี้ เช่น Linter และ CI/CD pipeline
- งานในสปรินต์สำหรับหนี้ทางเทคนิคแบบ Reactive & Acute
- เมื่อองค์กรเติบโตจนถึงระดับที่ต้องมี on-call แล้ว on-call sprint ควรถูกใช้ไปกับการดับไฟที่กำลังเกิดขึ้น หรือการทำงานตอบสนองที่เกี่ยวข้องกับหนี้ทางเทคนิค
- วิธีนี้ช่วยให้องค์กรจัดการรายการหนี้ทางเทคนิคที่เร่งด่วนได้ และทำให้ทีม on-call ลงมือจัดการปัญหาปัจจุบัน/อดีตอย่างเป็นรูปธรรมได้
- การเปิดให้ on-call ทำงานตอบสนองเป็นเรื่องสำคัญมาก โดยเฉพาะในช่วง Scale/Expansion เพราะการจัดการหนี้ทางเทคนิคแบบเร่งด่วนจะช่วยให้ทีมอื่นสามารถสร้างฟีเจอร์/ผลิตภัณฑ์ใหม่ และรองรับหนี้เพิ่มเติมที่ตามมาได้
- งานตาม roadmap สำหรับหนี้ทางเทคนิคแบบ Proactive และ Systemic
- การใส่งานหนี้ทางเทคนิคลงใน roadmap ต้องอาศัยการจัดแนวร่วมกันระหว่างหลายทีม
- ตัวอย่างของการใส่งานหนี้ทางเทคนิคลงใน roadmap เช่น การ rewrite ครั้งใหญ่, การปรับระบบข้อมูลของฟีเจอร์ที่ลูกค้าใช้บ่อย, การกำหนดและติดตั้ง alert สำหรับเส้นทางหลัก, การเปลี่ยนระบบชำระเงิน เป็นต้น
วิธีเปลี่ยนหนี้ทางเทคนิคจากภาระให้เป็นเครื่องมือเชิงกลยุทธ์
- ผ่านการทำความเข้าใจกับหนี้ทางเทคนิคที่สะสมอยู่ ทีมจะสามารถตัดสินใจเชิงกลยุทธ์โดยรวมได้ว่าจะทำ initiative ใด
- ลองคิดถึงสมมติฐานเรื่องหนี้ทางเทคนิคที่ทีมต้องเจอบ่อยๆ คุณกำลังโต้แย้งกับ 'หนี้ทางเทคนิค = สิ่งไม่ดี' หรือ 'หนี้ทางเทคนิค ≠ งานผลิตภัณฑ์' อยู่หรือไม่? คุณกำลังได้ยินเพื่อนร่วมงานที่คิดว่า 'ความเจ็บปวดของปัจเจก = ความเจ็บปวดขององค์กร' หรือเปล่า?
- อย่าใช้คำกว้างๆ อย่าง 'หนี้ทางเทคนิค' แต่ให้เรียกชื่อให้ชัดว่าเป็นหนี้การบำรุงรักษา หนี้ประสิทธิภาพนักพัฒนา หนี้ด้านเสถียรภาพ หนี้ด้านความปลอดภัย หนี้ผลิตภัณฑ์เชิงเทคนิค หรือหนี้จากการตัดสินใจ
- กำหนดขนาดของหนี้ทางเทคนิคเพื่อลดความกำกวม ว่าเป็น Acute หรือ Systemic?
- จัดลำดับความสำคัญของหนี้ทางเทคนิคอย่างมีกลยุทธ์ โดยเทียบกับส่วนอื่นของบริษัท และอิงจากตัวแปรอย่างระดับความมั่นใจ เวลา และผลกระทบต่อผู้ใช้
- พัฒนาและรักษาสมดุลของพอร์ตโฟลิโอหนี้ทางเทคนิคตามการเปลี่ยนแปลงและความต้องการของการเติบโตของบริษัท
2 ความคิดเห็น
ผมคิดว่าเนื้อหาที่พื้นฐานที่สุดแต่ก็สำคัญที่สุด คือการทำให้ชัดเจนว่า "นี่คือความเจ็บปวดของคุณ" ไม่ว่าจะเป็นตัวเลขหรืออะไรก็ตาม
ถ้าทำแบบนั้นไม่ได้ จริง ๆ แล้วก็อาจสรุปได้เหมือนกันว่า บางที มันอาจไม่ใช่หนี้ทางเทคนิคมาตั้งแต่แรกก็ได้