องค์กรควรตั้งเป้าลด “หนี้ทางเทคนิค” ให้เป็นศูนย์หรือไม่?

15 ต.ค. 2565 | 08:11 น.

องค์กรควรตั้งเป้าลด “หนี้ทางเทคนิค” ให้เป็นศูนย์หรือไม่? : คอลัมน์บทความ โดย เติมศักดิ์ วีรขจรพงษ์ รองประธานภูมิภาคเอเชียตะวันออกเฉียงใต้เอาท์ซิสเต็มส์ หนังสือพิมพ์ฐานเศรษฐกิจ ฉบับ 3,827 หน้า 5 วันที่ 16 - 19 ตุลาคม 2565

 

ถ้าธุรกิจคุณอยู่ในแวดวงการพัฒนาซอฟต์แวร์ คุณอาจเคยได้ยินเกี่ยวกับหนี้ทางเทคนิค (หรือ Technical Debt)  ซึ่งการที่เราต้องคอยดูแลรักษาโค้ดที่มีอยู่หรือปรับปรุงแอปพลิเคชันรุ่นเก่านั้น ถือเป็นส่วนหนึ่งของภาระการทำงานที่เป็นผลมาจากหนี้ทางเทคนิคขององค์กร กล่าวง่าย ๆ ก็คือหนี้ทางเทคนิคหมายถึงการเขียนโค้ดโดยใช้วิธีลัดในอดีต ที่ส่งผลมาถึงอนาคตทำให้คุณต้องแก้ไขอดีตของโค้ดนั้น

 

ลองจินตนาการดูว่าจะน่าหวั่นใจเพียงใดหากองค์กรต้องรื้อแก้โค้ดบางส่วนที่มีอยู่ และยังต้องทดสอบครั้งแล้วครั้งเล่าเพื่อให้แน่ใจว่าแอปพลิเคชันจะทำงานได้ตามที่คาดหวัง และยังต้องศึกษาทำความเข้าใจเกี่ยวกับโค้ด “เก่า” ที่นักพัฒนาคนอื่น ๆ เคยเขียนไว้เมื่อหลายปีก่อน แค่นึกถึงงานยุ่งยากมากมายที่รออยู่ ก็รู้สึกหมดแรงแล้ว!

 

แต่ที่สำคัญไปกว่านั้นก็คือ ผลกระทบที่เกิดขึ้นกับธุรกิจซึ่งเกิดจากการที่ใช้วิธีลัดและเกิดหนี้ทางเทคนิค:

 

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

 

 

-ต้องใช้ผู้เชี่ยวชาญด้านการพัฒนามากขึ้น: การมีแอปพลิเคชันที่ซับซ้อนและมีสถาปัตยกรรมและรูปแบบโค้ดที่ไม่เหมาะสมทำให้ต้องใช้นักพัฒนาที่มีความเชี่ยวชาญเพิ่มมากขึ้นเพื่อแก้ไขปัญหาและปรับปรุงแอปให้มีประสิทธิภาพมากขึ้น และเราทุกคนรู้ดีว่าทุกวันนี้การจ้างนักพัฒนาที่มีทักษะความชำนาญยากแค่ไหน

 

องค์กรควรตั้งเป้าลด “หนี้ทางเทคนิค” ให้เป็นศูนย์หรือไม่?

 

 

-งานไอทีที่คั่งค้างมีจำนวนเพิ่มมากขึ้น: คำร้องขอจากฝั่งธุรกิจค่อย ๆ สะสมคั่งค้างมากขึ้นเรื่อย ๆ เพราะทีมพัฒนาไม่สามารถรับมือกับความต้องการที่เพิ่มขึ้น และปัญหานี้กำลังบั่นทอนศักยภาพและความคล่องตัวของธุรกิจในการนำเสนอคุณประโยชน์ การสร้างสรรค์นวัตกรรมอย่างต่อเนื่อง ตลอดจนการรักษาขีดความสามารถด้านการแข่งขันขององค์กร

 

