บริหาร Requirement ในสัญญาอย่างไรให้ตรงใจลูกค้า
🤔เคล็ดลับการบริหารความต้องการ (requirement) ในสัญญา ให้ได้งานที่ตรงความต้องการของลูกค้าจริงๆ ทั้งที่สัญญาโดยทั่วไปมักจะระบุความต้องการไว้ ซับซ้อน อยู่ในหลายส่วนของสัญญา และดูจะไม่ชัดเจนเอาเสียเลย จริงๆแล้วเรามีเทคนิคที่จะแก้เรื่องนี้ได้ครับ
ปัญหาคลาสสิกของทุกโครงการ:
ทุกท่านเคยเจอใช่ไหมครับ เราทำงานตามสัญญาทุกประการ แต่ลูกค้ากลับปฎิเสธการรับงานนั้น แล้วแจ้งว่างานที่เราทำไม่ตรงความต้องการของเขาซะอย่างนั้น ทำให้เราต้องแก้งานใหม่ เสียทั้งเวลา และค่าใช้จ่ายมากมาย เพราะกว่าจะรู้ ก็เป็นตอนที่เราส่งงานไปแล้ว ซึ่งมักจะเป็นช่วงท้ายโครงการ บางครั้งก็สายเกินแก้ไปซะแล้ว
แล้วมันเกิดจากอะไรกันแน่ล่ะ?? :
ปัญหามันเกิดจาก เรามัวแต่สนใจนั่งตีความสัญญา และเอกสารขอบเขตรายละเอียดงาน (Term Of Reference หรือ TOR) แต่กลับไม่เคยทราบความต้องการที่แท้จริงของลูกค้าเลย พอทำงานออกมา มันก็ไม่ตรงความต้องการเขาน่ะสิครับ
แล้วมันแก้อย่างไรล่ะ?? :
จริงๆแล้ว ก็แค่อย่าเอาแต่อ่านสัญญา แล้วแปลความ (เอาเอง) อยู่ข้างเดียวครับ ให้นำสิ่งที่เราตีความ มาปรึกษาลูกค้า ว่าเข้าใจตรงกันหรือไม่ เพื่อให้เข้าใจสิ่งที่ลูกค้าต้องการจริงๆ พอทราบแล้ว เราก็สามารถระบุเนื้องานที่สำคัญที่จำเป็นต้องทำ ซึ่งต้องเน้นมากเป็นพิเศษ โดยสรุปการพูดคุยกับลูกค้าจะทำให้เราได้ค้นพบข้อมูลเชิงลึกเหล่านี้ ซึ่งในรายละเอียดสิ่งที่เราจะได้จากการสอบถามลูกค้าแบ่งเป็น 2 กลุ่มหลักครับ
- งานที่ลูกค้าอยากได้แต่สัญญาระบุไว้ไม่ชัดเจน หรือตีความยาก: ข้อแรกนี้สำคัญที่สุดเลยครับ การพูดคุยจะช่วยให้เราเข้าใจในสิ่งที่สัญญาระบุไว้ไม่ชัด ระบุไว้หลายส่วนของสัญญา แถมบางครั้งยังระบุไม่สอดคล้องกัน เมื่อนำสิ่งเหล่านี้มาสอบถามลูกค้า เราจะสามารถเข้าใจ ความต้องการของเขาได้อย่างถ่องแท้ เราจะได้เพิ่มงาน หรือกิจกรรมที่เกี่ยวข้องเพื่อให้ได้ตามความต้องการนี้
- งานที่ลูกค้าให้ความสำคัญระดับพลาดไม่ได้: สัญญาไม่ได้เขียนไว้ใช่ไหมล่ะครับ ว่างานไหนสำคัญมากๆ ระดับพลาดไม่ได้เลย หรือถึงเขียนไว้ ก็มักไม่ได้ชัดเจนขนาดนั้น แต่พอคุณรู้จากปากลูกค้าว่าเขามีข้อกังวล เขาเป็นห่วง เขาไม่อยากให้งานนั้นๆ ผิดพลาด คุณจะรู้ทันทีเลยว่าเป็นเรื่องที่สำคัญจริงๆ เราอาจถามเพิ่มเติมถึงเหตุผล หรือ ข้อจำกัด ที่เกี่ยวข้องเพิ่มด้วยก็ได้ คราวนี้คุณจะได้นำข้อมูลนี้มากำชับทีมงานได้ถูกต้อง เพื่อให้ไม่พลาดสิ่งที่สำคัญนี้ครับ
เอาล่ะครับ นอกจากทำงานที่ลูกค้าต้องการจริงๆแล้ว การพูดคุยดังกล่าวนี้ก็ทำให้เราได้ทราบว่า งานบางงานที่ระบุในสัญญา อาจไม่ได้เป็นความต้องการหลักเลย ซึ่งทำให้เราไม่จำเป็นต้องใช้พลังงานหลักไปกับงานเหล่านี้เท่ากับงานกลุ่มข้างต้น ทำให้เราสามารถประหยัดได้ทั้งเวลา และทรัพยากรของโครงการ ซึ่งเราก็มีเกร็ดเล็กเกร็ดน้อยในการบริหารงานกลุ่มนี้ดังนี้ครับ
- งานบางงานสามารถควบรวมเป็นงานเดียวกันได้: ในสัญญามักจะมีงานที่คล้ายๆกัน หรือระบุให้ทำซ้ำๆกัน เราสามารถเสนอให้ควบรวมงานนั้นได้ เช่น จากรายการคำนวณทางวิศวกรรมแยกฉบับ โดยแบ่งตามพื้นที่ที่เกี่ยวข้อง เราสามารถควบรวมให้เป็นเล่มรวมเล่มเดียว หรือ รายงานความคืบหน้างานรายสัปดาห์ (Weekly Report) สามารถขยายเป็นรายสองสัปดาห์ (Bi-weekly Report) กรณีนี้จะเห็นว่างานจะลดได้ครึ่งนึงเลยครับ
- งานที่อาจไม่จำเป็นอีกต่อไป: สังเกตไหมครับ บาง requirement ไม่ได้จำเป็นแล้วสำหรับโครงการ เนื่องจากสถานการณ์ได้เปลี่ยนไปแล้ว เช่น รายงานผลการศึกษาบางตัวที่ลูกค้าไม่ได้ต้องการข้อมูลนั้นแล้ว งานเหล่านี้เราสามารถเสนอได้ว่าอาจไม่จำเป็นต้องทำ แต่ทั้งที่ทั้งนั้น อย่าลืมว่าสิ่งที่ต้องนำส่งของโครงการยังคงต้องได้ตามวัตถุประสงค์อยู่นะครับ
- งานที่จำเป็นน้อย แต่ระบุไว้ว่าต้องทำ: ไม่ทำงานเหล่านี้ ก็แทบไม่ได้มีผลกระทบกับโครงการ เนื่องจากมีความจำเป็นน้อย ถึงน้อยมาก เราอาจเสนอว่าอาจไม่จำเป็นต้องทุ่มเททำในรายละเอียดมากก็ได้ อาจจะแค่ทำเท่าที่จำเป็นก็พอ ตัวอย่าง เช่น แผนระยะเวลาโครงการ (Project Schedule) ในช่วงที่ไม่ใช่ช่วงสำคัญ อาจเสนอให้ทำแบบละเอียดน้อยลง ก็ได้ครับ
อย่าลืมเพิ่มความพยายาม หรือเน้นมากขึ้นกับงานที่ลูกค้าต้องการ เพื่อหลีกเลี่ยงความผิดพลาด ทั้งนี้ทั้งนั้นงานที่เพิ่มขึ้นนี้ สามารถชดเชยกับงานจะลดลงในกลุ่มหลัง ในบางครั้งเราอาจเสนอแลกเปลี่ยนงานสองกลุ่มนี้อย่างเป็นทางการ โดยบันทึกเป็นความต้องการเพิ่มเติมของสัญญาเลยก็ได้ครับ ทั้งนี้ทั้งนั้นอย่าลืมว่าเราต้องได้รับความเห็นชอบจากลูกค้าด้วยนะครับ
✨เป็นอย่างไรบ้างครับ ลองเอาไปปรับใช้กับงานของพวกเราดูนะครับ ผมเชื่อว่าเทคนิคนี้จะทำให้เราบริหารสัญญาได้เป็นอย่างดี และที่สำคัญคือตรงใจลูกค้า ในท้ายที่สุดเราจะสามารถส่งงานได้ผ่านฉลุยแน่นอนครับ แล้วไว้พบกันบทความหน้าครับ
เกี่ยวกับผู้เขียน
อาจารย์ นิวัติ คล่องวานิชย์
Languages: EN I TH
Certified Project Management Professional, PMI
