工程管理者如何设定清晰预期，减少团队猜测

作为工程管理者，我们通常都对“什么是好的交付”“什么是好的沟通”有一套自己的判断标准。

问题在于，我们很容易默认：和我们共事的人，也天然认同这套标准。但团队成员的经验背景、成长环境和过往工作方式各不相同，这种默认常常并不成立。对于管理者来说，清晰设定团队预期，是减少沟通摩擦、提升交付质量的重要前提。

想象这样一个场景：

一位工程师曾在一家强调快速推出新产品和新功能的公司工作。在紧迫的截止日期下，他所在的团队更关注尽快交付一个客户可用的概念验证版本。即便这会带来一定技术债务，他们也可以接受，因为团队的思路是：先验证价值，后续再对成功的产品和功能进行重构。

而他的新经理，曾经亲眼见过许多以“最小可行产品（MVP）”名义上线的系统，长期停留在生产环境中，技术债务越积越多，最终变得难以维护。因此，这位经理更看重质量，宁愿放慢项目节奏，也希望团队最终交付的是可维护、可扩展的产品。

如果双方没有提前对齐，他们往往要等到问题爆发后，才意识到彼此对“好”的定义并不一样。到那时，经理可能会被认为“不切实际”，工程师则可能会被认为“表现不佳”。

优秀的管理者，会主动把双方对“好”的定义摆到台面上，并围绕它展开讨论。

通过审视自己的标准，评估团队现状与这些标准之间的差距，并清晰表达自己的期望，你可以避免团队通过反复试错来揣摩你的想法，也能减少大量不必要的管理摩擦。

第一步：先明确自己的管理预期

每个人心中都有一套关于高效团队的模板。第一步，是审视自己对交付和沟通的默认认知，并把这套模板清楚地表达出来。

你对团队交付成果有什么期望？

你可以先思考以下问题：

当你谈到 MVP 时，你期待的是一个可维护、经过充分测试、技术债务尽可能少的产品，还是一个用于快速获取反馈的概念验证版本？

你是否接受依赖少数关键专家来执行团队内部不成文的规则，还是更希望团队拥有明确的编码标准和成熟的代码审查流程？

你是否期待团队制定完整的质量保障策略，包括单元测试、集成测试和端到端测试？在发布新功能时，你认为哪些类型的测试是必须具备的？

你预期团队应该把多少时间用于交付新功能，又应该把多少时间用于处理技术债务？

当问题出现时，你希望团队负责人立即介入解决，还是把它视为其他成员学习和成长的机会？

对这类问题，很多管理者都有强烈判断，尤其是在基础工程实践上。因此，当我们看到团队没有遵循这些原则时，往往会感到格外沮丧。

但对于过去没有优先关注这些实践的团队来说，改变不会自动发生。你需要先清楚地向自己说明这些期望，再把它们明确传达给团队。

你希望团队如何与你沟通？

不同管理者有不同的沟通偏好。只要你在职业生涯中遇到过几位风格迥异的上级，就会明白这一点。不同团队也是如此。

不存在唯一正确的管理风格。

我见过一些新经理，对过于安静的团队感到沮丧。团队只有在事情快要失控时才会来找他们，于是他们觉得：“我总是在最后一刻才看到冰山。”

我也见过另一些经理，对过度沟通的团队感到疲惫。团队频繁来寻求确认和指导，让他们觉得：“我希望他们帮我分担项目，而不是不断来问我，让我感觉这仍然是我的项目。”

要缓解团队沟通问题，不要把沟通方式简单地分成“对”与“错”。更好的方式，是把它看作一个连续谱。这个谱上的理想位置，取决于你的管理偏好、团队成熟度和具体情境。

你可以从以下问题开始：

你希望团队在日常项目推进中持续向你同步进展，还是只在需要建议或批准时才来找你？

你希望团队只把成果和复盘经验同步给你，还是希望他们在这些经验产生时就同步给整个团队？

当团队有早期想法时，你希望他们先来找你讨论，还是带着完整方案再来找你？

如果团队遇到问题，你愿意亲自管理利益相关者的预期，还是希望团队自行处理？

当出现问题时，你更希望通过项目管理工具、即时通讯工具，还是电话了解详情？如果是 bug、事故或客户投诉，你的选择会不同吗？

这些答案会因团队构成、直接汇报对象的资历，以及你管理的团队数量而变化。

随着角色变化，你的沟通方式也应该随之调整。比如，当我管理一个四人团队时，我需要的信息密度和参与程度，与后来管理多个团队时完全不同。因此，每当角色或职责范围发生变化，都值得重新评估一次自己的沟通偏好。

第二步：将团队表现与管理预期进行比较

当你回答完这些问题后，就可以回到团队现状，看看实际情况与自己的期望是否一致。

关于团队交付

你可以观察：

团队如何平衡质量与速度？

他们是否在执行编码标准，并持续保障系统稳定性？

这些做法是否符合你的预期？

目前的交付结果如何？利益相关者如何看待这些结果？

