随着业务和产品的发展、团队的不断扩大，很多团队都不可避免的会遇到需求流程混乱的问题。虽然有的团队也编写了一些“需求流程规范”的文档，但最终却流于纸面，难以在团队真正落地。如何科学制定并有效落实需求管理规范呢？对此，云效产品经理陈逊进行了非常详细的直播分享，本文是他经验的文字总结。

1. 需求流程的常见问题

1.1 问题1：反馈需求的渠道太多，难以集中管理

如果团队没有使用协作平台，一般会采用多人在线编辑的文档，在IM聊天工具中进行协同编辑。这种方法在短期的协作中是非常高效的，但是随着业务的发展，客户的增多，这种协同文档也会越来越多，给提需求的人和承接需求的人都带来了困扰，他们不清楚应该在哪一个文档中管理需求，并且由于创建文档非常的方便，团队成员很容易创建新的文档来管理需求，这样会让整体的管理越来越糟糕，旧的文档中的需求便没有人再关注了。

即使团队使用了协作工具平台，如果缺少流程规范，也很容易出现类似的问题，产品经理会发现平台中有很多的需求池，收集需求和集中管理需求也非常的困难。

1.2 问题2：责权不明，需求长时间无人处理

需求的交付时间过长，是困扰很多团队的问题，而在这个过程当中我们发现并不一定是开发的时间长，而是需求长时间无人处理，一直处于停滞状态。

出现这种问题的原因，一般是团队之间的责权定义不明确，比如业务团队认为需求已经提交，等待研发团队开发，研发团队认为需求还没有说清楚，还要补充很多的信息，最后当团队发现问题的时候，可能时间已经过去了很久。这种停滞是毫无意义的，很容易让团队之间产生信任危机。

1.3 问题3：需求质量差，经常返工造成延期

需求质量差也是需求流程当中一个经常被提到的问题，质量问题一般包括以下几个方面：

• 需求表述不清
• 需求遗漏
• 逻辑存在漏洞或者冲突

在需求进入开发阶段以后，一旦发现需求的质量问题，就会造成开发和测试工作的返工，让需求交付时间延长，出现不必要的资源浪费。如果不幸在需求上线后才发现问题，那么损失就更大了。很多团队都在想办法解决需求质量的问题，需求评审设一个有效的手段，能够规避大部分的风险。

1.4 问题4：各个团队流程存在差异，跨团队协作比较困难

随着业务不断发展，业务线和产品线都有可能进行拆分，不同团队的需求流程也会逐渐形成差异化，如果一个需求需要两个以上的产品团队合作，就有可能会出现协作的问题。

如果产品形态确实存在较大差异，那么需求流程存在不同也是合理的。但是在一个产品线内部，产品形态基本是接近的，比较理想的情况是，各个产品团队尽量采用相同的需求流程来进行管理。这就好像医院的就诊流程，不同的科室都会采用相同的就诊流程，这样对于病人来说更加容易理解，不同科室之间，如果需要联合会诊也会更加的高效。

2. 为团队制定科学有效的需求流程

需求流程的规范化从制定规范到实施规范，是一个复杂的系统工程。在这个过程中，既要考验团队的组织协作能力，也要依靠工具平台的配置管理能力。接下来我们介绍一下需求流程的整个过程。

2.1 团队角色分析

完成一个需求，往往需要很多的角色一起协作，因此制定需求流程，首先需要对流程中所有相关的角色进行分析，我们可以用一张简单的表格列出各个角色的职能和责任，这里的关键是澄清角色在需求流程中所需要完成的工作，这也是我们后面设置需求详细流程的依据。将各个角色的关系绘制成完整的团队结构图，也有助于在需求流程推广过程中让每一位成员都清楚的了解完整的协作关系。

分析团队角色不能只关注技术团队，还要格外注意需求的来源团队（业务团队），如果需求的来源很多，涉及多个业务团队，那么一定要把每个团队的业务特点、需求类型、客户类型都考虑到，这些信息在需求流程中可能会产生不同的影响。

团队结构图

2.2 定义需求类型和结构关系