-เพิ่มความเสี่ยงการเกิดช่องโหว่ด้านความปลอดภัย: ทางลัดที่ใช้เพื่อให้สามารถพัฒนาแอปพลิเคชันได้อย่างรวดเร็วอาจก่อให้เกิดช่องโหว่ด้านความปลอดภัยตามมา

 

ดังนั้น องค์กรควรตั้งเป้าขจัดปัญหานี้ให้หมดไปอย่างสิ้นเชิง และยิ่งไปกว่านั้น ถ้าจำเป็นที่จะต้องนำเสนอผลิตภัณฑ์ดิจิทัลใหม่ ๆ ให้เร็วกว่าที่เคย ก็ยิ่งไม่มีทางที่จะอยู่รอดได้ถ้าหากยังมีหนี้ทางเทคนิคค้างอยู่

 

 

ทำไมการดำเนินธุรกิจอย่างปลอดหนี้ถึงเป็นเรื่องยาก

 

ก่อนอื่นเราจะเริ่มจากการตอบคำถามส่วนแรก นั่นคือ การขจัดหนี้ทางเทคนิคเป็นเรื่องยากที่จะทำได้สำเร็จ

 

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

 

ปัญหาก็คือ มีปัจจัยภายในและภายนอกหลายอย่างที่องค์กรไม่สามารถควบคุมได้จนก่อให้เกิดหนี้เพิ่มมากขึ้น ตัวอย่างเช่น:

 

1.ทีมที่ขาดความชำนาญ: ส่วนใหญ่แล้วเกิดขึ้นจากการที่นักพัฒนาอายุงานยังน้อยในทีมอาจไม่ทราบวิธีการปรับใช้แนวทางที่ถูกต้องเหมาะสม

 

2.ข้อมูลรายละเอียดไม่เพียงพอและมีการเปลี่ยนแปลงในนาทีสุดท้าย: หลายครั้งที่นักพัฒนาต้องสร้างหรือปรับเปลี่ยนแอปที่มีอยู่โดยทั้งที่ยังไม่เข้าใจภาพรวมเกี่ยวกับสิ่งที่ธุรกิจต้องการ

 

3.ไม่มีการจัดทำเอกสารและการถ่ายทอดองค์ความรู้ระหว่างทีมงานต่าง ๆ: เพื่อเร่งดำเนินโครงการ ทีมพัฒนามักข้ามขั้นตอนการจัดทำเอกสาร เพราะคิดว่าตนเองจะยังคงทำงานอยู่ที่เดิมเพื่อดูแลรักษาแอปอย่างต่อเนื่อง แต่ส่วนใหญ่กลับไม่เป็นเช่นนั้น และผลที่ตามมาก็คือ ทีมงานใหม่ที่ได้รับมอบหมายให้จัดการดูแลและปรับปรุงแก้ไขต่อไม่สามารถเข้าใจบริบทการทำงานของแอปนั้น ๆ โดยรวม และสุดท้ายแล้วก็ทำให้แอปเกิดข้อผิดพลาดเพิ่มมากขึ้น

 

4.ขาดวิสัยทัศน์: ทีมงานมุ่งเน้นเฉพาะการส่งมอบแอปพลิเคชันตามกรอบเวลาปัจจุบัน โดยไม่ได้นึกถึงการปรับเปลี่ยนในอนาคต  ซึ่งการมองการณ์ใกล้เช่นนี้ส่งผลกระทบโดยตรงต่อวิธีการออกแบบ รวมไปถึงขีดความสามารถของแอปเพื่อรองรับความต้องการในอนาคต

 

5.ความเปลี่ยนแปลงของตลาดที่ไม่อาจคาดการณ์ได้: หนี้ทางเทคนิคยังอาจเป็นผลสืบเนื่องมาจากทุกสิ่งที่องค์กรธุรกิจไม่เคยรู้มาก่อนเมื่อตอนที่เริ่มต้นสร้างโซลูชั่น และองค์กรก็ไม่ได้เตรียมพร้อมรับมือกับสถานการณ์นั้นๆ

 

