小团队管理与大团队管理

标签: | 发表时间:2017-07-17 15:06 | 作者:
分享到:
出处:http://mp.weixin.qq.com


来源:liulun

www.cnblogs.com/liulun/p/7159705.html

如有好文章投稿,请点击 → 这里了解详情



我们公司和大部分传统软件公司一样,随着业务的发展和新领域的开拓,公司的管理风格越来越像华为,这是不是最佳的演进路线,我觉得值得探讨,以下是我的思考,希望跟大家讨论。

一个问题

前段时间跟一个创业的朋友聊天,说起他们最近在做的一个项目,这是一个教育行业的管理系统,业务非常复杂,牵涉到的决策人,需要对接的系统也非常多,最后问到他们做了多久完成这个项目,朋友告诉我2个多月,6个人,其中还括一个美工,一个项目经理;剩下的都是开发人员,没有测试,没有前端开发;朋友问我,如果这个项目给你们做,你们需要做多久;我想了想说,这个项目如果交给我们做,顺利的话,至少要半年。

为什么差异这么大呢?

我们一个一个环节来分析一下,朋友的团队跟客户沟通需求的时候,功能性需求只用一个原型草图,非功能性需求就一个excel表格;如果我们公司做的话,至少要做需求调研报告,需求规格说明书;这个阶段的负责人甚至不会画原型,要到设计阶段才有人能画原型;

到设计阶段,朋友的团队几乎没有什么技术设计,业务按模块给开发人员分一下,各人设计好自己的数据库模型,汇总起来给项目经理看一下,没问题就进入开发阶段了,界面设计花的时间比较久,跟客户反复确认了两三次;如果我们公司做的话,至少要产出原型设计(低保真描述功能的设计稿,高保真描述界面的设计稿),概要设计,详细设计(技术设计、架构设计、网络设计)等等,而且几乎每个设计都要经历评审环节,组织评审就要协调人员,要等大家都有时间的时候再做评审,这都是损耗;

到开发测试阶段,朋友的团队几个开发人员从前端到后端,从开发到测试,都是这几个人做;如果我们公司来做的话,后台开发人员不做前端(不做复杂的前端页面,普通的前端工作还是要做的),质量保证要测试人员保证,测试把BUG提交到BUG管理工具,开发再去BUG管理工具查阅属于自己的BUG,修改完成之后,再关闭BUG,测试再做回归测试;这些流程看起来琐碎,但却损耗了大量的资源;

验收上线阶段,朋友的团队所有人都铺在项目现场,有问题,当场解决;我们公司要收集问题,让测试工程师验证问题,再由开发解决,解决之后再验证,再发布版本给现场的实施工程师,实施工程师再更新上线,给客户验证。

这个问题很明显:规模大的团队和规模小的团队工作方式的差异非常大,组织资源的方式也有明显的区别;我们抽象一下,把这两种模式称为:大军团模式和小编队模式,再看这两种模式的具体区别:

大军团模式

之前有一种理论,要完成一项超大规模的工程,往往需要成百上千人,有组织有纪律的协作才能完成;

这样就需要制定一系列的规章、制度、流程、KPI来约束这些人,

把这些人变成一个庞大机器的零部件,保证结果的达成,避免产生差错;

这是一种非常常见的大组织的运作模式,

不但在软件行业普遍存在(华为、惠普、IBM),

在造桥、修路、航天、汽车等工业领域也十分常见,

这种模式非常“稳”,他能保证目标的稳定达成,并且能使目标达成的过程清晰、可控。

小编队模式

第三次工业革命(信息技术革命)以来,小编队的运作模式发展越来越好,我司IPCC产品的核心:开源语音通信软件FreeSwitch,核心开发者也不过6个人;(说这个开源软件养活了半个呼叫中心行业的开发者都不足为过); 这种例子在软件行业不胜枚举,比如:git源码管理系统、linux操作系统、JavaScript语言等等。

甚至有些产品是一个人在短时间内完成的,这就是英雄;

有很多大规模的公司,比如谷歌、Facebook、国内的百度也在内部推行小编队的运作模式;

这种模式非常“快”,他能保证目标的快速达成,并且能使目标达成的效率非常高;

大军团的不足

效率低下

