ระบบเดิมไม่มีคนดูแลแล้ว ทำอย่างไรดี — วิธีรับช่วงต่อระบบที่คนอื่นทำไว้โดยไม่ต้องเริ่มใหม่ทั้งหมด

ผู้พัฒนาเดิมหายไป ระบบยังใช้ได้แต่แก้อะไรไม่ได้ และไม่มีใครกล้าแตะ เป็นสถานการณ์ที่ธุรกิจเจอบ่อยกว่าที่คิด บทความนี้อธิบายวิธีประเมินว่าระบบเดิมควรรับช่วงต่อหรือเขียนใหม่ สิ่งที่ต้องรวบรวมก่อนหาทีมใหม่ และวิธีส่งมอบที่ทำให้ไม่ต้องเจอปัญหาเดิมอีก
สถานการณ์นี้เกิดกับธุรกิจไทยบ่อยกว่าที่ใครคิด ระบบที่จ้างทำไว้เมื่อสามปีก่อนยังทำงานอยู่และธุรกิจก็พึ่งมันทุกวัน แต่คนที่เขียนมันไม่อยู่แล้ว อาจเป็นฟรีแลนซ์ที่เปลี่ยนอาชีพ บริษัทที่ปิดกิจการ หรือทีมที่ยังอยู่แต่ไม่รับงานเล็กแล้ว ผลคือระบบกลายเป็นกล่องดำที่ทุกคนกลัวจะแตะ อยากเพิ่มรายงานสักใบก็ทำไม่ได้ ผู้ใช้เพิ่มคนใหม่ก็ติดขัด และทุกคนในบริษัทได้แต่ภาวนาว่าอย่าให้มันพัง เจ้าของธุรกิจที่เจอสถานการณ์นี้มักคิดว่ามีทางเลือกเดียวคือทิ้งแล้วเริ่มใหม่ ซึ่งเจ็บทั้งงบและเวลา แต่ความจริงคือระบบเดิมส่วนใหญ่รับช่วงต่อได้ และบ่อยครั้งคุ้มกว่าการเขียนใหม่มาก เพราะระบบที่ใช้งานจริงมาหลายปีมีสิ่งหนึ่งที่ระบบใหม่ไม่มี คือความรู้เรื่องธุรกิจของคุณที่ถูกฝังอยู่ในนั้นทีละนิดจากการแก้ปัญหาจริงนับร้อยครั้ง สิ่งที่ต้องทำก่อนตัดสินใจคือประเมินอย่างมีหลักการ ไม่ใช่ตัดสินจากความกลัว
ประเมินก่อน — รับช่วงต่อหรือเขียนใหม่
การประเมินที่ดีใช้เวลาไม่กี่วันและตอบคำถามสี่ข้อ ข้อแรก ซอร์สโค้ดอยู่ในมือคุณหรือเปล่า ถ้ามีโค้ดครบและมีสิทธิ์เข้าถึงเซิร์ฟเวอร์และฐานข้อมูล การรับช่วงต่อเป็นไปได้เสมอ ถ้าไม่มีโค้ดเลย ทางเลือกจะแคบลงมากและอาจต้องพิจารณาการสร้างใหม่โดยย้ายข้อมูลออกมา ข้อสอง เทคโนโลยีที่ใช้ยังมีคนดูแลได้ไหม ระบบที่เขียนด้วยเทคโนโลยีที่ยังใช้กันแพร่หลายหาทีมรับช่วงได้ไม่ยาก ส่วนระบบที่ใช้ของเก่ามากหรือของเฉพาะทางผิดปกติ ต้นทุนการหาคนดูแลจะสูงขึ้นตามและควรนำมาคิดในสมการ ข้อสาม คุณภาพข้างในเป็นอย่างไร ทีมที่รับประเมินจะดูโครงสร้างโค้ด ความปลอดภัยพื้นฐาน และสภาพฐานข้อมูล เพื่อบอกได้ว่าการแก้เพิ่มในอนาคตจะยากแค่ไหน และข้อสี่ที่สำคัญที่สุด ระบบนี้ยังตอบโจทย์ธุรกิจวันนี้อยู่ไหม บางครั้งคำตอบที่ถูกคือเขียนใหม่ ไม่ใช่เพราะโค้ดแย่ แต่เพราะธุรกิจเปลี่ยนไปมากจนสิ่งที่ต้องการต่างจากเดิมโดยสิ้นเชิง ทีมที่ซื่อสัตย์จะบอกคุณตรง ๆ ว่ากรณีของคุณควรไปทางไหน และการประเมินที่ดีจะให้ตัวเลขทั้งสองทางให้คุณเทียบ ไม่ใช่ผลักไปทางที่ผู้ให้บริการได้งานใหญ่กว่า
ใช่ →
ใช้ระบบสำเร็จรูป (SaaS)
เร็ว ถูกกว่า เริ่มได้เลย
ไม่ → ต้องยืดหยุ่นสูงไหม?
มาก → พัฒนาเฉพาะ (Custom)
ปานกลาง → ปรับแต่งระบบ (Hybrid)
รวบรวมของให้ครบก่อนไปคุยกับทีมใหม่
ยิ่งคุณถือของครบเท่าไหร่ การรับช่วงต่อยิ่งเร็วและถูกลงเท่านั้น สิ่งที่ควรรวบรวมให้ได้มากที่สุดมีดังนี้ ซอร์สโค้ดทั้งหมดรวมถึงประวัติการแก้ไขถ้ามี ข้อมูลการเข้าถึงเซิร์ฟเวอร์ ฐานข้อมูล โดเมน และบริการภายนอกที่ระบบเรียกใช้ เอกสารใด ๆ ที่เคยได้รับตอนส่งมอบแม้จะเก่าแล้วก็ตาม รายชื่อและช่องทางติดต่อของผู้พัฒนาเดิมเผื่อสอบถามได้แม้เขาไม่รับงานต่อ และที่สำคัญที่สุดซึ่งมักถูกลืม คือความรู้ที่อยู่ในหัวพนักงานของคุณเอง คนที่ใช้ระบบทุกวันรู้ดีที่สุดว่าปุ่มไหนใช้ทำอะไร ขั้นตอนไหนต้องทำก่อนหลัง และมีจุดไหนที่ต้องทำแบบแปลก ๆ เพราะระบบเป็นอย่างนั้น ให้จดสิ่งเหล่านี้ไว้เป็นเอกสารก่อนที่พนักงานคนนั้นจะลาออก เพราะมันคือคู่มือที่ดีที่สุดที่ทีมใหม่จะได้ ถ้าคุณไม่มีสิทธิ์เข้าถึงบางส่วนเลย เช่น โดเมนที่จดในชื่อผู้พัฒนาเดิม ให้เริ่มติดต่อขอโอนตั้งแต่วันนี้ เพราะกระบวนการเหล่านี้ใช้เวลาและจะกลายเป็นคอขวดตอนที่คุณรีบที่สุด บทเรียนที่ควรจดจำจากประสบการณ์นี้คือ ทรัพย์สินดิจิทัลของธุรกิจต้องอยู่ในชื่อธุรกิจเสมอ ไม่ว่าจะทำงานกับใครก็ตาม
การรับช่วงที่ดีทำอย่างไร — และป้องกันไม่ให้เกิดซ้ำ
ทีมที่รับช่วงต่ออย่างมืออาชีพจะไม่รีบแก้อะไรในสัปดาห์แรก แต่จะเริ่มจากทำให้ระบบปลอดภัยก่อน ตั้งการสำรองข้อมูลที่ทดสอบกู้คืนได้จริง เปลี่ยนรหัสผ่านและสิทธิ์เข้าถึงทั้งหมดให้อยู่ในการควบคุมของคุณ และสร้างสภาพแวดล้อมทดสอบแยกจากระบบที่ใช้งานจริง เพื่อให้ทดลองแก้ได้โดยไม่กระทบธุรกิจ จากนั้นจึงเริ่มทำความเข้าใจโค้ดและเขียนเอกสารสิ่งที่ค้นพบไว้ ซึ่งเป็นการลงทุนที่คืนทุนทุกครั้งที่มีการแก้ไขในอนาคต งานแก้ไขจริงควรเริ่มจากของเล็กที่ความเสี่ยงต่ำ เพื่อสร้างความมั่นใจทั้งสองฝ่ายก่อนแตะส่วนที่สำคัญ และตลอดกระบวนการ ทีมควรอธิบายให้คุณเข้าใจได้ว่าระบบทำงานอย่างไรในภาษาที่คุณฟังรู้เรื่อง เพราะเป้าหมายไม่ใช่แค่ทำให้ระบบแก้ได้อีกครั้ง แต่คือทำให้ธุรกิจของคุณไม่ตกอยู่ในสถานะกล่องดำอีก สิ่งที่ควรทำไว้ตั้งแต่วันนี้เพื่อไม่ให้เจอเรื่องเดิมซ้ำ คือกำหนดให้ทุกสัญญาพัฒนาระบบระบุความเป็นเจ้าของโค้ดและข้อมูลไว้ชัดเจน เก็บสำเนาโค้ดและข้อมูลไว้ในที่ที่ธุรกิจควบคุมเอง จัดให้มีเอกสารพื้นฐานที่อัปเดตตามการแก้ไข และมีการดูแลต่อเนื่องที่ทำให้มีคนคุ้นเคยกับระบบอยู่เสมอ ค่าดูแลรายเดือนที่ดูเหมือนรายจ่ายเพิ่ม แท้จริงคือเบี้ยประกันที่ป้องกันไม่ให้คุณต้องอ่านบทความนี้อีกรอบในอีกสามปี
ผู้ใช้ / พนักงาน
ขอสิทธิ์ · อนุมัติ · บันทึก
ระบบและข้อมูลสำคัญ
ให้สิทธิ์เท่าที่จำเป็น และตรวจสอบย้อนหลังได้เสมอ — โดยเฉพาะเมื่อพนักงานลาออก
- ระบบเดิมส่วนใหญ่รับช่วงต่อได้ และมักคุ้มกว่าเขียนใหม่ — ประเมินก่อนตัดสินจากความกลัว
- รวบรวมโค้ด สิทธิ์ และความรู้ในหัวพนักงานให้ครบก่อนไปคุยกับทีมใหม่
- ทีมที่ดีทำให้ระบบปลอดภัยก่อนแก้ — สำรองข้อมูล คืนสิทธิ์ และสร้างที่ทดสอบแยก
Whale Task รับประเมินและดูแลต่อระบบที่ทีมอื่นพัฒนาไว้ให้ธุรกิจในเชียงใหม่และภาคเหนือเป็นประจำ เราเริ่มจากการประเมินอย่างตรงไปตรงมาว่าควรรับช่วงต่อหรือเขียนใหม่ พร้อมตัวเลขทั้งสองทางให้คุณตัดสินใจเอง ด้วยประสบการณ์กว่า 10 ปีข้ามหลายอุตสาหกรรม ถ้าธุรกิจของคุณมีระบบที่ยังใช้อยู่แต่ไม่มีใครดูแลแล้ว ปรึกษาเราได้ฟรี เราจะช่วยดูให้ว่าสถานการณ์จริงเป็นอย่างไรและทางไหนคุ้มที่สุดสำหรับคุณ
บริการที่เกี่ยวข้อง
รับพัฒนาระบบและซอฟต์แวร์เฉพาะทาง
ออกแบบและวางระบบตามความต้องการเฉพาะของธุรกิจคุณ ตั้งแต่ต้นจนใช้งานจริง
WhaleScope
ดูโครงสร้างตลาดของทุกหมวดธุรกิจไทย บน WhaleScope
รายชื่อบริษัท ผู้เล่นรายใหญ่ และอัตราคงอยู่ของแต่ละหมวด — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล
อ่านต่อ

Strangler Fig: ย้ายระบบเก่าทีละส่วน โดยไม่ต้องหยุดธุรกิจ
การเขียนระบบใหม่ทั้งก้อนแล้วสลับวันเดียว คือความเสี่ยงที่หลายองค์กรเจ็บมาแล้ว Strangler Fig คือกลยุทธ์ค่อย ๆ แทนที่ระบบเก่าทีละส่วน ให้ของใหม่โตคลุมของเก่าจนถอดออกได้

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

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

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