ขั้นตอนการเก็บ Requirement ที่ดี

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

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

เนื้อหานี่เหมาะสำหรับ ตำแหน่ง Business Analytic นะ ถ้า Project เป็น BA ด้วยก็ ต้องมาพิจารณาเรื่อง ขั้นตอนการเก็บ Requirement ด้วยเช่นกันครับ

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

หรือ จะเป็นแบบนี้
หมอ : อาการเป็นยังไงครับ
ผู้ป่วย : เจ็บคอ
หมอ : อ่าปากให้หมอดู คอหน่อยครับ
หมอ : คอแดงนะ แล้ว กินยาแบบไหนดีครับ แบบ A หรือ B

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

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

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

การเก็บข้อมูลต้องชัดเจน ชัดเจนยังไง คือ สามารถระบุออกมาได้เป็น ข้อ ๆ เช่น Stock ต้องมีการจัดการเรื่อง อะไรบ้างครับ เออ ก็มี รับของ จ่ายของ ประมาณนี้

นี่แหละครับ ความชิบหายมาเยื่อน ถ้าคนเก็น Requirement เขียนได้แค่นี้ การปิดประเด็นนี้จะให้มีแค่นี้ก็ได้ หรือ รับของ จ่ายของ แต่ ขอให้คนเก็บ Requirement ระบุเพิ่มเติมว่า

งั้นผมระบุในเอกสารว่า มี 2 ข้อ คือ รับ กับ จ่าย นะครับ ช่วยเซ็นต์ รับรองให้ด้วย

อาการที่เกิดขึ้นคือ ไม่กล้าเซ็นต์ ครับ คือการระบุหัวข้อให้นับได้ กับ การเซ็นต์ เป็นอะไรที่ user กลัวมาก ดังนั้นจะไม่กล้าเซ็นต์ รวมถึงขอกลับไปคิดก่อน

ดังนั้นการจะได้มาซึ่งข้อมูลที่มีคุณภาพ เราต้องระบุจำนวน และ มีการรับรองเป็นลายเซ็นต์

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

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

ดังนั้น ขอยำว่า Requirement ต้องถูกประเมินมาแล้ว ไม่ใช่มาคิดในที่ประชุม ที่ประชุมเป็นสถานที่ที่จะสรุป สิ่งที่คิด ไม่ใช่มานั่งคิด

คนเขียน Code เก่ง อาจจะเป็นคนเก็บข้อมูลที่เก็บไม่ได้

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

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