大军团强调集体的智慧,

个体想推动一项事务向正确的方向推进十分困难,

个体的决策往往会受到质疑或排斥

诸如:流程、规范、计划、考核、文档、评审、调研等词

都是为了保证目标的稳定达成所衍生出来的东西,

它们都是团队快速前进的束缚和绊脚石!

阻碍创新

大军团鼓励墨守成规、照章办事的氛围,

大军团强调分工,把员工看作螺丝钉,希望员工各司其职,不是职责范围内的事务尽量不要碰,因为你不专业,你可能会出错,大军团最害怕出错;

只有这样才能使目标达成的过程清晰可控;

然而创新却需要不拘一格的思想,需要独立自主的工作空间,需要组织具备容错性,这和大军团的工作方式是格格不入的;

资源浪费

为了使目标的达成过程清晰可控;

大军团制定了很多流程和制度来约束个体的行为;

他把每一项事务都拆分成很多环节;

又给每个环节制定了很多关卡;

而且每个环节都要留下数据,使过程有迹可寻;

因为大军团要做到每项事务都可以复盘,产生问题之后要可以追溯问题根源;

这样确实保证了目标达成过程的清晰可控,但却浪费了大量的资源;

小编队的优势

小编队也适合做大项目

有很多很庞大复杂的软件系统,都是以小编队的方式完成的;

比如操作系统linux,大数据分析系统hadoop,我们这个行业的freeSwitch等;

如果一个项目大到一定的规模,需要不同角色的人参与,那么也应该是有更多的小编队来做这一块事情;甚至更极端的做法,就是一个项目在建设之初,就考虑到会有很多小编队或个人参与到项目建设过程中,预留了多人、多团队协作的支撑工具,比如说nodejs的NPM,go语言和rust语言也有相应的规划;

小编队有很强的执行力

小编队不会说这个事情需要做个评审;

小编队不会说这个事情安排的资源不够,需要协调更多的资源;

小编队会把这个事情当成自己的事情,不会像大军团一样,把这个事情当成大家的事情来对待;

我们来看个图:

(图片遗失,暂不补充)

小编队有很强的创新力

软件行业不像建筑行业,90%以上的优秀软件一开始都是个人或者小编队创造出来的;很少见一个优秀软件是一个大规模的组织创造出来的。

一个案例

张小龙曾经说过一段话:

好的工具就不应该黏人,应该帮助用户非常高效率完成任务,而不是说用完了还要拿到手里玩一会儿、多用一会儿,那不是一个很高效的表现。但是对这样的一些想法的话,我特别希望它能够根植到大家意识里,时刻想一下什么是我们做的对用户有价值的事情;

假设你是马化腾,你会怎么给张小龙定KPI呢?考核微信的日活吗?……

无论你制定什么KPI,都会导致团队去围绕着那个KPI去完成任务;

KPI考核准则里有一项原则就是“可度量”,当你提出一项纯数据目标的时候,团队就会围绕着那个数字去工作。而偏离了做好产品的初心。

一个团队工作的目的不应该是完成KPI,工作的目的应该是做好产品,完成KPI只不过是做好产品这件事情的副产物,就像一个人好好工作的目的不应该是为了赚钱,他好好工作的副产物是赚了很多钱;

所以你制定了一系列的kpi考核制度,只能导致员工工作的动机更不纯粹。

最后

一个组织只要发展良好,总是会吸引更多的资源,所以组织规模的扩大是无可避免的,但如果一个组织规模已经超过500人了,那么你应该把他看作是50~100个小团队来对待,而不是把他当作一个500人的大团队来对待;



看完本文有收获?请分享给更多人

关注「伯乐在线」,看更多精选 IT 职场文章

相关 [团队管理 团队管理] 推荐:

团队管理101招

- 狂之想 - C++博客-牵着老婆满街逛
转载自:http://www.iteer.net/modules/doc/article.php?storyid=1402. 无论你是新手还是资深管理人,对你而言,管理好团队都是重要且具激励性的挑战. 切记:每位成员都能为团队作出一些贡献. 谨慎地设定团队目标,且认真严肃地对待它们. 尽早决定何种形态的团队适合你的目标.

小团队管理与大团队管理

