Requirement Changes เกิดได้ไงหว่า? การเปลี่ยน แปลงที่เกิดขึ้นใน project โดยเฉพาะอย่างยิ่ง Requirement Changes เป็นเรื่องปกติที่ทุกๆคนคงจะเคยเจอกัน ซึ่งสาเหตุของ Requirement Changes นั้นก็มีอยู่หลายอย่างครับ เช่น
- กระบวนการทำงานภายใน (internal process) ขององค์กรลูกค้าเกิดเปลี่ยนแปลงกระทันหันซึ่งส่งผลต่อ Project ที่เราทำอยู่
- หลายครั้งตัวลูกค้าที่ให้ Requirement กับเราอาจจะไม่รู้หรือไม่เข้าใจกระบวนการทำงานจริงๆ
- บางครั้งก็มีเรื่องการเมืองแอบแฝงมา ด้วยครับ เช่น คุยกับหัวหน้าไว้ว่าจะทำแบบนี้ แต่ถึงเวลาคนใช้จริง (end-users) ไม่อยากได้แบบนี้แล้ว
ความพึงพอใจของลูกค้าคือจุดสำคัญที่ ทุกบริษัทควรจะคำนึงถึงใช่มั้ยครับ? แต่ครั้นเราจะรับ Requirement Changes ทุกๆตัวทุกๆสถานการณ์ก็อาจจะไม่ใช่ทางเลือกที่ดีซักเท่าไรในมุมมอง Project Management เพราะว่าโอกาสที่ Project จะล้มเหลวก็อาจจะสูงขึ้น แทนที่จะทำให้ลูกค้าปลื้มมันจะกลายเป็นกดปุ่มทำลายตัวเองซะด้วยซ้ำครับ
ในความพยายามที่จะป้องกันไม่ให้ Project ล่มเพราะเรารับ Requirement Changes แบบไม่ดูตาม้าตาเรือ วันนี้ผมมีคำถามที่ควรถามเพื่อเก็บข้อมูลก่อนตัดสินใจว่าจะรับหรือไม่รับ Requirement Changes เหล่านั้นมาฝากกันครับ
1. Requirement ใหม่คืออะไร?
คำถามนี้ … ไม่ถามได้อย่างไร ฮ่าๆ จุดประสงค์สำคัญที่ต้องถามนอกจากเพื่อเก็บข้อมูลว่าลูกค้าอยากได้อะไรแล้ว ประเด็นสำคัญอีกข้อคือเพื่อตรวจสอบว่า ปัญหาที่ลูกค้าเจอหรือสิ่งที่ลูกค้าต้องการสามารถแก้ปัญหาด้วย IT หรือ System ใหม่ได้จริงๆ ลองถามให้ลึกๆดูเพื่อระบุสาเหตุจริงๆของปัญหานั้นครับ ถ้าซักๆไปแล้วเจอว่าต้นตอปัญหาคือเรื่องพวกการเมืองภายใน เรื่องคน เรื่องเกี่ยวกับโครงสร้างองค์กร มันอาจจะแก้ไม่ได้ด้วย IT หรือ System ใหม่ครับ
และเพื่อเป็นการสร้าง requirement ที่สมบูรณ์ (complete), ชัดเจน (clear), และถูกต้อง (valid) ระหว่างการพูดคุยลองประยุกต์ใช้ operational concept มาช่วยดูครับ
2. ประโยชน์ที่ได้จากการทำ requirement ใหม่นี้มีอะไรบ้าง?
คำถามนี้จะ ช่วยให้เรารู้วัตถุประสงค์ที่แท้จริงของ Requirement Change ตัวนี้ครับ ซึ่งเราสามารถใช้ประสบการณ์ในการประิเิมินเบื้องต้นว่ามันทำได้หรือทำไม่ได้ มันสมเหตุสมผลมั้ยระหว่างสิ่งที่เค้าขอกับวัตถุประสงค์จริงๆที่เค้าต้องการ ไม่แน่นะคุยไปคุยมาลูกค้าอาจจะเห็นว่า Change ตัวนี้ไม่ Valid แล้วก็ยกเลิกไปเลยก็ได้ (เสร็จโก๋) นอกจากนี้เรายังสามารถช่วยแนะนำทางเลือกที่ดีๆที่ช่วยให้ลูกค้าบรรลุวัตถุ ประสงค์นี้ได้โดยที่เราไม่ได้รับผลกระทบมากนักได้อีกต่างหาก
3. จะเกิดอะไรขึ้นถ้า requirement นี้ถูกปฏิเสธ?
คำถามนี้ เพื่อทดสอบดูว่า จริงๆแล้ว requirement นี้จำเป็นแค่ไหน? ถ้าเล็กๆน้อยๆก็ลองหาทางเลื่อนออกไปก่อนถ้า Project อยู่ในช่วงหลังๆแล้ว แต่ถ้าลูกค้าบอกว่าจะเสียหายเป็นตัวเงินเท่านั้นเท่านี้ก็น่าจะยากที่จะ ปฏิเสธหละครับ
4. มีทางอื่นหรือไม่ที่จะตอบสนอง requirement นี้ได้โดยไม่ต้องทำระบบใหม่?
ที่คำถามนี้ เพื่อหวังว่าจะช่วยให้งานเราน้อยลงบ้าง เช่น ถ้ามี workaround อยู่แล้วโดยใช้ระบบเก่า เราอาจจะขอให้ลูกค้าใช้ workaround นั้นไปก่อน แล้วเราค่อยนำ requirement นี้มาพิจารณาอีกครั้งสำหรับ release หน้า
5. มี requirement อื่นๆซ่อนอยู่อีกหรือไม่?
คำถามนี้ ต้องการที่จะลดโอกาสที่จะเกิด requirement changes ที่ต่อเนื่องกันมาเป็นลูกโซ่ครับ ถ้า requirement ใหม่ของลูกค้าเกิดขึ้นที่ feature ไหน เราควรจะคิดต่อไปด้วยว่า “แล้วมันจะมีอะไรใหม่ๆมาอีกมั้ยน้อ?” ถ้าเรามี business analysis หรือ field engineer ที่อยู่กับลูกค้า เป็นโอกาสอันดีที่เราจะลองเข้าไปสังเกตสังกาการใช้งานของลูกค้าเพื่อลองดู ว่าจะมีอะไรซ่อนอยู่จริงๆรึเปล่า (ถามปากเปล่าอย่างเดียวคงไม่พอ)
6. ทำไม requirement ถึงไม่ถูกระบุไว้ตั้งแต่แรก?
คำถามนี้ใช้ เพื่อตรวจสอบหาข้อบกพร่องของกระบวนการทำงานครับ ผมไม่ได้คิดไกลขนาดว่าจะไม่มี Requirement Changes เกิดขึ้นเลยตลอดการทำงานหรอกครับ เพียงแต่ว่าถ้ามันเกิดขึ้นบ่อยๆ (จนเกินไป) เราควรจะหันกลับมาดูว่า เราทำอะไรไม่ถูก หรือไม่ดีพอรึเปล่า? ซึ่งคำถามนี้จะช่วยให้เรามองเห็นถึงจุดบกพร่องเหล่านั้น ลองถามคำถามนี้กับลูกค้าดูครับ เราอาจจะมองเห็นว่า
- เราใช้เวลากับ Requirement Gathering กับ Requirement Analysis น้อยไปรึเปล่าน้า?
- Business Analyst (หรือคนที่ไปเก็บ Requirement จากลูกค้า) มีประสบการณ์น้อยไปรึเปล่าน้า?
- เ๊อ๊ะ หรือว่าเราไปเก็บข้อมูลผิดคน? แทนที่จะคุยกับคนใช้ระบบจริง (end users) เราดันไปคุยกับหัวหน้าเค้า? เป็นต้นครับ
ขั้นตอนต่อไปหละ?
หลังจากที่ เราได้รับคำตอบทั้งหมดมาแล้ว ก็ถึงเวลาที่เราจะตัดสินใจรับหรือไม่รับ Requirement Changes เหล่านี้ครับ จริงๆแล้วอำนาจตัดสินใจไม่ได้อยู่ที่เรา (Project Manager) คนเดียวหรอก เพียงแต่ว่าเราสามารถที่จะต่อรองกับลูกค้าได้ว่า ถ้ารับ Change มาแล้ว เราจะขอเลื่อนวันส่งงานไปเป็นเมื่อไร? เราจะคิดราคาเพิ่มเท่าไร? หรือว่าเราจะต้องลดคุณภาพลงมาอย่างไรเพื่อให้งานเสร็จตรงตามเวลาเดิม? อันนี้ก็เป็นความสามารถเฉพาะตัวของแต่ละคนแล้วหละครับ
แล้วเพื่อนๆหละครับ? มีกระบวนการจัดการกับ Change (Change Management) ยังไงกันมั่งครับ?
Project Management and Software Development Blog for Thais | Chapterpiece.com
Better Managing, Better Living
Requirement Changes … รับหรือไม่รับ
การเปลี่ยน แปลงที่เกิดขึ้นใน project โดยเฉพาะอย่างยิ่ง Requirement Changes เป็นเรื่องปกติที่ทุกๆคนคงจะเคยเจอกัน ซึ่งสาเหตุของ Requirement Changes นั้นก็มีอยู่หลายอย่างครับ เช่น
ความพึงพอใจของลูกค้าคือจุดสำคัญที่ ทุกบริษัทควรจะคำนึงถึงใช่มั้ยครับ? แต่ครั้นเราจะรับ Requirement Changes ทุกๆตัวทุกๆสถานการณ์ก็อาจจะไม่ใช่ทางเลือกที่ดีซักเท่าไรในมุมมอง Project Management เพราะว่าโอกาสที่ Project จะล้มเหลวก็อาจจะสูงขึ้น แทนที่จะทำให้ลูกค้าปลื้มมันจะกลายเป็นกดปุ่มทำลายตัวเองซะด้วยซ้ำครับ
ในความพยายามที่จะป้องกันไม่ให้ Project ล่มเพราะเรารับ Requirement Changes แบบไม่ดูตาม้าตาเรือ วันนี้ผมมีคำถามที่ควรถามเพื่อเก็บข้อมูลก่อนตัดสินใจว่าจะรับหรือไม่รับ Requirement Changes เหล่านั้นมาฝากกันครับ
1. Requirement ใหม่คืออะไร?
คำถามนี้ … ไม่ถามได้อย่างไร ฮ่าๆ จุดประสงค์สำคัญที่ต้องถามนอกจากเพื่อเก็บข้อมูลว่าลูกค้าอยากได้อะไรแล้ว ประเด็นสำคัญอีกข้อคือเพื่อตรวจสอบว่า ปัญหาที่ลูกค้าเจอหรือสิ่งที่ลูกค้าต้องการสามารถแก้ปัญหาด้วย IT หรือ System ใหม่ได้จริงๆ ลองถามให้ลึกๆดูเพื่อระบุสาเหตุจริงๆของปัญหานั้นครับ ถ้าซักๆไปแล้วเจอว่าต้นตอปัญหาคือเรื่องพวกการเมืองภายใน เรื่องคน เรื่องเกี่ยวกับโครงสร้างองค์กร มันอาจจะแก้ไม่ได้ด้วย IT หรือ System ใหม่ครับ
และเพื่อเป็นการสร้าง requirement ที่สมบูรณ์ (complete), ชัดเจน (clear), และถูกต้อง (valid) ระหว่างการพูดคุยลองประยุกต์ใช้ operational concept มาช่วยดูครับ
2. ประโยชน์ที่ได้จากการทำ requirement ใหม่นี้มีอะไรบ้าง?
คำถามนี้จะ ช่วยให้เรารู้วัตถุประสงค์ที่แท้จริงของ Requirement Change ตัวนี้ครับ ซึ่งเราสามารถใช้ประสบการณ์ในการประิเิมินเบื้องต้นว่ามันทำได้หรือทำไม่ได้ มันสมเหตุสมผลมั้ยระหว่างสิ่งที่เค้าขอกับวัตถุประสงค์จริงๆที่เค้าต้องการ ไม่แน่นะคุยไปคุยมาลูกค้าอาจจะเห็นว่า Change ตัวนี้ไม่ Valid แล้วก็ยกเลิกไปเลยก็ได้ (เสร็จโก๋) นอกจากนี้เรายังสามารถช่วยแนะนำทางเลือกที่ดีๆที่ช่วยให้ลูกค้าบรรลุวัตถุ ประสงค์นี้ได้โดยที่เราไม่ได้รับผลกระทบมากนักได้อีกต่างหาก
3. จะเกิดอะไรขึ้นถ้า requirement นี้ถูกปฏิเสธ?
คำถามนี้ เพื่อทดสอบดูว่า จริงๆแล้ว requirement นี้จำเป็นแค่ไหน? ถ้าเล็กๆน้อยๆก็ลองหาทางเลื่อนออกไปก่อนถ้า Project อยู่ในช่วงหลังๆแล้ว แต่ถ้าลูกค้าบอกว่าจะเสียหายเป็นตัวเงินเท่านั้นเท่านี้ก็น่าจะยากที่จะ ปฏิเสธหละครับ
4. มีทางอื่นหรือไม่ที่จะตอบสนอง requirement นี้ได้โดยไม่ต้องทำระบบใหม่?
ที่คำถามนี้ เพื่อหวังว่าจะช่วยให้งานเราน้อยลงบ้าง เช่น ถ้ามี workaround อยู่แล้วโดยใช้ระบบเก่า เราอาจจะขอให้ลูกค้าใช้ workaround นั้นไปก่อน แล้วเราค่อยนำ requirement นี้มาพิจารณาอีกครั้งสำหรับ release หน้า
5. มี requirement อื่นๆซ่อนอยู่อีกหรือไม่?
คำถามนี้ ต้องการที่จะลดโอกาสที่จะเกิด requirement changes ที่ต่อเนื่องกันมาเป็นลูกโซ่ครับ ถ้า requirement ใหม่ของลูกค้าเกิดขึ้นที่ feature ไหน เราควรจะคิดต่อไปด้วยว่า “แล้วมันจะมีอะไรใหม่ๆมาอีกมั้ยน้อ?” ถ้าเรามี business analysis หรือ field engineer ที่อยู่กับลูกค้า เป็นโอกาสอันดีที่เราจะลองเข้าไปสังเกตสังกาการใช้งานของลูกค้าเพื่อลองดู ว่าจะมีอะไรซ่อนอยู่จริงๆรึเปล่า (ถามปากเปล่าอย่างเดียวคงไม่พอ)
6. ทำไม requirement ถึงไม่ถูกระบุไว้ตั้งแต่แรก?
คำถามนี้ใช้ เพื่อตรวจสอบหาข้อบกพร่องของกระบวนการทำงานครับ ผมไม่ได้คิดไกลขนาดว่าจะไม่มี Requirement Changes เกิดขึ้นเลยตลอดการทำงานหรอกครับ เพียงแต่ว่าถ้ามันเกิดขึ้นบ่อยๆ (จนเกินไป) เราควรจะหันกลับมาดูว่า เราทำอะไรไม่ถูก หรือไม่ดีพอรึเปล่า? ซึ่งคำถามนี้จะช่วยให้เรามองเห็นถึงจุดบกพร่องเหล่านั้น ลองถามคำถามนี้กับลูกค้าดูครับ เราอาจจะมองเห็นว่า
ขั้นตอนต่อไปหละ?
หลังจากที่ เราได้รับคำตอบทั้งหมดมาแล้ว ก็ถึงเวลาที่เราจะตัดสินใจรับหรือไม่รับ Requirement Changes เหล่านี้ครับ จริงๆแล้วอำนาจตัดสินใจไม่ได้อยู่ที่เรา (Project Manager) คนเดียวหรอก เพียงแต่ว่าเราสามารถที่จะต่อรองกับลูกค้าได้ว่า ถ้ารับ Change มาแล้ว เราจะขอเลื่อนวันส่งงานไปเป็นเมื่อไร? เราจะคิดราคาเพิ่มเท่าไร? หรือว่าเราจะต้องลดคุณภาพลงมาอย่างไรเพื่อให้งานเสร็จตรงตามเวลาเดิม? อันนี้ก็เป็นความสามารถเฉพาะตัวของแต่ละคนแล้วหละครับ
แล้วเพื่อนๆหละครับ? มีกระบวนการจัดการกับ Change (Change Management) ยังไงกันมั่งครับ?
Project Management and Software Development Blog for Thais | Chapterpiece.com
Better Managing, Better Living