สมมติว่าวันแรกของ kick-off ลูกค้าส่งเอกสารความต้องการมา 80 ข้อ หัวข้อแรกเขียนว่า "อยากได้ระบบแบบเดิม แต่ดีกว่าเดิม" ทุกคนในห้องพยักหน้า ทีมพัฒนาจดทุกข้อ แล้วกลับไปเขียนโปรแกรม
สามเดือนต่อมา วันส่งมอบงาน ผู้ใช้หน้างานบอกว่า "ไม่ใช่แบบนี้"
ไม่มีใครโกหก ไม่มีใครทำงานไม่ดี ปัญหาอยู่ที่ requirement ตั้งแต่วันแรก ซึ่งเป็นเรื่องที่เกิดบ่อยกว่าที่คิด รายงาน Pulse of the Profession ของ PMI ปี 2557 พบว่า 47% ของโครงการที่ไม่บรรลุเป้า มีต้นเหตุจากการจัดการ requirement ที่ไม่ดี
ทำไม Software House ถึงมองเรื่องนี้ต่างออกไป
Enersys เริ่มต้นเป็น Software House ตั้งแต่ปี 2555 งานของเราคือสร้างซอฟต์แวร์จากโจทย์ของลูกค้า ไม่ใช่ติดตั้งโปรแกรมสำเร็จรูปแล้วจบ ทุกโครงการในช่วง 14 ปีสอนเราเรื่องเดียวกัน คือ requirement ที่ดีไม่ได้วัดจากความยาวของเอกสาร แต่วัดจากว่าทดสอบได้หรือไม่
ถ้าเขียนว่า "ระบบต้องใช้งานง่าย" ไม่มีใครตรวจรับได้ ถ้าเขียนว่า "พนักงานคลังเห็นยอดคงเหลือแยกตามคลังได้ในหน้าเดียว และตัวเลขตรงกับการตรวจนับสิ้นเดือน" ทุกคนรู้ตรงกันว่างานเสร็จเมื่อไหร่
ประสบการณ์นี้คือสิ่งที่เรานำมาใช้ใน kick-off ทุกโครงการ ไม่ว่าจะเป็นการพัฒนาซอฟต์แวร์ตามสั่ง หรือการวางระบบ Odoo
เริ่มจากงานที่ธุรกิจหยุดไม่ได้
รายการความต้องการ 80 ข้อมักมีของสำคัญปนกับของที่ "มีก็ดี" เราจึงไม่เริ่มจากรายการ แต่เริ่มจากคำถามว่า งานไหนที่ถ้าหยุดหนึ่งวัน ธุรกิจเสียหาย
สำหรับบางบริษัทคือการรับออเดอร์และส่งของ สำหรับบางบริษัทคือการปิดบัญชีสิ้นเดือน หรือการผลิตตามแผน งานกลุ่มนี้ต้องออกแบบให้ถูกก่อน ส่วนที่เหลือจัดลำดับตามมา
วิธีนี้ทำให้ทั้งสองฝ่ายเห็นตรงกันว่าอะไรต้องเสร็จในรอบแรก และอะไรรอได้
ฟังจากคนที่ทำงานจริง ไม่ใช่แค่ผู้บริหาร
ผู้บริหารรู้ว่าอยากได้ผลลัพธ์อะไร แต่คนที่รู้ว่างานเดินอย่างไรจริงคือคนหน้างาน เอกสารที่ส่งต่อกันหลายมือมักขาดรายละเอียด เช่น ขั้นตอนที่ต้องโทรถามอีกฝ่าย หรือไฟล์ Excel ที่ใช้คู่กับระบบเดิม
ใน kick-off เราจึงให้ที่ปรึกษาธุรกิจและนักวิเคราะห์ระบบของเราคุยกับเจ้าของกระบวนการฝั่งลูกค้าโดยตรง ดูว่างานไหลผ่านใคร ใช้ข้อมูลอะไร และขั้นตอนไหนต้องมีคนตรวจหรืออนุมัติ เจ้าของกระบวนการคือคนเดียวกับที่จะรับรองผลตอนทดสอบ จึงต้องอยู่ตั้งแต่วันแรก
เปลี่ยน "อยากได้" ให้เป็น "ตรวจรับได้"
ทุก requirement ที่ตกลงกัน ต้องมีเกณฑ์ตรวจรับ (acceptance criteria) ที่ทดสอบได้ ก่อนเริ่มพัฒนา
แบบที่ตรวจรับไม่ได้ คือ "ระบบต้องออกรายงานยอดขายได้"
แบบที่ตรวจรับได้ คือ "ผู้จัดการฝ่ายขายเลือกช่วงวันที่และสาขาได้ รายงานแสดงยอดขายแยกตามพนักงาน และยอดรวมตรงกับรายงานบัญชีของเดือนเดียวกัน"
ประโยคที่สองใช้เวลาเขียนนานกว่า แต่ช่วยประหยัดเวลาตอนส่งมอบได้มาก เพราะลูกค้ารู้ตั้งแต่ก่อนเริ่มงานว่าจะได้อะไร และทีมรู้ว่าต้องทำถึงไหน นี่คือที่มาของความมั่นใจก่อนเริ่มงาน
บอกให้ชัดว่าส่วนไหนใช้ของมาตรฐาน ส่วนไหนต้องพัฒนาเพิ่ม
ความคาดหวังที่ไม่ตรงกันเรื่องนี้ทำให้โครงการบานปลายบ่อยที่สุด ใน kick-off เราแยก requirement ทุกข้อออกเป็นสองกลุ่ม คือส่วนที่ใช้ความสามารถมาตรฐานของระบบได้ และส่วนที่ต้องพัฒนาเพิ่ม พร้อมเหตุผลของแต่ละข้อ
บางข้อที่ลูกค้าคิดว่าต้องพัฒนาเพิ่ม จริง ๆ แค่ปรับวิธีทำงานเล็กน้อยก็ใช้ของมาตรฐานได้ ทั้งเร็วกว่าและดูแลระยะยาวง่ายกว่า บางข้อเป็นจุดที่ทำให้ธุรกิจต่างจากคู่แข่ง ข้อแบบนี้ควรพัฒนาเพิ่มอย่างตั้งใจ
ใช้ Agile ยืนยัน requirement ด้วยงานจริงทุกรอบ
ต่อให้ kick-off ดีแค่ไหน เอกสารก็ยังเป็นแค่เอกสาร คนส่วนใหญ่รู้ว่าต้องการอะไรจริง ๆ ก็ตอนได้เห็นหน้าจอและลองกดใช้
เราจึงทำงานแบบ Agile วางแผน ลงมือทำ และประเมินผลเป็นรอบ ลูกค้าเห็นงานจริงตั้งแต่รอบแรก และใช้ผลแต่ละรอบปรับ requirement ของรอบถัดไป ตรงกับหลักใน Agile Manifesto ที่ว่าซอฟต์แวร์ที่ใช้งานได้คือตัววัดความคืบหน้าที่สำคัญที่สุด
Agile ไม่ได้แปลว่าเปลี่ยนอะไรก็ได้ทุกเมื่อ ความต้องการใหม่ที่เกิดระหว่างทางจะถูกบันทึกและจัดลำดับเทียบกับงานเดิม ลูกค้าเป็นคนตัดสินใจว่าจะสลับอะไรเข้าออก ขอบเขตจึงยืดหยุ่นได้โดยไม่บานปลาย
ทดสอบด้วยข้อมูลใกล้งานจริง และให้เจ้าของกระบวนการรับรอง
ก่อนขึ้นระบบจริง เราทดสอบเส้นทางงานที่ข้ามแผนก เช่น จากใบสั่งขายไปถึงการส่งของและการออกใบแจ้งหนี้ ด้วยข้อมูลที่ใกล้งานจริง แล้วให้เจ้าของกระบวนการฝั่งลูกค้าเป็นผู้รับรองผลตามเกณฑ์ตรวจรับที่ตกลงกันไว้ตั้งแต่ kick-off
แนวคิดนี้ตรงกับ Definition of Done ใน Scrum Guide ที่กำหนดว่างานจะนับว่าเสร็จเมื่อผ่านเกณฑ์คุณภาพที่ตกลงกันไว้ ไม่ใช่เมื่อทีมพัฒนาบอกว่าเสร็จ
วงจรจึงปิดครบ คือเกณฑ์ที่เขียนในวันแรก ถูกใช้ตรวจจริงในวันส่งมอบ ความมั่นใจตอนส่งมอบไม่ได้มาจากคำสัญญา แต่มาจากการที่ลูกค้าได้ตรวจด้วยตัวเอง
สัญญาณว่า requirement พร้อมเริ่มงานแล้ว
- ทั้งสองฝ่ายตอบได้ตรงกันว่างานไหนต้องเสร็จในรอบแรก
- เจ้าของกระบวนการของงานหลักทุกงานได้คุยกับทีมแล้ว
- requirement ทุกข้อในรอบแรกมีเกณฑ์ตรวจรับที่ทดสอบได้
- แยกแล้วว่าข้อไหนใช้ของมาตรฐาน ข้อไหนต้องพัฒนาเพิ่ม และเพราะอะไร
- ตกลงวิธีรับความต้องการใหม่ระหว่างทางแล้ว
- รู้แล้วว่าใครเป็นผู้รับรองผลตอนทดสอบ
ถ้ายังตอบไม่ครบ ควรใช้เวลาใน kick-off เพิ่มอีกหน่อย เวลาที่ใช้ตรงนี้ถูกกว่าการแก้งานหลังส่งมอบเสมอ
งานที่ Enersys ทำ
เราใช้วิธีนี้ทั้งในงานพัฒนาซอฟต์แวร์ตามโจทย์ลูกค้า และงานวางระบบ Odoo ERP ทุกโครงการเดินตามขั้นตอนเดียวกัน ตั้งแต่ทบทวนโจทย์ ออกแบบระบบ พัฒนาและส่งมอบเป็นรอบ ทดสอบก่อนขึ้นระบบ ไปจนถึงดูแลและขยายระบบ ลูกค้าจึงรู้ตลอดว่าโครงการอยู่ขั้นไหน ใครรับผิดชอบ และขั้นถัดไปคืออะไร อ่านหลักการวางระบบเพิ่มเติมได้ในบทความ 7 หลักการ implement Odoo ให้สำเร็จ
ถ้าคุณกำลังเริ่มโครงการซอฟต์แวร์หรือ ERP และอยากให้ kick-off ออกมาเป็นแผนที่ทุกฝ่ายตรวจรับได้ คุยกับทีม Enersys ได้
แหล่งข้อมูล