需求类型的定义可以说是整个需求流程当中的关键环节，常见的需求类型包括产品需求、用户需求、系统需求、技术需求，还有一些英文概念，例如user story、Feature等等。面对这么多需求类型，很多团队会感到困惑，不知道该选择哪个类。这里切不可完全照搬网络上的一些推荐方案，而是要选择适合团队的需求类型，尽量选择团队成员比较熟悉的比较常用的概念。 需求的类型其实跟团队角色有着非常大的关系。一般每个需求类型都会由一个角色主要负责。我们用递进的方式向大家介绍一下需求类型和结构关系，从简单到复杂逐渐转变，大家也可以看一下自己的团队更适合在哪个模式更合适。

我们先说一下最简单的模式，只采用一个需求类型：产品类需求（有的团队更习惯称产品为“系统”，因此习惯使用系统需求这个类型）。产品需求的负责角色就是产品经理，产品经理创建需求并完成设计，再指派给开发由开发团队完成需求的交付。当技术团队的分工更加明确，一个需求可能会有多个技术人员合作完成，这时我们会在需求下拆分任务，任务的负责角色就是技术团队，这些任务会分配给不同的技术人员各自完成，这样就形成了从产品需求到任务的两层结构。

由于产品需求是由产品经理创建的，因此产品需求的颗粒度会基本保持一致。如果需求的来源不仅仅来自于产品经理，很多业务角色也会创建需求，这时我们将会面临需求的分层，引入业务需求的类型，业务需求的负责角色就是业务团队。由于业务需求是来自于一线的客户或者用户，需求的颗粒度可能存在较大的差异，有的需求很小两周就可以实现，有的需求可能需要几个月。业务需求是无法直接交给技术团队进行开发的，必须要经过产品经理的分析、拆分和整合。

这里我们并不是说有多少的角色就需要创建多少需求类型，还是要根据协作关系的复杂度来判断，如果整个需求流程中的关系比较简单，人数也相对较少，那么一个需求类型就可以解决，如果团队之间存在多对多的协作关系，这时我们还会考虑引入需求和任务的分层。

需求类型和结构关系

2.3 定义需求管理空间

确定了需求类型之后，接下来就要对需求管理空间进行定义，首先需要定义空间的类型。空间类型一般包括：需求研发交付空间、原始需求收集空间、产品规划空间、项目管理空间等等。空间类型的选择也同样需要参考团队的具体协作场景，根据需求的类型和团队角色关系进行设置。每个需求空间会有多个角色进行协作，也可以支持多种需求类型的管理，同样每个空间也会有一个主要负责的角色。

需求研发交付空间一般是必备的，这个空间的负责角色是研发团队，同时管理产品需求和任务两种事项类型。产品经理会在这个空间里创建需求，在完成方案设计和评审之后指派给研发团队。

如果需求的来源也来自于业务团队，那么是否应该创建独立的空间来管理需求呢？这里我们要根据具体情况来定，如果业务团队和技术团队协作关系非常简单，已经形成了固定的搭配，是一对一的模式，这种情况不必另外单独创建空间，所有的角色都可以在一个空间内完成工作。因此需求空间的实质就是承载了一个长期固定协作的团队工作。

但是当业务团队和技术团队形成了多对多的协作关系时，我们就要考虑创建第二种空间类型，也就是业务需求的收集空间(需求池) 。这是因为业务团队录入的需求，经常会需要多个技术团队来承接，业务团队直接在研发交付空间中提需求，效率是比较低的，而且业务团队提出的需求，往往无法直接给研发团队进行开发，还需要经过产品团队的分析和转化。这时就需要一个统一的需求收集空间。

大部分情况下，这两种类型的空间就可以满足需求管理的要求了，产品经理在需求池中承接需求，并转化为产品需求，而产品需求将会直接进入研发空间，由研发团队进行交付。如果产品团队不断发展壮大，有了独立的组织架构，覆盖多条产品线，并且对产品的规划有比较明确的诉求，这是我们会考虑引入第三类需求空间：产品规划空间，这类空间的负责角色就是产品团队，管理比较大的产品主题（topic），产品主题也一样可以拆分产品需求，指派到研发交付空间，在研发团队的视角，产品需求可能会有多个来源，有的来自于业务团队收集的业务需求，有的来自于产品团队自身的规划。

