กรณีศึกษา เก็บความต้องการระบบจัดการร้านมือถือ จากคำขอถึงขอบเขตงาน
บทความนี้เล่ากระบวนการทำงานช่วงต้นที่ลูกค้ามักไม่เห็น คือขั้นตอนแปลงสิ่งที่ลูกค้าเขียนมา ให้กลายเป็นขอบเขตงานที่ประเมินราคาและลงมือทำได้
ขั้นตอนนี้สำคัญที่สุด เพราะงานที่บานปลายเกือบทั้งหมดเกิดจากการข้ามขั้นนี้ไป
สิ่งที่ได้รับตอนแรก
ลูกค้าร้านขายและซ่อมโทรศัพท์ส่งความต้องการมาเป็นข้อความยาวหลายย่อหน้า ใจความประมาณว่า
อยากได้ระบบจัดการหน้าร้าน เก็บสต๊อกสินค้า มีระบบผ่อน เงินดาวน์ ดูรายงานยอดขายได้ มีระบบซ่อมด้วย พนักงานอัปเดตสถานะได้ เจ้าของดูยอดรวมได้
ข้อความแบบนี้ชัดเจนพอสำหรับคุยกัน แต่ยังประเมินราคาไม่ได้ เพราะแต่ละคำมีขอบเขตกว้างมาก คำว่า "ระบบผ่อน" อาจหมายถึงแค่บันทึกยอด หรืออาจหมายถึงคำนวณดอกเบี้ยและแจ้งเตือนอัตโนมัติ ซึ่งต่างกันหลายเท่า
ขั้นที่ 1 แยกออกเป็นระบบย่อย
เริ่มจากแตกข้อความยาวออกเป็นกลุ่มงานที่ชัดเจน
- จัดการสินค้าและสต๊อก
- ขายและรับชำระเงิน
- ผ่อนชำระและติดตามยอดค้าง
- งานซ่อม
- รายงานสำหรับเจ้าของ
- ผู้ใช้และสิทธิ์การเข้าถึง
การแตกแบบนี้ทำให้เห็นทันทีว่างานไม่ใช่ก้อนเดียว แต่เป็นหกระบบที่ทำงานร่วมกัน และบางระบบทำทีหลังได้
ขั้นที่ 2 ถามคำถามที่ยังไม่มีคำตอบ
คำถามที่ต้องได้คำตอบก่อนเสนอราคา
| เรื่อง | คำถามที่ต้องถาม |
|---|---|
| สต๊อก | ต้องเก็บ IMEI รายเครื่องไหม มีสินค้ามือสองด้วยหรือเปล่า |
| ผ่อนชำระ | คิดดอกเบี้ยอย่างไร มีค่าปรับเมื่อจ่ายช้าไหม |
| งานซ่อม | ต้องตัดสต๊อกอะไหล่ด้วยไหม |
| ผู้ใช้ | มีกี่คน แต่ละคนควรเห็นอะไรบ้าง |
| สาขา | มีสาขาเดียวหรือหลายสาขา |
คำถามเรื่องสาขาเป็นตัวอย่างที่ดีของคำถามที่ต้องถามตั้งแต่ต้น เพราะถ้าอนาคตจะมีหลายสาขา โครงสร้างข้อมูลต้องออกแบบต่างไปตั้งแต่วันแรก การมาเพิ่มทีหลังหมายถึงการรื้อเกือบทั้งระบบ
ขั้นที่ 3 แยกสิ่งที่ต้องมีออกจากสิ่งที่อยากมี
ขั้นนี้ทำร่วมกับลูกค้า ไม่ใช่ตัดสินใจเอง
| ระยะแรก ต้องมี | ระยะถัดไป อยากมี |
|---|---|
| บันทึกสินค้าและ IMEI | สแกนบาร์โค้ด |
| ขายและออกใบเสร็จ | เชื่อมระบบบัญชี |
| บันทึกผ่อนและติดตามยอดค้าง | แจ้งเตือนอัตโนมัติทางไลน์ |
| รับงานซ่อมและอัปเดตสถานะ | ลูกค้าเช็คสถานะเองผ่านเว็บ |
| รายงานยอดขายรายวัน | กราฟวิเคราะห์แนวโน้ม |
ประโยชน์ของการแยกแบบนี้คือ ลูกค้าได้ระบบที่ใช้งานได้จริงเร็วขึ้น และได้ทดลองใช้ก่อนตัดสินใจว่าส่วนที่เหลือจำเป็นจริงไหม
ในทางปฏิบัติ ฟีเจอร์ในคอลัมน์ขวาหลายอย่างมักถูกยกเลิกไปเองหลังใช้ระบบจริงสักพัก เพราะพบว่าไม่ได้จำเป็นอย่างที่คิดตอนแรก
บทเรียนจากงานนี้
- ความต้องการที่ลูกค้าเขียนมา คือจุดเริ่มต้น ไม่ใช่ข้อสรุป หน้าที่ของผู้รับงานคือถามต่อจนเห็นภาพตรงกัน
- คำถามที่ดีมีมูลค่ามากกว่าการรีบเสนอราคา ราคาที่เสนอโดยยังไม่เข้าใจงาน มักจบด้วยการขาดทุนหรือทะเลาะกัน
- การแบ่งเป็นระยะช่วยทั้งสองฝ่าย ลูกค้าจ่ายน้อยลงตอนเริ่ม ผู้รับงานส่งมอบได้เร็วขึ้นและได้ผลตอบรับจริงมาปรับ
สรุป
ถ้าคุณกำลังจะจ้างทำระบบ สิ่งที่ควรสังเกตคือผู้รับงานถามคำถามมากแค่ไหนก่อนเสนอราคา
คนที่เสนอราคาได้ทันทีโดยไม่ถามอะไรเลย ไม่ได้แปลว่าเก่ง แต่มักแปลว่ายังไม่รู้ว่างานจริงมีอะไรบ้าง