บทความ 03

ประเมินขนาดโครงการระบบ: ทำไมจำนวนหน้าจอไม่ใช่คำตอบทั้งหมด

เข้าใจปัจจัยที่ทำให้ scope, เวลา และงบประมาณเปลี่ยน ตั้งแต่ workflow, role, integration, data migration จนถึงความพร้อมหลัง Go-live

11 นาที Project Owner, ผู้บริหาร และ Tech Lead 2026-07-17

Infographic ภาพรวม

สิ่งที่เห็น

Screens

สิ่งที่ต้องออกแบบ

Roles & rules

Integration

Data migration

Security & QA

Deploy & support

สถานการณ์ตัวอย่าง

ลองเริ่มจากเหตุการณ์ที่คนทำงานพบจริง

“มีแค่สิบหน้าจอ” แต่ทำไมประเมินงานไม่ได้ทันที

หน้าจออนุมัติหนึ่งหน้าอาจมีหลาย role, หลายสถานะ, การแจ้งเตือน, เอกสารแนบ, ประวัติแก้ไข และการเชื่อม ERP ความซับซ้อนอยู่ที่กติกาและข้อมูลเบื้องหลัง ไม่ได้อยู่ที่พื้นที่บนหน้าจอ

ถ้าคุณไม่ได้ทำงานสายเทคนิค ให้เริ่มจากส่วนนี้

ประเมินขนาดโครงการระบบ: ทำไมจำนวนหน้าจอไม่ใช่คำตอบทั้งหมด

ประเมินเป็น business flow ไม่ใช่รายการหน้าจอ

Integration, migration และ permission มักเปลี่ยนขนาดงานมาก

เริ่มด้วย discovery และ phase แรกที่มีขอบเขตปิดได้

ภาพขยายความแบบเคลื่อนไหว

ดูความสัมพันธ์ของแต่ละขั้น ก่อนลงรายละเอียด

เลือกแต่ละขั้นเพื่อดูว่าเกิดอะไรขึ้น ต้องตรวจข้อมูลใด และผลจากขั้นหนึ่งส่งต่อไปยังขั้นถัดไปอย่างไร

ขั้น 01 / 03

01 / ตัวขับความซับซ้อน

สิ่งที่มองไม่เห็นมักใช้เวลามากกว่าสิ่งที่เห็น

ระบบหนึ่งต้องออกแบบข้อมูล กติกา สิทธิ์ การตรวจความถูกต้อง error handling test case deployment และการดูแลหลังเปิดใช้ หน้าจอที่คล้ายกันอาจมี effort ต่างกันหลายเท่าเมื่อเงื่อนไขเหล่านี้ต่างกัน

ประเด็นที่ต้องตรวจให้เห็นหลักฐาน

จำนวน role และ permission
จำนวนสถานะและ exception
ระบบภายนอกที่ต้องเชื่อม
ข้อมูลเดิมที่ต้องย้าย

รายละเอียดเชิงลึก

ค่อย ๆ ดูทีละส่วนว่าเกิดอะไรขึ้น และควรเตรียมอย่างไร

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

01 / ตัวขับความซับซ้อน

สิ่งที่มองไม่เห็นมักใช้เวลามากกว่าสิ่งที่เห็น

จำนวน role และ permission
จำนวนสถานะและ exception
ระบบภายนอกที่ต้องเชื่อม
ข้อมูลเดิมที่ต้องย้าย
ระดับ security, availability และ support

02 / ประเมินอย่างมีช่วง

ช่วงงบประมาณที่มีสมมติฐาน ดีกว่าตัวเลขเดียวที่ดูแม่น

ช่วงต้นควรแสดงสิ่งที่รวม สิ่งที่ยังไม่รวม ความเสี่ยง และข้อมูลที่ทำให้ช่วงแคบลง ตัวเลขเดียวก่อนเห็น workflow และ integration มักซ่อนความไม่แน่นอนไว้ และนำไปสู่การตัด scope หรือเพิ่มงบภายหลัง

ตัวอย่างแบ่ง phase

เริ่มจาก Workflow อนุมัติ 1 ชุด

Phase 1: role, form, approval, notification และ report หลัก จากนั้นเก็บ integration ขั้นซับซ้อนและ analytics ไว้ Phase 2 เมื่อ flow แรกผ่านการใช้งานจริง

03 / ขอบเขตที่ปิดได้

Scope ที่ดีต้องบอกได้ว่าเมื่อไรเรียกว่าเสร็จ

แต่ละ flow ควรมีผู้ใช้ จุดเริ่ม จุดจบ ข้อมูลเข้า ผลลัพธ์ กรณีผิดพลาด และ acceptance criteria ที่ตกลงร่วมกัน รวมถึงระบุว่าใครเตรียมข้อมูล ใครอนุมัติ และใครรับผิดชอบหลัง Go-live

ถ้าคุณเป็นคนออกแบบหรือดูแลระบบ

Tech Lead ควรแยก functional scope ออกจาก non-functional requirements เช่น latency, availability, security, audit, backup และ observability

ก่อนนำไปใช้ ลองตรวจทีละข้อนี้

ระบุ flow หลัก

ระบุ role และ owner

ลิสต์ integration

ตรวจข้อมูลที่ต้องย้าย

กำหนด non-functional requirements

เขียน acceptance criteria

แหล่งอ้างอิง

AWS Well-Architected Framework: The Pillars

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

ผู้ตรวจทาน: SIS Product & Engineering
ตรวจทานล่าสุด: 2026-07-17

อ่านแล้วอยากรู้ว่าระบบของคุณควรเริ่มตรวจตรงไหน?

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

ทดลองประเมินด้วยเครื่องมือ คุยกับทีม SIS

กลับไป Knowledge Base