确定了空间类型之后，我们一般会按照组织架构来创建具体的空间，研发交付空间一般以研发经理的维度来区分，因为研发经理需要制定团队的工作计划，在同一个空间中效率最高。需求收集空间的创建一般以业务现进行划分，每个空间也有一位业务一号位（负责人），这样利于需求优先级的排定。

需求管理空间

2.4 制定需求流程规范

在确定了需求类型和空间类型之后，接下来我们要制定需求流程规范。每个需求类型都需要设置流程。需求流程和团队角色有着很大的关系，需求流程规范主要包括以下三个方面：

• 流程有哪些状态？
• 每个状态的责任角色是谁？
• 每个状态达成的必要条件有哪些？

产品需求的流程一般分为设计、开发、测试、发布等几个阶段。业务需求的流程一般分为确认、排期、实现、验收、评价等几个阶段。任务同样也有流程的概念，不过由于任务基本是由一个人独立完成，因此流程相对比较简单。

每个阶段一般都会包括to do、doing、done三种状态，例如业务需求创建完需要进入确认阶段，包含待确认、确认中、已确认三个状态。在选择状态的时候，不必每个阶段都要保留这三个状态，那样会显得有些繁琐，可以根据实际情况选择需要的状态。比如业务需求的确认是通过需求评审会，当场会形成结论，这时就不必选择“确认中”这个状态，只保留“待确认”和“已确认”。在需求指派给另一个角色的时候，就需要选择“to do”的状态，例如产品经理在完成需求设计之后，指派给开发时会将需求设置成“待开发”，开发在完成开发之后提交给测试团队，会将需求设置为“待测试”。

具体的状态还要根据团队的实际情况，设置对应的状态，状态的命名可以参考前文的规则。如果团队中已经形成了比较成熟的需求流程，那么建议尽量沿用团队已有的规范流程。

通过绘制需求流程图，可以同时将需求类型、空间类型、流程状态、团队角色同时展示在一张图上，便于在团队中推广需求规范时，让团队成员更清楚的了解规范内容。

需求流程图

2.5 确定需求评审/排期的时间节奏

需求评审和需求排期是需求流程中两个非常重要的事件，为了让团队协作保持一个固定的节奏，也是为了提高协作的效率，我们建议团队约定一个固定的时间，统一安排需求评审和需求排期。

一般我们建议每周安排一次需求评审，每两周安排一次需求排期。因为研发团队安排迭代的节奏一般是两周，而新需求是每周都会有。不过根据团队的实际情况，这个节奏可以再进行相应的调整。

2.6 需求流程规范发布

如果完成了以上的工作，那么恭喜你，团队的需求流程规范已经基本草拟完成，接下来你需要与各个角色的负责人和团队成员一起评审这个规范，取得大家的共识。在评审讨论过程中，还可以继续对这个规范进行修改和完善，这一步非常的重要，一个成功的流程规范，可能需要比较长的时间的打磨，才能够稳定下来。取得团队管理者的支持也是必要的，流程规范的落地实施本质上还是一个管理行为。

3. 通过云效进行专业的需求规范化设置

前面我们介绍了需求流程规范的制定方法，接下来我们结合云效产品实际功能的来演示一下，如何在工具中落实这些需求流程规范。

3.1 配置协作角色

管理员首先在云效Projex的「全局设置」中，根据规范创建对应的项目角色，并且为每个角色配置初始化的权限点，将来项目模板的角色可以从中进行选择，并且可以根据项目的要求修改各个角色的权限点。

3.2 配置需求类型和需求关系

接下来我们在云效中创建需求类型，类型的名称按照需求流程规范的要求来命名，每个类型可以选择不同的图标，方便用户进行区分。

需求的字段也需要先定义好，需求字段分为“全局字段”和“项目内字段”两种，全局字段的待选值是全企业统一的，在不同的项目空间和不同的需求类型中，都是相同的选项；而项目内字段，可以在各个项目空间各自设置待选值。这里需要把一些各个团队共享的字段创建为「全局字段」。

接下来要进行非常重要的需求关系设置，在全局设置中的可以找到「类型间关系」设置，根据需求规范创建类型关系，比如系统需求下面可以拆解研发任务，我们就可以在这里创建一种类型关系：父项是系统需求，子项是研发任务。这样需求的结构关系就规范起来了，用户只能按照设置的关系来拆解需求。

