มีเพื่อนคนนึงกำลังเจอปัญหาหนักใจเกี่ยวกับเรื่องการทำงานกับลูกค้าครับ เรื่องราวเป็นแบบนี้ฮะ

ตอนนี้มี project ที่ทำเสร็จไปแล้วซักระยะหนึ่งแต่ไม่ได้มีการทำdocumentใดๆไม่ว่าจะเป็น Unit test, UAT, User manual ดังนั้นตอนนี้ต้องกลับมาทำเพื่อให้เก็บเงินได้ (คงงงใช่ไหมคะว่าทำไมไม่ทำตั้งแต่แรก อันนี้ก็ไม่ทราบว่าคนเก่าเขาตกลงสัญญากันอย่างไรเพราะดิฉันเพิ่งเข้ามาก็ต้องมาทำงานที่เขาเหลือๆไว้ให้โดยที่ไม่มีอะไรเลยนอกจากเข้าไปคลำๆที่หน้าจอใช้งาน)

ซึ่งปัญหาก็คือทางลูกค้า reviewเอกสารเป็นสิบๆครั้งไม่ผ่านซักที แบบนี้เราจะมีวิธีแก้ไขอย่างไรบ้างคะ ตอนนี้เหตุกาณ์ก็คือลูกค้าไม่ค่อยมีเวลาดังนั้นก็ review ไม่ครบขยักขย่อนและไม่ review พร้อมกันทุกคน เป็นต้น และทุกครั้งต้อง print hard copy ให้เขาreviewเนื่องจากอ้างว่าปวดตา ซึ่งตอนนี้เสียค่า print ซีร็อกเป็นพันๆแล้วค่ะ ยังไม่ยอม sign ให้เลย และที่คิดไว้คือ

1.นัดคุยกับหัวหน้าเขาโดยตรงถึงปัญหาทั้งหมด

2.เสนอ solution review เพื่อให้มีการตรวจรับที่ชัดเจนแต่ตอนนี้ยังคิดไม่ออกว่าจะมี solution ยังไงดี

ขอรบกวนด้วยนะคะหรืออื่นๆๆพอจะมีคำแนะนำบ้างไหมคะ เครียดจริงๆค่ะ

ฟังแล้วเครียดแทนเลยครับ ปัญหาการทำงานกับลูกค้านี่อมตะจริงๆ แต่ในเมื่อหนีไม่พ้นก็ต้องลุยกันซักตั้งหละ มุมมองของผมต่อปัญหานี้มีดังนี้ครับ

มองภาพรวม

จากข้อมูลที่ได้มา ผมตีความได้ว่า Project นี้มีงานที่ต้องส่งมอบ (Deliverable) อยู่สองอย่างคือ หนึ่ง Software และสองเอกสารต่างๆ ซึ่งสถานการณ์ตอนนี้คือ Software ทำเสร็จแล้วและติดตั้งให้ลูกค้าใช้งานเรียบร้อยแล้ว แต่เอกสารยังไม่มีเลย การจะเก็บเงินจากลูกค้าก็เลยยังทำไม่ได้เพราะว่ายังส่งมอบงานไม่ครบตามสัญญา

ตรงนี้กลายเป็นปัญหาสำคัญของ Project Manager ที่เข้ามารับงานต่อเพราะต้องเป็นคนจัดการทำเอกสารพวก Unit Test, User Acceptance Test, User Manual ต่างๆให้เรียบร้อย พร้อมกับล่าลายเซ็นอนุมัติจากลูกค้าก่อนปิดงานและรับเงิน แต่เหมือนโชคไม่เข้าข้าง ลูกค้าไม่ค่อยอยากจะให้ความร่วมมือเท่าไร สถานการณ์เลยดูว่าจะเลวร้ายลงไป

นี่คือสมมติฐานของผมจากข้อมูลที่มี ถ้าผิดถูกยังไงช่วยบอกด้วยนะครับ

วิเคราะห์หาสาเหตุ

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

เอกสาร

เท่าที่อ่านมาคือลูกค้า Review หลายรอบแล้วยังไม่ผ่าน เป็นไปได้มั้ยครับว่าเอกสารเราเขียนไม่ดี เช่น ข้อมูลไม่ครบถ้วน ข้อมูลไม่ถูกต้อง รูปแบบไม่เป็นระเบียบเรียบร้อย หรือภาษาที่ใช้อ่านยาก อีกมุมมองหนึ่งคือว่าลูกค้าต้อง Review เอกสารมากไปรึเปล่าครับ? Unit Test, User Acceptance Test, User Manual จำเป็นต้องอ่านทั้งหมดเลยรึเปล่าครับ?