- -
如有好文章投稿,请点击 → 这里了解详情. 我们公司和大部分传统软件公司一样,随着业务的发展和新领域的开拓,公司的管理风格越来越像华为,这是不是最佳的演进路线,我觉得值得探讨,以下是我的思考,希望跟大家讨论. 前段时间跟一个创业的朋友聊天,说起他们最近在做的一个项目,这是一个教育行业的管理系统,业务非常复杂,牵涉到的决策人,需要对接的系统也非常多,最后问到他们做了多久完成这个项目,朋友告诉我2个多月,6个人,其中还括一个美工,一个项目经理;剩下的都是开发人员,没有测试,没有前端开发;朋友问我,如果这个项目给你们做,你们需要做多久;我想了想说,这个项目如果交给我们做,顺利的话,至少要半年.

如何提高团队管理能力?

- - 人人都是产品经理
接手任何一个部门的最重要的事情,是明确或者重新调整组织架构. 架构的关键是:谁在什么位置,负责什么内容,一定要明确. 出了问题,大家都清楚谁应该出来承担责任. 领导不是决定怎么爬梯子的人: 他是决定把梯子搭在哪个墙上的人. 所以他必须明确的指出这个方向,向全员传达. 如果这个没有做好,再优秀的团队也不会拿出好的结果.

关于技术团队管理的胡言乱语

- - 博客园_知识库
  临近年底,接到《程序员》杂志的邀请,希望我能写一篇与团队管理有关的年终盘点文章,盘点2013年业界与团队管理相关的大事. 试想,揪出各个公司在2013年的各种“大事”,指点江山,激扬文字,那种众人皆醉我独醒的感觉是相当的妙不可言. 可细细一想,2013年可以归纳为团队管理大事的事件倒是不少,例如Yahoo!美女CEO宣布取消在家办公制度,最近又按照绩效评估结果排名开始裁员;最近知乎上好事者提出的“你问什么离开xx公司”系列,各种回答纷至沓来,为2013的团队管理大事记提供了不少素材.

关于UED团队管理的那点事

- - legene的用户体验设计
昨天晚上跟几个做设计leader的朋友聊天,对方谈起目前的工作情况和难处,我听了后觉得很有感触. 如果换做一年前的我在这里,也一定也会遇到同样的处境. “产品经理觉得交互设计师的出现增加了一个环节,效率降低了”;. “我们设计好的方案产品经理挑了一部分做,然后功劳就变成他们的了”;. “我们辛辛苦苦设计的方案产品经理总是不采用,等上线后发现体验不好大领导又责怪我们,说UED是怎么做的设计”;.

公司团队管理大敌:营造内部帝国的“小帝王”

- - 创业邦
  对权力、声望、财富的追求没完没了,把部门越做越大,直到整个公司失控.   文 | Joe Robinson.   你的公司里是否有一种人,像是被“集邮”进来的. 他们在公司不起眼的地方混吃等死,没什么贡献. 这些人的存在拜某些部门领导所赐——他们在公司里建造了一个属于自己的小国家.   在管理学中,这种现象被称为“营造帝国”,员工数量和财政预算急速增长,人人自我膨胀——这会毁了你的团队、你的企业生存线.

[原]敏捷开发团队管理系列之七:大型研发管理团队的切分(二)

- - 陈勇的博客 - Scrum 敏捷开发培训咨询,绩效管理,团队管理,《火星人敏捷开发手册》
这是敏捷开发团队管理系列的第八篇( 团队管理栏目目录). 还是敏捷开发一千零一问的第二十八篇( 在这里提问, 之一, 之二, 之三, 问题总目录). 还是敏捷开发松结对编程系列的第十三篇( 松结对编程栏目目录),与之前系列 第六篇139团队、 第九篇微软TechED上的讲座有密切关系.

谷歌前产品经理谈创业团队管理:做好情景管理,控制团队规模

- - ITeye资讯频道
原文作者Tomasz Tunguz是Redpoint Ventures的风险投资人,曾在Google担任产品经理并参与过AdSense项目. 在文中,Tomasz Tunguz针对创业公司给出了2条极富实践性的建议: 针对不同类型的员工,做好激励和情景管理;努力平衡控制范围和管理职责范围(下文由 36Kr进行编译整理).