กำหนดขอบเขตระบบรุ่นแรกให้เล็ก แต่ใช้งานได้จริง

ปัญหาขอบเขตของระบบเฉพาะที่พบบ่อยไม่ใช่แค่ “ทำมากเกินไป” แต่รวมถึง “ทำทุกส่วนอย่างละนิด โดยไม่มีกระบวนการไหนใช้ได้ครบจริง ๆ”

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

รุ่นแรกที่มีประโยชน์กว่าควรรองรับงานหนึ่งส่วนที่มีจุดเริ่มต้นและจุดจบชัดเจน

เริ่มจากปัญหา ไม่ใช่หน้าจอ

แทนที่จะบอกว่า “ต้องมีหน้าจัดการลูกค้า” ให้อธิบายสิ่งที่เกิดขึ้นตอนนี้:

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

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

ขอบเขตที่ใช้ได้จริงมีหกองค์ประกอบ

ใช้ตารางนี้กำหนดรุ่นแรก:

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

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

แยก “ต้องมี” “ไว้ภายหลัง” และ “อยู่นอกระบบ”

จัดแต่ละความต้องการไว้ในกลุ่มใดกลุ่มหนึ่ง:

ต้องมี

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

ไว้ภายหลัง

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

อยู่นอกระบบ

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

การลดขอบเขตไม่ใช่แอบลบสิ่งที่ “ไว้ภายหลัง” แต่ต้องบันทึกว่าทำไมจึงเลื่อน และต้องมีหลักฐานอะไรจึงจะประเมินใหม่

เขียนสถานการณ์ตรวจรับที่ทดสอบได้

ชื่อฟีเจอร์ตรวจรับยากกว่าสถานการณ์จริง ลองใช้รูปแบบ “กำหนดให้–เมื่อ–แล้ว”:

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

เพิ่มกรณีข้อผิดพลาดและสิทธิ์ด้วย:

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

สถานการณ์เหล่านี้ช่วยทั้งการออกแบบ พัฒนา ทดสอบ และตรวจรับทางธุรกิจ

รุ่นแรกต้องมีแผนใช้งานจริงครบด้วย

ซอฟต์แวร์เสร็จไม่ได้แปลว่ากระบวนการเริ่มใช้งานได้แล้ว ขอบเขตควรระบุว่า:

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

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

ยืนยันรุ่นแรกด้วยเอกสารหนึ่งหน้า

เอกสารที่นำไปทำงานได้ไม่ต้องยาว แต่ควรมีอย่างน้อย:

1. ปัญหาธุรกิจหนึ่งเรื่องที่ต้องแก้
2. จุดเริ่มต้นและจุดสิ้นสุด
3. บทบาทและสิทธิ์
4. กฎหลักที่ต้องบังคับใช้
5. สิ่งที่เลื่อนออกไปและไม่รวมในขอบเขต
6. สถานการณ์ตรวจรับสำคัญสามถึงห้ากรณี
7. ผลลัพธ์ที่จะสังเกตหลังเริ่มใช้

ขอบเขตจึงจะชัดจริง เมื่อเจ้าของธุรกิจและทีมดำเนินงานอธิบายทั้งเจ็ดข้อได้ตรงกัน

---

บทความนี้เสนอวิธีกำหนดขอบเขตระบบทั่วไป ขอบเขตจริงต้องพิจารณากระบวนการ ความเสี่ยง และทรัพยากรของธุรกิจ