|
⇤ ← Revision 1 as of 2020-12-12 22:50:48
Size: 233
Comment:
|
Size: 1856
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
=== From: article by Adrian Hornsby, a Principle Developer Advocate from Amazon. === * Here are some things he suggested: 1. Don't do post-mortems to blame people, teams, or organisations. Instead, focus on the process(es) that failed to allow these mistakes to cause mischief. Never do a post-mortem to punish someone. There's no value in that, and you won't find improvements. 1. Don't assume events that happened were more predictable than they were. Only because they've happened are they now obvious. * (Hindsight bias) 1. Make sure you go deep enough. Don't just say we saw an error in the front end code. Really dig deep into the specific error and the conditions that led to it. How can the process catch this next time? A better QA process? More peer reviews? Better error logging? 1. If your resolution steps to stop it from happening are really vague like "improve documentation" or "train better", you don't understand it clearly enough to be more specific. Make these resolution steps actionable and concrete. 1. Try and keep your resolution steps to things that can be done in the short term. We are trying to stop these from happening again as soon as possible. Post-mortems can spawn longer term process changes, but that's not what you're focusing on at the moment. Don't try to re-architecture something fundamental or try to change the language some huge codebase is written in. 1. Let your post-mortem challenge what your team currently believes to be true. Don't assume because everyone believes something to be true that it is. * (Common belief fallacy) |
Software/Postmortem
- This is something most companies are bad at, problem solved and everybody wants to forget about it.
2020- https://www.freecodecamp.org/news/what-is-a-software-post-mortem/
From: article by Adrian Hornsby, a Principle Developer Advocate from Amazon.
- Here are some things he suggested:
- Don't do post-mortems to blame people, teams, or organisations. Instead, focus on the process(es) that failed to allow these mistakes to cause mischief. Never do a post-mortem to punish someone. There's no value in that, and you won't find improvements.
- Don't assume events that happened were more predictable than they were. Only because they've happened are they now obvious.
- (Hindsight bias)
- Make sure you go deep enough. Don't just say we saw an error in the front end code. Really dig deep into the specific error and the conditions that led to it. How can the process catch this next time? A better QA process? More peer reviews? Better error logging?
- If your resolution steps to stop it from happening are really vague like "improve documentation" or "train better", you don't understand it clearly enough to be more specific. Make these resolution steps actionable and concrete.
- Try and keep your resolution steps to things that can be done in the short term. We are trying to stop these from happening again as soon as possible. Post-mortems can spawn longer term process changes, but that's not what you're focusing on at the moment. Don't try to re-architecture something fundamental or try to change the language some huge codebase is written in.
- Let your post-mortem challenge what your team currently believes to be true. Don't assume because everyone believes something to be true that it is.
- (Common belief fallacy)