Post-Mortem กับการทำ Software

Post-Mortem คืออะไร?

ถ้าแปลตรงๆ “Post-Mortem” ก็แปลได้ว่า การหาสาเหตุของการตาย แต่การตายในที่นี้เรากำลังพูดถึงการที่ software ได้ตายลงไป! หรือมีบางสิ่งบางอย่างที่ทำให้ Software ที่เรากำลังพัฒนานั้นล่ม (Users ไม่สามารถเข้าใช้งาน Software ได้)

แต่ แต่ แต่ การทำ Post-Mortem นั้นเราจะไม่ทำแค่ตอน Software ล่มเท่านั้นนะ แต่เรายังใช้เมื่อ Users ใช้งาน Software แล้วพบ Bugs, Defect, Issue หรืออะไรก็แล้วแต่ที่ไม่ใช่เรื่องดีๆ ใน Software ที่เราพัฒนาขึ้นมา เราก็ใช้เจ้า Post-Mortem นี่แหละในการชำแหละปัญหาต่างๆ ออกมานั้นเองครับโผมมม

ซึ่งการทำ Post-Mortem ควบคู่กับการทำ Software นั้นมีบทบาทที่สำคัญเป็นอย่างมาก สำหรับการทำ Software เพราะเมื่อไหร่ก็ตามที่ Software ที่เรากำลังพัฒนาได้ตายลงไป หรือ users เจอปัญหาบน Software เราจะมีวิธีไหนบ้างที่จะสามารถป้องกันไม่ให้เกิดปัญหาเหล่านั้นขึ้นอีก หรือถ้าเกิดปัญหาเหล่านั้นขึ้นมาจริงๆ เราจะมีวิธีไหนบ้างที่จะสามารถลดเวลาในการแก้ไขปัญหาที่เกิดขึ้น และทำให้ Software กลับมาใช้งานได้ตามปกติได้เร็วที่สุด

“Take extra care to make sure the postmortem document isn’t just a useless list of apologies or excuses or finger-pointing — that’s not its purpose.”

ผมมีตัวอย่างมาแชร์สำหรับการทำ Post-Mortem ที่ผมได้เคยผ่านมาให้ได้อ่านกันครับ ไปกันเล๊ย

ก่อนเราจะทำ Post-Mortem ได้นั้นก็แน่นอนว่าต้องมีปัญหาเกิดขึ้นมาก่อน และเราได้ทำการแก้ไขปัญหาที่เกิดขึ้น และทำให้ Software ของเรานั้นกลับมาทำงานได้ปกติ เมื่อเกิดทั้งสองข้อนี้ไปแล้ว เราก็จะมาเข้าสู่การทำ Post-Mortem กันนนเลย

🎈 ขั้นตอนที่ 1 — สร้าง Template

สร้าง Template ขึ้นมาโดยกำหนดช่วงเวลาตั้งแต่ Web ล่ม จนถึงเวลาที่เราได้แก้ไขจน Web สามารถกลับมาใช้งานได้ปกติ กรอบเวลานี้จะเป็น “เวที” ให้ทุกคนในทีมเขียน timeline ร่วมกันในขั้นตอนถัดไป

🎈 ขั้นตอนที่ 2 — เขียน Timeline

เราจะให้สมาชิกแต่ละคนในทีมเขียนลงไปใน Post-it ว่าทำอะไรไปบ้างในช่วงที่ Web ล่ม จนถึงตอนที่สามารถแก้ไขให้ Web กลับมาใช้งานได้ปกติ (เขียนสิ่งที่ตัวเองเจอและทำ และห้ามแอบดูโพยคนอื่นนะ)

เมื่อทุกคนเขียนเสร็จ นำ Post-it ทั้งหมดมาเรียงบน timeline เราจะเห็นภาพรวมของเหตุการณ์จากมุมมองของทุกคนในทีมพร้อมกัน

🎈 ขั้นตอนที่ 3 — โหวต

เมื่อทุกคนเขียนเสร็จ เราจะให้แต่ละคนอ่าน Post-it action ของคนอื่น แล้วทำการโหวต Post-it action ที่เป็นประโยชน์ โดยใช้ระบบ dot voting แบบง่ายๆ:

• ติ๊กบวก (+) — action นี้เป็นประโยชน์ ควรเก็บไว้
• ติ๊กลบ (-) — action นี้ไม่ได้ช่วยอะไร หรือทำให้ช้าลง

การโหวตช่วยให้ทีมเห็นตรงกันว่า action ไหนสำคัญจริงๆ โดยไม่ต้องเถียงกัน

🎈 ขั้นตอนที่ 4 — Discuss

นำ Post-it action ที่มีคนโหวตเยอะที่สุดมา Discuss กัน เพื่อครั้งต่อไปถ้าเกิดปัญหาขึ้น ทุกคนในทีมจะได้เข้าใจตรงกันว่าควรเริ่มแก้ไขปัญหาจากจุดไหนก่อน เพื่อให้ลดระยะเวลาแก้ไขปัญหาให้ได้มากที่สุดเท่าที่จะมากได้ (จริงๆ มันก็ไม่ควรเกิดขึ้นอีกนะ)

Post-Mortem ที่ดีควรมีอะไรบ้าง?

จากหนังสือ Software Engineering at Google: Lessons Learned from Programming Over Time ได้เสนอวิธีการทำ Post-Mortem ที่ดี และควรทำดังนี้:

• A brief summary of the event — สรุปเหตุการณ์ที่เกิดขึ้น
• A timeline of the event, from discovery through investigation to resolution — เรียงลำดับเหตุการณ์ตั้งแต่พบปัญหา จนถึงตอนที่แก้ไขปัญหาเสร็จสิ้นและ Software ใช้งานได้ปกติ
• The primary cause of the event — หาสาเหตุปัญหาหลักของเหตุการณ์ที่เกิดขึ้น
• Impact and damage assessment — ประเมินผลกระทบ และความเสียหายที่เกิดขึ้น
• A set of action items (with owners) to fix the problem immediately — เลือก action items ที่เขียนใน timeline เพื่อครั้งหน้าจะสามารถแก้ไขปัญหาได้ทันที
• A set of action items to prevent the event from happening again — เลือก action items ที่เขียนใน timeline เพื่อนำมาป้องกันไม่ให้เหตุการณ์เกิดขึ้นอีก
• Lessons learned — บทเรียนที่ได้รับจากเหตุการณ์ที่เกิดขึ้น

“The key to learning from your mistakes is to document your failures by performing a root-cause analysis and writing up a postmortem, as it’s called at Google (and many other companies).”

Originally published on suwankhp · Medium