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 ของเรานั้นกลับมาทำงานได้ปกติ
เมื่อเกิดข้อที่ 1 และ 2 ไปแล้วเราก็จะมาเข้าสู่การทำ Post-Mortem กันนนเลย
🎈 ขั้นตอนที่ 1 สร้าง Template ขึ้นมาโดยกำหนดช่วงเวลาตั้งแต่ Web ล่ม จนถึง เวลาที่เรานั้นได้แก้ไขจน Web สามารถกลับมาใช้งานได้ปกติ
🎈 ขั้นตอนที่ 2 เขียน timeline เราจะให้สมาชิกแต่ละคนในทีมเขียนลงไปใน Post-it ว่าทำอะไรไปบ้างในช่วงที่ Web ล่ม จนถึงตอนที่สามารถแก้ไขให้ Web กลับมาใช้งานได้ปกติ(เขียนสิ่งที่ตัวเองเจอและทำ และห้ามแอบดูโพยคนอื่นนะ)
🎈 ขั้นตอนที่ 3 โหวต เมื่อทุกคนเขียนเสร็จ เราจะให้แต่ละคนนั้นอ่าน Post-it action ของคนอื่น แล้วทำการโหวต Post-it action ที่เป็นประโยชน์
🎈 ขั้นตอนที่ 4 นำ Post-it action ที่มีคนโหวตเยอะที่สุดมา Discuss กัน เพื่อครั้งต่อไปถ้าเกิดปัญหาขึ้นทุกคนในทีมจะได้เข้าใจตรงกันว่าควรเริ่มแก้ไขปัญหาจากจุดไหนก่อน เพื่อให้ลดระยะเวลาแก้ไขปัญหาให้ได้มากที่สุดเท่าที่จะมากได้(จริงๆ มันก็ไม่ควรเกิดขึ้นอีกนะ)
จากหนังสือ : 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).