来自上级或业务侧的哪些压力，正在影响团队的交付方式？

如果你对团队的交付质量还没有信心，哪些具体改变可以帮助他们赢得你的信任？

关于团队沟通

你可以继续思考：

团队提供的进展信息是否足够清晰、足够及时，能让你判断他们是否正在朝目标推进？

他们来找你时，通常带着初步想法，还是已经准备好完整方案？

如果你负责提供技术指导，你是否足够投入，能在合适的时间给出反馈？如果技术指导由技术负责人承担，团队是否仍然过度依赖你？

团队成员通常会在采取行动前多久征求你的意见？又有多少时候是先采取行动，再通知你？

大多数情况下，你是否认可他们的判断和选择？

如果你对团队与你沟通的方式并不满意，哪些具体改变可以帮助他们赢得你的信任？

当你更清楚地看到自己的期望与团队表现之间的差距后，就可以判断哪些不匹配最值得优先处理。

例如，基础工程实践上的分歧通常影响很大，应该尽快解决。相反，如果有些下属更愿意向你倾诉，而另一些下属更独立，你可能会发现，自己完全可以根据每个人的需要，提供不同程度的支持。

第三步：清晰沟通你的团队预期

一旦明确了对团队的期望，就要选择合适的方式把它们传达出去。

不同类型的期望，适合不同的沟通场景。工程标准应被记录下来，并面向所有工程师公开分享。理想情况下，这些标准应该通过协作流程共同制定。而关于某位主管或资深工程师是否需要承担更多责任，则更适合在一对一沟通中讨论。

下面是几个常见的预期对齐场景。

制定工程标准

你可以与团队一起制定通用的工程标准。编码规范、代码审查流程、代码覆盖率目标，都是很好的起点。

关键不只是制定标准，还要共同约定如何执行这些标准。

理想情况下，团队应该与你一起参与方案制定。如果需要推动重大变革，你可能需要给出更明确的方向。但即便如此，也要尽量让团队参与讨论，因为这会显著提高后续落地的可能性。

在适当情况下，你还可以根据这些标准，更新或重新创建团队对于“完成”的定义。对于研发团队来说，借助 PingCode 这类智能化研发管理工具，将目标、需求、开发、测试、发布和知识沉淀等环节串联起来，也能让工程标准不只停留在文档里，而是体现在日常协作和交付流程中。

鼓励团队所有权

如果你同时负责多个团队或项目，并希望团队负责人在来找你之前，先承担更多解决问题的责任，就要直接告诉他们。

同时，也要询问他们需要哪些支持才能成功。有些情况下，他们需要的帮助可能比你想象得更多；另一些情况下，他们真正需要的，可能只是相信自己有能力做出判断。

你可以鼓励他们先彼此交流想法，而不是第一时间依赖你；也可以引导他们向具备相关领域经验的同事寻求建议，而不是由你亲自解决所有问题。

过去，我曾与一群资深工程师和主管定期沟通，鼓励他们提出需要帮助的领域。有时，我也会主动抛出问题，推动他们展开讨论。

这种改变需要时间和耐心。不要因为短期内看不到明显变化就放弃。

加强团队沟通机制

相反，如果你的团队很少同步工作进展，也不太愿意分享细节，就需要让他们知道你需要什么程度的信息，以及希望以什么频率获取更新。

同时，也要鼓励他们提出顾虑。你可能会发现，他们过去的上级管理得过细，以至于他们把“少说少错”当成了安全策略。一旦理解你的意图，他们通常愿意一起找到一个更合适的平衡点。对于跨职能团队或多项目团队，也可以借助 Worktile 这类通用项目协作系统，把任务、文档、日程和沟通信息集中管理，减少信息散落带来的误解和遗漏。

处理与利益相关者的脱节

有时，团队表现不佳并不是因为他们自身的价值观有问题，而是受到了来自上级或业务侧的压力。

如果你与公司在速度与质量的取舍、平台投入、技术债务治理等方面存在分歧，不要期待团队替你解决这些问题。

相反，你应该主动向工程、产品以及在必要情况下的业务负责人说明：你希望推动什么改变，这些改变会带来什么影响。

在这类沟通中，数据非常重要。缺陷数量、事故频率、回滚次数、新功能发布速度等数据，都是很好的切入点。它们能帮助你把“我认为应该这样做”，转化为“我们有证据表明，这样做更有利于业务和团队”。

结语：清晰预期是工程管理的基础

在赋能团队这件事上，最大的阻碍之一，是我们误以为团队只需要具备所谓的“基本常识”。

如果要数清有多少次工程经理曾沮丧地对我说“这不是常识吗”，恐怕我的手指和脚趾都不够用。

但现实是，沟通标准和交付标准在不同团队之间差异很大，甚至在同一个团队内部也可能存在显著差异。

让下属去猜测你的意图，对他们是一种消耗，对你也是一种消耗。

认真思考你希望团队如何运作，并把这些期望清楚地表达出来，能够减少大量不必要的摩擦，也能帮助你与团队建立更健康、更稳定的合作关系。