技术团队的情绪与效率

一直以为偶尔的效率不稳定是我个人性格的问题，现在看来跟节奏/挑战性有关。

这也解释了为什么我在执行持续无序任务/低难度任务的时候，即便使用GTD，效率也会极大降低；而在熬夜学习新知识，效率反而提高了的情况。

限制每天/同时执行的GTD的数量是非常有效的办法。最近我在用blossom，恰恰是基于这个原则设计，把我的平均生产力提高了差不多一半的样子。

顺便发现R2节点下看到的回复数好像并不是立即刷新的，与 全部 相比有个几分钟延迟的样子。

深表赞同。

在开发节奏上，我们在分配任务时，会按照预估时间的1.2~1.5倍来计划，尽量做到大家在项目中时间相对宽松，能做一些开发任务外的尝试，不只是输出，最好有输入。情绪管理上，除了Leader主动去感知团队成员的情绪，也需要培养大家主动找Leader谈话（或者每周列会谈话一次）的氛围，鼓励成员把对公司/团队的不满和期待都说出来。

好棒的文章

总结得非常好

早上点开的，拖到现在给看了，觉得很多地方总结的不错，都是可以拿出来直接借鉴的经验

讨论的背景也挺宽，甚至提到了现在的工程师文化里既需要宽松的空间也要注意到对低难度任务带来的不积极等等。从这些角度看看自己，也能看清些自己，提高效率

有的团队根本没有节奏的概念， 对团队成员的情绪控制根本达不到“管理”层面， 加上其他方面的因素，整体的效果是每个人都有做不完的事， 却没有一个稳定拿的出手的产品， 搞笑的是技术负责人往往会归因到个别员工或其他管理人员身上。 一将无能，累死三军 真不是危言耸听。

@tt7

有感受 +1

我现在所在的团队就毫无节奏可言。
Leader不考虑员工情绪，始终传递上层的指示，直言 this is the order ,can't disobey.
每个员工带上四五个项目，各种bug、需求、迭代，所有的需求都是通过邮件来沟通，妈蛋，已阵亡！！

这就是全工程师团队的优越性，因为其他职位可能无法理解这种焦虑

『压力不是来自于任务本身，而是任在大脑中的堵塞，带来的焦虑和心理的抵触』


这句深有体会，经常由于想着要业余学习的东西，以及工作中要完成的任务，一时脑袋中太多东西就容易焦虑，，，，，


稍微有点对策，可能就是，把工作需要做的事写好优先级列出来，，业余时间要学得不要太急于求成，稍微为其 时间消耗 增加一点估值，

我觉得情绪往往来自于沟通和说服的能力的不足。

我就非常欠缺说服别人的能力，以前在公司的团队里，我往往是技术专家的角色，当发现系统里存在一些问题的时候，我讲出来，不仅团队成员会不信，还会极力反驳。即使后期出了不满足需求，线上事故等问题，依然死不承认。一个新的需求，对于我给出接近“完美”的解决方案，一定要改头换面一下，删掉几个关键步骤。

但也不是每个人都这样，当时的老大就会承认问题，以前我私下跟他指出系统数据库有个地方使用有误，其实他只要改一行代码就可以避免，但是他没有。后来果真因为这一点出了线上事故，老大就说如果当时听我的就好了。虽然不能完全避免问题，但至少可以减轻事故的损失。

我刚开始工作的时候，老大和同事很少指点问题，唯一记得第一个老大说的一句话，大意是“出了问题一定要找到出问题的原因，不能在一个问题上栽两次”，一直严格遵守这句话。除了在能力或者时间极为不足的时候。

难道这个行业真的像乔布斯的那句“和聪明人一起工作，最大的好处是不用考虑他们的自尊”？

好文，节奏很重要。

最近做的一个项目也是累死人。
有7个开发者左右，大多数都是新手，该项目时间有限，接过来后急急匆匆的就投入开发
连需求都没搞清楚，一味地输出，只保证按期交付，忽略了当中许多管理的问题
这篇文章点到了其中道理，这样下去只能把团队搞散
团队管理仍存在诸多不足，把该文章往群里一发，期望能够有（chi）所（xin）成（wang）效（xiang）

很好的总结，Leader很重要，控制节奏、疏导情绪、争取资源…… 最重要的，要能兼顾上下级，不能只对上，不对下，那样团队成员就苦逼了！

曾为文章里所说的现象苦思原因无果，还是文章里说的透彻啊。学习了。

总结得非常好，目前就有这样的问题。

@leonwu 来我们这里呗~ :P