效率并不是管理唯一追求的目标；速度也不是敏捷的目的。 在管理上我们总是有很多人违反日常认知的东西，这些内容对我们的工作影响非常大。
其中最大的一个认知是：效率不是管理唯一追求的目标，甚至不是最主要的目标。
假设你是甲方，找到两个软件团队。其中一个软件开发团队 A 估算需要 10 个月完成整个项目，而另外一个团队 B 估算说，我们只需要 3 个月做完。
然后采纳了团队 B，希望 3 个月完成项目，而你把项目周期汇报给了领导，其它各个团队按照 3 个月做了工作安排进行配合。
实际做下来这个团队花了 6 个月（这很正常不是吗？）你汇报上去，然后被领导骂。你感到很困惑，即使延期了 3 个月还是比团队 A 快啊。
实际上在很多公司对交付速度没有那么看重（虽然口上天天讲提效冲刺），速度背后的其它管理需求更重要。
在上面这个案例中，领导也需要睡得着觉不是。
稳定、可控大于速度
不管干什么工作，睡得着觉很重要，包括自己和领导。
在前面的案例中，属于典型的给公司省了钱，给自己和领导填了麻烦，况且钱还不一定省的下来。
速度提升的代价是，质量降低、管理成本、上下游系统配合等一些列问题。
所以在国内找一家估算 10 个月，刚好 10 个月就能交付的软件团队还比较难，这需要非常厉害的管理水平。
在做咨询的过程中，有一个非常重要“行规”：不要在汇报中出现惊喜。 在中国人的思想中，往往把高级的东西藏起来，放到最后讲这样显得比较高深。
实际上无论是汇报、还是日常工作，给领导"惊喜"都非常不好。
估算 8 个人天的工作，1 天就做完了，并不能体现能力多强，而是体现了估算多么不专业，沦为笑柄。
所以做估算、决策工作关键原则是：估算和决策的合理性比结果更重要。
即使估算得非常多，只要是按照合理方式估算的，那么大家都需要认可。但是通过不合理的方式减少估算，让其看起来好一些，这会带来麻烦。
同样的，决策过程的合理性也比结果重要。
在前面的例子中，团队 A、B 的选择上，从结果来看团队 B 更加诱人，但是应该通过更加合理的方式（例如多维评估和打分机制），来做出选择，这样公司在管理上变得更可控。
消除单点故障
一个企业中不可控的因子非常多，尤其是人员。
不过对大多数公司来说，人员的风险没那么大。但是对于银行、证券这类重要岗位就不一样了。
某些银行会定期让一些关键岗位的人出去考察学习，目的就是让其脱岗看看业务能不能继续运行下去，防止出现关键的单点故障。因为谁都可能因为疾病或者紧急事而离岗，保证业务正常运转不能依赖关键岗位上的人员。
虽然大部分公司不可能做到这种程度，但是还是有一些方法在软件团队中实现单点故障的消除。
其中一种方法是代码公有制，避免代码责任田，团队为代码质量负责，测试人员为最终的产品质量负责。
有时候我们会觉得让一个熟悉某个模块的人持续工作在这个模块上效率最高，所以理所当然的安排熟悉的人做熟悉的事情。
实际上这样做带来更多的麻烦：
- 长期让一个人工作在一个模块，导致其他人对这个模块不熟悉，高度依赖某个人，造成单点故障。
- 如果没人参与到这个模块，这个模块的质量和设计就取决于维护者自己的觉悟，从人性的角度看这是不可靠的。
换个角度来看，程序员并不拥有编写的代码，所有的产出都是团队的，团队需要整体对其负责。
对于关键的角色，往往都需要设置一个 backup，防止出现休假、离职的情况无法顺利交接。
例如，我们一般会给 TL 设置一个 backup，这一点非常重要。关键角色的岗位人员调动几乎是必然的，离职、升职、调动、请假都需要 backup 把相关的工作顶上。
从这些角度来看，效率往往没这么重要。