技术团队的情绪与效率
引:为什么工程师的效率有那么明显的波峰波谷?为什么会有负面情绪?负面情绪与工作效率有什么关系? 团队 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. 情绪
影响效率的另一个问题是情绪,情绪问题危害很大,最直接的在于:
- 情绪很容易泛化:单一诱因导致的问题会影响各个方面:工作积极性,工作效率,工作质量等等
- 情绪很容易传染:小圈子内,情绪很容易传染(QQ 群功不可没)
- 情绪不好消除:后面会看到,导致情绪的问题多是之前小问题的日积月累,或者就是现阶段不好解决的问题。
情绪的影响因素很多,简单列举几个很常见的:
- 研发节奏过于紧凑:在上一节中提到当开发的情绪体力持续透支时,会有恶劣的情绪问题。 这个在开发团队中并不少见。当开发节奏太过紧凑,团队不注意休整时,团队很容易负面情绪弥漫,而情绪一旦形成印象,便不会那么好消散。
- 薪酬倒挂:这个也是大家诟病 HR/Leader的重要原因,当一个团队薪酬内部增长太乏力时,内部人员会有流出,团队需要再招聘新人,而市场上平均待遇已经和之前不同,所以新招来的人员待遇往往也会水涨船高。 这个是很致命而且不好消解的。HR 太过节约成本,往往会对团队有致命的伤害。
- 与 Leader 理念/习惯 不合。
- 工作内容安排不当,太困难或太简单,或者与职业发展规划不符。
- 纯粹发泄。
- ......
情绪问题暴露后,也不是不能解决,有明确的诉求时直接去解决问题本身。没有明确诉求的可能是抱怨性格或者与公司方向不合,那也无法强求。
而真正可怕的是团队 Leader(或者需要对这些问题负责的人) 对团队本身情绪的不知情。当大家私密的 QQ 群/讨论组 都没有你,聚会也没有参加,不会有什么真心话交流,只有工作上例行的接触时,就已经是挺危险的信号, 成员离职时再去寻找原因已然太晚。
4. 纠结的Leader
Leader 这个词并不是太贴切,这个职位的职责应该是服务团队的开发同学,找到并解决大家开发不爽的地方,做好技术和业务的架构,保证整体研发输出的质量和时间点。
而且 Leader 其实并不容易当. 要获得工程师的尊重, 需要满足下面一项或多项
- 技术过硬,能解决团队遇到的各种技术问题。
- 情商逆天,有能力和意愿感知团队成员的情绪,并能不断给积极的反馈, 团队保持很强的凝聚力。
- 资历深厚,业内有影响力或者披荆斩棘创下了公司的基业,能为团队争取到资源。而在没有得到工程师的充分尊重前,各种措施的执行都会收到影响,技术决策的讨论更得充分尊重大家的意见。
5. 技术驱动
技术驱动业务是产生颠覆式创新的动力之一,工程师更清楚技术的边界在哪里,哪些情景已经可以被成熟(或者半成熟,但可驾驭)的技术方案来解决了,这些会把公司与竞争对手拉开一个或者半个技术时代,输出更酷炫的产品。
这个时代对于工程师来说是最好的时代,Github等开源社区的兴起,让新技术的学习成本变得很低。数据挖掘,自然语言分析,图数据库,数据可视化,虚拟化,移动互联等技术的发展更给业务带来了无限的可能,而美国市场与中国市场还存在5-10年的时间差,也为我们提供了很多可以参照的模板。
技术驱动有更多实际可以做的事情,放到二手车行业,例如当其他产品靠用户自己填购车需求时,你实现了通过用户的行为轨迹挖掘用户的需求;当其他产品还是几张图片来展示车况,你实现了低成本的全景照片,当其他产品还在要经销商自己维护关系时,你通过图数据库计算出了他可能的朋友圈...
那么问题来了,应该如何推动产生更多的技术推动型的产品呢
- 宽松的学习氛围:技术驱动型一般借助于相对前卫的技术,大多数同学对这些技术都没有多少经验,依赖于持续的学习,而学习就需要有学习的氛围,尤其是时间的保障。
- 优秀的工程师:技术驱动对工程师的自我实现需求要求的更高,只想完成现有任务不想多事的工程师显然不合适。
- 技术与业务的结合:最理想的是工程师本身有商业思维,能够主动将新技术与业务结合起来,寻找最大价值的结合点;其次是工程师定期宣讲技术成果,与产品同学共同讨论。例如:『我们已经将20万经销商数据全部存入图数据库,支持宽度遍历,深度遍历这些查询方式,他们的时间复杂度是O(n+e)』 『我们可以对这几十万条评论内容进行分析,分辨出褒义还是贬义,还可以匹配上我们数据库中的品牌车系,准确率能有60%』
技术驱动也有一些硬伤,或者说工程师同学主导项目时都很容易出现的硬伤:优先级,时间点,任务管理。
-
优先级:醉心于技术的同学会被问题本身吸引,例如『MongoDB 还支持数据分片,那我搭个集群试试』『我试试这里能不能承载1w qps 的压力』『虽然我正在看 iBeacon,但是 Ardunio 也好酷哇,我做个Demo先』等等, 在这种吸引下,工程师很难对套页面,修数据这种任务感兴趣,而这些对项目来说优先级可能会更高。(心理学中也有类似结论,当难度降低到一定程度,动机的强度也会降低。)
-
时间控制:同时因为要使用的很多是大家没用过的技术,技术本身可能不成熟,大家经验也不多,有时候一些坑要好长时间才能埋上,这样固定的时间点很难保证产出。
-
任务管理:许多热衷于解决问题的同学同时也是挖坑小能手,他们能预见一种更优雅的解决方案,但是没有时间和精力去完成,在这个过程中还挖了更多新的坑,于是这些坑一直没有时间埋...
也因为以上几个原因,我们会发现很多醉心于技术的同学在做项目时会出现虎头蛇尾,总也结束不了的样子。 这种情况需要技术同学自己注意每月确定团队的大方向,定期汇报,发周报或者半月报。
如何提高个人与团队的效率。是会伴随行业发展长久存在的问题,每个团队都要去寻找自己的答案,大家一直在努力。