Premortems

[流星99.Run-Feed2News]

=-= [摘要] -=-
Google has a pretty good culture of doing postmortems. When something fails, someone
close to the failure tries to document what happened and why. A good postmortem
document should also point the way to avoid similar mistakes in the future. Mistakes
happen, but you don’t want to make the same mistakes over and over again. […]


=-=-{内容} =-=-=-=-=-=-=-=-=-=-=-=-=-=-

Google has a pretty good culture of doing postmortemsdoing postmortems. When something
fails, someone close to the failure tries to document what happened and why. A good
postmortem document should also point the way to avoid similar mistakes in the future.
Mistakes happen, but you don’t want to make the same mistakes over and over again.
Instead, it’s important to try to get to the root of a problem and fix it there.
Failure can be a good thing if you learn valuable lessons along the way.
But it’s also a rule of thumb of software engineering that it’s 10x harder to
catch a problem at each new level of deployment. That’s why solid tests (e.g. unit
tests) are so helpful; it’s much easier to fix a problem when you catch it earlier.
Likewise, requiring code reviews before submitting code changes can avoid lots of
stupid mistakes. Once buggy or poor code is checked in, debugging a problem can
get much harder. And if a problem makes it out into production, it’s typically
even more difficult to fix.
When you take a solid practice like postmortems and think about going further upstream,
you land on the idea of a “premortem.” An example of a premortem would be going
to each member of a team before a product launches and asking them: “What’s going
to break or fail? What’s the mostly likely thing to go wrong?” After all, the
people who have been working hard on a project have been steeped in it and are intimately
familiar with potential weaknesses and failures.

I first heard the idea of a premortem from a Freakonomics podcastfrom a Freakonomics
podcast, but the idea is so simple that it practically explains itself. However,
there are a couple subtleties. First, don’t bring everyone into one big room and
ask “Hey, what’s going to go wrong?” That’s a recipe for groupthink unless there
are a small number of glaring problems.
Instead, you want to collect the initial feedback independently and privately so
that people won’t be biased by hearing what others are saying. With private feedback
you might end up hearing opinions that people are afraid to express in public. If
you do have to settle for a big group meeting, ask people to channel their personal
voice of doom on their own before opening up the public discussion.
The second subtlety is that “dogfooding,” the process of testing your own product
internally before introducing them to the world, is almost like a premortem if you
can get good feedback internally. The touchy issue here is authenticity: people
want their feedback to be taken seriously, but internal feedback might be biased
or skewed for various reasons. Even if you disagree with internal feedback, it makes
sense to take a clear-eyed look at what people are saying. And if you do disagree,
it helps to explain your reasons for adjusting to feedback or not.
Could a pre-mortem help your next project avoid a massive failure? Why not give
it a shot to find out? Premortems can be an easy and fast exercise, and you might
get some really useful insights. Just ask the people close to the launch to brainstorm
“What’s most likely to go wrong?” before the project launches.

-=--=-=-=-=-=-=-=-=-=-=-=-=-=-===---===-=--====-=

-=-{ =-= }-=-
组：cn.edu.lang.english
标签: Personal
=-={ -=- }=-=


**链接**：

doing postmortems
https://groups.google.com/forum/#!topic/google-appengine/p2QKJ0OSLc8
----
Premortem!
https://www.mattcutts.com/images/premortem.png
----
from a Freakonomics podcast
http://freakonomics.com/2014/06/05/failure-is-your-friend-a-new-freakonomics-radio-podcast/


--
Feed2News：从RSS、ATOM上面转载内容到新闻组里面
作者： NewBlue < beyooo (at) GMail (dot) COM >
管理员：流星99 < liuxing99 (at) GMail (dot) COM >