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