序
多数大公司大了后都不可避免会遇到大公司病，机构臃肿，行动缓慢，协调困难，思维僵化。为此，大公司采取了各种各样的做法，建设企业文化，调整组织机构，更换领导人，加强流程规范，建立特区，建立快捷通道，引入敏捷方法。这些措施往往都能取得一定时间的效果，却很难与整个公司抗衡，随着时间流逝，大公司病还在蔓延。
为什么会这样？是解决措施有问题？还是管理能力不足？还是没有找到真正的问题？
下面对大公司病的一些另类思考，试图向真正问题迈进一步，“大公司中的反模式”是其中第四篇。
正文
整个系列应该叫《理解大公司病》，不理解大公司病，如何能够治病。这是第四篇，在前面三篇“正确是最大的错误”、“减少错误不等于增加成功”、“治大国不是烹小鲜”中，从一些大家平时不甚关注的角度向大家讲述了大公司病的部分理解。本文将对上三篇进行一些总结。
正确、安全、简单 vs. 成功、创新、复杂
正确、安全、简单是存在于每个人心中的渴望。公司的本质还是由人组成的，人和人与人之间的关系构成了公司的基石，所以源于个人的这些渴望在不自觉地影响着人们的行为，最终体现到公司行为中。在大公司，尤其如此。即使在大公司中，你依然会听到人们对缺乏安全感，不知道什么是正确，太复杂不够简单等种种抱怨，这正是力量的表现。
成功、创新、复杂是真实世界对企业的要求。公司是一个盈利性的组织，成功是公司追求的，因为不成功则成仁。创新是公司持续成功的保障，公司必须持续满足客户的需求。而复杂是公司面临的现实情况，在互联网时代，公司服务的人群快速扩大，市场竞争越发激烈，公司生存的环境越来越复杂。公司，尤其是大公司需要在这复杂的环境中不断创新以取得持续的成功。
当正确、安全、简单在大公司碰到了成功、创新与复杂，会发生些什么？正确、安全、简单代表着公司向内的力量，它们引导着公司看自己，关注公司内部。成功、创新和复杂是外部环境要求，是外在的驱动力。如果两者不能匹配上，会出现各种怪现象。当然，100%匹配几乎不可能。
下面，就以大公司中几个常见话题作为示例进行简单讨论。分工和绩效两个话题因篇幅限制，讨论不深刻，未来可能单独成篇。
反模式1：分工不应该是扯皮的基点，逃避责任的港湾
大公司强调的分工会逐渐演变成“圈地运动”。分工在传统意义上是通过分工加强专业能力，降低人员培养成本，提升整体工作效率，最终有效提升公司的成功、创新，帮助公司更有效的应对复杂环境。而在大公司，分工的主要目的却是为了划分职责地盘，不能有任何模糊，因为只有这样，工作中谁该做什么才是简单清晰的，谁该承担什么责任是清晰的，人们才知道什么是正确。主导分工的管理者觉得正确、安全、简单，接受分工的员工也这么感觉。然而，分工与成功、创新、复杂的关系越来越弱。
“圈地运动”式的分工往往成为扯皮的基点。类似的场景经常出现，两个农夫各自站在自己的田里骂对方的田没种好，说对方没有证据证明自己的田没种好。一个例子可以参看王建硕博客《写代码这件事》http://www.huxiu.com/article/3267/1.html?odby=agree。
“圈地运动”式的分工往往成为逃避责任的港湾。还有一种情况，在所有分工都明确的情况下，产品依然失败了，是谁的责任？要不是都没有责任，因为每个人都做好了自己分工内的工作，找不出做错的证据，最终公司承担；要不是大家承担责任，每个人都有错，才导致了错误的发生，最终法不责众。
反模式2：绩效KPI应该是跑道而不是终点
绩效评估是大多数大公司都有的制度，而这项制度在大多数大公司都实施的不尽如人意。其本意是通过绩效评估，统一组织发展方向，传递组织目标，保持组织活力，帮助组织在复杂环境中成功与创新。然而在实际过程中，因为成本原因、因为沟通障碍、因为工作复杂度增加，绩效评估的难度不断上升。因为各种原因，管理者会采用简单的方式来进行绩效评估。从而导致如下结果：
绩效评估最终促成KPI导向。绩效评估极大的破坏了员工的安全感，尤其是在有末位淘汰的情况下。绩效评估清晰向员工指明什么是正确的。只做KPI上规定的事是最简单的。从而为了正确、安全、简单，员工变成了KPI导向，唯KPI是从，不在KPI上的一概不做，在KPI上的积极做好。
绩效评估最终促成老板导向。绩效评估可能成为老板显示威严的工具。它用简单的方式帮助老板巩固了安全感，清晰阐释了老板需要的正确。员工为了自身的正确、安全、简单，唯老板之命是从。
KPI导向、老板导向极大制约了公司的成功、创新，阻碍公司灵活应对复杂环境。对于员工来说，正确、安全、简单的创新是在是太难了，一个人在对抗一个体系。在有些公司，情况甚至发展到阻碍公司发展的程度。
其他反模式
流程制度能防止错误，也能阻碍成功。流程制度是好的，仅在他们能够帮助公司更加成功这一前提下。因为分工过细，每个人都站在自己的田里看问题，为了保证自身的正确、安全和简单那，大公司中的流程制度如果不经刻意控制的话会源源不断的增加。然而，这与公司的成功、创新、应对复杂很可能存在一定矛盾，降低了整体运行效率，甚至会出现内部分工中的矛盾冲突。
Smart目标让我们捡了芝麻丢了西瓜。管理学课程告诉我们，目标要Smart，但对于知识密集型产业例如软件研发而言，Smart目标不是个好主意。符合Smart目标能让管理者感到正确、安全和简单，但员工则会用另一种方式让Smart目标不能达到效果，例如单元测试覆盖率。单元测试是软件研发中的流行实践，80%的单元测试覆盖率显然是Smart目标，制订此目标的目的是提升研发团队的软件研发能力，保证软件质量。然而，提升单元测试覆盖率却不去提升软件研发能力是更简单的选择，员工可以用自动生成单元测试方法的方式，他们总能达成管理者规定的Smart目标，却让管理者的期望变为流水。
尾声
国庆大假几天，终于写完了近期关注的“理解大公司病”话题。后续的话题还很多，如复杂系统、敏捷、管理实践、软件研发等等。如同乔布斯所说，大公司病、复杂系统、管理实践、敏捷、软件研发这些都是点，我们需要不断学习回顾以让这些点最终都汇聚成线。希望在不久的将来，能够把串起的线呈现给大家。
配合正确、安全、简单vs.成功、创新、复杂，可以设计出一系列的小工具来检查公司对内力量与对外力量间的协调程度，还可以进行针对性的一些改进。读完了，你有什么收获呢？
参考
再次推荐《BBC系列：神秘的混沌理论》http://v.youku.com/vshow/idXMTcyNjE2MzMy.html，理解复杂系统，理解简单与复杂的关系，非常重要。
我有另一系列文章讲述了分工在软件研发中不再有效，《债思维——软件研发新视角》http://www.ituring.com.cn/article/1836。
