พอดีเห็นโพสของ KongRuksiam Studio เลยนึกได้ว่าหลายปีก่อนมีเรื่องเคสคล้ายกับ Meme นี้ เลยคิดว่า เอามาจดลง Blog ไว้ดีกว่า
เพราะมันเป็นประสบการณ์ตรงที่เจอมาเหมือนหลายปีก่อน ที่เกือบทำให้โปรเจกต์เกือบ 20 ล้านพัง เพียงเพราะการรับปากมั่วๆ และความพยายาม "ลักไก่" ของ User ครับ เลยมาแชร์ บันทึกไว้ครับ
ในโลกของการทำ Project IT ช่วงที่บีบที่สุดคงหนีไม่พ้นช่วง UAT (User Acceptance Test) เพราะมันคือด่านสุดท้ายก่อนปิดงาน แต่จะทำอย่างไร? ถ้าด่านนี้ไม่ได้สู้กันด้วยหลักฐาน หรือ Test Script แต่สู้กันด้วย "คำขู่" และ "ข้อมูลเท็จ" อย่างเคสของผมจะ Migrate ระบบจาก AIX > Linux
จุดเริ่มต้น: "ทำไมไม่มีปุ่ม Approve ใน Email?"
เหตุการณ์เกิดขึ้นกลางห้อง UAT เมื่อ User ท่านหนึ่งโวยวายหนักว่า ระบบส่ง Email แจ้งเตือนมันใช้งานไม่ได้จริง เพราะหัวหน้าเขาต้องกดปุ่ม Approve ได้ทันทีจากในเมล พร้อมมีตารางข้อมูล 1 2 3 4 แสดงให้ครบถ้วน
พอเราชี้แจงตาม Requirement ว่า "Feature นี้ไม่มีอยู่ในขอบเขตงานครับ และใน Software เดิมก็ไม่สามารถทำได้ มันแจ้ง Information อย่างเดียว" สิ่งที่ได้รับกลับมา คือ เหวี่ยง ขึ้นเสียง และประโยคไม้ตาย:
"ก็ Support บ. น้อง ยืนยันกับพี่ในเมล์แล้วว่าทำได้!
ถ้าไม่ทำคืนมา พี่ไม่เซ็นผ่าน และจะยกเลิกสัญญา MA ทั้งหมดด้วย!"
ความกดดันจาก "User อีกท่าน" ที่บอกให้ "ยอมๆ ไปเหอะ"
ในสถานการณ์นั้น User อีกท่านบอกว่า "รับๆ ทำไปเถอะ จะได้จบๆ" และ พี่ PM บอกทำนองนี้เหมือนกัน แต่ทว่านี่คือ กับดักที่อันตรายที่สุด เพราะถ้าเรารับปากในสิ่งที่ไม่มีอยู่จริง นอกจากเราจะต้องแบกงานเพิ่ม (Scope Creep) เรายังกลายเป็นคนผิดที่ทำของเดิม "หาย" ไป ทั้งที่มันไม่เคยมี !!!
ที่พีคกว่านั้นคือตัวต้นเรื่องอย่างฝ่าย Support ที่ไปรับปากไว้ดันใช้มุก "พี่ไม่ได้ตอบ" ทั้งที่ลูกค้าเปิดเมล์โชว์กลางที่ประชุมเลย แอบกระชิบพี่ท่านนี้คดีเก่าๆของแกจะตอบลูกค้าแนวนี้จนมีประเด็นที่ลูกค้าขู่ไม่ต่อ MA มูลค่า 21 ล้าน + Project อีก 25 ล้านที่กำลังคุยๆกันมาแล้วด้วย
ตรวจสอบหลักฐานจากระบบ
เมื่อโดนบีบจนสุดทาง ผมตัดสินใจใช้ไม้แข็ง ขอเข้าไปตรวจสอบ E-mail หัวหน้าเขาต้องกดปุ่ม Approve ได้ทันทีจากในเมล พร้อมมีตารางข้อมูล 1 2 3 4 แสดงให้ครบถ้วน และจะถ่าย VDO เพื่อไปเป็นหลักฐาน User นี้แจ้งว่ามีจริง และเอาไปประกอบการขอ Change Request จากทาง CEO
ผลลัพธ์ User ท่านนั้นรีบเข้ามาขวางไม่ให้ไปพบหัวหน้า เพิ่งมารู้ตอนหลังตำแหน่งผู้อำนวยการ และแจ้งว่าพี่ไม่เอา Feature นี้แล้ว อย่าไปรบกวนหัวหน้าพี่เลย ความจริงคือไม่มี Email ฉบับนั้น หรือมันอาจจะเป็นการตกลงกันเองหลังบ้านที่ผู้ใหญ่ไม่รู่ ถ้าตอนนั้นผมไปขอเข้าพบ และตรวจสอบ Email น่าจะมีประเด็นยาวกับทาง User ที่จุดประเด็น)
จากเรื่องนี้ เราพบว่า
- Product Knowledge - การเข้าใจ Product ที่เราทำสำคัญมากๆ ถ้าเราไม่รู้ Feature เดิม และข้อจำกัด อาจจะโดน User หลอกได้ง่ายๆ เอาจริงๆถ้าเรารู้ระบบเราทำอะไรได้หรือไม่ได้ จะช่วยให้คุณนิ่ง พอที่จะไม่ตกเป็นเหยื่อของการข่มขู่ แบบ Case Call Center เลย
- หน้าที่ของเราคือ Protect Scope - ไม่ใช่รับทุกอย่างเพื่อซื้อเวลา เคสนี้เราต้องป้องกันทีม และองค์กร มันจะวนกลับไปข้อแรก ถ้าเราเข้าใจ Product มากพอ มีสติ รับมือกับปัญหาได้
- การสื่อสารต้องมี Traceability - ก่อนจะ Confirm อะไรกับลูกค้า ต้องคุยกับทีมให้จบ และต้องมีหลักฐานเป็นลายลักษณ์อักษรเสมอ อย่าใช้แค่คำพูด เพราะในวันที่เกิดปัญหา "คำพูด" จะปลิวหายไป แต่ "Email" หรือ "Document" จะเป็นสิ่งที่ช่วยชีวิตคุณ และที่สำคัญ อย่าตอบเมล์คนเดียว เคสนี้ทีมหน้างานก็อึ้ง เพราะ User มีหลักฐานจริง
- Support & Sales ต้องเป็นทีมเดียวกัน - การรับปากมั่วซั่ว (Over-promising) เพื่อเอาตัวรอดของฝั่ง Support สร้างความเสียหายระดับหลายล้านบาทได้
- อย่ารับปากเพียงเพราะรำคาญหรืออยากให้จบ: การที่ User + เพื่อนร่วมงานบอกว่า "รับๆ ไปเถอะ" คือจุดเริ่มต้นของนรก (Technical Debt & Scope Bloat) ถ้ามีปัญหาขึ้นมา คนที่เชียร์เค้าไม่ได้ออกมา Support เรา เราซวยเลยนะ กลายเป็นต้องรับ Damage จากผู้ใหญ่แทน
ในโลกการทำงาน บางครั้งเราอาจจะไม่ได้คำขอโทษจากคนที่ก่อเรื่อง แต่สิ่งที่เราจะได้คือ "ภูมิคุ้มกัน" และ "ความน่าเชื่อถือ" จากผู้ใหญ่ที่เห็นว่าเรารักษาผลประโยชน์ของบริษัทได้จริงๆ
Discover more from naiwaen@DebuggingSoft
Subscribe to get the latest posts sent to your email.
