ระบบที่ดูใช้งานได้ แต่ดูแลไม่ได้

22 กุมภาพันธ์ 2569อ่าน 6 นาที
ระบบที่ดูใช้งานได้ แต่ดูแลไม่ได้

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

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

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

ทำไมความถูกและเร็วถึงน่าเลือก

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

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

ดอกเบี้ยของหนี้ทางเทคนิค

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

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

สิ่งที่ควรถามก่อนเซ็นสัญญา

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

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

Software DevelopmentTechnical DebtDocumentation

บริการที่เกี่ยวข้อง

รับพัฒนาเว็บแอปพลิเคชัน

สร้างเว็บแอปที่รองรับการเติบโตและเชื่อมกับระบบอื่นได้

WhaleScope

ดูโครงสร้างตลาดของธุรกิจซอฟต์แวร์ สื่อ และไอที บน WhaleScope

รายชื่อบริษัท ผู้เล่นรายใหญ่ อัตราคงอยู่ และการกระจายรายจังหวัดของหมวดการจัดทำโปรแกรมคอมพิวเตอร์ — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล

อ่านต่อ

เมื่อไม่มีใครเข้าใจระบบที่ AI สร้างขึ้น

โค้ดที่ AI เขียนทำงานได้ตั้งแต่วันแรก แต่เมื่อมันพังในเดือนที่หก คำถามไม่ใช่ว่าใครจะแก้ แต่คือใครเข้าใจมันพอจะแก้

ระบบที่ไม่มี Documentation เสี่ยงกว่าที่คิด

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

ถ้าผู้พัฒนาลาออก ใครจะดูแลระบบต่อ?

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

ระบบที่ดี ควรอยู่ได้นานกว่าคนที่สร้าง

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