Expectation of problem solving

ความคาดหวังกับการแก้ปัญหา ทำไมลูกค้าแจ้งปัญหาแล้วคาดหวังว่าจะได้รับการแก้ไขโดยไม่ต้องอธิบาย
 
ในการสนทนาเพื่ออัพเดทความคืบหน้าของงานสัปดาห์นี้ ก่อนจบมีหัวข้อเกี่ยวกับงานค้างสองงาน ที่สรุปไว้ว่า "รอข้อมูลเพิ่มเติม" ส่วนเรื่องราวที่ได้รับทราบจากคำบอกเล่า เป็นที่น่าสังเกตว่าทั้งสองเหตุการณ์คล้ายกัน ได้สอบถามขอรายละเอียดเพิ่มเติมแล้ว แต่ผู้แจ้งปัญหาไม่ยินดีอธิบาย ตอบกลับมาในทำนองว่า ทางผู้ให้บริการควรหาทางจัดการเอง
 
ปกติแล้วงานของทีมพัฒนาแบ่งเป็น 2 ด้าน งานสร้างและงานซ่อม
 
งานสร้าง เป็นการตั้งค่าและปรับคุณสมบัติ เพื่อให้โปรแกรมทำงานสอดคล้องกับการออกแบบระบบ ซึ่งแต่ละองค์กรจะมีรายละเอียดแตกต่างกัน
งานซ่อม ดูแลการใช้งานโปรแกรมให้ราบรื่น รวมทั้งการเก็บงานที่เป็นกรณีซับซ้อน ยังไม่ครอบคลุม หรือการทำงานภายใต้เงื่อนไขพิเศษ ที่พบเจอไม่บ่อย
 
จะเห็นว่า "งานสร้าง" เริ่มจากความเชี่ยวชาญโปรแกรมของทีมพัฒนาที่มีมากกว่าผู้ใช้ จึงออกแบบเตรียมระบบงานที่เหมาะสมได้ก่อนที่จะเริ่มทำงานจริง โดยไม่ต้องรอให้ร้องขอ แต่ในทางกลับกันเมื่อเริ่มทำงานไประยะหนึ่ง ผู้ใช้ก็อาจพบกรณีที่หลุดรอดจากการออกแบบ ทำให้การทำงานติดขัดหรือได้ผลลัพธ์ไม่ถูกต้อง ผู้ใช้จะรู้รายละเอียดจริงที่เกิดขึ้นมากกว่า อาจบอกได้ว่าเรื่องนี้ทำงานแตกต่างจากเรื่องอื่นอย่างไร จึงเป็น "งานซ่อม" ของทีมพัฒนา
งานค้างกรณีที่หนึ่งเป็นงานสร้าง ออกแบบงบการเงินใหม่ให้หัวหน้าสำนักงานบัญชี หลังจากส่งมอบให้ใช้งานไปแล้ว ได้รับแจ้งกลับมาว่า "ยังใช้ไม่ได้ ก็เลยไม่ใช้" เมื่อพยายามขอรายละเอียดว่าใช้ไม่ได้ตรงไหนบ้าง เพื่อจะได้ปรับปรุง ก็ได้รับคำตอบว่า งานยุ่ง ไม่มีเวลาอธิบาย คนออกแบบรู้จักโปรแกรมดีน่าจะรู้ว่าควรปรับปรุงอย่างไร
กรณีที่สองเป็นงานซ่อม ผู้ใช้แจ้งปัญหามา ว่าเจอโปรแกรมคำนวณตัวเลขมูลค่าสินค้าผิด เมื่อทีมพัฒนาลองสุ่มตรวจสอบกับสินค้าหลายตัวแล้วไม่พบ จึงสอบถามขอเบาะแสเพิ่มเติม ซึ่งได้รับคำตอบคล้ายกับกรณีแรก คนดูแลโปรแกรมน่าจะหาเจอได้เอง

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

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

ปัญหาที่ผู้ใช้แจ้งมาก็เป็นเช่นเดียวกัน บางครั้งรู้แต่ว่าผิดปกติ โดยที่ไม่สามารถอธิบายหรือชี้ชัดได้ เพราะไม่เข้าใจกลไกโปรแกรม ยิ่งโดนซักถามด้วยคำศัพท์ทางเทคนิคก็ยิ่งสับสน พาลหงุดหงิด ควรระมัดการสื่อสารด้วยภาษาเฉพาะทางกับผู้ใช้ การอธิบายไม่ได้อาจเกิดจากการตั้งคำถามที่ยากเกินไป
 
"ไม่คู่ควร"
 
คุณเป็นผู้เชี่ยวชาญโปรแกรม บางครั้งก็ลืมไปว่าบางเรื่องที่ง่ายสำหรับคุณ แต่กับคนที่ไม่เชี่ยวชาญอาจเป็นเรื่องยาก ถ้าคนคนนั้นถูกส่งมาเรียนเพื่อเอาไปถ่ายทอดให้ผู้ใช้คนอื่นต่อ หลังจากที่คุณพยายามแล้วพบว่าต้องเริ่มอธิบายตั้งแต่พื้นฐาน พลางนึกในใจว่าเรื่องง่าย (ในความคิดของคุณ) ยังไม่รู้ แล้วจะไหวเหรอ คุณจะมีความอดทนถึงเพียงใด สำหรับหัวหน้าสำนักงานบัญชี ที่ต้องอธิบายเรื่องบัญชีแล้วพบว่าแม้แต่พื้นฐานง่ายๆ คนที่คุยด้วยไม่เข้าใจ ก็คงรู้สึกเช่นนั้น งานยุ่ง เวลาน้อย จึงไม่อดทนพอที่จะคุยกับคนที่ไม่คู่ควร หากคนนั้นจะมาจากทีมพัฒนา แต่พื้นความรู้ห่างไกลจนตามไม่ทัน ย่อมไม่ได้รับความเชื่อถือ
ไม่ผิดที่ไม่รู้ แต่คนจากทีมพัฒนามักถูกคาดหวังไว้สูง หากต้องปะทะกับคนเก่ง อาจลดบทบาทมาประสานงาน ขอความช่วยเหลือจากคนอื่นหรือแจ้งหัวหน้าทีมที่สามารถรับมือได้ดีกว่า แต่ถ้าหาใครช่วยไม่ได้ ก็ต้องทำการบ้านค้นคว้าความรู้พื้นฐาน แสดงให้เห็นว่าพยายามพัฒนาตัวเองแล้ว

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


 
May 2022 / Sathit J.