“我的团队最近似乎一直在原地打转。
我们正在推进一个非常关键的项目，截止日期也越来越近。我一直努力推动大家向前走，但所有人似乎都不清楚究竟应该由谁负责什么，项目进度因此越来越慢。
平时遇到问题时，我们通常习惯由团队共同讨论、协作解决。面对现在这种情况，你有什么建议吗？”
这是团队管理中非常常见的问题。
团队已经有了清晰的路线图，项目目标和截止日期都很明确，甚至可能已经制定了 OKR。人员配置看起来也足够，按理说完全有能力完成工作。
但奇怪的是，尽管每个人似乎都知道应该做什么，团队就是迟迟无法真正向前推进。所有人都很忙，却总感觉哪里不对劲。
这时候，管理者需要做的一件事，就是进一步明确每个人的角色和职责。
你可以邀请团队成员共同定义职责，继续采用强调参与和自主性的授权式管理；也可以直接给出清晰的分工和要求，采取更具指导性的管理方式。
有些管理者天然更倾向于授权式管理。可能是因为他们更擅长这种方式，希望每个人都有表达意见的机会；也可能是管理者和团队都习惯通过讨论达成共识。
还有一种可能是，管理者并不清楚应该如何给出明确指示，或者担心这样做会显得过于强势。
这本身并不是坏事。
既然你的团队习惯通过协作解决问题，本文将重点讨论：当团队陷入停滞时，管理者如何通过明确项目目标、梳理职责分工和采用教练式管理，帮助团队打破僵局、推动项目向前。
当然，有些时候，团队确实需要管理者提供更加明确的方向。至于如何在不变得专横、粗暴或事无巨细的情况下给出指导，我们会在后续文章中继续讨论。
第一步：明确并记录项目的核心目标
你可能已经完成了这一步，但仍然值得重新确认：请把团队在这个项目中最需要实现的结果清楚地写下来。
这个结果应当是可观察、可衡量、基于事实并且现实可行的。
你可以思考几个问题：
- 项目结束时，团队希望看到哪些具体变化？
- 哪些指标能够证明项目取得了成功？
- 利益相关者将依据什么判断项目是否达到了预期？
OKR 在这一步通常非常有帮助，因为它能够把模糊的目标转化为清晰、可衡量的结果。
确定目标后，还要把它记录在所有项目参与者和利益相关者都能看到的地方。
不要只在项目启动会上提到一次，而要在整个项目推进过程中不断重复。
你可以把它放在演示文稿的开头，在项目进度更新中再次强调，在讨论优先级和作出取舍时反复引用。对于研发团队，也可以借助 PingCode 将项目目标、需求、任务、进度和相关知识集中管理，让目标与具体执行工作保持关联，减少信息分散带来的理解偏差。
团队需要始终记住：
我们当前最重要的目标究竟是什么？
当团队在执行过程中出现分歧时，这个目标也应当成为大家判断优先级、分配资源和作出决策的共同依据。
第二步：明确团队成员的角色和职责
当团队成员陷入困境，或者项目迟迟无法推进时，通常有两个原因：
一是前进的路径不够清晰；
二是团队缺少完成工作所需的条件。
当然，也可能两种情况同时存在。
先明确项目推进路径
你们已经确定了目的地，接下来需要明确的是：每个人分别需要做什么，团队才能顺利到达那里。
管理者可以直接说明谁负责什么，也可以带领团队完成一次职责划分练习，共同建立一份角色与职责文档。
如果你希望继续采用授权式管理，可以邀请团队成员一起讨论：
- 每个角色需要承担哪些核心职责？
- 每个角色应当交付哪些成果？
- 哪些工作由某个角色独立负责？
- 哪些事项需要多个角色共同参与？
- 哪些职责存在重叠？
- 又有哪些重要工作目前无人负责？
你可以先与团队中的其他负责人一起梳理主要角色，例如产品经理、工程经理和技术负责人，再分别列出每个角色需要承担的职责和预期成果。
这里需要注意的是，讨论的重点应当放在“角色”上，而不是具体的人。
例如，团队里可能有多名工程师，但在第一轮讨论中，不必立刻把每一项任务分配到某个人身上。可以先定义工程师这一角色整体需要负责什么，再根据项目的实际情况进行进一步拆分。
当然，如果不同类型的工程师承担着明显不同的职责，例如前端工程师、后端工程师和测试工程师，那么分别讨论这些角色也完全合理。
这项练习的核心目的，是帮助团队形成一套共同认知：
什么事情由谁主导，什么事情需要谁参与，最终结果由谁负责。
完成初步讨论后，把结果整理成共享文档，并与团队其他成员同步。
允许大家提出问题、补充信息，并根据反馈进行调整。对于跨职能或非研发团队，可以使用 Worktile 将职责文档、项目任务、负责人和截止时间集中到同一协作空间中，方便成员随时查看分工和同步进展。
职责文档不是一份宣布之后就不能修改的规章制度，而是帮助团队提高协作效率、减少职责模糊的工作工具。
第三步：把职责分工当作一次实验
这种职责划分方法适用于许多不同类型的团队和合作关系。
它不仅可以用在产品研发团队中，也可以用于招聘经理、招聘人员与面试官之间的分工，设计团队和业务运营团队的协作，以及导师与实习生之间的职责划分。
几乎任何需要多人协作完成复杂任务的团队，都可以使用这种方法。
你也可以明确告诉团队，这并不是一次永久性的组织调整，而是一项实验。
例如，你可以这样说：
“我们先用这种方式明确当前项目中的角色和职责。在项目推进过程中，我们会持续观察哪些安排有效，哪些地方仍然存在问题，再根据实际经验进行调整，并把这些经验应用到未来的项目中。”
这种表达能够降低团队的抵触情绪。
因为人们往往并不排斥尝试一种新方法，他们真正担心的是，一项尚未经过验证的安排会不会从此固定下来，再也无法改变。
当角色变得更加清晰之后，团队通常也会更容易发现：为了履行这些职责，他们还缺少哪些资源、信息和支持。
第四步：明确团队成功所需的条件
假设你已经建立了共享的角色文档，也和团队进行了讨论，但成员对此表达了反对或不满。
更棘手的情况是，团队没有提出任何意见，只是以震惊、恼怒或困惑的沉默来回应。
先不要慌张。
请记住，团队此前一直处于原地打转的状态。现在出现分歧，并不一定意味着这项尝试失败了。
恰恰相反，这可能是团队第一次真正开始讨论：到底是什么阻碍了项目推进。
你可以对团队说：
“这份新的职责文档目前只是一项尝试。我们的目的不是增加更多规则，而是改善协作方式，帮助团队结束反复讨论、迟迟无法推进的状态。
为了让你能够顺利履行自己的职责，你还需要哪些条件和支持？”
这时，管理者需要把关注点从“你是否接受这份职责”，转向“你需要什么才能取得成功”。
如果团队仍然感到停滞，可以采用教练式管理方法，通过开放式问题帮助成员进一步思考。
例如：
- 目前最大的障碍是什么？
- 哪些信息或资源仍然缺失？
- 哪些决策需要进一步明确？
- 你需要谁的支持才能继续推进？
- 哪些要求是必须满足的，哪些地方可以作出取舍？
- 如果资源有限，你认为最应该优先解决什么问题？
把团队提出的需求整理成一份清单，并放在公开共享的文档中。
这样做有两个好处。
一方面，管理者可以更清楚地判断哪些需求能够满足；另一方面，团队也可以看到管理者是否真正兑现了自己的承诺。
团队提出的某些需求，你可能能够争取到。
例如：
- 邀请其他团队的工程师协助进行代码审查；
- 进一步明确最小可行产品应当包含哪些内容；
- 帮助团队协调关键资源；
- 推动利益相关者更快作出决定；
- 减少与核心目标无关的临时任务。
但也会有一些需求无法完全满足。
例如，你也许可以帮助团队争取两周延期，但无法继续延长；可以协调一部分额外资源，却无法为项目增加一支完整的新团队。
管理者不需要承诺满足所有要求，但需要让团队看到：你认真听取了他们的需求，也已经尽力争取必要的支持。
第五步：持续采用教练式管理
当团队成员遇到困难、因为挫折而想要放弃，或者固执地坚持某种方案时，不要急于替他们解决所有问题。
继续与他们合作，并通过开放式问题引导他们思考。
你可以询问：
- 现在真正阻碍你前进的是什么？
- 你已经尝试过哪些方法？
- 还有哪些不同的选择？
- 每种选择可能带来什么结果？
- 为了推动项目向前，你愿意作出哪些取舍？
- 你希望我提供什么支持？
教练式管理的关键，不是管理者给出所有答案，而是帮助团队成员更清楚地理解问题，并对接下来的行动承担责任。
当然，以授权和赋能的方式管理团队，并不意味着每一次都能得到理想的结果。
你可能并不完全认同团队对任务分配的决定，也可能发现某些成员仍然没有真正理解自己的职责。
但是，只要项目目标足够明确，角色和责任得到了记录，管理者也持续与团队成员沟通，团队就已经开始从反复讨论、原地打转的状态，逐渐转向真正的行动。
更重要的是，在这个过程中，你可能会惊喜地发现，团队成员提出了许多你从未考虑过的新方法。
而通过共同定义目标、职责和成功条件，团队也会逐渐建立更深的信任。
这种信任不仅能够帮助团队解决当前项目中的问题，也会成为未来应对复杂挑战的重要基础。
团队原地打转时，管理者应该做什么？
授权式管理并不意味着管理者什么都不做。
真正有效的授权，是通过清晰的项目目标、明确的职责分工、必要的资源和持续的提问，让团队真正有能力承担责任并推动工作。
当团队原地打转时，管理者可以重点做好五件事：
- 明确项目最重要的目标；
- 梳理团队成员的角色和职责；
- 将职责分工视为可持续调整的实验；
- 明确团队完成工作所需的资源和条件；
- 通过教练式管理帮助成员解决问题。
不过，授权式管理也并非适用于所有场景。
当团队持续无法达成一致、项目面临迫切风险，或者成员尚不具备独立作出判断的条件时，管理者可能需要暂时采取更具指导性的方式。
这种方式可能会让一些人感到不适，但在特定情况下，清晰而直接的指导，反而可能成为对团队最有力的赋能。
文章包含AI辅助创作，作者：liu，如若转载，请注明出处：https://docs.pingcode.com/baike/5250219
