微软研发致胜策略 04：极端的热情-CSDN博客

这是一本老书，作者 Steve Maguire 在微软工作期间写了这本书，英文版于 1994 年发布。我们看到的标题是中译版名字，英文版的名字是《Debugging the Development Process》，这本书详细阐述了软件开发过程中的常见问题及其解决方案，强调团队合作、项目管理和开发流程的优化。该书成为软件开发和项目管理领域的经典著作，受到了广泛的认可和赞誉。

不记录，等于没读。

如果负责人想让软件开发团队进入创作状态，他必须创造一种激发这种热情的开发氛围。不幸的是，随着公司从小作坊发展为大型企业，程序员日常承担的非开发工作量会显著增加。负责人应该努力消除不必要的报告、会议和其他妨碍开发工作的公司流程。这些流程越简单越好。如果程序员有机会在不受繁琐公司流程干扰的情况下工作，他们就有更好的机会抓住创意的浪潮并推动项目向前发展。关键是负责人应该始终致力于解决实际需要，而不是形式上的需求。请求报告或召开会议是获取信息的常见方式，但如果有其他更有效的方式获取信息（确实有），为什么还要让程序员负担报告和会议呢？

作为一位软件开发团队的领导者来说，我极力想达到的目标就是创造出一个理想的工作环境，让所有人都能尽情发挥，创造出足以自豪的产品。为了做到这一点，我努力避免设计师写不必要的报告、参与不必要的会议、不合适的工作计划以及任何与改善产品无关的流程。本章关注这些流程如何降低生产效率，以及应对方法。

无人理睬的报告

一次出差回来，上司要求作者必须写出差报告，非写不可。作者只好花了一整个下午写报告。
一个月之后，上司询问一个问题，这个问题在上次的出差书面报告中早就详细说明了。经过了解，上司并没有看过这个报告，只是将报告放到了档案柜。作者有些恼怒：“既然你根本没打算看这份报告，为什么一定要我写呢？”
没想到上司惊讶的说：“每个人都要写报告，这是公司的政策。”

这就是过度死守规则的错误示范，规则是该遵守没错，但把规则当作铁律就太蠢了。 任何公司都一样，凡是没人看的报告就不该写，除非要写报告的人加深印象。不要因为公司的规章制度，就强制员工写那些无意义也不会有人看的报告，规章制度不是法律，过度死守规章制度有时候会对正常工作造成伤害。

小男孩问妈妈为什么她每次把肉放到烤箱前，都把肉切下来一块。

妈妈也不知道，这是妈妈的妈妈教她的。

妈妈也开始困惑，所以妈妈去问了小男孩的外婆，但外婆也不知道原因。外婆只是看到自己的妈妈这样做，所以外婆也照做了。

妈妈又去问了曾外婆，外婆说：那个时候，我只有一个小烤盘，如果不把肉切掉一块，烤盘就放不下了！

任何规章制度（流程），随着时间的流逝，人们往往会忘记当初设置流程的原因。时至今日，即使这些流程已经过时，人们还是习惯遵守流程，不问缘由。

我曾经大力主张，主管应该全力扫除那些阻碍目标而不必要的工作，像这种没有意义的报告就是其中一种。除非我认为这个会议重要到可以打断程序设计师的工作，否则我尽量不召开。同样地，除非很有必要，我也不会要求他们写报告。我宁愿他们去做开发工作、和其他的同仁互相切磋技术，我也不要他们写一份其实不需要的报告。我认为，除非有充分的理由，我不应该剥夺他们写程序的时间，打断他们进行到一半的构想。

当我请属下写报告时，我都要求愈短愈好，而且表达清楚就行，不要什么正式的文体。

好报告、坏报告

有一种很值得花功夫写读的报告，就是项目的检讨报告，也就是开发小组在产品刚完成不久所写的分析报告。分析报告主要是针对“我们能从刚完成的项目中学到什么？”

如果你正准备写一份项目检讨报告，我诚恳地建议您，除了指出您发现的问题，提出您的看法和意见，还要建议如何防范这个问题，把详细的步骤一并写出来，这样才能让下一次的项目进步，不重蹈覆辙。这样的报告就很有建设性。

对于一个报告：提出清楚的解决方案、详细的执行步骤、由谁负责、什么时候该完成。

避免召开会议

我很少召开会议，因为那会打断组员的工作，影响工作的顺利进行。我也很不喜欢周期性的会议，因为这种会议大都没有明确的动机。你去开会是因为真有什么事需要用开会解决，还是因为“时间到”？我认为开会本身不重要，重要的是您需要项目现况的信息，如果这些信息可以用更好、更有效率的方式取得，何必非开会不可？

什么情况下，开会是利多于弊的呢？以下是我的看法：

当某个人必须把信息传达给很多人时。
信息需要双向或多向沟通时，人们必须与其他与会者互动。
必须要亲眼目睹或亲身经历，信息才能传达给接受者，例如产品示范等。
需要讨论的问题过于敏感，不适合通过电子邮件来传达，比如重组或裁员。

在你决定召开一次会议之前，请花一分钟问自己以下的问题：

“这个会议的结果是否非常重要，即使是中断这么多人的工作都值得？”
“还有没有比较不影响组员工作的方法，可以让我达到同样的目的

请注意定期会议的价值，确定它值得每个人放下手上的工作。

如果非开会不可，请尽量不要中断做了一半的工作。把时间安排在早晨刚上班、或是下午刚上班。换句话说，把开会时间排在时间段的最前或最后面。

让会议有效果

有一些会议是必要的。既然是必要的，我们必须尽量让会议有效果，去其弊取其利。会议的目的在于获得结论，一旦你确定某一会议是必须举行的，在发出开会通知前，请先问自己这样的问题：

这次会议的目的是什么？
我希望在这次会议中获得什么结果？
我该怎么做，才能确保我的目的能够达到？

如果你能清楚回答以上的问题，那你就比较能掌握开会的效率，不会让会议变成漫无目的的讨论。如果你对未来的目标有清楚的认识，而且知道要如何达成这个目标，你就会成竹在胸，该请谁来开会、讨论什么议题、如何导出结论。很多会议之所以无疾而终，就是因为该做决定的人根本没有出席，或是该提供重要讯息的人未受邀列席。

再次强调：每一个会议都必须得到某种程度的结论。如果开了会却没有结论，就是浪费时间的会议。

避免会后工作

开会的缺点之一就是伴随而来的后续工作。管理者需要尽量排除不必要的后续工作。有些后续工作是必须的，但有些是在浪费时间，比如：要求组员在会后把发言写成文档再发给他。

铲除障碍物

世界上有两种日程表。
一种是管理者的日程表。他们是面向老板的，日程表都是以小时为单位，所以开会对他们来说，只是在日程表上找出一个小时。
另一种是工匠的日程表，也就是程序员的日程表。他们需要做出实际的东西，日程表都是至少以半天为单位。所以，他们不喜欢开会，因为一小时的会议，会将半天分成两半，每个部分都时间太短，导致无法做成任何事情。
—— 《为什么程序员不喜欢开会？》，by Paul Graham （出处：阮一峰的网络日志第 4 期）

如果你希望你的组员保持高昂的工作情绪，就让他们专心致力在产品的开发，不要被一大堆会议、报告及莫名其妙的填表或行政程序等等之类没有生产效率的东西打扰。