Requirement Change … รับ/ไม่รับ
การเปลี่ยนแปลงที่เกิดขึ้นในโปรเจกต์โดยเฉพาะอย่างยิ่ง Requirement Changes เป็นเรื่องปกติที่ทุกๆคนคงจะเคยเจอกัน ซึ่งสาเหตุของ Requirement Changes นั้นก็มีอยู่หลายอย่าง เช่น
- กระบวนการทำงานภายใน (internal process) ขององค์กรลูกค้าเกิดเปลี่ยนแปลงกระทันหันซึ่งส่งผลต่อโปรเจกต์ที่เราทำอยู่
- หลายครั้งตัวลูกค้าที่ให้ Requirement กับเราอาจจะไม่รู้หรือไม่เข้าใจกระบวนการทำงานจริงๆ ข้อมูลที่เราได้มาจึงไม่ถูกต้องหรือไม่ครบถ้วน
- บางครั้งก็มีเรื่องการเมืองแอบแฝงมาด้วยครับ เช่น คุยกับหัวหน้าไว้ว่าจะทำแบบนี้ แต่ถึงเวลาคนใช้จริง (end users) ไม่อยากได้แบบนี้แล้ว
ความพึงพอใจของลูกค้าคือจุดสำคัญที่ทุกบริษัทควรจะคำนึงถึงใช่มั้ย? แต่ครั้นเราจะรับChange ทุกๆตัวทุกๆสถานการณ์ก็อาจจะไม่ใช่ทางเลือกที่ดีซักเท่าไรในมุมมอง Project Management เพราะว่าโอกาสที่โปรเจกต์จะล้มเหลวก็อาจจะสูงขึ้น แทนที่จะทำให้ลูกค้าปลื้มมันจะกลายเป็นกดปุ่มทำลายตัวเองซะด้วยซ้ำ
ในความพยายามที่จะป้องกันไม่ให้โปรเจกต์ล่มเพราะเรารับ Change แบบไม่ดูตาม้าตาเรือ วันนี้มีคำถามที่ควรถามเพื่อเก็บข้อมูลก่อนตัดสินใจว่าจะรับหรือไม่รับ Requirement Changes เหล่านั้นมาฝากให้คิดกันดูครับ
1. Requirement ใหม่คืออะไร?
คำถามนี้ … ไม่ถามได้อย่างไร จุดประสงค์สำคัญที่ต้องถามนอกจากเพื่อเก็บข้อมูลว่าลูกค้าอยากได้อะไรแล้ว ประเด็นสำคัญอีกข้อคือเพื่อตรวจสอบว่า ปัญหาที่ลูกค้าเจอหรือสิ่งที่ลูกค้าต้องการสามารถแก้ปัญหาด้วย IT หรือซอฟต์แวร์ใหม่ได้จริงๆ ลองถามให้ลึกๆดูเพื่อระบุสาเหตุจริงๆของปัญหานั้น ถ้าซักๆไปแล้วเจอว่าต้นตอปัญหาคือเรื่องพวกการเมืองภายใน เรื่องคน เรื่องเกี่ยวกับโครงสร้างองค์กร การรับ Change ตัวนี้เข้ามาก็ป่วยการ
2. ประโยชน์ที่ได้จากการทำ Requirement ใหม่นี้มีอะไรบ้าง?
คำถามนี้จะช่วยให้เรารู้วัตถุประสงค์ที่แท้จริงของ Change ตัวนี้ ซึ่งเราสามารถใช้ประสบการณ์ในการประเมินเบื้องต้นว่ามันทำได้หรือทำไม่ได้ มันสมเหตุสมผลมั้ยระหว่างสิ่งที่เค้าขอกับวัตถุประสงค์จริงๆที่เค้าต้องการ ไม่แน่นะคุยไปคุยมาลูกค้าอาจจะเห็นว่า Change ตัวนี้ไม่ Valid แล้วก็ยกเลิกไปเลยก็ได้ นอกจากนี้เรายังสามารถช่วยแนะนำทางเลือกที่ดีๆที่ช่วยให้ลูกค้าบรรลุวัตถุประสงค์นี้ได้โดยที่เราไม่ได้รับผลกระทบมากนักได้อีกต่างหาก
3. จะเกิดอะไรขึ้นถ้า Requirement นี้ถูกปฏิเสธ?
คำถามนี้เพื่อทดสอบดูว่า จริงๆแล้ว Change นี้จำเป็นแค่ไหน? ถ้าเล็กๆน้อยๆก็ลองหาทางแก้ปัญหาเฉพาะหน้าแบบไม่กระทบงานหลักมากนักแล้วเลื่อน Change ตัวนี้ออกไปก่อนถ้าโปรเจกต์อยู่ในช่วงหลังๆแล้ว แต่ถ้าลูกค้าบอกว่าจะเสียหายเป็นตัวเงินเท่านั้นเท่านี้ก็น่าจะยากที่จะปฏิเสธหละครับ
4. มีทางอื่นหรือไม่ที่จะตอบสนอง Requirement นี้ได้โดยไม่ต้องทำอะไรใหม่?
ที่คำถามนี้เพื่อหวังว่าจะช่วยให้งานเราน้อยลงบ้าง เช่น ถ้ามี Workaround อยู่แล้วโดยใช้ระบบเก่า เราอาจจะขอให้ลูกค้าใช้วิธีนั้นไปก่อน แล้วเราค่อยนำ Requirement นี้มาพิจารณาอีกครั้งสำหรับ Release หน้า
5. มี Requirement อื่นๆซ่อนอยู่อีกหรือไม่?
คำถามนี้ต้องการที่จะลดโอกาสที่จะเกิด Requirement Change ที่ต่อเนื่องกันมาเป็นลูกโซ่ ถ้า Requirement ใหม่ของลูกค้าเกิดขึ้นที่ Feature ไหน เราควรจะคิดต่อไปด้วยว่า “แล้วมันจะมีอะไรใหม่ๆมาอีกมั้ย?” ถ้าเราสามารถเข้าถึงผู้ใช้ตัวเป็นๆได้ก็เป็นโอกาสอันดีที่เราจะลองเข้าไปสังเกตสังกาการใช้งานของลูกค้าเพื่อลองดูว่าจะมีอะไรซ่อนอยู่จริงๆรึเปล่า (ถามปากเปล่าอย่างเดียวคงไม่พอ)
6. ทำไม Requirement ถึงไม่ถูกระบุไว้ตั้งแต่แรก?
คำถามนี้ใช้เพื่อตรวจสอบหาข้อบกพร่องของกระบวนการทำงาน ผมไม่ได้คิดไกลขนาดว่าจะไม่มี Requirement Changes เกิดขึ้นเลยตลอดการทำงานหรอกเพียงแต่ว่าถ้ามันเกิดขึ้นบ่อยๆ (จนเกินไป) เราควรจะหันกลับมาดูว่า เราทำอะไรไม่ถูก หรือไม่ดีพอรึเปล่า? ซึ่งคำถามนี้จะช่วยให้เรามองเห็นถึงจุดบกพร่องเหล่านั้น ลองถามคำถามนี้กับลูกค้าดูครับ เราอาจจะมองเห็นว่า
- เราใช้เวลากับ Requirement Gathering กับ Requirement Analysis น้อยไปรึเปล่า?
- Business Analyst (หรือคนที่ไปเก็บ Requirement จากลูกค้า) มีประสบการณ์น้อยไปรึเปล่า?
- หรือว่าเราไปเก็บข้อมูลผิดคน? แทนที่จะคุยกับคนใช้ระบบจริง (end users) เราดันไปคุยกับหัวหน้าเค้า? เป็นต้น
ขั้นตอนต่อไป?
หลังจากที่เราได้รับคำตอบทั้งหมดมาแล้ว ก็ถึงเวลาที่เราจะตัดสินใจรับหรือไม่รับ Requirement Changes เหล่านี้ จริงๆแล้วอำนาจตัดสินใจไม่ได้อยู่ที่ Project Manager อย่างเราคนเดียวหรอก เพียงแต่ว่าเราสามารถที่จะต่อรองกับลูกค้าได้ว่า ถ้ารับ Change มาแล้ว เราจะขอเลื่อนวันส่งงานไปเป็นเมื่อไร? เราจะคิดราคาเพิ่มเท่าไร? หรือว่าเราจะต้องตัดงานอื่นออกไปอย่างไรเพื่อให้งานเสร็จตรงตามเวลาเดิม?
ยิ่งมีข้อมูลมากเราก็ยิ่งเตรียมตัวได้ดีมาก มีทางเลือกที่ยื่นให้ลูกค้าพิจารณาได้มาก ที่สำคัญคือเราต้องพยายามแสดงให้เค้าเห็นว่าเราไม่ได้ปฎิเสธ Change ใดๆ แต่เรากำลังทำความเข้าใจกับสิ่งที่กำลังเกิดขึ้น กำลังรวบรวมข้อมูลให้ได้มากเพียงพอที่จะตัดสินใจเลือกสิ่งที่ดีที่สุดให้กับลูกค้าเองครับ ยากแต่สนุก … ถ้าลูกค้ามีเหตุผลและรับฟังเรานะ ฮ่าๆ
ผมเขียนบทความนี้เพราะอยากเปลี่ยนแปลงสิ่งที่เป็นอยู่ในอุตสาหกรรมการผลิต ซอฟท์แวร์ให้ดีขึ้นตามความเชื่อและประสบการณ์ของผม ถ้าเพื่อนๆเชื่อในแนวทางเดียวกัน เรามาช่วยกันคนละไม้คนละมือทำให้สังคมของเราดีขึ้นครับ จะแชร์บทความนี้ผ่าน Social Network หรือจะแบ่งปันเรื่องราวนี้ให้คนที่นั่งข้างๆฟังบ้างก็ได้
The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson
อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ
