博文共赏：也谈大公司病2——减少错误不等于增加成功-InfoQ

【编者按】《博文共赏》是 InfoQ 中文站新推出的一个专栏，精选来自国内外技术社区和个人博客上的技术文章，让更多的读者朋友受益，本栏目转载的内容都经过原作者授权。文章推荐可以发送邮件到 editors@cn.infoq.com。

序

多数大公司大了后都不可避免会遇到大公司病，机构臃肿，行动缓慢，协调困难，思维僵化。为此，大公司采取了各种各样的做法，建设企业文化，调整组织机构，更换领导人，加强流程规范，建立特区，建立快捷通道，引入敏捷方法。这些措施往往都能取得一定时间的效果，却很难与整个公司抗衡，随着时间流逝，大公司病还在蔓延。

为什么会这样？是解决措施有问题？还是管理能力不足？还是没有找到真正的问题？

下面对大公司病的一些另类思考，试图向真正问题迈进一步，“减少错误不等于增加成功”是其中第二篇。

正文

稳重是大公司的特点，安全的成功是大公司的追求，不断减少错误是大公司的一条行事准则。你可以做不成事，但是千万别犯错。大公司这种减少错误的倾向从何而来？是大公司病的一种吗？会影响大公司的成功吗？

对于产品而言，减少错误不等于增加成功。

在产品选型上，大公司力求减少错误。大公司有充足的财力人力，会投入大量的成本进行产品论证和市场调研。与此同时，还得与公司的已有产品，尤其是现金牛产品划清界限。为保证进入足够大的市场，为保证不与公司自身产品自相残杀，为证明本产品的重要性超过其他产品，n 论 PPT 的论证和产品 PK 是不可少的。直到产品方向得到市场论证或高层一致，方才放行，既花费了巨量的成本，又消耗了相当的时间。

进入产品研发阶段，研发团队力求减少错误，此处以软件研发为例。因为不敢犯错，研发团队会力争力求一次完成，瀑布模型成为必然选择，因为瀑布模型是错误最少的模型。然而，研发团队对产品认识不够深刻，一次完成的风险太大，一定会犯错，怎么办？研发团队会争取把错误变成别人的错误，为此不惜吹毛求疵。曾多次参加这样的需求评审会，开发、测试人员围绕着产品的设计细节不断追问需求人员，要求需求人员解答所有的需求细节，需求人员也从来没有做过这个产品，双方对着需求文档纸上谈兵式的纠缠细节。为了一次考虑清楚与相关系统的关系，设计讨论、评审也不能缺少。需求评审、设计评审等各种评审、讨论让软件研发变成会海。到了编码阶段，要求不高，没错就行，同时时间也不足，匆匆完成。而测试时间则会不断增长，因为产品宁可不上线，也不能有很多错误，哪怕是小错误也不行。

每个产品研发的参与者都致力于减少错误，每个人都很努力，都没错，这能帮助产品成功吗？

公司在选型和研发上都有巨大投入，一旦没有大产出，公司怎么处理？
选型和研发的效率低下，产品可能错失时机？
前期产品论证时和后期瀑布研发时对产品进行了从大方向到细节的纸上谈兵，这种纸上谈兵完全有可能在不断强化错误的方向，谁敢承认这些错误，谁来为这些大错买单？
因为时间被前期的其他事务占据，导致时间不足，从而对设计和代码质量降低了要求，从而导致产品投向市场后难以快速演进，响应市场变化缓慢，怎么办？
在整个过程中，缺少来自真正用户的反馈，团队也缺乏学习，怎么可能推出市场真正满意的产品？

对于管理而言，减少错误也不等于增加成功。

对于管理而言，有一点我一直没搞清楚，管理是为了成功还是为了安全？很多人可能都认为管理是为了可重复的成功，那么是可重复重要呢还是成功重要？对大公司，安全、可重复、少犯错可能更重要一些，毕竟“稳定压倒一切”嘛。

流程制度是减少错误的典范，因为不遵守流程是有错的，而流程多了无所谓。流程制度是典型减少错误的工具，与成功关系不大。在某公司，基本上没有人知道项目中有多少个流程。这不仅是因为流程繁多，还因为不断有新流程被发明出来，旧流程版本被更新。为什么人们会热衷于发明新流程？表面原因很多，例如提升服务质量，工作规范化等等。但除了部分工作必须的流程外，其他流程被发明的根本原因在于

责任界定，出了问题时流程可以证明问题是别人的问题，我没错；
防范错误的重复出现，因为曾经出现过重大风险，所有我们要增加审核；
防范坏人，留下记录。嗯，最后一句防 1% 的坏人，把 99% 的好人也防住啦。

会议占据了大量的时间，因为不开会是有错的，而“必要”的会议是没错的。为了减少错误，人们利用会议相互试探、扯皮，把决策权向上推，找人共同担责，等等理由不一而足。一个有一个的会议就此被发明出来，每一个会议都非常“必要”，因为一定有足够的理由证明其必要性。劣币驱除良币，会议的盛行导致会议综合症，部分必要的会议受到抵触，并不能取得预期的效果。

报告在大公司是如此盛行，因为不做报告是有错的，而多做报告是没错的。因此按照时间维度的日报、周报、月报，按照工作类型的项目、部门、业务、财务，各种报告层出不穷。虽然并非所有的报告都是坏的，但放到一起，报告繁多显然是大公司一绝。同时有一些糟糕的例子，例如软件研发中的日报。至今为止，大多数软件公司开发人员依然要填日报，原因是什么呢？在某会议上有位演讲者是这么讲的。“虽然大家都知道日报与成功没啥关系，但是这是当前唯一有效的选择。”也就是说，这是不犯错的选择。

流程、会议、报告是管理中减少错误的典型案例。很难说某个流程、某个会议、某个报告是不必要的，没有意义的，但是为了减少错误，肆意的增加流程、会议、报告后，这就成为了公司不能承受之重，不仅降低公司运行的效率，甚至影响正常工作的开展。

对于个人而言，减少错误同样不等于增加成功。

有个小故事讲得很好。一天，需求分析师向公司技术牛人提出了一个需求，牛人看过后有点不高兴的问道：“你觉得这个需求有价值吗？”需求分析师诚恳的回答：“没有价值，但是我要写周报啊。”牛人听后，沉思了一会说：“好，我帮你做，我也要写周报啊。”需求分析师和牛人都不想犯错，因为在大公司有个最严重的错误，工作量不饱和。一旦工作量不饱和，所有人都能看见，而实际工作干了什么，却不一定有人清楚。

有一种方式的减少错误，就是老板导向。因为不能犯错，揣测上意、溜须拍马在大公司的某些地方开始盛行，抢功、挣表现、求亮点成为必备功课。听说在某公司，几个部门管理者相互安插内奸，目的只是为了比其他人领先几分钟发项目战报。这对部门管理者非常重要，是否实干并不重要，在老板面前增加成功、减少错误显然是更加关键。

还有一种方式的减少错误，KPI 导向。每到 KPI 评定的时候，都会拿出 KPI，这里那里有错。曾经出现一种情况，某部门的测试团队有一个月停止工作，全员编写无人使用的自动化测试，因为团队每个人的 KPI 中都有自动化测试脚本覆盖率要求。

大公司的螺丝钉精神也与减少错误相关，因为甘当螺丝钉最安全。大公司有很多优秀人才，随着时间变迁，他们会成为优秀的螺丝钉，在不犯错的条件下继续寻求成功。

尾声

综上所述，大公司中有很多行为是以错误 - 惩罚的形式驱动的（套用句流行语，看起来大公司的负能量好足啊。），减少错误作为一种本能被不断放大，而且大多数人难以认识到它的危害。当所有减少错误的倾向走到一起，会带来整体工作效率的急剧降低，会议冗长、报告繁多、流程复杂、分工增加等大公司病征仅仅是其表象而已。

最后用一个科学实验“大猩猩再也不敢犯错了”来结束。把 5 只大猩猩关进笼子里，在笼子的左边放上香蕉。哪一只大猩猩去拿香蕉，就暴打 5 只大猩猩。后来不用你去暴打，哪一只大猩猩去拿香蕉，另外 4 只就会暴打它。这时，往笼子里再放一只大猩猩，新来的大猩猩想去拿香蕉，另外几只大猩猩会用暴打让它学会别犯错。再往后，以此类推，从此大猩猩们养成了不吃香蕉的文化。据说，后来不知情的大猩猩打其他大猩猩打得最狠。