项目所能耗费的资源是有限的→要把有限资源用在投资回报率高的项目上→从契合度的角度看，流程可分3个品级：①收益明显，不做机会成本极大的；②收益不明显，但有收益的；③看不到收益的→①是一定要做的，③是一定不要做的，而②是可做可不做的→从保证契合度的角度看，②是应该被舍弃的。
尺度清晰之后，所要做的工作是选择和集中。依据Intel创始人安迪…格鲁夫的观点，事业成功并非因为面面俱到，而是因为强的地方足够强。（他说：只有偏执狂才能成功）
这对流程的选择和集中同样有意义。从软件项目的角度看，向流程中添加步骤总是安全的，因为任何步骤都有其正面意义。而其负面意义（耗费人力）往往是不直接可见的。这更像是慢性疾病，只有在漫长的时间之后，才暴露出其致命的面目，比如，人浮于事等。
如本条逻辑链中所描述的，流程的步骤总是可以分为3类：①收益明显，不做机会成本极大的；②收益不明显，但有收益的；③看不到收益的。
从基本原则的角度来看，①和③的做和不做是不言自明的，关键是对②的处理。
我们来看一组例子。
“需求分析人员与测试人员共同对规格说明书进行Review”这一步骤是属于类型①。
“所有开发人员需要与测试人员对Test Case进行Review”这一步骤是属于类型②。
“所有开发人员要关注项目的收入是否已经到账”这一步骤是属于类型③。(www.xing528.com)
其中，不Review规格说明书的风险极大，可能导致测试人员的Test Case不能形成对规格说明书的全覆盖，所以这是一定要做的。收入到账与否与开发人没有任何关联，所以根本不需要考虑。而所有开发人员是否要Review Test Case则是两难的问题。
从收益上看，这并不是无收益的步骤，因为开发人员可以判断Test Case是否对自己可能的实现进行了全覆盖。但这样做显然会增加一点开销，同时收益并非十分明显。因为只要需求分析人员完成了对Test Case的Review就可以一定程度上保证Test Case对规格说明书的全覆盖。
表面上看，这类Case可以选择做，也可以选择不做，但事实上却是只能选择不做。否则我们没有任何办法来防止项目组的持续性“熵增”，项目组的资源会不断摊薄在各种各样的非核心事务上，最终导致在代码编写这样核心工作上的时间减少。
项目管理中的加减法
当运作项目的时候，人们似乎天生有做加法的倾向。这大概是因为加法很容易给人一种安全的假象。比如说，多写了一篇设计文档，似乎可以让项目更安全。
但这其实完全错了，证明它甚至不需要实证，只需要用逻辑进行推导就够了。
项目资源（尤其是时间资源）是运作其他任务的前提，那么多做了A一定是少做了B。而项目中各个工作的内蕴价值并非是均摊的，因此时间资源分散得越厉害，核心工作上分摊的时间越少。与此同时，时间分得越散，单位时间的产出越低。这并不难理解，烧一壶开水，如果今天烧两分钟，明天烧两分钟，那么1万个小时也烧不开，如果连续烧，1个小时就够用了。
这也就意味着，高效的项目管理者的主要任务是做减法，把但凡不影响项目根本，可做可不做的东西全部减掉，把有限的资源只投入到最核心的工作上去。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
