หากยังตอบคำถามต่อไปนี้ไม่ได้ ควรเริ่มจากการสำรวจและสรุปความต้องการก่อนเสนอราคาส่งมอบทั้งโครงการ แต่ละคำถามมีมุมที่ต้องดู 3 อย่าง คือทำไมถึงสำคัญ คำตอบที่พร้อมจริงหน้าตาเป็นอย่างไร และสัญญาณอันตรายที่พบบ่อยเมื่อยังตอบไม่ได้
1. ใครเป็นเจ้าของเนื้อหาและใครมีสิทธิ์ publish?
เพราะถ้าไม่รู้ว่าใครอนุมัติเนื้อหาได้จริง งานตรวจรับจะยืดออกไปเรื่อย ๆ ทุกครั้งที่ต้องรอคนเซ็นชื่อ
คำตอบที่พร้อม: รายชื่อบทบาทตั้งแต่ผู้เขียน ผู้ตรวจ ไปจนถึงผู้กด publish จริง พร้อมสิทธิ์ในระบบ CMS ที่ตรงกับบทบาทนั้น และมีขั้นตอนอนุมัติที่เขียนไว้เป็นลายลักษณ์อักษร ไม่ใช่แค่ปากเปล่าในที่ประชุม
สัญญาณอันตราย: คำตอบที่มาในรูป “เดี๋ยวถามในทีมดูก่อน” หรือมีคนหลายคนอ้างว่าตัวเองอนุมัติได้ เป็นสัญญาณว่ายังไม่มีเจ้าของเนื้อหาตัวจริง และงานจะเจอปัญหาสิทธิ์การเข้าถึงตอนใกล้ส่งมอบ
2. Content type และภาษามีกี่แบบ?
จำนวน content type และภาษาส่งผลตรงต่อโครงสร้างข้อมูลใน CMS และปริมาณงานแปล ยิ่งประเมินผิดตั้งแต่ต้น ยิ่งต้องปรับโครงสร้างทีหลังซึ่งมีต้นทุนสูง
คำตอบที่พร้อม: มีรายการ content type ที่ใช้งานจริงพร้อมฟิลด์คร่าว ๆ ของแต่ละแบบ และระบุชัดว่าภาษาไหนคือภาษาหลัก ภาษาไหนแปลบางส่วน และภาษาไหนแปลเต็มทั้งหน้า
สัญญาณอันตราย: ถ้าคำตอบคือ “น่าจะไม่กี่แบบ” หรือแต่ละแผนกให้จำนวนไม่ตรงกัน ควรถือว่ายังไม่มีการสำรวจจริง และเสี่ยงที่โครงสร้าง CMS จะไม่พอใช้เมื่อเนื้อหาจริงเริ่มเข้าระบบ
3. ข้อมูลใดมาจาก CMS และข้อมูลใดมาจากระบบอื่น?
หน้าเว็บองค์กรมักผสมเนื้อหาที่แก้ไขเองกับข้อมูลที่ดึงจากระบบอื่น เช่น ราคาหรือสถานะจากระบบหลังบ้าน ถ้าไม่แยกให้ชัด งานจะกลายเป็นงานเชื่อมต่อระบบที่ซ่อนอยู่ในงานเว็บไซต์
คำตอบที่พร้อม: มีแผนผังง่าย ๆ ที่บอกว่าข้อมูลแต่ละก้อนมาจากไหน ใครเป็นเจ้าของระบบต้นทาง และข้อมูลไหนแก้ไขในหน้าเว็บได้ตรง ๆ
สัญญาณอันตราย: คำตอบที่บอกแค่ “เดี๋ยวดึงจากระบบหลังบ้าน” โดยไม่รู้ว่าระบบหลังบ้านคือระบบไหนหรือใครดูแล คือสัญญาณว่าขอบเขตงานจริงยังไม่ถูกประเมิน
4. API มี documentation, sandbox และ owner หรือยัง?
การเชื่อมต่อ API ที่ไม่มีเอกสารหรือ sandbox ทดสอบ ทำให้ประเมินเวลาพัฒนาได้ไม่แม่นยำ และมักเจอปัญหาหลัง go-live มากกว่าช่วงพัฒนาเสียอีก
คำตอบที่พร้อม: มีเอกสาร endpoint ที่อัปเดตล่าสุด มี sandbox หรือ environment ทดสอบที่เข้าถึงได้จริง และมีคนรับผิดชอบตอบคำถามเชิงเทคนิคเมื่อเจอ error ที่ไม่คาดคิด
สัญญาณอันตราย: ถ้า API มีแต่เอกสารเก่าที่ไม่มีใครรับรองว่ายังตรงกับของจริง หรือไม่มี sandbox ให้ทดสอบก่อนเชื่อมต่อจริง ควรตั้งงบเวลาสำรองไว้ล่วงหน้า เพราะความเสี่ยงจะโผล่มาตอนใกล้ deadline
5. ต้อง migrate ข้อมูลเดิมเท่าไรและคุณภาพข้อมูลเป็นอย่างไร?
การย้ายข้อมูลเดิมมักถูกมองข้ามตอนประเมินราคา ทั้งที่ใช้เวลาตรวจสอบและทำความสะอาดข้อมูลมากกว่าที่คาดไว้เสมอ
คำตอบที่พร้อม: มีตัวอย่างข้อมูลจริงให้ดูก่อนเริ่มงาน รู้ปริมาณคร่าว ๆ ของสิ่งที่ต้องย้าย และรู้ว่าข้อมูลส่วนไหนต้องแปลงรูปแบบก่อนนำเข้า CMS ใหม่
สัญญาณอันตราย: ถ้าคำตอบคือ “ข้อมูลไม่เยอะ” โดยไม่มีใครเปิดไฟล์จริงมาดู หรือไม่มีใครรู้ว่าข้อมูลเก่าซ้ำซ้อนแค่ไหน ควรกันเวลาสำรวจข้อมูลไว้ก่อนเริ่มพัฒนา ไม่ใช่ระหว่างพัฒนา
6. มีข้อกำหนด identity, audit, PDPA และ retention อะไรบ้าง?
เว็บไซต์องค์กรที่เชื่อมระบบเดิมมักพ่วงมากับข้อมูลผู้ใช้และสิทธิ์การเข้าถึง ถ้าไม่ชัดเจนตั้งแต่ต้น ความเสี่ยงจะกลายเป็นเรื่องกฎหมายและความปลอดภัย ไม่ใช่แค่เรื่องฟีเจอร์
คำตอบที่พร้อม: มีข้อกำหนดเป็นลายลักษณ์อักษรว่าใครยืนยันตัวตนได้บ้าง ต้องเก็บ log อะไรไว้ตรวจสอบย้อนหลัง และข้อมูลส่วนบุคคลต้องเก็บนานเท่าไรก่อนต้องลบตามนโยบาย
สัญญาณอันตราย: ถ้าไม่มีใครตอบคำถามเรื่อง PDPA ได้ชัดเจน หรือส่งต่อให้ทีมกฎหมายไปเรื่อย ๆ โดยไม่มีกำหนดเวลา ควรหยุดพัฒนาฟีเจอร์ที่เกี่ยวกับข้อมูลส่วนบุคคลไว้ก่อนจนกว่าจะได้คำตอบ
7. ใครดูแลระบบหลัง go-live และต้องส่งมอบอะไรให้เขา?
งานพัฒนาเว็บไซต์จบที่ go-live แต่ระบบต้องมีคนดูแลต่อ ถ้าไม่รู้ล่วงหน้าว่าใครรับช่วงต่อ เอกสารส่งมอบมักถูกเขียนแบบเร่งรีบตอนท้ายโครงการ
คำตอบที่พร้อม: รู้ตัวบุคคลหรือทีมที่จะดูแลระบบหลังส่งมอบ และมีรายการเอกสาร บัญชีผู้ดูแล และขั้นตอนตรวจสอบเบื้องต้นที่ต้องส่งมอบให้ตรงกับสิ่งที่ทีมนั้นใช้งานจริง
สัญญาณอันตราย: ถ้ายังไม่มีคำตอบว่าใครดูแลต่อ หรือคำตอบเปลี่ยนไปทุกครั้งที่ถาม ควรระบุในสัญญาว่าการส่งมอบเอกสารจะทำอย่างไร เพื่อป้องกันช่วงเปลี่ยนผ่านที่ไม่มีใครรับผิดชอบ