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

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

试图创造紧迫感的努力几乎老是拔苗助长

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

截至目前，对于他们全部的疑问个人回答都是 - 不。我不会试图给团队制造更强的紧迫感。你也不该该。紧迫感并非目的。试图创造紧迫感反映的是个由来已久、关于匆忙和快速的悖论 — 这个悖论让你以为你若是并不老是忙着，那你已经落后了。

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

那些有过拼命按时出门却把钥匙落在家里的经历的人都知道：匆忙常常拔苗助长。惶恐不安、狂乱的步伐更在乎结果而非过程当中的行动、这也致使了负面的后果。

欲速不达

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

无从创新

匆忙且持续的压力下降了咱们保持积极主动的能力。咱们不会多花20分钟思考来理解设计意图、避免浪费多日的工做。咱们没法意识到一个浏览器插件自己是个彻底错误的方案，咱们应该中止在上面的投入。方案返工也须要时间，因此同意紧迫性的环境里一般不鼓励返工；可是就是那几分钟或者几小时，能够节省下后来成周、成月的时间。

微观管理

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

快速失效

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

信息倒置

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

使命感

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

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

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

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

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

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

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

---

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