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

标签: 技术 团队管理 | 发表时间:2014-01-15 18:09 | 作者:
出处:http://kb.cnblogs.com/

  临近年底,接到《程序员》杂志的邀请,希望我能写一篇与团队管理有关的年终盘点文章,盘点2013年业界与团队管理相关的大事。试想,揪出各个公司在2013年的各种“大事”,指点江山,激扬文字,那种众人皆醉我独醒的感觉是相当的妙不可言。可细细一想,2013年可以归纳为团队管理大事的事件倒是不少,例如Yahoo!美女CEO宣布取消在家办公制度,最近又按照绩效评估结果排名开始裁员;最近知乎上好事者提出的“你问什么离开xx公司”系列,各种回答纷至沓来,为2013的团队管理大事记提供了不少素材。可惜,不在局中之人,就算怀着最善意的心思去揣摩,也难以一窥其中究竟,所以对作者来说豪气万分地指点江山,倒极有可能落得个牛头不对马嘴的下场。思忖至此,不觉赧然。正欲一口回绝之际,忽又想起,虽然没法过一把“粪土今年万户侯”的瘾,在这蛇尾巴的当口,和大家分享一下2013年在国内团队管理方面的各种新名词,也是件颇有意思的事情。当然,本人身处互联网行业,做的主要是技术团队管理的事情,眼界所限,也只能以我的个人体验作为整篇文章的基础了。

   2013你方唱罢我登台的名词们

  说起团队管理,我想但凡超过一个人的团队,都会面临这个问题。团队规模小,个体能力强,依靠个人能力就能维持住团队;而如果团队规模较大,一般就需要投入更多的精力来建立良好的团队协作体系,依靠文化和制度建立团队的执行力。从微软到Google再到Facebook,概莫能外。当然,规模与团队管理的方式并不能简单地划等号,巨大如Google这样的公司,仍然在良好的工程师文化的基础之上,保持了相对宽松和灵活的团队管理体系。

  团队管理并非是什么神秘和高端的事情,采用什么样的团队管理方式,既与组织的目标和文化根基相关(说白了就是公司的创始人和早期员工),也和当下的环境(包括行业环境与公司内部环境)相关。随着一波一波的组织兴起,一阵一阵的环境变化,团队管理领域的新名词也如长江后浪推前浪般层出不穷。在2013年的舞台上, 全端工程师、自组织团队、新兵训练营等名词闪闪发光。

  有句老话说:“太阳底下没有新鲜事。”这话放在团队管理领域显然极为适合。纵观技术团队的氛围,从软件领域史前时代单兵作战的黑客群体,到重量级软件工程束缚下的“开发资源”,再到轻量级软件工程对个体能力的重视,团队管理的方式明显在“注重个体”与“注重流程”之间走了一个轮回。显然,采用什么样的团队管理方式无非是“现阶段能够最大化收益的做法”与“团队成员期望”之间的博弈结果。幸好,这种博弈不必是零和博弈,而可以是一种协作博弈。敏捷方法把软件开发看作团队的“合作博弈”,尝试在软件开发效率、客户满意度和工程师的满意度之间找到新的平衡。过去若干年敏捷思潮在软件领域迅速地攻城掠地,一方面固然是由于这种方式能够提升效率,满足了客户和公司业务发展的需要;另一方面也是因为敏捷方法较好地平衡了团队与开发个体的需要。

  不管怎么说,软件行业发展到了现在,软件从最初的个体手工制作进入需要某种规模的协作时代,软件从业人员快速增长,软件开发工具正在逐渐降低开发的门槛,各种软件开发方法与实践层出不穷,这些都使得软件行业中的团队管理方式愈发丰富。在当下,恐怕我们已很难用某种特定的模式或者架构来描述软件领域的技术团队管理趋势,反而活跃在2013年技术团队管理舞台上的新名词,或许能够给我们打开一扇窗,让我们能够透过这些名词窥视到技术团队管理领域的大潮。

   2013年终名词盘点

   全端工程师(Full Stack Engineer)

  2013年最让人印象深刻的技术团队管理方面的名词,非“全端工程师”莫属。“全端工程师”是指那些具有多端开发能力的工程师(例如前端、后端、移动开发端,甚至还有运维端),这类工程师可以一个人搞定一个项目,或者至少可以一个人搞定一个功能所有的设计和开发工作。从“前端工程师”(听说有些企业甚至还有“JavaScript工程师”和“HTML工程师”的分工)、“后端工程师”等日渐细化的职位描述变成高端大气的“全端工程师”,其中的变化可不是简单的名词替换。

  和真实的社会一样,程序员的世界也处于不断的进化中。社会分工往往是社会进步的标志,因此,当程序员分裂成架构师、设计师、开发工程师时,我们并不觉得惊讶;当开发工程师细化成后端工程师、前端工程师之后,我们同样可以把它看作是程序员社会的进步与发展。可“全端工程师”是怎么回事?难道社会分工的发展在程序员的世界中不再适用了?而且“全端工程师”的称号特别让人容易回想起软件领域的史前时代,那时候的黑客们可是真正的全端工程师(当然,我猜他们不一定喜欢工程师这个一点都不酷的称号),软件硬件、编程电路无所不能。

  在当下的软件环境中,“全端工程师”这个概念到底意味着什么呢?在我看来,“全端工程师”的概念与生产工具的发展以及开发需要更加“快速”直接相关。开发语言与开发工具的发展,加上技术开发平台的标准化程度越来越高,可直接使用的框架和组件越来越完善,和几年前相比,如今的工程师可以更容易地掌握多端开发技能。另一方面,越来越受重视的“快速”开发和部署则在进一步寻找开发过程中可优化的部分。显然,如果一个工程师能够从前端到后端完成一个功能或者产品,那么开发人员之间、开发人员与相关协作者之间的沟通成本无疑会变得更小,开发的响应速度也会变得更快。一个拥有足够多“全端工程师”的组织,显然可以以更快的速度和更低的成本开发产品;而一个拥有全端开发能力的“全端工程师”显然也具有更好的适应性和改变世界的能力。《与机器赛跑》这本书把经济周期归结为生产力的提升,认为生产力的提升是造成就业结构变化的主要原因,那些跟不上生产力变化的个体将会被社会无情地淘汰。虽然我并不同意这本书关于经济周期原因的判断,但关于未来,我想说:“一招鲜,吃遍天”早已行不通了。未来的工程师不再需要用前端或者后端的名称定义自己,变革只会把保守的人甩下车。技术的作用在于满足用户已经表现出来或还未表现出来的需求。对工程师来说,发挥价值的地方仍在于与产品的强联系。积极发挥技术的力量,影响产品,影响设计,探索各种可能性,用技术帮助自己所在的组织改变世界才是迈向未来之道。

   自组织团队(Self-organizing Team)

  “自组织团队”这个词2013年也大有市场。这个名词本身并不新鲜,但今年,我多次在各种场合听到演讲者提到这个名词,要么是介绍自身自组织团队的经验,要么是信誓旦旦要成为自组织团队。那么,这个自组织团队,究竟是什么名堂?

  其实,自组织应该可以被看作是宇宙的常态:原子自组织成了分子,细胞自组织成了生命。如果将企业比作生命体,从生命的发展过程来看,我们现在所习惯的这种完全自上而下的控制方式才是怪异且不自然的。当然,社会组织(公司)不是生命体,但越来越多的研究表明,组织更接近类似生命体的复杂系统,而不是对特定输入具有可预测输出的简单决定性系统。

  对一个团队而言,自组织意味着什么?在一个组织中,任何一个参与者都不具有完整的信息,也无法完全理解整个系统。因此,参与者必须集思广益。但如果参与者不能够成为真正的决策者,他们即使能够将所有信息集中起来并得到合理的解决方案,也无法采取任何行动。另外,从心理的角度考虑,如果没有合理的激发机制让参与者有意愿集中自己的信息并解决问题的话,那么组织也无法快速响应遇到的问题。一个自组织的团队需要良好的沟通和决策机制,以及良好的激发和激励机制。

  当然,凡事不可极端。设想企业是一个完全由个体自发组织起来的团队,它能够正常工作吗?我想很难。毕竟,组织的目标与个人的目标不大可能完全一致。从这个意义上说,组织中必须存在一定程度的控制,这样才有可能让整个组织朝着组织的目标顺利前进。然而,过度的控制往往又是扼杀创新的主要原因,卢茨在《绩效致死》这本书中,用生动的案例描述了通用汽车这家曾经是美国骄傲的公司是如何在超强的控制下变得死气沉沉,一片萧条。那么,我们要决定的,就是在自组织和控制之间选择怎样的平衡。而作为一个管理者,借用《管理3.0》一书的描述,管理者就像花园中的园丁:偶尔照料成熟期的系统,让它们自己解决自己的问题;频繁维护年轻的系统,让它们按照组织的意愿生长;对趋于死亡的系统,发现它们并把它们清除出去。

   新兵训练营(Basecamp)

  2013年,新兵训练营“突如一夜春风来”,瞬间在不少公司站稳了脚。各公司开始建立自己的新兵训练营,训练营的名字也各有千秋,从忠厚朴实的“新兵训练营”到高端大气的“特种兵训练营”,不一而足。其实,这些软件公司早就意识到了生力军的重要性,而且也早已有各种形式的新员工培训帮助新员工快速融入自己的组织。虽然新员工培训这颗羊头下,各企业卖的狗肉各不相同——有的企业把新兵训练营做成了技术培训营,有的企业则把新兵训练营变成了“洗脑营”。但毫无疑问,这些组织并非不明白新员工的重要性,也并非没有帮助新员工熟悉工作环境的机制,为什么2013年的舞台上,新兵训练营会受到格外的重视呢?

  新兵训练营这个名字早已有之,在国内软件行业被广泛接受应该与Facebook的实践有关。扎克伯格2012年宣布IPO时对外发表的公开信中提到了Facebook的Bootcamp,并说“业内有许多人负责管理工程师团队,并不愿亲自动手编写代码;然而,我们寻找的实践型人才都希望也能够经受新兵训练营的检验”。Facebook的新兵训练营以严格著称,它不仅是一个培养和训练人的地方,同时也是生产真正符合组织文化的员工的工厂。毫无疑问,Facebook的新兵训练营有不少值得借鉴的地方,无论是它的组织方式,它的强制性,以及它的导师机制,都是值得称道的。不过,在期望新兵训练营发挥文化方面的作用时,各位可得多留点心。

  我相信,每个管理者都希望自己的组织是一个有“文化”的组织,并且愿意花费相当多的精力在自己的组织中“打造”企业文化。这样看来,Facebook的新兵训练营确实是个值得效仿的方式——文化,从新员工抓起。可是,设立一个新兵训练营,设计一套课程,派培训师上去喊喊口号就能够让团队的新成员变成“符合组织文化”的个体?显然没有这么简单。文化并不是虚无缥缈的口号,组织的工作方式、工具、流程、奖励机制等才是实打实的企业文化的体现。一个为经理安排单独办公室,并根据级别设置办公室大小的公司,就算找来全世界最好的培训师,恐怕也没办法说服新员工相信“平等尊重”是公司的文化。因此,想要效仿新兵训练营,首先得理解Facebook的新兵训练营只不过是它的文化体系中的一个组成部分,并非是文化的生产者。与其花大代价去折腾新兵训练营,不如老老实实把自己团队内的文化根基建设好。说白了,新兵训练营值得借鉴的是它的理念和实践,而不是期望它成为组织内的洗脑机器。

   写在最后的话

  2013年即将过去,软件行业又将翻过新一页。在这个唯一不变的就是变化的时代,我尝试从记忆中把今年耳闻最多的三个名词揪出来,算是管中窥豹,和各位读者分享对技术团队管理的理解。

  段念,豆瓣网工程副总裁,有10多年的软件从业经验,从事过通讯、嵌入式系统、互联网等多个行业的工作。对技术团队管理、敏捷开发与测试等领域感兴趣。

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

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

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

团队管理101招

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

小团队管理与大团队管理

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

如何提高团队管理能力?

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

关于UED团队管理的那点事

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

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

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

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

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

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

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

前端技术

- - CSDN博客综合推荐文章
随着互联网产业的爆炸式增长,与之伴生的Web前端技术也在历经洗礼和蜕变. 尤其是近几年随着移动终端的发展,越来越多的人开始投身或转行至新领域,这更为当今的IT产业注入了新的活力. 尽管Web前端技术诞生至今时日并不长,但随着Web技术的逐渐深入,今后将会在以下几方面发力. JavaScript的兄弟们.

SSI技术

- - 开源软件 - ITeye博客
1.       SSI,通常称为“服务器端包含”技术. 使用了SSI技术的文件默认的后缀名为.shtml,SSI技术通过在html文件中加入SSI指令让web服务器在输出标准HTML代码之前先解释SSI指令,并把解释完后的输出结果和HTML代码一起返回给客户端. 2.       SSI技术的优点:SSI技术是通用技术,它不受限于运行环境,在java、dotnet、CGI、ASP、PHP下都可以使用SSI技术;解释SSI的效率比解释JSP的效率快很多,因为JSP规范提供了太多的功能,这些功能都需要servlet引擎一一进行解释,所以效率比较低.