自组织是不是团队管理的乌托邦？

对于很多管理者，最幸福的事，莫过于做到名义上管理一个团队，但实际上什么都不需要做。他所带的逆天团队还可以成果迭出。对于团队中的成员来讲，如果他可以做什么都不被管，做什么都有人帮，那真是可以做梦也会笑醒的。这样的团队存在么？自组织的团队据说就可以，不管你信不信，所以我看了这本书。
我想要谈论它，还有个人变动的原因。我曾经待过养老的公司，也从热衷微管理的公司走过。几个月前又刚从一个大公司出来，到了一个小小的初创企业。环境的变化会让人变得更加敏感，上面那些变化让我得以对比思考管理的各个方面。其实那个大公司也不大，不过大公司很多问题它都有而已。（大公司病嘛，等有时间再讨论）
很多时候，加入一个有问题的团队，就像旅行路上经过的沼泽地。为了生存你只能滚着前进，与沼泽保持尽可能大的接触面，然后弄一身脏泥巴。等到滚多了，再加上勤奋努力，很容易的，你会成为一个滚泥巴专家。
你很可能忘记，本来只是为了经过。你想要去的，是美好的远方。
这只是个提醒。也许你只想研究技术，但你值得知道，哪些是该受的，哪些是该得的。如果你还想管理，不想掉进泥沼里，你更不应该停止对好团队的追求。这本书也就更值得一看。
这是一篇读书笔记，书是《管理3.0》。这本书都很多理论和观点有意思，我会谈谈我喜欢的一些，包括自组织相关的思维方式、创新问题、开发模式和团队管理。也会补充我认为缺失的一环。最后是一个问题，也是对个人最重要的问题，你适合什么样的团队？
思维方式
值得一提的是系统思维，来源于彼得·桑吉的《第五项修炼》，“将问题视为整个系统的一个组成部分，侧重于组织内的循环关系和非线性因果关系”（P47）。其实就是不要将一个运动的整体割裂对待。当一个人作为个体存在于团队内部时，其他人都是环境变量。你做的所有动作，都会对其他人产生影响。要认识到自己能力可以扩展的边界。当然重要的是，不要跟猪做队友。
这本书我也是几年前看过，关于系统内部正向反向反馈的说法印象深刻。只要反馈环建立起来，就会有习惯的力量帮助你或者阻碍你。所以要关心当前团队的运转情况，强化正向反馈。
其次是关于简化论的说明，“找到了心脏病的诱因（简化论），并不意味着可以制造一个不生病的心脏（构建论）”（P9）。这也是很多人知道自己团队的问题，却不知道如何构建一个好团队的原因。简化论是很多人思考停止的地方，因为对于吐槽来说足够了，殊不知后面才是更有价值的。
关于创新
1. 创新需要土壤
在这个人人视抄袭为平常的国家里，创新已经稀有到要比鬼还少了。为什么中世纪后有文艺复兴，为什么有春秋战国可以百家争鸣？我与作者一样，非常赞同土壤的说法，“复杂性系统方法认为创新是可遇而不可求的，它是水到渠成而自然涌现的结果。得先有涌现所需的土壤，才能期待它的发生”（P52）。就在去年提这说法的时候（内部在创新方面一直有讨论），我是希望说明创新是需要多数人参与，发生在少数人身上的，要给工程师们空间，不要太多管理操作。
前文有个关键词是“涌现”，它在做属性时，按照定义是“当一个系统的属性不能追溯到系统的任何独立部分时，我们就称之为涌现属性”，就像“流动性是水的涌现属性，文化是群体的涌现属性”；做动词时，强调的是自然发生，整体性质的体现，比如在说涌现式设计则强调 “最好的架构不是预先定义好的（可能有一个基本的形式），它可以在产品开发过程中逐步浮现出来”（P21）。这里隐含的意思，我理解，创新是一种整体表现，也是需要用结果后验的，我们要做和能做的只是增大其可能性而已。
2. 包容式多样性
作者更进一步，强调了土壤的肥沃问题，“团队的多样性能够显著增加其创造力。但必须有足够的共同点加一些制衡，即包容式多样性”（P60）。做事要找志趣相投的人只是其一，只有能力互补，才容易有火花碰撞出来。这个在我组织过的黑客马拉松、参加过的内部创新大赛表现得十分明显，如果只是技术人组队，很容易陷在 Geek 圈里，玩玩原型做技术储备可以，离产品化还是甚远。
说起来，此次微博的升级视频，我自认为是个小的正向例子。那是有一天，设计师跑过来问说如果想利用每个人的信息来生成个性化的视频，能不能搞得定。如果没有服务的话，他只能每个人手动生成了，可能几千个。我说没有经验，但可以试试看。于是有了最后的 AppleScript + Shell + JavascriptX 的奇怪组合。我想说的是，由于有设计师的参与，由于不同领域的人共同对技术应用边界的摸索，才有了产品质量的成果出来。事实上效果还是比较令人满意的，没看过的可以看看这里：http://www.weibo.com/1819367693/Bp6II3a1V
我说这个例子是偶然，因为从想法到实现还有相当长的路要走。大多数想法都像书中所说，"一个很好地想法可能在公司内被踢来踢去好几年而得不到利用，这不是因为大家没有看到它的好处，而是因为不知道应该由谁来负责将它踏实地落到行动上”（P63）。我是负责后端团队，通常不会与设计师打交道，与这位设计师认识纯粹是由于组织黑客马拉松的时候他帮忙设计制作了宣传视频。
3. 勒曼第六法则
对于一个业务基本稳定的公司，创新难还有一个重要原因，就是勒曼第六法则，"许多软件产品并没有演化使自身变得更好，他们演化之目的只是为了尽量不被用户抛弃（不可避免）”（P310），大多时候，它们 “为了将客户满意度维持在相同的水平，要不断增加产品的功能性”。制定 KPI 当然要 SMART 不是么？你见过 KPI 说要将创新水平提高几个百分点么？。。。
说回创造力，还有个有趣的三阶段理论。先是前习俗创造力，属于儿童的，是自发性的；然后是习俗创造力，一般在7-11岁左右，开始是真正的思考，了解世界的边界；最后是后习俗创造力，也是创新开始的地方（P67）。最后一阶段的时候，便是讲初心的地方，“即使知道有实实在在的约束，也可以像小孩子一样充满想象力”（P70）。这个理论很类似的一个学习理论，会在后面人员培养处再讲。这里主要说明边界学习对创新的影响。边界客观存在，不要让它制约你的想法。
4. 罗杰斯创新曲线
罗杰斯有个创新曲线，说的是团队人群分布。“创新者2.5%、早期采用者13.5%、早期采用人群34%、后期采用者34%、迟缓者16%。改变要从渴望尝试新事物的创新者入手，一次努力推动后面人群。忽略行动迟缓者，他们会一直抵制改变，直到其他所有人都采用”（P335）。这个比例在不同团队肯定会有所差异，你只要记住，不要想当然所有人都愿意改变就行。然后在尝试新事物的时候，不要怕反对声音。
管理者要做的就是发现这种萌芽，帮助其成长而不被恶劣环境影响。对那些不愿意改变的力量进行驱赶，甚至可以让他们适当痛苦。“让停滞痛苦不堪”（P336）说的就是这种迂回方式，有些人吃一堑才能长一智。
手中的鞭子和驴头前面的胡萝卜同样有用。
开发模式
书中提了两家的宣言：
敏捷软件开发（P19）
“个人和交互 胜于 流程和工具；可以工作的软件 胜于 复杂的文档”；
“虽然右项也具有价值，我们认为左项具有更大的价值”
精益软件开发（P24）
“可以工作的软件犹不足，尚需精益求精；响应变化犹不足，尚需稳步增加价值”
“在追求左项的过程中，我们发现右项亦不可或缺”
说实话我对这些模式都不感冒，这方面我更功利，我觉得不同发展阶段需要不同的开发方式。特别在互联网行业，一个团队的开发活动需要在高速度和高质量方面反复切换。
在团队人员紧缺的时候，你要有速度意识，这是质量下降几乎是必然的；如果人员稍微充沛，就要重新思考质量问题，承认低质量软件的存在与不合理之处，持续改进。因为当用户请求量上来，几乎所有的问题都会显现出来（墨菲定律），你要做的是在Bug 酿成灾难之前消灭掉。
我在心里是渴望精益的。
关于不同开发方式其实网上有很多争吵，极端言论也比比皆是，但看两者的宣言，你很难产生针锋相对的感觉。为什么？因为很多人在交流时急于表达自己的观点，（或有意或无意地）不会强调与对方观点的相同之处，这在沟通中造成了很多无谓的争执。相互熟悉的人之间也无法避免这种情况，更别说背景差异的团队成员之间了。
因此我也更加赞同敏捷宣言里对个人和交互的强调。有效沟通才可能让改进发生。
团队管理
1. 动机管理，以人为本
“人是任何软件项目中最复杂的元素”（P62），确实所有对时间和项目的管理，都是对人的管理。而其中最难的部分，是人员的动机管理，“所有管理者首先关注的应该是激励员工以确保他们愿意全心全意做事，而这一切，都需要动力”（P56）。如果一个人已经与团队贰心，那你实质上已经失去他了。所有的CEO（大忽悠）都会谈价值观，谈企业文化，也是这个目的。
我们把只画饼的宣传叫做忽悠，是在强调奖励的必要性。但奖励最重要的目的是要变成激励，书里提醒 “不要把为团队聚餐买单当成庆祝里程碑式胜利表达谢意的方式。为团队买单是为了解决人们社交和相互联系的需求”（P85）。而且“不要应某些员工的要求而取悦他们，从而引入规则、实践和政策。真正的目的必须是引入秩序和稳定性”。
后面这句话我不知道是否理解得准确，我只能说部分同意。我同意规则和秩序，只要他们是公平的，而不在意是否为了取悦员工。事实上我认为，除了真正的团队目标，其他所有事情都应该为了成员愉悦而做，这样才能最大发挥成员的价值。
在某种程度上，管理应该是服务性的。
2. 适当授权，解除电网
如果说动机管理搞定了人员能动性的问题，那么授权管理就是为解决工作效率的问题。“智慧的控制要做到无形中的影响。决策的制定也应该来自人员之间的互动，而非来自我的权威”（P109），这方面英文Empowerment更容易理解一些。把权力下放给员工，但不要忘记目的是“不是增强激励，而是改善管理”。当然，授权也是分级别的：告知、贩卖、咨询、商定、建议、征询、委托（P125）。当然，“这并不意味着需要分级的架构”。
授权不当就会造成隐形电网的存在。“当管理者对下属赋能时，他们并不会清楚地点明其职权界限，这意味着人们往往只能摸着石头过河，磕磕绊绊，中间还伴随着情感伤害”，“它是时间和资源的双重浪费。屡屡触及隐形电网的经历会扼杀人们的积极性”（P173）。这方面我倒是体会颇深，因为不同等级的信息不对称和相互之间的沟通问题，会造成很多理解上的偏差，碰上电网是非常可能发生的。这个事故的预防（降低频次）以及处理好坏（减轻伤害），不同的管理者之间差距非常明显。坏的结果多了，就很容易造成多一事不如少一事的氛围，离自组织也必然是越来越远。
3. 运用同侪压力
适当授权之后，就可以放手团队去解决问题了，也是时候做好准备接受成员犯错的考验了。“若要有所作为，必先磨练耐性”（P130），而且“当已授权的团队走进办公室请求你决定某件事情时，要想办法让他们自己解决问题”（P135）。不要做保姆，不止是减轻当前的负担，重要的是要防止成员思维惰性，养成依赖别人思考的习惯。
 团队可以自行运转，来源于成员想一起共事的意愿，但意愿能促进协作么？书里提到的“同侪压力”，很好的说明了这一点。当你做事的时候，大家都在看着你。你的能力展现无遗，好与不好都在每个人心里。这种社会压力让成员之间可以互相驱动，也是规则发挥作用的地方。
