摘要:软件开发是一项团队活动,必然需要团队成员间的交流与协作。由此,如何提高团队协作的效率便成为大家共同关注的话题。本期三位嘉宾将结合自己的实践经验与大家一起探讨。
金仕达卫宁软件科技有限公司首席架构师李枫:审时度势,及时调整
分工合理,责任明确
团队是由个人组成的,团队中的个人往往经历不同、背景不同、性格有差异、水平有高低。在团队形成后、正式开工前,首先应该进行合理分工,要结合每个人的特点和爱好,充分发挥出每个人的特长。因为如果工作不愉快、不顺手的话,效率自然低下。分工完成后,每个人对应的职责也就确定了。这时应该同每一位团队成员进行明确申明,最好以文字形式落实到个人并与日常绩效考核挂钩,以避免互相推诿、相互等待的情况出现。
制定高效的沟通机制
分工完成后团队即开始工作,此时必须保证信息在整个团队内的畅通,特别是互相之间有工作关联的同事,在发现问题时需要及时提出,以免造成不必要的工时浪费。但软件开发本身是一种需要精力集中并且安静的工作,多次临时性的打断会造成开发思路的停滞,因此团队负责人最好能够每天在固定的时间段内组织大家进行沟通,并了解工作的进度。而固定的时间也会让大家形成习惯,使效率得到提升。
发现团队瓶颈
大家往往会陷入一种误区,认为团队中每个员工效率发挥到极致的时候就是这个团队效率最高的时候。但经过企业管理实践不断的论证,这种想法其实是非常可怕的谬论。正确的做法应该是将整个团队看成一个整体,再去谈效率问题。团队的分工协作就好比是生产的流水线,流水线的整体生产效率不取决于流水线上效率最高的环节,而取决于效率最低、速度最慢的环节。当流水线上某一环节出现故障而停滞时,整个流水线也就停滞了。这也是常说的木桶原理。所以我们必须时刻去发现团队中的短板,尽一切力量帮助它,提高它的效率。这样,也许会牺牲局部某些个人的效率,但经过一段时间的实施后,你可能会惊奇地发现整个团队的效率变高了。
定期检查,及时调整
流水线的机器是死的,而程序员们是活的。因此团队的瓶颈也许会因为调整而发生变化,这时需要团队负责人审时度势,及时进行调整。也许需要修正前期的分工,也许需要改变正在使用的技术,甚至是更换无法胜任的团队成员。让整个团队的工作效率保持在一个较高的并且能够相互匹配的水平,这样做非常重要。
总结
团队是一个整体,不能靠每个员工进行单打独斗,要始终牢记团队的最终效用取决于团队中效率最低的环节。进行合理分工是预防瓶颈发生的前提,而建立高效的沟通机制则是发现瓶颈的有效方法。当瓶颈环节出现后要尽团队最大力量去发挥其效用,而当瓶颈发生变化时需及时做出调整,才能提高团队协作的效率。
杭州云图科技有限公司研发总监,资深项目管理专家涂勇:提升研发团队协作效率的四个秘诀
要提升研发团队的协作效率,我认为可从目标、规则、沟通和工具四个方面入手。
目标,让团队成员有明确的前进方向
清晰明确的团队目标可以对团队高效协作形成很强的牵引力,更重要的是,团队目标是团队成员个人目标制定的前提。要让团队高效率的协作,最好的方法就是让团队所有成员每时每刻的工作都围绕团队目标开展。需要指出的是,将团队的目标分解成近期目标、中期目标和远期目标是一个值得推荐的做法。此外,少数优秀的团队管理者甚至能够将团队的远期目标上升到团队使命感和价值观的高度。要做到这点,管理者需具备卓越的领导力。
具体到研发管理,对项目而言,明确项目目标并不困难,诸如产品发布、系统上线等这些都可以作为项目目标,并且项目经理也可以很容易以项目计划的形式来加以落实。但对职能部门的管理者而言,制定好职能部门的目标就很考验管理水平。职能部门的经理不应忽视部门目标的重要性,而这可以与团队成员的个人职业发展目标结合起来考虑。
规则,让团队成员始终保持住队形
高效率团队运作,一定有良好的团队规则做保证。明确告诉团队成员,什么样的行为是团队所不能容忍的,并将其形成制度。制度违反者都应受到相应的惩罚,并做到及时(第一时间)、公平(一视同仁)、公开(团队内部)。制度是团队的高压线,不坚决执行的制度还不如没有制度,记住这点很重要。
如果说制度告诉团队什么事不能做,那么规范就是告诉团队成员尤其是新进入团队的成员应该怎样做。文档规范、编程规范、原理图设计规范等开发规范,是团队高效率协作的保证。规范不是制度,可以容忍一时不遵守规范的情况,但应该让团队在遵守规范方面做得越来越好。培训、优秀案例和反面教材宣传等都是推行规范的好实践。另外,规范不是高压线,不赞成对违反规范的成员进行惩罚,最好的方式是对在规范方面做得优秀的人进行公开表扬。
制度和规范都是针对的人,对事来说规则即是流程。没有高效率的工作流程,也就没有高效率的团队。对于牵涉多人协作的工作,即使是一个设计不完备的流程也比没有流程好。值得指出的是:流程应该随着团队内外部的环境变化而做持续优化,在一些大公司中甚至会成立专门的流程改进小组,足见流程持续优化的重要性。
沟通,让团队成员凝聚成一个有机的整体
良好的沟通对一个高效率团队有多么重要,熟悉Scrum的朋友对此会有更深刻的体会。“坐到一起,每日站立会议,Review会议”,Scrum在团队沟通方面推崇的最佳实践都体现了沟通的重要性。为什么很多公司搬入新办公大楼后就开始走下坡路?下面的这个分析很可能就是主要原因:团队成员在新办公区的座位会比以前拉得更大,以前与团队成员坐在一起的主管们搬入了独立的办公室,而这会导致团队间原来形成的良好沟通氛围消失,其后果严重到足以给企业带来致命打击!好吧,我承认这听起来有点骇人听闻,目的只是想借此强调一下沟通的重要性。
通过开会来达到团队沟通的目的是一种好的方式吗?有人会说是,有人会说不是。其实,开会这种方式,无所谓好与不好,关键就两点:是否有必要开会以及开个什么样的会。我的个人感触:一人用嘴大家用耳的会应该是表彰大会;开了跟没开一样的会最好是批判大会;如果开会有人睡着了,大多数情况下是因为会议本身具有催眠效果。
相比开会这种沟通方式,我更喜欢现场管理和看板管理。
工具,是团队高效率协作的倍增器
这方面最容易让人想到的也是大多数团队目前所采用的方法就是:引入适合团队的协同软件。前面介绍的明确目标、制定规范和加强沟通等方面的措施,如果能有合适的团队协同工具支持和配合,推行起来则要顺利很多。
如何选择一款合适的协同软件呢?引入的协同软件贵在精而不在多,功能完备集成性好的协同软件可以避免引入过多系统而产生的信息孤岛。侧重自上而下管控的IT 系统只会在规范团队方面起作用,要提升团队协作效率,更应该选择实现注重协作性的系统。免费的协同软件大多不如付费的,但价格昂贵的协同软件对多数团队而言并不适合。
优秀的管理者的工具箱中,总是会有各种各样的宝贝。诸如团队绩效、团队竞争等都是激发团队成员潜能和斗志的好方法,实施得好的话,可以显著提升团队成员间的协同效率。
如果你正好在带团队,不妨尝试一下上面提到的这些方法,相信你的团队的协作效率一定会越来越高。
Pragmatic.ly 联合创始人,Teahour.FM主播系统架构师叶玎玎:创业型开发团队的协作心得
毫无疑问,Stephen R. Covey的《The 7 Habits of Highly Effective People》和David Allen的 《Getting Things Done: The Art of Stress-Free Productivity》是个人管理类的超级畅销书,让我们学会如何才能成为高效能人士。然而,即使团队里的所有人都是高效能人士,这个团队也不一定是个高效能团队。我们常说“一个和尚有水喝,两个和尚挑水喝,三个和尚没水喝”,正是出于这个道理。顾名思义,团队协作是指所有团队成员之间协同、合作,里面会有分工、沟通、协调,甚至会有妥协,所以我们需要一些规则和工具来帮助团队提高协作效率。本文的一些心得和实践来自于我在小团队(<10)的经验,并且在团队内部相互信任、目标一致的基础上,所以不涉及办公室人事管理,适合于创业型开发团队。
目标一致
不仅要确保团队的长期目标一致,还要确保短期目标一致。如同在足球场踢球,刚开始比赛时,大家战术和思想都是一致的。而一旦进球后,就会出现有人想守,有人想攻的情况,这种不一致会造成局面被动并可能导致输球。创业团队也是如此。所以在任何时候,团队成员都要保持一致意见:现阶段的目标是什么,什么事情对团队最重要,然后所有做的事情都配合这个目标来完成。
合理安排
小团队人少,永远有做不完的事,所以在做计划时总是害怕资源出现闲置而添加过多任务。我们一开始也是如此。但慢慢发现,这样不仅弄得团队身心俱疲,不停地赶进度,而且也会因为不停地延期导致团队很沮丧、压力过大影响工作的心情和状态。因此,现在每次迭代只会给大家80%~90%的工作量。有意思的是,很多时候时间都是刚刚够。
易者优先
如果讨论时遇到意见分歧,且这些不一致的意见不涉及对错,那么会很容易陷入各自试图说服别人接受自己观点的困境,纯属浪费时间。所以我们采用易者优先原则,设置了单任务最长讨论时间。一旦超过讨论时间又无法达成共识,就会选择最简单的方案,先做出来,然后大家测试,最后再做改进。
免扰模式
确定项目计划后,我们就基本启动了免扰模式。我们不鼓励在工作时随意地打断别人,即使是一起在办公室工作时。在我们看来,每一次粗暴的打扰(例如电话、 IM)都是对效率的损害,我们更需要的是100%专注在要做的事情上。因此,我们要求每个人如果需要讨论,就先想清楚整个问题,然后在 Pragmatic.ly或者Hipchat里发出来。短时间来看可能回复会有延时,但从长期来看反而能让大家都能更深入的思考、更专注的工作。
尽量避免会议。只有一个例外是遇到困难需要头脑风暴时,因为开会比起文字是效率更高的选择。但只有任务涉及者才需要参与,而不需要浪费其他人的时间。
状态同步
团队人越多,沟通成本越高,尤其是需要知道团队的当前状态时,例如目前进度如何,接下来有哪些事情要做,做完的时候需不需要其他成员帮忙审查,或者有没有卡在某些地方需要帮助。这些状态和信息同步是非常耗时的,我们更倾向于用眼睛看代替嘴巴说,而 Pragmatic.ly就很好地满足了这点。项目里的所有信息和状态都会实时地同步给整个团队。
代码审查
作为开发团队,我们不一定能保证每个任务都有充足的测试覆盖而且也不追求100%覆盖率。但每一段代码、每一次修改,都必须有其他人来审查,通过后才能进入主干。代码审查中可以发现当事者没考虑过的设计细节和一些实现上的Bug,保证了软件质量。通过代码审查,每个人可以学习到其他人好的思维方式和编码方式,也会提出做的不好的地方和改进意见,是整个团队在代码级别的另一种沟通和思考,促进了团队的成长。代码审查也能避免单点故障,万一出了问题,即使代码编写者不在,仍然有其他人能立刻去修正。
过程审查
除代码需要审查外,过程也是一个很有审查必要的事情。所以我们会不定时地一起进行一次简单的回顾,各自对这个周期的一些工作提出意见,然后在下一个周期里有针对性地改进。整个工作过程就是这样不断地在迭代式调整和改进,让我们根据自身的情况,实践出最适合团队的方式。
健康工作
要想工作好,身体先练好。一个健康的成员才可能高效地工作。在Y Combinator有个理论,在产品发布前,你应该专注并只专注两件半事情,1开发+1跟用户聊天+0.5锻炼身体。而在产品发布后,你应该专注并只专注三件事情,0.5开发+1跟用户聊天+1运营+0.5锻炼身体。可见锻炼身体的重要。我们团队每个人基本每天都会有专门的运动时间,跑步、游泳,或者健身房,已然成了我们工作的一部分。
金仕达卫宁软件科技有限公司首席架构师李枫:审时度势,及时调整
分工合理,责任明确
团队是由个人组成的,团队中的个人往往经历不同、背景不同、性格有差异、水平有高低。在团队形成后、正式开工前,首先应该进行合理分工,要结合每个人的特点和爱好,充分发挥出每个人的特长。因为如果工作不愉快、不顺手的话,效率自然低下。分工完成后,每个人对应的职责也就确定了。这时应该同每一位团队成员进行明确申明,最好以文字形式落实到个人并与日常绩效考核挂钩,以避免互相推诿、相互等待的情况出现。
制定高效的沟通机制
分工完成后团队即开始工作,此时必须保证信息在整个团队内的畅通,特别是互相之间有工作关联的同事,在发现问题时需要及时提出,以免造成不必要的工时浪费。但软件开发本身是一种需要精力集中并且安静的工作,多次临时性的打断会造成开发思路的停滞,因此团队负责人最好能够每天在固定的时间段内组织大家进行沟通,并了解工作的进度。而固定的时间也会让大家形成习惯,使效率得到提升。
发现团队瓶颈
大家往往会陷入一种误区,认为团队中每个员工效率发挥到极致的时候就是这个团队效率最高的时候。但经过企业管理实践不断的论证,这种想法其实是非常可怕的谬论。正确的做法应该是将整个团队看成一个整体,再去谈效率问题。团队的分工协作就好比是生产的流水线,流水线的整体生产效率不取决于流水线上效率最高的环节,而取决于效率最低、速度最慢的环节。当流水线上某一环节出现故障而停滞时,整个流水线也就停滞了。这也是常说的木桶原理。所以我们必须时刻去发现团队中的短板,尽一切力量帮助它,提高它的效率。这样,也许会牺牲局部某些个人的效率,但经过一段时间的实施后,你可能会惊奇地发现整个团队的效率变高了。
定期检查,及时调整
流水线的机器是死的,而程序员们是活的。因此团队的瓶颈也许会因为调整而发生变化,这时需要团队负责人审时度势,及时进行调整。也许需要修正前期的分工,也许需要改变正在使用的技术,甚至是更换无法胜任的团队成员。让整个团队的工作效率保持在一个较高的并且能够相互匹配的水平,这样做非常重要。
总结
团队是一个整体,不能靠每个员工进行单打独斗,要始终牢记团队的最终效用取决于团队中效率最低的环节。进行合理分工是预防瓶颈发生的前提,而建立高效的沟通机制则是发现瓶颈的有效方法。当瓶颈环节出现后要尽团队最大力量去发挥其效用,而当瓶颈发生变化时需及时做出调整,才能提高团队协作的效率。
杭州云图科技有限公司研发总监,资深项目管理专家涂勇:提升研发团队协作效率的四个秘诀
要提升研发团队的协作效率,我认为可从目标、规则、沟通和工具四个方面入手。
目标,让团队成员有明确的前进方向
清晰明确的团队目标可以对团队高效协作形成很强的牵引力,更重要的是,团队目标是团队成员个人目标制定的前提。要让团队高效率的协作,最好的方法就是让团队所有成员每时每刻的工作都围绕团队目标开展。需要指出的是,将团队的目标分解成近期目标、中期目标和远期目标是一个值得推荐的做法。此外,少数优秀的团队管理者甚至能够将团队的远期目标上升到团队使命感和价值观的高度。要做到这点,管理者需具备卓越的领导力。
具体到研发管理,对项目而言,明确项目目标并不困难,诸如产品发布、系统上线等这些都可以作为项目目标,并且项目经理也可以很容易以项目计划的形式来加以落实。但对职能部门的管理者而言,制定好职能部门的目标就很考验管理水平。职能部门的经理不应忽视部门目标的重要性,而这可以与团队成员的个人职业发展目标结合起来考虑。
规则,让团队成员始终保持住队形
高效率团队运作,一定有良好的团队规则做保证。明确告诉团队成员,什么样的行为是团队所不能容忍的,并将其形成制度。制度违反者都应受到相应的惩罚,并做到及时(第一时间)、公平(一视同仁)、公开(团队内部)。制度是团队的高压线,不坚决执行的制度还不如没有制度,记住这点很重要。
如果说制度告诉团队什么事不能做,那么规范就是告诉团队成员尤其是新进入团队的成员应该怎样做。文档规范、编程规范、原理图设计规范等开发规范,是团队高效率协作的保证。规范不是制度,可以容忍一时不遵守规范的情况,但应该让团队在遵守规范方面做得越来越好。培训、优秀案例和反面教材宣传等都是推行规范的好实践。另外,规范不是高压线,不赞成对违反规范的成员进行惩罚,最好的方式是对在规范方面做得优秀的人进行公开表扬。
制度和规范都是针对的人,对事来说规则即是流程。没有高效率的工作流程,也就没有高效率的团队。对于牵涉多人协作的工作,即使是一个设计不完备的流程也比没有流程好。值得指出的是:流程应该随着团队内外部的环境变化而做持续优化,在一些大公司中甚至会成立专门的流程改进小组,足见流程持续优化的重要性。
沟通,让团队成员凝聚成一个有机的整体
良好的沟通对一个高效率团队有多么重要,熟悉Scrum的朋友对此会有更深刻的体会。“坐到一起,每日站立会议,Review会议”,Scrum在团队沟通方面推崇的最佳实践都体现了沟通的重要性。为什么很多公司搬入新办公大楼后就开始走下坡路?下面的这个分析很可能就是主要原因:团队成员在新办公区的座位会比以前拉得更大,以前与团队成员坐在一起的主管们搬入了独立的办公室,而这会导致团队间原来形成的良好沟通氛围消失,其后果严重到足以给企业带来致命打击!好吧,我承认这听起来有点骇人听闻,目的只是想借此强调一下沟通的重要性。
通过开会来达到团队沟通的目的是一种好的方式吗?有人会说是,有人会说不是。其实,开会这种方式,无所谓好与不好,关键就两点:是否有必要开会以及开个什么样的会。我的个人感触:一人用嘴大家用耳的会应该是表彰大会;开了跟没开一样的会最好是批判大会;如果开会有人睡着了,大多数情况下是因为会议本身具有催眠效果。
相比开会这种沟通方式,我更喜欢现场管理和看板管理。
工具,是团队高效率协作的倍增器
这方面最容易让人想到的也是大多数团队目前所采用的方法就是:引入适合团队的协同软件。前面介绍的明确目标、制定规范和加强沟通等方面的措施,如果能有合适的团队协同工具支持和配合,推行起来则要顺利很多。
如何选择一款合适的协同软件呢?引入的协同软件贵在精而不在多,功能完备集成性好的协同软件可以避免引入过多系统而产生的信息孤岛。侧重自上而下管控的IT 系统只会在规范团队方面起作用,要提升团队协作效率,更应该选择实现注重协作性的系统。免费的协同软件大多不如付费的,但价格昂贵的协同软件对多数团队而言并不适合。
优秀的管理者的工具箱中,总是会有各种各样的宝贝。诸如团队绩效、团队竞争等都是激发团队成员潜能和斗志的好方法,实施得好的话,可以显著提升团队成员间的协同效率。
如果你正好在带团队,不妨尝试一下上面提到的这些方法,相信你的团队的协作效率一定会越来越高。
Pragmatic.ly 联合创始人,Teahour.FM主播系统架构师叶玎玎:创业型开发团队的协作心得
毫无疑问,Stephen R. Covey的《The 7 Habits of Highly Effective People》和David Allen的 《Getting Things Done: The Art of Stress-Free Productivity》是个人管理类的超级畅销书,让我们学会如何才能成为高效能人士。然而,即使团队里的所有人都是高效能人士,这个团队也不一定是个高效能团队。我们常说“一个和尚有水喝,两个和尚挑水喝,三个和尚没水喝”,正是出于这个道理。顾名思义,团队协作是指所有团队成员之间协同、合作,里面会有分工、沟通、协调,甚至会有妥协,所以我们需要一些规则和工具来帮助团队提高协作效率。本文的一些心得和实践来自于我在小团队(<10)的经验,并且在团队内部相互信任、目标一致的基础上,所以不涉及办公室人事管理,适合于创业型开发团队。
目标一致
不仅要确保团队的长期目标一致,还要确保短期目标一致。如同在足球场踢球,刚开始比赛时,大家战术和思想都是一致的。而一旦进球后,就会出现有人想守,有人想攻的情况,这种不一致会造成局面被动并可能导致输球。创业团队也是如此。所以在任何时候,团队成员都要保持一致意见:现阶段的目标是什么,什么事情对团队最重要,然后所有做的事情都配合这个目标来完成。
合理安排
小团队人少,永远有做不完的事,所以在做计划时总是害怕资源出现闲置而添加过多任务。我们一开始也是如此。但慢慢发现,这样不仅弄得团队身心俱疲,不停地赶进度,而且也会因为不停地延期导致团队很沮丧、压力过大影响工作的心情和状态。因此,现在每次迭代只会给大家80%~90%的工作量。有意思的是,很多时候时间都是刚刚够。
易者优先
如果讨论时遇到意见分歧,且这些不一致的意见不涉及对错,那么会很容易陷入各自试图说服别人接受自己观点的困境,纯属浪费时间。所以我们采用易者优先原则,设置了单任务最长讨论时间。一旦超过讨论时间又无法达成共识,就会选择最简单的方案,先做出来,然后大家测试,最后再做改进。
免扰模式
确定项目计划后,我们就基本启动了免扰模式。我们不鼓励在工作时随意地打断别人,即使是一起在办公室工作时。在我们看来,每一次粗暴的打扰(例如电话、 IM)都是对效率的损害,我们更需要的是100%专注在要做的事情上。因此,我们要求每个人如果需要讨论,就先想清楚整个问题,然后在 Pragmatic.ly或者Hipchat里发出来。短时间来看可能回复会有延时,但从长期来看反而能让大家都能更深入的思考、更专注的工作。
尽量避免会议。只有一个例外是遇到困难需要头脑风暴时,因为开会比起文字是效率更高的选择。但只有任务涉及者才需要参与,而不需要浪费其他人的时间。
状态同步
团队人越多,沟通成本越高,尤其是需要知道团队的当前状态时,例如目前进度如何,接下来有哪些事情要做,做完的时候需不需要其他成员帮忙审查,或者有没有卡在某些地方需要帮助。这些状态和信息同步是非常耗时的,我们更倾向于用眼睛看代替嘴巴说,而 Pragmatic.ly就很好地满足了这点。项目里的所有信息和状态都会实时地同步给整个团队。
代码审查
作为开发团队,我们不一定能保证每个任务都有充足的测试覆盖而且也不追求100%覆盖率。但每一段代码、每一次修改,都必须有其他人来审查,通过后才能进入主干。代码审查中可以发现当事者没考虑过的设计细节和一些实现上的Bug,保证了软件质量。通过代码审查,每个人可以学习到其他人好的思维方式和编码方式,也会提出做的不好的地方和改进意见,是整个团队在代码级别的另一种沟通和思考,促进了团队的成长。代码审查也能避免单点故障,万一出了问题,即使代码编写者不在,仍然有其他人能立刻去修正。
过程审查
除代码需要审查外,过程也是一个很有审查必要的事情。所以我们会不定时地一起进行一次简单的回顾,各自对这个周期的一些工作提出意见,然后在下一个周期里有针对性地改进。整个工作过程就是这样不断地在迭代式调整和改进,让我们根据自身的情况,实践出最适合团队的方式。
健康工作
要想工作好,身体先练好。一个健康的成员才可能高效地工作。在Y Combinator有个理论,在产品发布前,你应该专注并只专注两件半事情,1开发+1跟用户聊天+0.5锻炼身体。而在产品发布后,你应该专注并只专注三件事情,0.5开发+1跟用户聊天+1运营+0.5锻炼身体。可见锻炼身体的重要。我们团队每个人基本每天都会有专门的运动时间,跑步、游泳,或者健身房,已然成了我们工作的一部分。