小团队管理与大团队管理.docxVIP

北大青鸟中关村 小团队管理与大团队管理 我们公司和大部分传统软件公司一样，随着业务的发展和新领域的开拓，公司的管理风格越来越像华为，这是不是最佳的演进路线，我觉得值得探讨，以下是我的思考，希望跟大家讨论。 一个问题 前段时间跟一个创业的朋友聊天，说起他们最近在做的一个项目，这是一个教育行业的管理系统，业务非常复杂，牵涉到的决策人，需要对接的系统也非常多，最后问到他们做了多久完成这个项目，朋友告诉我2个多月，6个人，其中还括一个美工，一个项目经理；剩下的都是开发人员，没有测试，没有前端开发；朋友问我，如果这个项目给你们做，你们需要做多久；我想了想说，这个项目如果交给我们做，顺利的话，至少要半年。 为什么差异这么大呢？ 我们一个一个环节来分析一下，朋友的团队跟客户沟通需求的时候，功能性需求只用一个原型草图，非功能性需求就一个excel表格；如果我们公司做的话，至少要做需求调研报告，需求规格说明书；这个阶段的负责人甚至不会画原型，要到设计阶段才有人能画原型； 到设计阶段，朋友的团队几乎没有什么技术设计，业务按模块给开发人员分一下，各人设计好自己的数据库模型，汇总起来给项目经理看一下，没问题就进入开发阶段了，界面设计花的时间比较久，跟客户反复确认了两三次；如果我们公司做的话，至少要产出原型设计（低保真描述功能的设计稿，高保真描述界面的设计稿），概要设计，详细设计（技术设计、架构设计、网络设计）等等，而且几乎每个设计都要经历评审环节，组织评审就要协调人员，要等大家都有时间的时候再做评审，这都是损耗； 到开发测试阶段，朋友的团队几个开发人员从前端到后端，从开发到测试，都是这几个人做；如果我们公司来做的话，后台开发人员不做前端（不做复杂的前端页面，普通的前端工作还是要做的），质量保证要测试人员保证，测试把BUG提交到BUG管理工具，开发再去BUG管理工具查阅属于自己的BUG，修改完成之后，再关闭BUG，测试再做回归测试；这些流程看起来琐碎，但却损耗了大量的资源； 验收上线阶段，朋友的团队所有人都铺在项目现场，有问题，当场解决；我们公司要收集问题，让测试工程师验证问题，再由开发解决，解决之后再验证，再发布版本给现场的实施工程师，实施工程师再更新上线，给客户验证。 这个问题很明显：规模大的团队和规模小的团队工作方式的差异非常大，组织资源的方式也有明显的区别；我们抽象一下，把这两种模式称为：大军团模式和小编队模式，再看这两种模式的具体区别： 大军团模式 之前有一种理论，要完成一项超大规模的工程，往往需要成百上千人，有组织有纪律的协作才能完成； 这样就需要制定一系列的规章、制度、流程、KPI来约束这些人， 把这些人变成一个庞大机器的零部件，保证结果的达成，避免产生差错； 这是一种非常常见的大组织的运作模式， 不但在软件行业普遍存在（华为、惠普、IBM）， 在造桥、修路、航天、汽车等工业领域也十分常见， 这种模式非常“稳”，他能保证目标的稳定达成，并且能使目标达成的过程清晰、可控。 小编队模式 第三次工业革命（信息技术革命）以来，小编队的运作模式发展越来越好，我司IPCC产品的核心：开源语音通信软件FreeSwitch，核心开发者也不过6个人；（说这个开源软件养活了半个呼叫中心行业的开发者都不足为过）； 这种例子在软件行业不胜枚举，比如：git源码管理系统、linux操作系统、JavaScript语言等等。 甚至有些产品是一个人在短时间内完成的，这就是英雄； 有很多大规模的公司，比如谷歌、Facebook、国内的百度也在内部推行小编队的运作模式； 这种模式非常“快”，他能保证目标的快速达成，并且能使目标达成的效率非常高； 大军团的不足 效率低下 大军团强调集体的智慧， 个体想推动一项事务向正确的方向推进十分困难， 个体的决策往往会受到质疑或排斥 诸如：流程、规范、计划、考核、文档、评审、调研等词 都是为了保证目标的稳定达成所衍生出来的东西， 它们都是团队快速前进的束缚和绊脚石！ 阻碍创新 大军团鼓励墨守成规、照章办事的氛围， 大军团强调分工，把员工看作螺丝钉，希望员工各司其职，不是职责范围内的事务尽量不要碰，因为你不专业，你可能会出错，大军团最害怕出错； 只有这样才能使目标达成的过程清晰可控； 然而创新却需要不拘一格的思想，需要独立自主的工作空间，需要组织具备容错性，这和大军团的工作方式是格格不入的； 资源浪费 为了使目标的达成过程清晰可控； 大军团制定了很多流程和制度来约束个体的行为； 他把每一项事务都拆分成很多环节； 又给每个环节制定了很多关卡； 而且每个环节都要留下数据，使过程有迹可寻； 因为大军团要做到每项事务都可以复盘，产生问题之后要可以追溯问题根源； 这样确实保证了目标达成过程的清晰可控，但却浪费了大量的资源； 小编队的优势 小编队也适合