ส่วนใหญ่ปัจจัยเหล่านี้เป็นสิ่งที่เราไม่อาจคาดเดาได้ ดังนั้นองค์กรจึงควรวางแผนรับมือกับคำถามว่า “เราควรตั้งเป้าลดหนี้ทางเทคนิคให้เป็นศูนย์ดีหรือไม่” คำตอบสั้นๆ ก็คือ ไม่ เนื่องจากหนี้ทางเทคนิคที่ไม่สามารถควบคุมได้ย่อมจะส่งผลกระทบต่อความคล่องตัวของธุรกิจและความสามารถในการตอบโจทย์ความต้องการทางธุรกิจที่สำคัญ รวมไปถึงการตอบสนองต่อแรงกดดันของตลาด  ซึ่งไม่มีทางเป็นไปได้เลยที่เราจะขจัดหนี้ทางเทคนิคให้หมดไปอย่างสิ้นเชิง

 

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

 

เคล็ดลับในการจัดการหนี้ทางเทคนิค

 

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

 

ทีมงานขององค์กรธุรกิจควรดำเนินการดังต่อไปนี้เพื่อปรับปรุงการจัดการหนี้ทางเทคนิคให้ดียิ่งขึ้น:

 

-ปรึกษาทีมพัฒนาเพื่อกำหนดระดับของหนี้ทางเทคนิคที่องค์กรยอมรับได้ และช่วยให้ทีมงานมีความคล่องตัวในระดับที่เพียงพอเพื่อให้สามารถตอบโจทย์ความต้องการของธุรกิจ

 

-ประเมินความเสี่ยงของการปล่อยผ่าน “หนี้ทางเทคนิค” บางส่วน เพื่อให้สามารถทำงานได้เสร็จตามกำหนดเวลา

 

-ประเมินผลกระทบและปัญหายุ่งยากที่จะเกิดขึ้นเมื่อต้องจัดการกับหนี้ทางเทคนิคภายหลัง ด้วยการตั้งคำถามที่เหมาะสม เช่น “หลังจากที่เปิดให้ใช้งานแอปพลิเคชั่นแล้ว จะต้องย้ายข้อมูลจากที่หนึ่งไปยังอีกที่หนึ่งเพื่อที่จะแก้ไขโค้ดหรือไม่” หรือ “จะก่อให้เกิดผลกระทบต่อพาร์ทเนอร์ที่ใช้ API จากระบบของเราหรือไม่”

 

และอีกหนึ่งคำแนะนำ คือ องค์กรควรหันมาใช้แพลตฟอร์มการพัฒนาที่มีเครื่องมือที่จำเป็นครบครันอยู่แล้ว ซึ่งจะช่วยให้ธุรกิจจัดการหนี้ทางเทคนิคได้ทันทีตั้งแต่วันแรก แพลตฟอร์มที่ว่านี้ก็คือแพลตฟอร์ม Low-Code ซึ่งประกอบด้วยเครื่องมือพัฒนามากมายที่จะช่วยให้ทีมพัฒนาสามารถสร้างสรรค์ผลิตภัณฑ์สำหรับอนาคต โดยมีการจัดการหนี้ทางเทคนิคอย่างเป็นระบบภายไว้ในกระบวนการของการพัฒนา

 

นอกจากนี้ ยังมีความสามารถของ AI ที่จะช่วยให้ผู้บริหารไอทีสามารถตรวจสอบสถาปัตยกรรมที่ซับซ้อน ครอบคลุมกลุ่มผลิตภัณฑ์ต่าง ๆ เพื่อระบุปัญหาที่เกิดขึ้น และช่วยนักพัฒนาดำเนินการตามแนวทางปฏิบัติที่เหมาะสม พร้อมหลีกเลี่ยงข้อผิดพลาด