ระบบที่ใช้มานานมักมาถึงจุดที่ทุกคนรู้สึกตรงกันว่าไม่ไหวแล้ว หน้าจอโหลดช้า แก้อะไรทีต้องรอเป็นสัปดาห์ คนที่เขียนไว้แต่แรกลาออกไปนานแล้ว แต่ระบบนั้นก็ยังรันงานจริงอยู่ทุกวัน และนั่นคือเหตุผลที่การตัดสินใจเรื่องนี้ยากกว่าที่คิด บทความนี้ว่าด้วยเกณฑ์ที่ใช้ตัดสินว่าจะเขียนใหม่ทั้งระบบ ค่อย ๆ แทนทีละส่วน หรือแค่ปรับของเดิมให้อยู่ต่อได้
การเขียนใหม่ให้ภาพที่สวยที่สุดในห้องประชุม ไม่ต้องแบกของเดิม ได้เลือกเครื่องมือใหม่ และประเมินเวลาได้ง่ายกว่าเพราะยังไม่เจอปัญหาจริง ทีมพัฒนาเองก็มักเชียร์ทางนี้ เพราะการไล่อ่านโค้ดที่คนอื่นเขียนไว้สิบปีนั้นน่าเบื่อกว่าการเริ่มจากหน้าว่างมาก
สิ่งที่ประมาณการมักไม่รวมคือ ระหว่างที่เขียนใหม่ ระบบเดิมยังต้องรันอยู่ ยังต้องแก้บั๊กอยู่ และธุรกิจก็ยังขอฟีเจอร์ใหม่อยู่ ทีมจึงต้องดูแลสองระบบพร้อมกันหลายเดือน ซึ่งเป็นช่วงที่แพงที่สุดและเหนื่อยที่สุดของทั้งโปรเจกต์
โค้ดเก่าที่ดูรกและไม่สมเหตุสมผล ส่วนใหญ่ไม่ได้รกเพราะคนเขียนไม่เก่ง แต่รกเพราะมันสะสมเงื่อนไขจริงของธุรกิจไว้ทีละข้อตลอดสิบปี เช่น ลูกค้ากลุ่มนี้คิดภาษีอีกแบบ สาขานี้ปิดยอดคนละวันกับที่อื่น ใบสั่งซื้อที่เกินวงเงินต้องให้สองคนอนุมัติ เงื่อนไขพวกนี้ไม่มีใครจดไว้ที่ไหน มันอยู่ในโค้ดล้วน ๆ
ระบบใหม่ที่เขียนจากสเปกซึ่งคุยกันในห้องประชุมสามครั้ง จึงมักขาดเงื่อนไขที่ระบบเก่าทำได้อยู่แล้ว และจะรู้ตัวก็ต่อเมื่อขึ้นระบบจริงแล้วมีคนโทรมาบอกว่ายอดไม่ตรง
ถ้ายังมีคนในองค์กรที่อธิบายได้ว่าแต่ละส่วนทำงานยังไง การปรับของเดิมมักคุ้มกว่า แต่ถ้าไม่เหลือใครเลยและเอกสารก็ไม่มี ต้นทุนของการปรับจะสูงกว่าที่เห็น เพราะทุกการแก้ต้องเริ่มจากการเดาว่าจะไปพังตรงไหน
ระบบที่ช้าเพราะเซิร์ฟเวอร์เล็กหรือฐานข้อมูลไม่มี index แก้ได้ด้วยเงินก้อนเล็กมาก ส่วนระบบที่ช้าเพราะโครงสร้างข้อมูลผิดตั้งแต่ต้น แก้ยังไงก็ไม่หาย สองอย่างนี้ดูเหมือนกันจากฝั่งผู้ใช้ แต่ราคาต่างกันสิบเท่า
เฟรมเวิร์กหรือภาษาที่เจ้าของเลิกออกแพตช์ความปลอดภัยแล้ว เป็นเหตุผลที่หนักที่สุดข้อเดียวที่ควรเขียนใหม่ ไม่ใช่เพราะมันเก่า แต่เพราะช่องโหว่ที่ประกาศใหม่จะไม่มีใครอุดให้ และฝ่าย IT ขององค์กรใหญ่จะไม่ยอมให้ผ่านการตรวจ
ถ้ากำลังจะเพิ่มสาขา เปิดช่องทางขายใหม่ หรือเปลี่ยนวิธีคิดราคา ระบบใหม่ที่ออกแบบเผื่อไว้จะคุ้มกว่า แต่ถ้ากระบวนการนิ่งมาห้าปีและจะนิ่งต่อไป การเขียนใหม่คือการจ่ายเงินก้อนใหญ่เพื่อให้ได้สิ่งเดิม
ระบบที่หยุดได้หนึ่งคืนกับระบบที่หยุดไม่ได้เลย ใช้วิธีคนละแบบ อย่างหลังบังคับให้ต้องค่อย ๆ แทนทีละส่วน ไม่ว่าจะอยากเขียนใหม่แค่ไหนก็ตาม
แทนที่จะเลือกระหว่างเขียนใหม่ทั้งก้อนกับไม่ทำอะไรเลย วิธีที่ได้ผลกับระบบองค์กรส่วนใหญ่คือแทนทีละส่วน ตัดฟังก์ชันหนึ่งออกมาทำใหม่ ให้ระบบใหม่กับระบบเก่าทำงานคู่กันไปก่อน แล้วค่อยย้ายผู้ใช้ทีละกลุ่ม
ข้อเสียคือช้ากว่าและต้องมีวินัย ถ้าไม่ปิดของเดิมตามแผน องค์กรจะจบลงด้วยการมีสองระบบที่ต้องดูแลตลอดไป ซึ่งแย่กว่าจุดเริ่มต้น
ไม่ว่าจะเลือกทางไหน งานที่กินเวลาที่สุดมักเป็นการย้ายข้อมูล ข้อมูลที่ใช้งานจริงมาสิบปีมักมีลูกค้าคนเดียวกันซ้ำสามรายการ มีช่องที่ถูกเอาไปใช้ผิดวัตถุประสงค์เพราะไม่มีที่ให้กรอก และมีไฟล์แนบที่ลิงก์เสียไปแล้ว งานส่วนนี้ต้องมีคนจากฝั่งธุรกิจมานั่งตัดสินด้วย ไม่ใช่งานที่ทีมพัฒนาตัดสินเองได้
ห้าข้อนี้ทำให้การประเมินแม่นขึ้นมาก และมักทำให้เห็นเองว่าควรเลือกทางไหน ก่อนที่จะมีใครเสนอราคาด้วยซ้ำ
เล่าโจทย์มาคร่าว ๆ ได้เลย เราตีกรอบงบและระยะเวลาให้ฟรีตั้งแต่คุยครั้งแรก
ระบบองค์กรตอบแชท LINE OA ด้วยมือเริ่มไม่ไหวเมื่อมีเจ้าหน้าที่หลายแผนกและลูกค้าทั่วประเทศ เล่างานจริงที่เชื่อม LINE OA กับระบบหลังบ้าน ส่งเรื่องให้ถูกคนตามแผนกและพื้นที่
ระบบองค์กรเกณฑ์ตัดสินใจระหว่าง ERP สำเร็จรูปกับระบบที่พัฒนาเอง ต้นทุนที่คนมักลืมคิดทั้งสองทาง และทางเลือกที่สามที่โรงงานส่วนใหญ่เหมาะกว่าการเลือกสุดทางใดทางหนึ่ง
AI และข้อมูลChatbot ที่ตอบจากเอกสารของบริษัทใช้เทคนิคที่เรียกว่า RAG บทความนี้อธิบายว่ามันทำงานยังไง พลาดตรงไหนบ้าง โดยเฉพาะกับเอกสารภาษาไทย และวัดยังไงว่าตอบถูกจริง
