ใครคือ Technical Product Support ที่ดีที่สุดของคุณ?
Who Knows and Understands The Most About Your Products?
The Way It Is
บริษัทที่ผลิตหรือขายซอฟต์แวร์ส่วนใหญ่จะมีกลุ่มคนที่สร้างซอฟต์แวร์ ขอเรียกรวมๆว่า Developer และกลุ่มคนที่ซัพพอร์ตซอฟต์แวร์ ขอเรียกว่า Customer หรือ Product Support โครงสร้างและลำดับขั้นมักเป็นแบบนี้
พวกเค้าก็คิดว่า แฮ่ๆ กับงานซัพพอร์ตนี่แหละมีประสิทธิภาพดีแล้ว แบ่งงานกันชัดเจนแล้ว … ผมว่าผิด
The Way It Should Be
ทำไมถึงคิดว่าผิด เหตุผลสองข้อครับ
- ผมมีความเชื่อว่าคนที่มีความรู้และความเข้าใจในโปรดักส์ในซอฟต์แวร์ของตัวเองดีที่สุดก็คือคนที่สร้างมันขึ้นมา … ใครเป็นคนสร้างล่ะ ก็ Developer ไง แล้วทำไมเราถึงไม่ให้คนที่รู้ดีที่สุดทำงานที่จะได้ใช้ความรู้ที่เค้ามีอย่างเต็มที่ ทำไมต้องมีคนอีกกลุ่มมารับงานที่เค้าไม่ได้มีส่วนร่วมสร้างมาตั้งแต่ต้น ความรู้ความเข้าใจมันเทียบกันไม่ได้อยู่แล้ว ไม่ใช่คนที่ทำงาน Support ไม่เก่งแต่มันเป็นการใช้คนไม่ถูกงานและไม่เต็มประสิทธิภาพ
- การทำงานที่มีลำดับขั้นมากมีแต่ก่อปัญหา ทั้งความล่าช้าในการจัดการปัญหาของลูกค้า ความผิดพลาดในการสื่อสารกันระหว่างทีม ความขัดแข้งกันของคนที่ทำงานซัพพอร์ตและคนที่ทำงานพัฒนา
จากการวิเคราะห์ของตัวผมเอง … ที่มันเป็นแบบรูปข้างบนเพราะเหตุผลที่ฟังไม่ขึ้นแบบนี้
- Developer ไม่ค่อยมีทักษะเรื่องพูดคุยสื่อสารกับลูกค้า — ผมสงสัยว่า อ่าวทำไมหละ Developer พูดภาษาคนไม่รู้เรื่องหรอ? พูดได้คุยได้แต่ไม่อยากพูดมากกว่ารึเปล่า? หัดสิ ฝึกสิ มีแต่ผลดีกับตัวเองทั้งนั้น
- Developer ไม่มีสิทธิเข้าถึงข้อมูลใน Production Environment — ทำไมไม่มีสิทธิหละ เพราะ Developer ไม่น่าไว้ใจ เชื่อใจไม่ได้งั้นหรอ? ไร้สาระน่า คุณเอาอะไรมาวัดเรื่องพวกนี้ ด้วยสาเหตุนี้เลยต้องตั้งทีม Production Support กลุ่มคนที่คุณคิดว่าไว้ใจให้สิทธิเข้าถึง Production Environment ได้ขึ้นมา ไม่สมเหตุสมผลอย่างรุนแรงเลย ยิ่งทำให้งานช้าขึ้นไปอีก Developer อยากได้ข้อมูลอะไรมาใช้ในการวิเคราะห์ปัญหาก็ต้องรอคนอื่นไปหามาให้ เพื่ออะไร?
- Developer ต้องพัฒนาโปรดักส์เวอร์ชั่นใหม่ไม่มีเวลาให้เรื่องซัพพอร์ต — นี่เป็นการดึง Developer ให้ออกห่างโลกปัจจุบันซึ่งก็คือปัญหาที่เจอจากโปรดักส์ที่เค้าทำ นอกจากไม่เข้าใจว่าปัญหาคืออะไรแล้ว ความรู้สึกรับผิดชอบและความเป็นเจ้าข้าวเจ้าของในผลงานที่เค้าทำก็น้อยซะเหลือเกิน ก็จะคิดอะไรมากล่ะ มีคนรับหน้าให้ตั้งหลายด่าน กว่าจะถึงตัวเองลูกค้ากับหัวหน้าก็หมดแรงด่าแล้ว ฮ่าๆ การให้ปรับปรุงโปรดักส์ให้ดีขึ้นไม่ได้แปลว่าต้องออกโปรดักส์เวอชั่นใหม่เสมอไป และถ้าเราให้ความสำคัญกับลูกค้าอย่างสูงสุดจริงตามที่โม้ไว้ ปัญหาที่ลูกค้าเจอต้องมีความสำคัญกว่างานพัฒนาเวอร์ชั่นใหม่ครับ
ผมมีความเชื่ออย่างหนักแน่นว่า คนที่จะเป็น Product Support ได้ดีที่สุดก็คือ Developer คนที่เป็นผู้สร้างโปรดักส์ตัวนั้นออกมา ถ้าเลือกได้ผมจะสอดแทรก (แกมบังคับ) ให้ Developer ของผมทุกคนรับหน้าที่นี้ไปด้วยตั้งแต่วันแรกที่เค้าเริ่มงานเลย ผมเชื่อว่านี่คือการ Put The Right Man To The Right Job ซึ่งมันจะเพิ่มประสิทธิภาพในการทำงาน เพื่อความรู้ทักษะในด้านอื่นๆให้กับ Developer ของผม … ผมมองเห็นแต่ข้อดีของ
Developer is your best Product Support Engineer.
เหมือนหลายบริษัทระดับโลกที่มีขนาดไม่ใหญ่มากเค้าประยุกต์ใช้หลักการนี้ทำให้เค้าจัดการงานพัฒนาและซัพพอร์ตโปรดักส์ได้อย่างมีประสิทธิภาพมาก เช่น HubSpot มีแนวทางการทำงานแบบนี้ครับ
They [software development teams] have end-to-end responsibilities, including design, programming, testing, release, monitoring, and responding to production problems. They get operational information about the services they own — such as speed and errors — on a real-time dashboard, and they get customer questions and complaints.
ป.ล. ผมเขียนบทความนี้โดยคิดว่า Developer จะเป็นคนที่รู้จักโปรดักส์ตัวเองดีที่สุดนะ ถ้าไม่ใช่นี่ต้องพิจารณาตัวเองอย่างหนักเลย
ป.ล. ผมทราบครับว่ามันจะมีการจัดเทรนนิ่งเรื่องโปรดักส์ให้ทีม Customer และ Product Support อยู่เป็นระยะ … แต่ผมไม่เคยเห็นว่ามันจะได้เรื่องได้ราวเลยซักครั้ง สุดท้ายสองทีมนี้ก็เป็นได้แค่คนฟอร์เวิร์ดปัญหาต่างๆมาให้ Developer เห้อ มีแต่เสียกับเสีย
ป.ล. เคยได้ยินเทคนิคที่ว่า 70–30 มั้ย? ตัวเลขอาจจะเปลี่ยนไปนะ แต่ความหมายของมันคือ Developer จะทำงานเวอร์ชั่นใหม่ 70% ทำงานซัพพอร์ต 30% … บอกเลยตรงนี้ ไม่เวิร์ค!!! เพราะความจริงที่เกิดขึ้นคือทำงานเวอร์ชั่นใหม่ 110% และทำงานซัพพอร์ต -10% ฮ่าๆ … ผมว่าไม่ต้องแบ่งเป็นเปอร์เซ็นต์หรอก กำหนดไปเลยว่าถ้ามีปัญหาลูกค้าเข้ามาต้องหยุดงานไปแก้ไขทันที คำว่าหยุดงานไม่ได้แปลว่าต้องหยุดทุกคนแต่เป็นแค่บางคนที่เกี่ยวข้อง … คล้ายๆหลักการ On Call ของ Operation Team ครับ
ผมเขียนบทความนี้เพราะอยากเปลี่ยนแปลงสิ่งที่เป็นอยู่ในอุตสาหกรรมการผลิตซอฟท์แวร์ให้ดีขึ้นตามความเชื่อและประสบการณ์ของผม ถ้าเพื่อนๆเชื่อในแนวทางเดียวกัน เรามาช่วยกันคนละไม้คนละมือทำให้สังคมของเราดีขึ้นครับ จะแชร์บทความนี้ผ่าน Social Network หรือจะแบ่งปันเรื่องราวนี้ให้คนที่นั่งข้างๆฟังบ้างก็ได้
The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson
อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ
