BT

技术团队的情绪与效率

作者 申玉宝 发布于 2015年1月15日 | ArchSummit 全球架构师峰会(北京站)2016年12月02-03日举办,了解更多详情!

引:为什么工程师的效率有那么明显的波峰波谷?为什么会有负面情绪?负面情绪与工作效率有什么关系? 团队 Leader 应该怎样保证整体的效率输出与大家的成长?为什么醉心于技术的同学做项目总是虎头蛇尾?

对工程师来说经常会有明显的效率差异,有时一天能搞定好几个模块,顺带加了好几个新的技能点,而有时一个简单的功能投入了两三天还和之前没什么区别。虽然任务并不复杂,但忍不住会刷会微博,聊会 QQ,即使硬着头皮去做,往往效率也不如意,甚至引入一些新的低级 Bug。这个差异与技能水平和工作态度无关,在绝大多数工程师身上都会看到。

效率的影响因素非常多,首先是焦虑。

1.焦虑,执行力崩溃,GTD

当任务单一时大家的效率往往很高,例如『今天下班前只提供一个用户获取接口就行,传入城市编码,分页返回用户』,这个对绝大多数同学没什么心理负担。但现实情景不会这么简单,尤其是在创业型公司,每天会有各种任务,可能运营一会会要一份数据,产品一会报一个 Bug,或者老大又提了几个新的优化点,这些任务单个来看工作量不大,但是持续而无序的任务到达一个工程师身上时,完全可以摧毁他一天的效率和心情。尤其是研发需要注意力集中,频繁的任务切换会浪费大量的时间和精力。

在 GTD(Get Things Done)中对此有阐述『压力不是来自于任务本身,而是任务在大脑中的堵塞,带来的焦虑和心理的抵触』。当一件任务还没有完成时,持续到来的新任务会带来很大的心理压力,意志不够强大时,很容易导致执行力崩溃,进入一种任务怎么做都做不完的绝望状态。

知道原因了,自然也有解决方案,GTD 提供了一套很可行的执行方案。简化后如下:

把任务放在 『待归类』『今日待办』『日程』『等待』几个盒子中收集:每次收到新任务先做一个判断,如果这个任务5min 可以搞定的话直接干掉,否则都放在『待归类』盒子里。整理:每天开始的时候从『待归类』盒子中开始过滤任务,挑出来今天需要做的3件事,放进『今日待办』。如果今天不需要做再根据有没有明确的执行时间,放入日程或者等待盒子里。执行:只盯着『今日待办』即可,再有新任务执行 收集步骤。回顾:定期整理自己的『日程』『等待』盒子。完整的流程图:

这套解决方案能将杂乱地任务明确下来,一定程度上减轻心理压力。

Tools:符合GTD 的时间管理工具很多,Doit.im 是其中的佼佼者,全平台覆盖,强烈推荐。 Omnifocus 则是功能最强大的,支持无限级目录等功能,不过只支持 Mac/iPhone/iPad,且价格不菲。 也可以使用印象笔记/OneNote来自己规划管理,这样相对灵活。

Doit.im:

上面说到的是在任务压力面前个人可以做什么,那作为公司/项目经理/产品经理,也需要为避免『执行力崩溃』做一些事情,那就是保持开发的节奏。

2.节奏,情绪的体力值

第一次听到『开发的节奏』是在微博的Scrum项目流程培训上,这个概念解释了以前大学时我们学生外包团队遇到的诸多问题。 简而言已,可以给每个人的情绪量化出一个体力值)。每个开发任务/每个会议/每次报告 都会消耗这个体力值,当体力透支时,后面可能会需要几天不等的时候来恢复体力(我们说的恢复干劲也是这个东西),当透支次数过多时,可能会引发更恶劣的情绪问题。

所以一个健康的团队需要维持开发的节奏,具体操作可以是 每1-2周为一个周期,进行大的项目规划,研发任务占用时间最好不高于80%,之后每个人能有休息/自我充电的时间,在下个周期开始时,团队又能进入满体力值的状态。

具体到我现在的团队,我们以一周为一个单位,每周一产品经理提完本周的需求,我们进行分工消化后,存进需求系统。这周的其他时间内,产品应最大量减少对开发的干扰,下周一的时候对上周的任务进行回顾和总结。 这套方案起到了一定的效果,团队成员没有明显的疲惫感,每周能自由支配一些时间(任务能早早完成的话,自由适配时间更多)。

Tools:团队的需求管理系统 我们先后试过 Onenote多人协作/ Teambition / Team.oschina /c禅道,但普遍不理想,或者功能太复杂,或者无法同时集成 Bug 系统,目前采用的是开源的 Cynthia,Cyntia也是我们团队的Bug管理系统。 具体工具的选择有时间单拉一篇 Blog 来讲 #.#

Cynthia:

3. 情绪

影响效率的另一个问题是情绪,情绪问题危害很大,最直接的在于:

  1. 情绪很容易泛化:单一诱因导致的问题会影响各个方面:工作积极性,工作效率,工作质量等等
  2. 情绪很容易传染:小圈子内,情绪很容易传染(QQ 群功不可没)
  3. 情绪不好消除:后面会看到,导致情绪的问题多是之前小问题的日积月累,或者就是现阶段不好解决的问题。

情绪的影响因素很多,简单列举几个很常见的:

  1. 研发节奏过于紧凑:在上一节中提到当开发的情绪体力持续透支时,会有恶劣的情绪问题。 这个在开发团队中并不少见。当开发节奏太过紧凑,团队不注意休整时,团队很容易负面情绪弥漫,而情绪一旦形成印象,便不会那么好消散。
  2. 薪酬倒挂:这个也是大家诟病 HR/Leader的重要原因,当一个团队薪酬内部增长太乏力时,内部人员会有流出,团队需要再招聘新人,而市场上平均待遇已经和之前不同,所以新招来的人员待遇往往也会水涨船高。 这个是很致命而且不好消解的。HR 太过节约成本,往往会对团队有致命的伤害。
  3. 与 Leader 理念/习惯 不合。
  4. 工作内容安排不当,太困难或太简单,或者与职业发展规划不符。
  5. 纯粹发泄。
  6. ......

情绪问题暴露后,也不是不能解决,有明确的诉求时直接去解决问题本身。没有明确诉求的可能是抱怨性格或者与公司方向不合,那也无法强求。

而真正可怕的是团队 Leader(或者需要对这些问题负责的人) 对团队本身情绪的不知情。当大家私密的 QQ 群/讨论组 都没有你,聚会也没有参加,不会有什么真心话交流,只有工作上例行的接触时,就已经是挺危险的信号, 成员离职时再去寻找原因已然太晚。

4.纠结的Leader

Leader 这个词并不是太贴切,这个职位的职责应该是服务团队的开发同学,找到并解决大家开发不爽的地方,做好技术和业务的架构,保证整体研发输出的质量和时间点。

而且 Leader 其实并不容易当. 要获得工程师的尊重, 需要满足下面一项或多项

  1. 技术过硬,能解决团队遇到的各种技术问题。
  2. 情商逆天,有能力和意愿感知团队成员的情绪,并能不断给积极的反馈, 团队保持很强的凝聚力。
  3. 资历深厚,业内有影响力或者披荆斩棘创下了公司的基业,能为团队争取到资源。而在没有得到工程师的充分尊重前,各种措施的执行都会收到影响,技术决策的讨论更得充分尊重大家的意见。

5. 技术驱动

技术驱动业务是产生颠覆式创新的动力之一,工程师更清楚技术的边界在哪里,哪些情景已经可以被成熟(或者半成熟,但可驾驭)的技术方案来解决了,这些会把公司与竞争对手拉开一个或者半个技术时代,输出更酷炫的产品。

这个时代对于工程师来说是最好的时代,Github等开源社区的兴起,让新技术的学习成本变得很低。数据挖掘,自然语言分析,图数据库,数据可视化,虚拟化,移动互联等技术的发展更给业务带来了无限的可能,而美国市场与中国市场还存在5-10年的时间差,也为我们提供了很多可以参照的模板。

技术驱动有更多实际可以做的事情,放到二手车行业,例如当其他产品靠用户自己填购车需求时,你实现了通过用户的行为轨迹挖掘用户的需求;当其他产品还是几张图片来展示车况,你实现了低成本的全景照片,当其他产品还在要经销商自己维护关系时,你通过图数据库计算出了他可能的朋友圈...

那么问题来了,应该如何推动产生更多的技术推动型的产品呢

  1. 宽松的学习氛围:技术驱动型一般借助于相对前卫的技术,大多数同学对这些技术都没有多少经验,依赖于持续的学习,而学习就需要有学习的氛围,尤其是时间的保障。
  2. 优秀的工程师:技术驱动对工程师的自我实现需求要求的更高,只想完成现有任务不想多事的工程师显然不合适。
  3. 技术与业务的结合:最理想的是工程师本身有商业思维,能够主动将新技术与业务结合起来,寻找最大价值的结合点;其次是工程师定期宣讲技术成果,与产品同学共同讨论。例如:『我们已经将20万经销商数据全部存入图数据库,支持宽度遍历,深度遍历这些查询方式,他们的时间复杂度是O(n+e)』 『我们可以对这几十万条评论内容进行分析,分辨出褒义还是贬义,还可以匹配上我们数据库中的品牌车系,准确率能有60%』

技术驱动也有一些硬伤,或者说工程师同学主导项目时都很容易出现的硬伤:优先级,时间点,任务管理。

  1. 优先级:醉心于技术的同学会被问题本身吸引,例如『MongoDB 还支持数据分片,那我搭个集群试试』『我试试这里能不能承载1w qps 的压力』『虽然我正在看 iBeacon,但是 Ardunio 也好酷哇,我做个Demo先』等等, 在这种吸引下,工程师很难对套页面,修数据这种任务感兴趣,而这些对项目来说优先级可能会更高。(心理学中也有类似结论,当难度降低到一定程度,动机的强度也会降低。)

  2. 时间控制:同时因为要使用的很多是大家没用过的技术,技术本身可能不成熟,大家经验也不多,有时候一些坑要好长时间才能埋上,这样固定的时间点很难保证产出。

  3. 任务管理:许多热衷于解决问题的同学同时也是挖坑小能手,他们能预见一种更优雅的解决方案,但是没有时间和精力去完成,在这个过程中还挖了更多新的坑,于是这些坑一直没有时间埋...

也因为以上几个原因,我们会发现很多醉心于技术的同学在做项目时会出现虎头蛇尾,总也结束不了的样子。 这种情况需要技术同学自己注意每月确定团队的大方向,定期汇报,发周报或者半月报。

如何提高个人与团队的效率。是会伴随行业发展长久存在的问题,每个团队都要去寻找自己的答案,大家一直在努力。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

by liu pi1ot

好文章

by LU Jerome

确实是好文章,通常技术网站都只关心技术,在实际项目中,技术其实不是项目成败的决定性要素,团队的管理,尤其是情绪管理通常决定项目的成功与否

by 狄 浦

技术人员也值得一看,得知自身情绪变化带来的影响,以及如何消除,从而进一步提升效率和自身价值.

by lee joe

学习了,结合自身有了很多感悟

总结起来就一个词--professional(专业) by Zhefu Zhou

程序员玩心重,很容易投入却不考虑优先级,不善于处理多任务。这些都是年轻人的通病,需要时间去磨练,当然,有一个好的leader或mentor就有望快速通过这个阶段。

by su sin

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

6 讨论
提供反馈
错误报告
商务合作
内容合作
Marketing
InfoQ.com及所有内容,版权所有 © 2006-2016 C4Media Inc. InfoQ.com 服务器由 Contegix提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司 京ICP备09022563号-7 隐私政策
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.