มุมมองของ Dev อยากได้อะไรจาก Support

หลายครั้งที่ดูงาน MA ในฝั่งของ Dev เองที่เป็นส่วนสุดท้ายที่ได้รับงานจาก Support มาแล้ว อย่างที่ บ ผม Support แยกเป็น 3 Tier App CS> Senior CS และสุดท้าย Developer นั้นเองครับ แต่การทำงานจริง Forword เมล์แบบไม่มีข้อมูลอะไรเลยมาแทน หรือไม่ดองจนวินาทีสุดท้ายที่ลูกค้าไม่จ่าย MAแล้วส่งต่อ อันหลัง ถ้าผ่านมาหลายเดือนและ หลักฐานพวก Log อะไรหายไปหมดแล้ว หรือคนที่แจ้งย้ายหน่วย อาจจะเสียชีวิตไปแล้วก็มีนะ

ทางผมเองได้มีปรับ App และ Pattern มาให้ 2 Tier ก่อนหน้าให้ความเมตตาในการขอข้อมูลเตรียมไว้ หรือ กรอกไว้ เพื่อช่วยทาง Support Tier App CS > Senior CS สอบถาม End User (ลูกค้า) เพื่อลด Ticket Ping-Pong / Ticket Dancing / Mail Loop ส่งถามกันไปกันมา กว่าจะเข้าสาระอีกที 20-30 Hop และรอกันไปมา จนลูกค้าหงุดหงิด โดย Pattern ของผมจะประมาณนี้ครับ

Pattern ในการเตรียมข้อมูลส่งให้ Developer

- Step Action / Step to Reproduce

• ฝั่ง APP ต้องมีการลง Log / Trace ไว้ และมี Glossary บอก Code ต่างๆในระบบ เพื่อให้ Support หาข้อมูล แล้วตอบได้ก่อนเลย หรือใช้ AI มาตอบได้
• ฝั่ง Support ต้องลองถาม ขอข้อมูลที่ app เตรียมไว้ และ สรุปขมวดจาก End User (ลูกค้า) ว่ามี Action อะไรกับระบบบ้าง 1 2 3 4 และเกิดปัญหาข้้น

สิ่งที่ควรถามเพิ่ม

• ทำซ้ำแล้วเกิดขึ้นไหม หรือ ไม่เกิด (อันนี้ต้องคุย Step อีกที ถ้าคุยแล้ว จะเป็นเรื่องของ Race Condition แล้ว)
• ใคร ทำอะไร ที่ไหน และเวลาอะไร ตรงนี้มันจะช่วยในการตรวจสอบ Log เอา มาFilter ได้ครับ

เมื่อพอได้ Setup แล้ว ทาง Support เองสามารถลอง Proof ได้ หรือ ได้ Keyword ค้น KM ข้างในองค์กร / Glossary บอก Code ต่างๆในระบบ

- อะไรที่ผิด (Actual Result) / ที่ถูก คือ อะไร (Expected Result)

• หลายครึ่งผมจะเจอ Support บอกว่ามันผิด ลูกค้าแจ้งมา ตัดจบไปแบบงงๆ ทาง Dev มาตรวจสอบ Unit Test และ Spec อ้าว มันถูกตาม Spec นี่ .............. และเกิด Ticket Ping-Pong วนไปถามกลับ
• ใช่ครับสิ่งที่ Support ต้องลองถาม ที่ถูก คือ อะไร เพราะว่า ถ้าทาง Support หรือ Dev ลองตรวจแล้ว มีอะไรผิดปกติ จะได้ปรึกษากับ Domain Expert ในองค์กรได้ / KM ข้างใน โดยอิงกับ ที่ถูก คือ อะไร (Expected Result) มันจะมี 2 แบบ
  - New Case
  - ลูกค้าเข้าใจผิด

- Environment ที่เกิดปัญหา

• ข้อมูลส่วนนี้สำคัญนะครับ Device / OS ฝั่ง
  - APP ที่ผมทำ ตอน Error มันจะออก Log มาเก็บไว้เลย Environment ในวันนั้น Device / OS ได้ อันนีี้ อาจจะต้องแจ้ง IT ลูกค้า เพื่อขอ Log ออกมา
  - Support เองสามารถลองลูกค้าได้เหมือนกัน
• จากประสบการณ์จริงเคยเจอเคสที่ Windows 7 พัง และ Windows 8.1 / 10 / 11 ไม่พัง ถ้ามีข้อมูลส่วนนี้ Support สามารถทดสอบได้ก่อนได้

- Log File จากระบบ

• ฝั่ง APP Implement ได้หลายแบบเลย อย่างที่ผมทำ
  - Console.log >> ERROR CODE ออกมา
  - PopUp >> ERROR CODE ออกมา
  - Trace Log
  - Error Log >> เก็บช่วงที่ Error จะได้รู้เวลา + Stack Trace ช่วงนั้น
• นอกจาก APP เตรียมไว้แล้ว การประชาสัมพันธ์มีส่วนด้วยครับ ของผมทำ Wiki และแปะใน Transfer Slide
• สุดท้าย เหลือแต่ทาง Support ติดต่อขอข้อมูล Log มา

- เวอร์ชั่นที่ผิด / เวอร์ก่อนหน้า ถูกไหม ?

• ฝั่ง APP ต้องบอก VERSION โดยอาจจะขึ้นที่ title bar หรือ สักมุมของหน้าจอ
  อย่างงานที่ผมทำระบบ Internal แสดงที่ตัว title bar หรือ อาจจะลงเป็น Log ไว้
• อันนี้เป็นคำถามแรก ที่ Developer อยากได้ เพราะ จะได้ไปค้นหา Tag ของ Code ได้ เพื่อมาลองทดสอบ และ Debug อีกที จำได้ว่ามีเคสนึงไม่ได้ข้อมูลส่วนนี้ Dev ไล่ลองไล่ย้อนไป 8-9 Tag ถึงเจอว่า Error ที่เวอร์ชันไหน

- จุดสังเกตุอื่นๆ

• อาจจะต้องลองถามบริบทอื่นๆของลูกค้าช่วงนั้นด้วย จะได้เสริม สร้าง Value เช่น ลูกค้า คนออกเยอะได้ user ใหม่มาใช้ เราอาจจะแจ้งทีมได้ เพื่อที่จะหาทางป้องกันจาก App หรือ สอนลูกค้าเพิ่มให้เข้าใจระบบลดภาระเราเองในอนาคต

สุดท้ายเน้นย้ำว่า App ต้องช่วยให้ Support ง่าย 30% อีก 70% ที่เหลือเรื่องคนล้วน และ Process ที่ต้องซึมซับ และ Improve ครับ