要让同侪压力转化成动力，要注意“与那些试图破坏这些团队的人做斗争”，因为“只有在人们想要加入某个团体时，该团体的社会压力才会起作用”（P224）。最好的方式是，“建立团队、设定目标、再退后一步”。如果有人要破坏团队的规则，那么“找他谈一谈”，不奏效就“再谈一谈”，还不行就“请他离开”。团队是作为团队而存在，而不是为某个人。我的经验是，在这方面越果断越好。
如果怕请人离开，那就把好入门的关。“在允许某人加入（有挑战性的）项目之前，必须对他进行适当的测试”（P185），这是书中根据荷兰的低交通事故率总结的经验。我在微博也一直坚持，没有经过内部新兵训练以及高性能服务设计演练的人，再忙也不会让其进入正式的开发序列。这是对当事人负责，如果他因为经验缺乏酿成事故，以后做事也会畏手畏脚；更是对团队其他人负责，团队不应该因为某个人的问题而受拖累。互联网应用，完成功能只是基本的，还要保证性能、可用性等很多方面。问题在上线前解决要远比上线后简单。而一旦上线，就是7x24小时的服务，出了问题基本是不搞定不眠不休的（也是苦逼之处）。
一句话，宁肯一堆人累，也不要被一个人坑。
4. 保护团队成员
“管理者既要促进自组织，还要保护大家不受伤害”（P175）。我本来觉得这是对管理者基本的要求，但是在一次内部讨论中，出现了截然不同的相反观点。有人反问说，如果一个人不能很好地保护自己，总需要人呵护，如何期望他在对外合作中，甚至在公司外部的行业洗礼中生存下来？
如果说从个人角度来看待这个问题，尚可以理解的话，从团队角度看来我是完全不赞同。组成团队的主要目的是为了完成共同的目标，而不是为了让个人接受锻炼。而在完成目标过程中成员之间互相配合互相帮助，也是团队存在的价值所在。让个人成长，在团队中发挥更大价值，跟让个人接受磨练以成长到更高层次，是两件事。
特别是当管理者不是领导整个公司的时候（个人还没体验过），如果不喜欢随波逐流，期望自己的团队在公司内可以变得更好，举例来讲先变成自组织模式，更要注意这点。如果让团队中的普通成员去接受不必要的压力，要么他觉得太困难无法做事，要么他适应下来，结果把外界的习惯带回当前小团队，所有这些都会对团队向自组织转变起到负面作用。这就是环境的力量。用系统思维方式来看，如之前所述，就是不要让环境对团队改进产生负向反馈。
5. 开始，不要停止改进
开始改变并不意味着就从此一路向前了。一切都在变化之中，环境、人员甚至是目标都有可能随时改变。而整个团队也很可能进入局部优化的状态，事情做得马马虎虎，也总是问题不断。这时候就要考虑模拟退火了。“先加热再冷却会改变金属的性质，比如强度和硬度，这种技术叫退火。复杂性系统中，错误和噪声-通常由环境引发，会扰乱系统并使之拜托局部优化，在这之后，系统更容易找到更好地位置安定下来。”（P339）
用错误和噪声来改善团队，说起来有些奇怪，再看一下模因论可能就好理解了：“不要求模因组内所有思想、概念和实践都必须是有益的。其中的一些有害处，但由于同属于一个模因组，负面思想也会帮助正面思想互相复制，这样便可以中和负面影响。危险范例：没有确凿证据能够证明代码集体所有制的价值，但是此实践似乎能增强其他敏捷实践，所以复制它也不会有什么坏处。”（P204）
如果发生了局部优化，我理解很可能是某些方法措施有了什么副作用。这时就要重新审视团队，是否有规则没有实施或者被错误的实施了；如果发现新规则不适应当前的团队，要继续尝试其他可能。
不恰当的错误补救例子很多，比如弹性制度下一个人钻空子不好好工作变为全部人强制坐班，或者一个人在项目过程中出现沟通问题，全部人天天一起开会。这种情况还有很多，说个亲身经历的创新相关的例子。
曾经有一次大家想搞创新，但是在如何创新上分化成了两派。一派就是我刚才提的土壤论，希望解放大多数同学的创造力；另一派则是规划论，认为创新是可以规划出来，用项目来管理的。讨论结果是决定先用后者。不出意料的是，执行规划论的结果就是，大家只是将其看做是另一项工作任务而已。问题是本来都忙不过来了，还要再进行一项自己毫不在意的事情，即使它的名字叫创新，会有什么动力呢。因此这个行动基本上还未开始就结束了。然后，整个事情最奇怪的地方出现了，再没有人谈论创新问题，好像不存在这件事情一样。
举这个例子，不是说理念分歧的问题，而是整个团队在失败尝试之后的总结和使用方式，也就是如何获取经验的问题。当一件事情失败之后，不要怕把事情放在台面上讨论，特别是尝试，大部分都是要失败的。如果失败了而不总结，才是对自己最大的不负责任。总结可以得到经验，但要时刻对经验保持警惕。好的经验固然让人成熟进步，错误经验却让人裹足不前。
攻打威虎山的时候，正面土匪多有坦克，小分队又从背面上山了不是？
这就够了么
思想是好思想，行动也有方法，就能实现么？在我看来，至少还有两个问题需要解决才行，也是书上没有讲的。一是目标管理，二是人员培养。
1. 目标管理
这个目标管理不同于前面说的动机管理。动机管理是解决愿不愿意做的问题，目标是解决要做什么的问题。一个团队是自组织的，意味着每个人都是自主的而不是被管理的，好的时候会像大雁一样跟随头雁，不好的时候就各自为政，一盘散沙。
因此目标管理是不可忽略的。咦，那还怎么自组织？我个人理解，这不是像KPI 一样的设定与分解，而是一起来讨论团队目标，然后自我选择与设定的过程。事情一样，但规则不同。
2. 人员培养
并不是每个人都适合自组织团队。有的人能力不足，无法自主完成任务；有的人驱动不足，需要监督和指导；有的人悟性不够，无法自己发现问题。你也许会说，那就不是我们需要的人啊。
那只是理想。什么都是变化的，市场是变的，目标是变的，人也是如此。好的方面是，他的能力会提高，你有可能培养出一个合格的人；不好的方面是，他可能离开，你会流失已有的成员。
所以现实是，在你集合一群合格的人之前，你有漫长的路要走，而你的船不能停或掉头。因此，人员培养是必须要重视的。但其实团队能给的帮助有限，只有足够的压力和适当的指导。适当的指导让其找到方向，适当的压力让其不要懈怠，如此而已。
人必先自救，而后人救之。这句话放在这里依然是适用的。
自组织是不是团队管理的乌托邦
你可能会想，有个先进社会还说达到之后人人富足，衣食无忧，我不也天天在初级阶段生活么？自组织会不会成为团队管理的乌托邦？坦率来讲，我也不知道。我曾经看过（自以为）自组织的影子，但是没有完全实现。
每个人有特定适应的团队，如果你怀疑自组织，你可以不去实践，但你肯定需要寻找自己心仪的团队，不管是加入还是组建。我只是知道我喜欢这样的团队，我也愿意尝试。
你要考虑的问题其实是，你适合什么样的团队。想一想，
你是否能够把握自己的方向？
你是否希望不再被指手画脚？
你是否能够自学愿意帮助他人？
你希望找到一群跟你一样的人？
...
如果是的话，那就值得一试。
我们正在试。
原文： http://ericliang.info/is-self-organization-utopia-of-group-management/
作者: 梁宇鹏|