从规范流程的视角来解决团队协同效率低下的问题

01

今天这篇文章来谈一谈，如何通过规范化项目流程，解决团队协同效率低下的问题。

在具体谈这个问题之前，还是要先强调一下，作为项目经理，我们需要具备或者逐步培养自己的全局思维（模型：发现问题-界定问题-探究根因-制定方案-评估方案-做出决策），意思是说，当项目中遇到问题的时候，不要就着问题去解决问题，而应该全局思考，找到问题的根本原因，然后才是制定方案去落地。

02

回到今天要谈的话题：当发现团队协同效率低下的时候，该如何应对？

根据塔克曼理论，团队的组建分为5个阶段，分别为：组建期、震荡期（冲突期）、规范期、执行期（成熟期）、解散期。

从这张图可以看出，团队协同效率低最容易出现的阶段就是震荡期。当然，其他阶段也可能出现团队协同效率低下的情况，只是说在震荡期的时候会表现得特别明显。

那是什么原因会造成团队协同效率低呢？

可能原因之一：团队彼此间信任不够，害怕冲突，欠缺投入，无视结果

可能原因之二：项目中的目标不明确

可能原因之三：团队中的沟通不顺畅，氛围不佳

可能原因之四：团队成员技能不足，缺乏经验

可能原因之五：没有工作流程，或者工作流程繁琐

我们暂且假设梳理出来这么多原因导致团队协同效率低下。这么多原因，项目经理要一个个去解决，是一个非常头疼的事情，况且也是不现实的事情。

那该怎么办呢？

其实可以进一步探究一下根本原因，通过分析会发现，根本原因就两类，一是和人有关，一是和事相关。

在项目推进的过程中，要解决人的问题，想必大家都深有感触。因为要改变一个人的思想，认知，这是非常难的事情，而且人本身就是一个可变的因素，会有很多不确定性。

但我们可以从事的角度出发，潜移默化的影响和改变大家的工作习惯，以及在项目中的行为方式，则是相对比较简单的。

该如何做呢？

这个时候，我们首先的往往就是从规范流程入手。流程是一种依据明确规则来应对结果不确定性的机制，其存在不仅是有效这么简单，更重要的是为提升效率而服务。

03

以互联网或游戏项目为例，项目研发流程通常是我们最常用的一种解决团队效率低下的手段之一。

PS：这个流程是更细化的版本研发全流程，你也可以把版本改为需求，可以用于一个需求的全研发过程。

为什么说一个好的流程，可以解决团队协同效率低下的问题呢？

第一、源于需求、忠于目标

团队协同效率低下，从事情的角度来说，更具体一点，就是团队成员彼此间的工作流不清晰，各角色的具体职责界定的不够明晰，或者团队彼此间的工作流程和步骤太过于冗余，更还有甚者，每个人都按自己的工作方式去做事情，压根不管上下游的情况。这些都是现实可能存在的问题，而要解决问题就是我们的目标。

第二、依托业务，梳理流程

前面我们谈到，是游戏项目为例，具体到某个版本或某个需求的全过程，这是业务本身。我们要思考的是，该版本从开始启动到最后发布出去，整个环节是怎样的。

根据上面的流程图，我把我们的版本全流程梳理成为7个阶段，分别为：版本（需求）评审、设计方案确认和排期、版本（需求）开发、版本（需求）验收和测试、版本（需求）发布、外网观察和版本（需求）完结、外网问题处理和总结。

第三、以终为始，开展设计

梳理了7个阶段，接下来就是以终为始，开展设计，这个设计的过程，其实就是定义清楚每个角色的具体事项，以及侧重点。设计阶段是非常重要的一环，每个阶段流程的设计，会直接影响到团队各个角色的工作流转。

版本（需求）评审：这个阶段，核心的角色是产品人员，界定清楚了产品人员该做什么事情，包括但不限于：产品需求必须是产品内部对齐确认过的且每个需求都清晰；产品负责人在评审前一天发出需求；产品负责人组织需求评审；产品负责人邮件输出需求评审纪要。这样一界定，产品人员就清楚在需求评审阶段要做什么事情了。

设计方案确认和排期：设计方案确认，肯定是和开发有关的。在需求评审完之后，就是开发开始设计方案，并对设计方案进行审核及确认。从需求评审到设计方案，不只是界定清楚了阶段，更是衔接了从产品到开发人员的过渡。 也即，需求评审完，就是告诉开发人员，要开始写需求的设计方案了。