3.3 配置工作流

创建好需求类型之后，我们开始设置工作流程。云效预置了常用的工作项状态，管理员还可以根据需求规范继续创建其他的状态。

每个需求类型都可以设置不同的流程，我们将工作项状态添加到需求流程中，然后通过勾选checkbox来决定流程的走向。一般在同一个阶段内，状态的流转可以不加限制，而在从一个阶段向另一个阶段跨越的时候，则需要进行严格的限制。

3.4 配置流程状态的角色和卡点

我们需要决定对每一个状态的变化设置卡点，卡点包含「必填字段」和「角色控制」两个方面，比如说进入开发状态，只能由开发团队来操作，并且计划完成时间也必须填写，那么就可以按照图片所示进行设置。

3.5 配置项目空间模板

下一步我们就可以设置项目空间的模板了。云效预置了研发交付类、业务需求收集类等多个模板，我们可以根据规范创建对应的项目模板，每个模板中包含了协作角色和需求类型，管理员可以从之前维护好的角色和需求类型中，将需要的数据加入项目模板。

配置好项目模板后，我们可以创建实际的项目空间。比如按照产品研发团队创建研发交付空间，按照业务线创建业务需求的收集空间。

3.6 将项目模板的配置同步到各个项目空间

如果要保证不同的团队的项目空间，遵循一个相同的需求流程，我们需要设置模板的「同步」功能，实现一个统一地规范性管理。一旦开启了模板的同步，所有由这个模板创建的项目，都会使用模板的规则，项目管理员将无法修改需求流程，如果企业管理员修改了模板的需求流程，项目会自动使用模板的最新流程。

同步的设置也可以按照不同的需求类型进行分别配置，有的需求类型可以既同步需求字段，也同步需求流程，而有的需求可以只同步其中一个，甚至不同步，这样可以满足各种管理场景的诉求。

3.7 通过自动化规则实现需求状态的联动

当需求和任务出现分层管理的时候，让每一层需求的状态保持最新的进展，会让跨团队的协作更高效，云效的自动化规则支持有关联的需求和任务进行自动的状态同步，比如当系统需求下的研发任务变为「进行中」的时候，系统需求的状态也会自动变为「开发中」。

我们可以直接在项目模板中设置这些自动更新状态的规则，这样所有项目都会共享这些自动规则。配置规则一般主要是两个场景：

• 当任何子项变为doing的时候，父项自动变成doing
• 当所有子项变为done的时候，父项自动变成done

3.8 配置需求评审流程

为了保证需求的质量，并且在研发团队中达成共识，我们建议使用云效的需求评审功能。我们可以基于不同的项目，选择是否开启需求评审。在项目设置的「评审设置」中，我们首先选择哪些需求类型需要进行评审，再设置进入评审的「状态节点」，一般是“设计完成”后，可以启动评审。最后可以预置评审的评委，一般是项目经理、开发经理、测试经理等等。完成了配置后，当需求到达指定状态时，用户就可以发起评审了。

一般会由需求的负责人来发起评审，这时可以根据需求调整评委的范围，填写评审的注意事项。评审发起后，各个评委都会收到通知，也可以在项目的「评审」菜单中集中查找与自己相关的所有评审，然后在需求的详情页面中填写评审的结论和意见。

如果所有的评委都选择通过，或者超时未发表意见，均视为评审通过。只要有一位评委选择不通过，则视为评审不通过。评审通过后，自动化规则会将需求自动设置为下一个阶段的todo（如：待开发），通过对流程卡点的设置，可以实现需求从设计阶段进入开发阶段，只能依赖评审，而不同通过手工设置（管理员除外），这样可以让需求评审对需求流程的控制更加有效。

注：文中云效产品演示部分，视频版本会更加直观，视频版见：这里

4. 总结

需求流程的治理是一个长期的过程，需要整个团队的执行力和流程管理人员的推动能力，更需要研发流程中各个角色的互相理解与支持。

云效产品所提供的产品特性，能够帮助各个团队将需求规范落实下去，并且尽量减少协作过程中的工作量和不必要的误会，让整个需求流程变得有序且透明。