อำนาจต่อรอง

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


ไม่มีกระบวนการทำงานที่ชัดเจน

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

ลูกค้า

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

ขาดการสนับสนุนที่ดี

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

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

หาทางแก้

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

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

จัดการเอกสาร

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

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

หาอำนาจต่อรอง

อืม … ข้อนี้พูดยากครับ ผมไม่ทราบข้อมูลของสถานการณ์ทั้งหมด แต่ถ้าเป็นผมผมคงต้องมองหาอำนาจต่อรองหรือแรงจูงใจที่จะทำให้ลูกค้ายอมทำงานให้เรา สถานการณ์นี้ผมตั้งสมมติฐานไว้ว่า Software ถูกส่งมอบและติดตั้งให้ลูกค้าไปแล้วซึ่งเหมือนว่าเราเสียอำนาจต่อรองอันยิ่งใหญ่ไปเรียบร้อย แต่ไม่เป็นไร ลองกลับมาดูที่สัญญาอีกรอบว่ายังเหลืออะไรให้เราใช้ได้บ้าง เช่น อืม … User Training, Documents, Source Code หรืออื่นๆ  เราอาจจะคุยกับหัวหน้างานของลูกค้าว่าการ Review ต้องได้รับการอนุมัติก่อนที่จะส่งมอบอะไรที่เหลือให้ได้ ประมาณนี้ครับ

สร้างกระบวนการที่ดี

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

จากประสบการณ์ครับ คร่าวๆกับกระบวนการ Review เราควรจะมี

1. กำหนดบทบาทที่ชัดเจนของคนที่เกี่ยวข้องก่อนครับ อย่างน้อยต้องมีสามกลุ่มนะ หนึ่งคือเจ้าของเอกสาร (Author) สองคนอ่าน (Reviewer) และสามประธาน (ดูเวอร์มั้ย ฮ่าๆ) ก็คือคนกลาง (Moderator) ที่จับคนสองกลุ่มแรกมาเจอกันและอำนวยความสะดวกให้กระบวนการเดินไปได้
2. Kick-off Meeting หรือประชุมเพื่อเริ่มงาน คล้ายๆกับเป็นการนำคนที่เกี่ยวข้องกับเอกสารฉบับนี้เข้ามานั่งคุยกัน เป็นการแจ้งให้ทราบว่าเราจะเริ่ม Review แล้วนะ กำหนดการเป็นแบบนี้นะ เริ่มวันนี้ เสร็จวันนี้ เนื้อหาคร่าวๆในเอกสารมีอะไรบ้าง จุดสำคัญที่ควรเน้นเป็นพิเศษคืออะไร เป็นต้น
3. ให้เวลาคนอ่านไปอ่านเอกสารตามที่ได้กำหนดไว้ครับ
4. Peer Review Meeting เป็นการประชุมเพื่อพูดคุยถึงผลที่ได้จากการ Review ครับซึ่งคนทั้งสามกลุ่มต้องมีส่วนร่วม เรื่องราวเป็นแบบนี้ครับ คนอ่านนำส่วนที่คิดว่าไม่ถูกต้องในเอกสารมาบอกคนเขียน ถ้าคนเขียนคิดว่า “เอ้อ ผิดจริงหวะ” ก็ให้แก้ไป ถ้าคนเขียนคิดว่าไม่ผิดก็ให้คนเขียนอธิบาย แล้วมาหาข้อตกลงร่วมกันครับว่าจะแก้หรือไม่แก้ในจุดนี้
5. ให้เวลาคนเขียนไปแก้เอกสาร
6. คนกลางต้องตรวจสอบครับว่าเอกสารฉบับใหม่ได้แก้ไขทุกจุดที่ตกลงกันไว้แล้วหรือไม่ ตรงนี้ไม่ต้องมีประชุมแล้วนะครับ เสียเวลา
7. เมื่อทุกอย่างครบถ้วนก็โอเคครับ ส่งขออนุมัติเอกสารได้

อีกเรื่องที่สำคัญคืออย่าลืมติดตามงาน (Tracking) ด้วยนะครับ งาน Review เป็นงานที่น่าเบื่อ ไม่ค่อยมีใครอยากทำ โอกาสที่งานจะไม่เสร็จทันเวลามีสูงครับ

ลูกค้า ลูกค้า ลูกค้า

