引:为什么工程师的效率有那么明显的波峰波谷?为什么会有负面情绪?负面情绪与工作效率有什么关系? 团队 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. 情绪
影响效率的另一个问题是情绪,情绪问题危害很大,最直接的在于:
情绪的影响因素很多,简单列举几个很常见的:
情绪问题暴露后,也不是不能解决,有明确的诉求时直接去解决问题本身。没有明确诉求的可能是抱怨性格或者与公司方向不合,那也无法强求。
而真正可怕的是团队 Leader(或者需要对这些问题负责的人) 对团队本身情绪的不知情。当大家私密的 QQ 群/讨论组 都没有你,聚会也没有参加,不会有什么真心话交流,只有工作上例行的接触时,就已经是挺危险的信号, 成员离职时再去寻找原因已然太晚。
4. 纠结的Leader
Leader 这个词并不是太贴切,这个职位的职责应该是服务团队的开发同学,找到并解决大家开发不爽的地方,做好技术和业务的架构,保证整体研发输出的质量和时间点。
而且 Leader 其实并不容易当. 要获得工程师的尊重, 需要满足下面一项或多项
5. 技术驱动
技术驱动业务是产生颠覆式创新的动力之一,工程师更清楚技术的边界在哪里,哪些情景已经可以被成熟(或者半成熟,但可驾驭)的技术方案来解决了,这些会把公司与竞争对手拉开一个或者半个技术时代,输出更酷炫的产品。
这个时代对于工程师来说是最好的时代,Github等开源社区的兴起,让新技术的学习成本变得很低。数据挖掘,自然语言分析,图数据库,数据可视化,虚拟化,移动互联等技术的发展更给业务带来了无限的可能,而美国市场与中国市场还存在5-10年的时间差,也为我们提供了很多可以参照的模板。
技术驱动有更多实际可以做的事情,放到二手车行业,例如当其他产品靠用户自己填购车需求时,你实现了通过用户的行为轨迹挖掘用户的需求;当其他产品还是几张图片来展示车况,你实现了低成本的全景照片,当其他产品还在要经销商自己维护关系时,你通过图数据库计算出了他可能的朋友圈...
那么问题来了,应该如何推动产生更多的技术推动型的产品呢
技术驱动也有一些硬伤,或者说工程师同学主导项目时都很容易出现的硬伤:优先级,时间点,任务管理。
优先级:醉心于技术的同学会被问题本身吸引,例如『MongoDB 还支持数据分片,那我搭个集群试试』『我试试这里能不能承载1w qps 的压力』『虽然我正在看 iBeacon,但是 Ardunio 也好酷哇,我做个Demo先』等等, 在这种吸引下,工程师很难对套页面,修数据这种任务感兴趣,而这些对项目来说优先级可能会更高。(心理学中也有类似结论,当难度降低到一定程度,动机的强度也会降低。)
时间控制:同时因为要使用的很多是大家没用过的技术,技术本身可能不成熟,大家经验也不多,有时候一些坑要好长时间才能埋上,这样固定的时间点很难保证产出。
任务管理:许多热衷于解决问题的同学同时也是挖坑小能手,他们能预见一种更优雅的解决方案,但是没有时间和精力去完成,在这个过程中还挖了更多新的坑,于是这些坑一直没有时间埋...
也因为以上几个原因,我们会发现很多醉心于技术的同学在做项目时会出现虎头蛇尾,总也结束不了的样子。 这种情况需要技术同学自己注意每月确定团队的大方向,定期汇报,发周报或者半月报。
如何提高个人与团队的效率。是会伴随行业发展长久存在的问题,每个团队都要去寻找自己的答案,大家一直在努力。