KM มันควรสร้างตอนที่ยังอยู่ ไม่ใช่มาสร้างตอนที่จะลาออกไป

เนื่องจากน้องในทีมได้ลาออกทำงานที่อื่น แล้วมี Effect ที่แปลกมากถึงที่สุดเลย พอตอนน้องเค้ายังอยู่เวลามีเคสอะไร เรื่องซ้ำซาก แบบเดิม วนถามน้องเค้าไปเรื่อยๆ ผมเตือนให้ทำ KM หรือปรับคู่มืออะไรเพื่อป้องกันไม่ได้ทำกัน บ่นมาหลายรอบเลย ทั้ง CS / DEV

แต่พอน้องเค้าแจ้งลาออกแล้ว KM จาก DEV ผุดขึ้นเป็นดอกเห็ด แล้วถูกหรือป่าวก็ไม่รู้ เพราะเร่งทำกัน

ตอนยังอยู่ทำไมไม่ลองทำกัน ตอนที่จากไป ถึงสนใจมาทำ KM กัน

ทำไมต้องทำ KM

• มันเป็นสรุปไง ขมวดปัญหาที่อาจจะคุยกันเป็น 15-20 hop ตอบเมล์กันยาวเหยียด เพื่อให้หาเจอได้อย่างรวดเร็ว และเห็นว่า ROOT CAUSE เป็นยังไง แล้วการแก้ไขปัญหา ต่อทำอย่างไร ?
• ถ้า KM มันมี Pattern เป็นระเบียบ มันเอามาช่วยให้คนรุ่นหลังเข้ามาหา และปรับปรุงมันได้ (Contribute)
• เพิ่ม Bus Factor ด้วย ยิ่งรู้มาก รู้กันหลายคน ความเสี่ยงลดลงได้มาก เช่นกัน
• เมื่อ KM มีปริมาณมาก ยังเอาไปช่วยทำ Chatbot ได้ด้วยนะ ลดภาระไปอีก //ปัญหาที่เจอ ทุกคนอยากได้ Chatbot แต่ไม่มีใครยอมลง Effort ในส่วนนี้เลย

อ้าว เรามีระบบ Ticket นี้ หาเจอได้เสมอ Support ท่านนึงได้กล่าวไว้

• ปัจจุบันหาไม่เจอ เพราะไม่ได้สรุปไว้
• ปัญหาเดิมๆก็วน Loop เดิม หาไม่เจอส่งให้ Dev หาไป และโทษระบบซะงั้น

แล้วคำถามต่อไปเลยนะ ถ้าเคสใหม่หลังจากนี้ KM จะถูกสร้าง หรือ ปรับปรุงให้ล่าสุดไหม ?

หรือ เป็น KM เลือด ใครทำต้อง Update ไปตลอด

แนวคิดนี้วนกลับมาที่การทำ Test บางอย่างมันซับซ้อน เขียน Code เทพแหละเข้าใจ แต่ถ้าเราไม่อยู่แล้ว ใครจะมาไล่ไห้ ทำ Test กันเถอะ ครับ ตัว Test อธิบายการทำงานของ Code ได้เหมือนกัน //ควรเป็น Automate ด้วย

อย่าให้เกิดเหตุการณ์ที่คนลาออกไปแล้ว มาเร่งสร้าง KM หรือ Test ก่อนจะจากกันไป

ทำทีละนิด เพิ่มที่ละหน่อย Continuous Improvement