เรื่องใหญ่ยักษ์ทีเดียว สาเหตุที่วิเคราะห์ไว้มีอะไรบ้างนะ? ไม่มีแรงจูงใจ ไม่อยากรับผิดชอบ งานยุ่งจริงๆ ต่อต้านการเปลี่ยนแปลงครั้งนี้ หรือเพราะคนที่เกี่ยวข้องมีมากเกินไป โอเคครับ ทีละข้อ … คิดไปคิดมาทีละข้อไม่ได้ครับ ผมมองว่าสี่ข้อแรกเป็นเรื่องที่ใกล้เคียงกันคือลูกค้าไม่ยอมทำงานให้เรา จัดการตรงนี้ก่อนดีกว่า

หนึ่ง … อย่างแรกระวังกับดับที่ว่า “โอเคคุณไม่ว่าง เดี๋ยวเราทำให้” ไม่ว่ากับงานอะไร เราไม่ควรแก้ปัญหาด้วยวิธีนี้ครับ เดี๋ยวลูกค้าจะติดนิสัย (ฮ่าๆ) มาสร้างแรงจูงใจในการทำงานให้ลูกค้าดีกว่าครับ

• การจัด Kick-off Meeting ก็เป็นอีกทางหนึ่งที่ช่วยได้ครับ เหมือนเป็นการกระตุ้นและสร้างแรงจูงใจที่ดีให้ลูกค้านะครับ เราควรใช้ประโยชน์จากการประชุมนี้ให้เยอะๆด้วยการชี้ให้เห็นถึงประโยชน์ของการ Review เอกสารต่างๆ เช่น User Manual จะช่วยให้คุณทำงานได้อย่างถูกต้องและใช้งานระบบได้อย่างเต็มประสิทธิภาพ รวมถึงประโยชน์ในอนาคตถ้ามีพนักงานใหม่ๆเข้ามาทางบริษัทก็ไม่ต้องใช้เวลาสอนงานมาก อะไรประมาณนี้ครับ

• ถ้าผมเป็นลูกค้าแล้วต้องอ่านเอกสาร 3-4 ฉบับ รวมๆแล้วเป็นร้อยๆหน้า ผมก็ไม่อ่านฮะ งานประจำก็เยอะอยู่แล้วเจอแบบนี้ก็ไม่ไหวเหมือนกัน บางครั้งเราก็ต้องเข้าใจลูกค้าด้วย น้ำพึ่งเรือเสือพึ่งป่าครับ ผมมองว่าเราควรแบ่งงานให้เป็นส่วนย่อยๆ (วิธีนี้ยังใช้ได้ดี) เราอาจจะไม่จำเป็นต้องให้ทุกคนอ่านทุกหน้าของเอกสารครับ แบ่งกันอ่านได้ครับ ลูกค้าคนแรกอ่านฉบับนี้ หน้าหนึ่งถึงห้าสิบ ลูกค้าอีกคนก็อ่านอีกส่วนหนึ่ง แล้วก็ไม่จำเป็นว่าเอกสารทุกฉบับต้องเริ่ม Review พร้อมๆกันด้วยนะครับ ขอแค่วางแผนให้ชัดเจนว่าจะฉบับไหนก่อนหลัง เมื่อเสร็จแล้วก็ขออนุมัตืไปทีละฉบับก็ได้

• คอยอยู่ช่วยเหลือ ตอบคำถามของลูกค้าอย่างใกล้ชิดด้วยครับ ตรงนี้ก็ต้องเสียสละนิดนึงนะครับเพื่อสร้างความรู้สึกที่ดีให้ลูกค้า บางครั้งคำพูดแค่ว่า “มีอะไรถามได้ เรียกได้ตลอดนะครับ” ก็ช่วยเยอะนะ แต่พูดแล้วต้องอยู่ให้เรียกด้วยนะฮะ ฮ่าๆ

สอง … มีคำแนะนำที่ดีมากจาก Bennet P. Lientz และ Lee Larssen ว่าจากประสบการณ์ของเค้าสองคนบอกว่าเราควรจำกัดการมีส่วนร่วมของลูกค้าอาวุโส (Senior User) ครับ อันนี้เห็นด้วยเลยครับ เคยได้ยินคำพูดนี้มั้ยครับ

One specialist is good, more than one is disaster.

“การมีผู้เชี่ยวชาญหนึ่งคนนั้นดี แต่ถ้ามีมากกว่าหนึ่งนั่นมันหายนะชัดๆ” จริงครับเพราะว่าท่านๆเหล่านี้จะรู้เยอะ รู้มาก และมั่นใจในตัวเองแบบสุดๆ โอกาสจะเกิดปัญหาที่ว่าคนนึงบอกว่าเอกสารนี้ถูกแล้วแต่อีกคนบอกว่าผิดๆ แล้วไม่มีใครยอมใครซึ่งการเถียงกันเองแบบนี้ทำให้งานเราไม่เดินหน้าไปไหนครับ

สาม … เห็นด้วยครับว่าการไปพูดคุยกับหัวหน้างานของลูกค้าเป็นทางเลือกที่ดี แต่มีคำแนะนำนิดนึงครับว่าอย่าไปพูดเรื่องข้อบกพร่องของลูกน้องเค้าหละ เช่น ไม่รับผิดชอบ ไม่ให้ความร่วมมือ ไม่สนใจทำงาน อะไรแบบนี้ครับ หัวหน้าส่วนใหญ่จะไม่ค่อยเปิดใจรับฟังเรื่องพวกนี้ซักเท่าไร และจะลงเอยด้วยการปกป้องลูกน้องจนลืมเรื่องงานไปซะหมด ทางที่ดีเราควรคุยในมุมที่ว่าคนทำงานไม่พอ (Resource Issue) จะดีกว่าครับ

สี่ … แต่ถ้ากลับกลายเป็นว่าคนที่ไม่ให้ความสนใจกับงานนี้คือหัวหน้างานซะเองหละ? โห เหนื่อยหน่อยครับอันนี้ สาเหตุอาจจะเป็นเพราะหัวหน้าคนนี้ไม่อยากให้งานนี้สำเร็จ เค้าไม่อยากเปลี่ยนแปลงอะไรๆที่ทำอยู่แล้ว เป็นต้น ปัญหานี้มีคำแนะนำสองทางครับ หนึ่งมองหาความช่วยเหลือจากลูกน้อง (ลูกค้า) ถ้าเรามีความสัมพันธ์ที่ดีกับพนักงานระดับล่าง เราก็อาจจะขอความร่วมมือในการพูดคุย (จริงๆก็กดดัน) ให้หัวหน้าเค้าหันมาให้ความสนใจกับงานนี้มากขึ้น คล้ายกับว่าเราคนนอกครับ ให้คนในเค้าจูงใจกันเองอาจจะง่ายกว่า สองถ้าทั้งหัวหน้าและลูกน้องเป็นพวกเดียวกันหละ? (ให้มันยากขึ้นมาอีก ฮ่าๆ) เราอาจจะต้องเข้าหาหัวหน้าและทีมงานกลุ่มอื่นเพื่อขอความช่วยเหลือแล้วหละครับ ลองอ่านดูครับ ปัญหาการเมืองต้องแก้ด้วยการเมือง

เผื่อเหลือเผื่อขาดไว้ครับ ในกรณีที่เราในฐานะ (Project Manager) แก้ปัญหานี้ไม่ได้เพราะคุยกับทั้งลูกค้าและหัวหน้าของลูกค้าไม่รู้เรื่อง เราควรแจ้งเรื่องนี้ให้หัวหน้าเราเองรับทราบไว้ครับ บางครั้งอาจจะต้องให้คนใหญ่คนโตเค้าคุยกันเอง

ทั้งหมดนี้ก็เป็นความคิดเห็นของผมที่มีต่อปัญหานี้ครับ อาจจะไม่ครบถ้วนทุกมุมมอง แนวทางแก้ไขบ้างข้ออาจจะถูกใช้แล้ว หรือบางข้ออาจจะใช้ไม่ได้เลย ฮ่าๆ ไม่เป็นไรครับ รบกวนคุณ jojoe บอกด้วยครับว่าสมมติฐานผมผิดตรงไหนรึเปล่า เดี๋ยวมาคิดหาแนวทางอื่นๆให้ครับ หวังว่าเพื่อนๆคนอื่นจะมีทางออกมาให้พิจารณาอีกนะครับ

ปล. อ้อ … เรื่องที่ต้อง Print เอกสารเยอะแยะเนี่ยะ อาจจะต้องทำใจนิดนึงครับเพราะอ่านเอกสารผ่านคอมพิวเตอร์มันลำบากจริงๆนั่นแหละ แต่ถ้าเรามีกระบวนการที่ดีน่าจะช่วยประหยัดได้นะครับ ตรวจสอบเอกสารให้เรียบร้อย -> เลือกคนที่จะ Review -> Print เฉพาะส่วน -> อ่านรอบเดียว -> แก้รอบเดียว -> ขออนุมัติ

ขอให้ผ่านปัญหานี้ไปได้ด้วยดีครับ