[转译]软件团队：培养使命感，而不是制造紧迫感

紧迫感"/>

[转译]软件团队：培养使命感，而不是制造紧迫感

原文出处：Don’t create a sense of urgency, foster a sense of purpose.

试图创造紧迫感的努力几乎总是适得其反

我领导着软件开发团队。不可避免的会有人（CEO、股东、顾客）希望我们能进度更快点儿。我经常会被问到-“你觉得团队当前有强烈的紧迫感吗？”，或者更直接的“你能让团队感觉到更强的紧迫感吗？” 更多的请求比较隐晦，但也换汤不换药 - “我真的希望能让这个项目完成，但它还没有火力全开。你能再推进一把吗？”

截至目前，对于他们所有的疑问我的回答都是 - 不。我不会试图给团队制造更强的紧迫感。你也不应该。紧迫感并不是目的。试图创造紧迫感反映的是个由来已久、关于匆忙和快速的悖论 — 这个悖论让你觉得你如果并不总是忙着，那你已经落后了。

只要你不是每天24小时都在产品上工作（坦率说，哪怕你是），那你就很容易相信进度还能再快点儿。毕竟我们都想要快。要做到事情永远比已经完成的多，进度快一点可以让我们早点完成；好像团队只要再忙碌一点，我们就不用面临艰难的选择。

那些有过拼命按时出门却把钥匙落在家里的经历的人都知道：匆忙经常适得其反。惊慌失措、狂乱的步伐更在意结果而非过程中的行动、这也导致了负面的后果。

欲速不达

理论上，专业的软件工程师、设计师和产品经理会总期望提交专业质量的成果 - 并不愿走那种可能会损害其成果质量的捷径。现实中，我们都有愉快地工作、让我们的工作符合公司发展方向的主观愿望。可即便是最顶尖的团队也无法对压力免疫。于是小事就开始堆积 - 没时间修复的用户体验的小问题、测试覆盖率下降、未能监测关键流程以及新功而产生的技术债务。

无从创新

匆忙且持续的压力降低了我们保持积极主动的能力。我们不会多花20分钟思考来理解设计意图、避免浪费多日的工作。我们无法意识到一个浏览器插件本身是个完全错误的方案，我们应该停止在上面的投入。方案返工也需要时间，所以赞成紧迫性的环境里通常不鼓励返工；但是就是那几分钟或者几小时，可以节省下后来成周、成月的时间。

微观管理

试图制造紧迫感需要付出额外的管理成本。员工来的早吗？他们待的晚吗？工作成果够吗？但对于领导团队而言，有更多的大且深入的问题值得他们关注。而且微观管理会侵蚀团队的信任。小心不要过快地释放这种观点 - 即便你不会陷入微观管理，你可能会错误的鼓励团队中的经理们去这么做。

快速失效

里程碑所带来的生硬的紧迫感会快速的失效 - 在工作过程中、职业生涯中都是如此。对于有经验的软件工程师和设计师（正是你最需要他们才智的那帮人）而言，这会让你显得挺业余，并且不会带来长期的忠诚度。

信息倒置

当关于紧迫性的沟通变成了最高优先级、更重要信息，其他诸如我们为什要讨论这个项目、以及谁会因为这个项目受益等 - 这些会带来更大价值的信息 - 就被淹没了。

使命感

让我们扔掉紧迫感去寻求使命感吧。使命感是一种对努力的目标的深刻理解，同时也是一种倾注时间和能量的渴求，这个使命因我们想对世界产生的影响而共鸣。

使命感是对我们事业的沉浸，同时也推动着我们的行动。使命感让我们更快更聪明的奔向共同的目标，也意味着良好的判断：因为我们都理解了 - 对于我们共同创造的事业，我们的行动会带来哪些短期和长期的影响。

强烈的使命感表现出来，可以是当一个软件工程师看到一个潜在的顾客与某个工作流争吵的时候，愿意留下来很晚让这个工作流变得简单一点；也可以是一个设计师花费了整个周末而做几次计划外的迭代，只因他们沉浸于手上的问题，并且希望给出更好的方案。

结果就是，当你停止了制造紧迫感，潜伏在你团队中的激情和动机得以释放，让正确的事情以正确的步调来完成。

营造使命感与制造紧迫感是不同的。一个有高度使命感的团队看起来很像一个有高度紧迫感的团队。产出非常高，成员非常投入。但其中最主要的区别在于你作为领导者所做的工作差别很大。

制造紧迫感就是关于截止时间、唠叨和催促进度。培养使命感则不同，它是共同的努力，并且需要坚信，你的团队成员会把他们的使命感转化为持续增加的效率。

你作为团队领导者的主要工作，就是雇佣合适的团队成员，并且花时间激发他们的使命感。帮助团队成员理解他们工作的影响，速度就会随之而来。

后记：任何观点都有它对应的时间和空间上的上下文。我的观点不是说我们能承受时间上的浪费。管理（并最终放弃）跟不上合理进度的员工是每个公司都需要发展的能力。绝大多数合理的组织需要可预测性，并且有充分的理由设定深思熟虑的截止时间。而且每个公司都希望能快速的发展。关键是不要让紧迫感本身成了一个目标。