在方案设计阶段，通常会有两轮确认，一是核心骨干确认，一是对应开发leader确认。当设计方案确认之后，就是进行WBS分解，并进行详细的工作量评估。在这里，如果项目经理要做的更好，其实还可以定一个规则，比如，需求评审完之后，1-2天内要输出详细工作量评估，并直接发给项目经理。有了这个规则之后，就不用项目经理挨个去催问。

当WBS分解完成，项目经理拿到详细工作量评估之后，就开始进行排期，制定详细的计划。当计划出来之后，项目经理还需要和各团队成员一起核对确认。

版本（需求）开发：计划输出了，就自然到了下一个阶段，需求开发阶段。这个阶段的核心角色仍然是开发人员，同时还有测试和产品人员的配合。因为在开发期间，开发除了自己进行编码以外，产品人员需要输出配置，流程中会特别规定，在开发自测前必须要输出产品配置。有了这个规定之后，就可以比较好地避免产品配置输出不及时，或者不按要求输出，从而影响了开发的进度。

此外，我们在流程中要求开发自测联调时，在交付需求验收之前，必须要跑自测用例，所以流程中还会规定和要求，测试人员的自测用例需要在规定的时间节点里面输出。这些通常都会非常清楚地体现在计划中。

在版本（需求）开发阶段，通过一系列的流程和规范，可以比较好地衔接开发、产品、测试之间的协同，减少三者之间合作的不确定性。同时，把彼此之间的关键节点清晰地体现出来，可以让他们各自知道上下游的合作及情况。

在版本（需求）开发阶段的最后，还会特别定义，怎么输出版本给到产品和美术进行验收。即流程最后提到的，开发人员自测完成按规范同步版本，具体来说有自测用例通过率达到95%及以上，这个版本才可以交付，而且交付的时候，要写清楚版本的情况，服务器的情况等，并且要主动通知产品人员和项目经理。

版本（需求）验收和测试：到了验收和测试环节，核心角色是产品人员和测试人员，然后是开发人员。产品人员验收，要按规定时间验收完成，并输出详细的体验问题单，且在验收完成后，还需要及时的周知开发人员。当然，这里我们有TAPD工具，会自动通知开发人员。即，产品人员提交体验单之后，可以提给项目经理，项目经理会直接分派给对应开发人员；或者产品人员可以直接派发给开发人员。两种方式都可以。

在确定该版本（需求）是否转测试的前置条件是，这个需求的体验问题是否都修改完成了，或者我们在规则中会界定，当体验问题修改完成度到达90%及以上且无阻塞性问题时，就可以转测试。在转测试通知测试人员时，通常不需要人工通知，是可以直接通过工具设置自动流转，如我们设置的需求状态为转测试时，则自动进入到测试计划中。

在需求进入到测试计划之前，开发人员还需要同步好可测试的版本。

这样，测试人员在接到该需求可测试时，即可安排测试人员跑用例，提bug，而对应的bug也会直接关联到对应的开发人员，开发修复bug，最后当bug修复满足版本要求时，则会进入到版本（需求）发布阶段。

版本（需求）发布阶段：在版本或需求是否发布时，核心角色是开发，产品、测试和项目经理。因为每个项目都不太一样，这个阶段就不详细说明。但有一点是共通的，就是版本质量必须满足要求，才可以发布，而且发布的有严格的流程管控。

外网观察和版本（需求）完结：在版本发布之后，产品人员要重点去外网进行验证和确认，项目经理也需要一起关注外网的反馈情况。这里主要是作用是，一旦出现外网问题，可以第一时间做出反应和安排，确保问题可以得到快速的解决。

项目全流程这样设计完成之后，每个角色的侧重点在不同的阶段都不一样，且每个角色彼此之间的协同都很清晰。这样可以大大减少过程中的因为人的主观能动性导致的不确定性。

第四、发布推行，持续优化

流程设计完成之后，就是发布推行，并且在运转的过程中持续地进行优化。

流程发布和推行，可以先集中在事情上，通过事情的流转，来逐步影响到人。

然后在执行的过程中，每个阶段都跟进执行到位，观察团队彼此在协作过程中是否还有存在其他效率低下的情况。

04

规范化的流程，在项目推进的过程中，能够提供相对安全可靠的保障。一个好的、规范化的流程，是可以起到事半功倍的效果。

项目经理通过制定明确的规范和标准流程，确保团队成员能够清晰地了解每个阶段的任务，从而降低项目实施过程中的不确定性。

当然，规范化的流程只是解决团队成员效率低下的一个维度。团队效率低，可能还涉及到目标的清晰以及传达到位与否，可能还涉及到团队成员本身的能力。

在解决项目实际问题的过程中，切忌凡是讲流程，把一切问题都归结到流程，这样不仅解决不了问题，反而会使得效率更低。