引：为什么工程师的效率有那么明显的波峰波谷？为什么会有负面情绪？负面情绪与工作效率有什么关系？ 团队 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先』等等， 在这种吸引下，工程师很难对套页面，修数据这种任务感兴趣，而这些对项目来说优先级可能会更高。（心理学中也有类似结论，当难度降低到一定程度，动机的强度也会降低。）
-
时间控制：同时因为要使用的很多是大家没用过的技术，技术本身可能不成熟，大家经验也不多，有时候一些坑要好长时间才能埋上，这样固定的时间点很难保证产出。
-
任务管理：许多热衷于解决问题的同学同时也是挖坑小能手，他们能预见一种更优雅的解决方案，但是没有时间和精力去完成，在这个过程中还挖了更多新的坑，于是这些坑一直没有时间埋...
也因为以上几个原因，我们会发现很多醉心于技术的同学在做项目时会出现虎头蛇尾，总也结束不了的样子。 这种情况需要技术同学自己注意每月确定团队的大方向，定期汇报，发周报或者半月报。
如何提高个人与团队的效率。是会伴随行业发展长久存在的问题，每个团队都要去寻找自己的答案，大家一直在努力。
http://kb.cnblogs.com/page/513335/
