Page 209 - The Art of Designing Embedded Systems
P. 209

196  THE  ART OF  DESIGNING EMBEDDED SYSTEMS

                          A classic complaint at the end of any project is that creeping fea-
                      turism inflated the spec. The post mortem must address this, in a quanti-
                      tative way. No:  “Marketing kept changing the specs” may be accurate,
                      but leaves a manager no specific information useful to the next project.
                      Better: “Four spec changes, with a total impact of 23 additional devel-
                      opment days, accounted for 60% of the schedule slip. All changes made
                      sense in terms of the goals. Unhappily, management forgot the impact
                      and kept the same schedule. Next time get their approval in writing for
                      the slip.”
                          The goal is not to find failure, but to find answers.  Successes are
                      every bit as important to understand, so you can capitalize on them next
                      time.
                          No one person is smart enough to find solutions to all problems. The
                      document should be  input to a brainstorming meeting  where your col-
                      leagues hash out better ways to perform next time. Feed these ideas, where
                      appropriate, back into the document.
                          The only bad postmortem is one that’s not honest and thoughtful. Do
                      assess yourselves without beating  each other up-no   matter how badly
                      things went.  But  be  intolerant of  flippant,  whiny,  or unreflective post
                      mortems. If a team member is unable or unwilling to look for ways to im-
                      prove the organization, especially in this nonthreatening context, then that
                      person is simply not suited to a career in this fast-changing industry. At
                      least not with me.
                          A post mortem without specific quantifiable data is a waste of time.
                      “Well, we ran somewhat late and were over budget” is useless informa-
                      tion. “We finished early and saved a ton of money” is just as bad. You
                      can’t take action, or learn things, without knowing the specifics of the
                      situation.
                          But  our memories are notoriously  unreliable.  During a  six-month
                      project lots of things happen, good and bad. Many dates might be missed
                      and many met.  By the time  you’re analyzing the results of the project,
                      there’s no way you’ll remember-accurately-even   a few of these.
                          Preserve the data, so during the post mortem you’ll have the accurate
                      information you need to produce useful recommendations. The engineer-
                      ing notebook, which I’ve endorsed throughout this book, is a logical place
                      to record all of this information.
                          Too many people feel that college is the end of education. It’s just the
                      start. We’ve all got to struggle forever to learn more and to improve. Read-
                      ing, studying, seminars, trade shows are all important ingredients. Equally
                      important is self- and organizational examination, looking for good things
                      to emulate and bad things to fix.
   204   205   206   207   208   209   210   211   212   213   214