为工程管理者我们通常都对“什么是好的交付”“什么是好的沟通”有一套自己的判断标准。问题在于我们很容易默认和我们共事的人也天然认同这套标准。但团队成员的经验背景、成长环境和过往工作方式各不相同这种默认常常并不成立。对于管理者来说清晰设定团队预期是减少沟通摩擦、提升交付质量的重要前提。想象这样一个场景作为一位工程师曾在一家强调快速推出新产品和新功能的公司工作。在紧迫的截止日期下他所在的团队更关注尽快交付一个客户可用的概念验证版本。即便这会带来一定技术债务他们也可以接受因为团队的思路是先验证价值后续再对成功的产品和功能进行重构。而他的新经理曾经亲眼见过许多以“最小可行产品MVP”名义上线的系统长期停留在生产环境中技术债务越积越多最终变得难以维护。因此这位经理更看重质量宁愿放慢项目节奏也希望团队最终交付的是可维护、可扩展的产品。如果双方没有提前对齐他们往往要等到问题爆发后才意识到彼此对“好”的定义并不一样。到那时经理可能会被认为“不切实际”工程师则可能会被认为“表现不佳”。优秀的管理者会主动把双方对“好”的定义摆到台面上并围绕它展开讨论。通过审视自己的标准评估团队现状与这些标准之间的差距并清晰表达自己的期望你可以避免团队通过反复试错来揣摩你的想法也能减少大量不必要的管理摩擦。第一步先明确自己的管理预期每个人心中都有一套关于高效团队的模板。第一步是审视自己对交付和沟通的默认认知并把这套模板清楚地表达出来。你对团队交付成果有什么期望你可以先思考以下问题当你谈到 MVP 时你期待的是一个可维护、经过充分测试、技术债务尽可能少的产品还是一个用于快速获取反馈的概念验证版本你是否接受依赖少数关键专家来执行团队内部不成文的规则还是更希望团队拥有明确的编码标准和成熟的代码审查流程你是否期待团队制定完整的质量保障策略包括单元测试、集成测试和端到端测试在发布新功能时你认为哪些类型的测试是必须具备的你预期团队应该把多少时间用于交付新功能又应该把多少时间用于处理技术债务当问题出现时你希望团队负责人立即介入解决还是把它视为其他成员学习和成长的机会对这类问题很多管理者都有强烈判断尤其是在基础工程实践上。因此当我们看到团队没有遵循这些原则时往往会感到格外沮丧。但对于过去没有优先关注这些实践的团队来说改变不会自动发生。你需要先清楚地向自己说明这些期望再把它们明确传达给团队。你希望团队如何与你沟通不同管理者有不同的沟通偏好。只要你在职业生涯中遇到过几位风格迥异的上级就会明白这一点。不同团队也是如此。不存在唯一正确的管理风格。我见过一些新经理对过于安静的团队感到沮丧。团队只有在事情快要失控时才会来找他们于是他们觉得“我总是在最后一刻才看到冰山。”我也见过另一些经理对过度沟通的团队感到疲惫。团队频繁来寻求确认和指导让他们觉得“我希望他们帮我分担项目而不是不断来问我让我感觉这仍然是我的项目。”要缓解团队沟通问题不要把沟通方式简单地分成“对”与“错”。更好的方式是把它看作一个连续谱。这个谱上的理想位置取决于你的管理偏好、团队成熟度和具体情境。你可以从以下问题开始你希望团队在日常项目推进中持续向你同步进展还是只在需要建议或批准时才来找你你希望团队只把成果和复盘经验同步给你还是希望他们在这些经验产生时就同步给整个团队当团队有早期想法时你希望他们先来找你讨论还是带着完整方案再来找你如果团队遇到问题你愿意亲自管理利益相关者的预期还是希望团队自行处理当出现问题时你更希望通过项目管理工具、即时通讯工具还是电话了解详情如果是 bug、事故或客户投诉你的选择会不同吗这些答案会因团队构成、直接汇报对象的资历以及你管理的团队数量而变化。随着角色变化你的沟通方式也应该随之调整。比如当我管理一个四人团队时我需要的信息密度和参与程度与后来管理多个团队时完全不同。因此每当角色或职责范围发生变化都值得重新评估一次自己的沟通偏好。第二步将团队表现与管理预期进行比较当你回答完这些问题后就可以回到团队现状看看实际情况与自己的期望是否一致。关于团队交付你可以观察团队如何平衡质量与速度他们是否在执行编码标准并持续保障系统稳定性这些做法是否符合你的预期目前的交付结果如何利益相关者如何看待这些结果来自上级或业务侧的哪些压力正在影响团队的交付方式如果你对团队的交付质量还没有信心哪些具体改变可以帮助他们赢得你的信任关于团队沟通你可以继续思考团队提供的进展信息是否足够清晰、足够及时能让你判断他们是否正在朝目标推进他们来找你时通常带着初步想法还是已经准备好完整方案如果你负责提供技术指导你是否足够投入能在合适的时间给出反馈如果技术指导由技术负责人承担团队是否仍然过度依赖你团队成员通常会在采取行动前多久征求你的意见又有多少时候是先采取行动再通知你大多数情况下你是否认可他们的判断和选择如果你对团队与你沟通的方式并不满意哪些具体改变可以帮助他们赢得你的信任当你更清楚地看到自己的期望与团队表现之间的差距后就可以判断哪些不匹配最值得优先处理。例如基础工程实践上的分歧通常影响很大应该尽快解决。相反如果有些下属更愿意向你倾诉而另一些下属更独立你可能会发现自己完全可以根据每个人的需要提供不同程度的支持。第三步清晰沟通你的团队预期一旦明确了对团队的期望就要选择合适的方式把它们传达出去。不同类型的期望适合不同的沟通场景。工程标准应被记录下来并面向所有工程师公开分享。理想情况下这些标准应该通过协作流程共同制定。而关于某位主管或资深工程师是否需要承担更多责任则更适合在一对一沟通中讨论。下面是几个常见的预期对齐场景。制定工程标准你可以与团队一起制定通用的工程标准。编码规范、代码审查流程、代码覆盖率目标都是很好的起点。关键不只是制定标准还要共同约定如何执行这些标准。理想情况下团队应该与你一起参与方案制定。如果需要推动重大变革你可能需要给出更明确的方向。但即便如此也要尽量让团队参与讨论因为这会显著提高后续落地的可能性。在适当情况下你还可以根据这些标准更新或重新创建团队对于“完成”的定义。对于研发团队来说借助PingCode这类智能化研发管理工具将目标、需求、开发、测试、发布和知识沉淀等环节串联起来也能让工程标准不只停留在文档里而是体现在日常协作和交付流程中。鼓励团队所有权如果你同时负责多个团队或项目并希望团队负责人在来找你之前先承担更多解决问题的责任就要直接告诉他们。同时也要询问他们需要哪些支持才能成功。有些情况下他们需要的帮助可能比你想象得更多另一些情况下他们真正需要的可能只是相信自己有能力做出判断。你可以鼓励他们先彼此交流想法而不是第一时间依赖你也可以引导他们向具备相关领域经验的同事寻求建议而不是由你亲自解决所有问题。过去我曾与一群资深工程师和主管定期沟通鼓励他们提出需要帮助的领域。有时我也会主动抛出问题推动他们展开讨论。这种改变需要时间和耐心。不要因为短期内看不到明显变化就放弃。加强团队沟通机制相反如果你的团队很少同步工作进展也不太愿意分享细节就需要让他们知道你需要什么程度的信息以及希望以什么频率获取更新。同时也要鼓励他们提出顾虑。你可能会发现他们过去的上级管理得过细以至于他们把“少说少错”当成了安全策略。一旦理解你的意图他们通常愿意一起找到一个更合适的平衡点。对于跨职能团队或多项目团队也可以借助Worktile这类通用项目协作系统把任务、文档、日程和沟通信息集中管理减少信息散落带来的误解和遗漏。处理与利益相关者的脱节有时团队表现不佳并不是因为他们自身的价值观有问题而是受到了来自上级或业务侧的压力。如果你与公司在速度与质量的取舍、平台投入、技术债务治理等方面存在分歧不要期待团队替你解决这些问题。相反你应该主动向工程、产品以及在必要情况下的业务负责人说明你希望推动什么改变这些改变会带来什么影响。在这类沟通中数据非常重要。缺陷数量、事故频率、回滚次数、新功能发布速度等数据都是很好的切入点。它们能帮助你把“我认为应该这样做”转化为“我们有证据表明这样做更有利于业务和团队”。结语清晰预期是工程管理的基础在赋能团队这件事上最大的阻碍之一是我们误以为团队只需要具备所谓的“基本常识”。如果要数清有多少次工程经理曾沮丧地对我说“这不是常识吗”恐怕我的手指和脚趾都不够用。但现实是沟通标准和交付标准在不同团队之间差异很大甚至在同一个团队内部也可能存在显著差异。让下属去猜测你的意图对他们是一种消耗对你也是一种消耗。认真思考你希望团队如何运作并把这些期望清楚地表达出来能够减少大量不必要的摩擦也能帮助你与团队建立更健康、更稳定的合作关系。