ว่าด้วยลูกค้า API

หน้าที่การงานของผมคือเป็น API Support ด้วยชื่อตำแหน่งผมหวังว่าลูกค้าคนที่คุยด้วยจะเป็น Developer ที่เจอปัญหาตอนเขียน code ที่ใช้ API ผม หรือว่าลูกค้าของเขาเจอปัญหาแล้วเขาวิเคราะห์แล้วว่าเกี่ยวกับ code ของเขาที่เรียกใช้ API เรานะ

แต่โลกแห่งความจริงมันไม่ง่ายขนาดนั้น เอาเข้าจริงผมมีลูกค้าเป็น Dev แทบนับหัวได้เลย ส่วนใหญ่เป็นลูกค้าระดับ end user หรือ manager ที่ไม่รู้อะไรเลย หรือไม่ก็ sys-admin ซึ่งคิดว่าทุกอย่างแก้ด้วยการ config file เท่านั้น (ไม่ได้ว่า sys-admin ไม่ดีนะ มีใน loop ช่วยได้เยอะ แต่แบบ… มันไม่ใช่ทุกอย่างเปลี่ยนได้ด้วย config file ไง) ซึ่งเวลาทำงานกับลูกค้าพวกนี้จะเสียเวลามากกว่าจะได้ข้อมูลที่สำคัญๆ มา เพราะว่าเวลาส่วนใหญ่จะเสียไปกับการอธิบายให้เขาเข้าใจว่าปัญหาอยู่ที่ไหนและทำไมเราต้องการข้อมูลพวกนั้น + เวลาเขาจะไปคุยกับ Dev/Ops เขาแล้วมาตอบเราอีกที

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

น่าสังเกตุว่าปัญหานี้เกิด API สำหรับภาษา Java เป็นส่วนใหญ่ แต่กับ JavaScript API อีกตัวที่ผมดูแลนั้นลูกค้าที่ติดต่อเข้ามาเป็น Dev ที่เขียน Code ที่กำลังเจอปัญหาจริงๆ ซะส่วนมาก~

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

ปัญหาในมุมของ Support กับมุมของลูกค้า

2 – 3 อาทิตย์ที่ผ่านมาผมรับ issue server ตัวนึงที่ผมต้องดูแล (โดยไม่ได้ตั้งใจ) สิ่งที่ลูกค้าเจอ server ตัวนั้นไม่ปล่อย data ให้ลูกค้าเจ้านึง ลูกค้าบอกมาด้วยว่า software อีกตัวของบริษัทผมที่ต่อคนละ infrastructure กันเลย มันได้ data นะ

ผมใช้เวลาประมาณ 2 อาทิตย์ในการค้นพบว่า นอกจากลูกค้าจะ config backend ตัวนึง (ซึ่งเป็น server อีกตัวของบริษัทผม) ผิดนิดหน่อย ไอ้ backend ตัวนั้นยังส่ง data มาช้าไปถึง 15 นาทีหรือบางทีก็ไม่มาเลย เพราะ data source บอกว่าไม่มีข้อมูลนี้ ซึ่งทุกอย่างที่ลูกค้าเจอ ผมก็ replicate ปัญหาได้ใน environment ของผมหมด (เพราะสุดท้ายต้นตอของ data ก็มาจากที่เดียวกัน)

ในอาทิตย์ที่ผ่านมา ผมพยายามจะบอกลูกค้าว่า server ของผมไม่ผิดอะไร แล้วไอ้ software ตัวนั้นคุณต่อยังไง จนกระทั่งวันนี้ได้ email จากลูกค้าว่า

“กูรู้ว่า server มึงกับ software ตัวนั้นมันไม่เหมือนกัน มึงควรจะหันมาสนใจกูสักทีว่าทำไม backend ของ server มึงไม่ส่ง data มา มึงก็ replicate ปัญหาได้เองนี่ จะคอยถามกูทำไม มึงนี่ไม่พยายามจะเข้าใจกูเลย ” (จริงๆ เป็นภาษาอังกฤษนะ)

อ่านแล้วจุก แต่ก็จริงอย่างที่ลูกค้าว่า เพราะผมมัวเอาแต่สนใจปัญหาว่าที่ server ของผม จนลืมไปว่าสำหรับลูกค้าน่ะเขาไม่มองเจาะเป็นตัวๆ หรอก แต่เขามองรวมๆ ว่า “ระบบของบริษัทนี้มันไม่ส่ง data มา” ความจริงผมเองก็ควรจะส่งเรื่องให้ทีมที่ support backend, data source ไปตั้งนานแล้วว่าทำถึงไม่ส่ง data มา

ในแง่เฉพาะ support product ผม โอเค ผ่าน แตในแง่ support ลูกค้าแล้วถือว่าสอบตกเพราะยังไม่ได้แก้ปัญหาอะไรให้ลูกค้าเลย เอาแต่ปกป้องตัวเองว่าไม่ผิดท่าเดียว ผมควรจะมองปัญหาที่แท้จริงที่ลูกค้าเจอให้ออกว่าคืออะไร (กรณีนี้คือระบบของบริษัทผมมันไม่ส่ง data มา , ไม่ใช่ server ตัวนี้มันไม่ส่ง data)

นี่ก็เป็นอีก 1 บทเรียนที่ผมได้ในปีที่ 11 ของการทำงาน

What am I?

I am a stupid IT support who don’t use TDD, Agile or Scrum. I do only write an email to client, read and debug code. What a shame.

ผมมันโง่ไม่อยู่ใน agile ผมมันโง่ไม่อยู่ใน agile ผมมันโง่ไม่อยู่ใน agile ผมมันโง่ไม่อยู่ใน agile ผมมันโง่ไม่อยู่ใน agile

ผมมันโง่ไม่อยู่ใน scrum ไม่ได้เขียน code ผมมันโง่ไม่อยู่ใน scrum ไม่ได้เขียน code ผมมันโง่ไม่อยู่ใน scrum ไม่ได้เขียน code

ผมผิดเองแหละ ผมผิดเองแหละ ผมผิดเองแหละ ผมผิดเองแหละ ผมผิดเองแหละ ผมผิดเองแหละ ผมผิดเองแหละ ผมผิดเองแหละ ผมผิดเองแหละ ผมผิดเองแหละ