在企业中，业务需求的管理和对接常常是产品团队面临的重大挑战。本文作者结合自身入职新公司后遇到的需求管理问题，详细梳理并分享了一套全新的业务需求管控流程，希望能帮到大家。

最近入职了一家新公司，职责是作为某业务线的的产品 BP，负责对接该业务线的需求并推进，完善业务线的系统能力。

由于产研团队在业务需求承接环节没有统一的管理机制，在业务需求沟通与承接时遇到了一些问题，这些问题对于需求的管控，交付，以及产研团队的产出价值都产生了不同程度的负面影响。因此在合作一段时间后，对需求的对接流程以及提交需求的要求进行了梳理，并宣贯执行，如果你所在的团队对内部需求的承接也没有管控机制，可以参考。

原需求协作场景

场景一：业务直接提“解决方案”

这是沟通中经常遇到的情况，业务不提需求的场景，解决什么问题，价值是什么，而是直接说“我要 XXX 功能，什么时候能上线？”

该场景暴露了团队对于需求价值关注度低，缺少需求判断环节。

这种“需求”如果直接跟着业务的方案思路走，帮他们完善方案并推进开发，很可能会出现以下风险：

• 实现后业务不使用，说这不是他们想要的功能；
• 实现后业务使用，但价值并不高；
• 方案本身并不合理，或过于复杂导致实现成本过高。

场景二：习惯提“口头需求”，“一句话需求”

经常是开会中说了一句话，聊天时发了一条消息，或者讨论还没有明确结论的情况下，认为已经提需求了，在接下来的某一天突然问你需求进度怎么样了。

这种情况下，通常都是“一句话需求”，或者只是讨论的方向还没有形成明确的需求，这种“需求”如果进行承接，很可能出现以下风险：

• 需求零散混乱，造成后续的需求管理，开发等流程疲于应对，占用产研团队大量的精力与人力；
• 看似做了很多需求，但很可能整体价值不高，对业务关键指标的提升无多少影响；
• 产品的时间被迫切割为零散时间，占用思考时间。

场景三：需求描述混乱或过于发散

这也是沟通中经常出现的一种情况，与业务沟通需求时描述不清，无法形成闭环，或者沟通无重点，全程都在发散思维，每次沟通时间都很长，但没有有效的结论，造成双方的时间浪费，很可能后续业务还会提出质疑，说已经和产品沟通好几次了，浪费了我们时间但产品还是做不出来。

这三个场景，是我与新的业务方合作时经常遇到的，和一些朋友交流后，发现大家或多或少都遇到过类似的情况。

为了后续更好的与业务方合作，以及更好的提高产研团队的价值产出，结合实际情况梳理了一份需求协作流程，实际应用了一段时间，相比之前好了很多。

新的需求协作流程，主要是通过规范提需流程和设置提需要求，解决上述的问题。

新需求协作流程

提需流程

如上文所述，业务方原本提需求处于无序的状态，习惯“随时随地提一个”，且认为只要和产品说过就算提交需求，所有需要都必须开发实现。

新的协作方式，对提交需求流程进行了明确的规定，整体流程如下：

首先，需要按照“需求提交模板”的要求填写文档

这个要求的目的是通过书面化的形式，让业务在提需求前，进一步的梳理自己的诉求，理清楚思路以及必要性，加深业务自己的思考，同时也为产品收集更多的信息，便于更好的理解与处理需求。

其次，需要通过邮件的形式提交需求

这一步的目的是通过正式邮件进行提需，后续需求是否准入，方案是否达成一致，排期，效果跟踪都可以基于提需邮件进行反馈，做到需求的全流程跟进并有据可依。

同时，邮件需要发送直属领导以及业务部门老大，也增加了提需的门槛和心理压力，会再一次促使提需人提需前仔细思考。

发送邮件也相当于周知，让相关人员知道该需求以及后续的情况（如是否准入，产品方案是否达成一致），避免日后出现分歧。

最后，通过需求准入会双方共同确认是否准入

这一步则是为了与业务方达成一致，明确准入的需求以及优先级，后续的产品设计以及推进按照共识进行，避免需求无序。

同时也能强化“提交需求≠必须开发”的认知，业务方有提交需求的权利，产研团队也有拒绝需求的权利，面对业务提的无法证明价值和成功概率的需求，产研团队是可以说不的。

需求准入会上，由提需人阐述需求，重点包括背景，使用人群，需求价值，由参会的业务部门领导与产研领导共同决定是否准入。

提需要求

产品团队提供需求提交模板以及示例，提需人需要按照要求填写模板，从而提高业务需求的质量，也在开会前收集更多信息。

以下是提供的模板：

在设计提需模板时，并没有要求过多的字段，主要是为了简化业务的工作，避免对业务过于复杂。但对于每个字段的描述，则要求详细且可以量化。

其他说明

推行需求协作流程，不仅是产品经理自己的事情，也涉及跨部门的协作，需要产研内部与业务方均支持，尤其是业务方，要避免觉得是为了限制他们而产生负面情绪。

强调新协作流程的价值

在与业务方宣贯时，需要强调需求协作流程是为了更好的支持业务，快速有效的将重点需求落地。可以先列举当前协作中的真实痛点例子，这些痛点不仅是产品经理的痛点，也是业务的痛点。

设置特殊需求处理流程

上文提到按照固定时间进行需求准入会，但实际中会有一些特殊情况，无法等到需求准入会或无需必须参加准入会：

• 一种是紧急需求。需要设置处理紧急需求的机制，避免框架限制业务，但需要限制次数，比如每季度最多可以申请 3 次，且一旦插入紧急需求，涉及到已有需求排期变更需要同步业务；
• 一种是实现成本较低，比如添加一个枚举值，这种需求可以单独流程无需参加准入会，但需要设置明确的判断条件，如“单开发人日≤0.5 天，无系统架构影响的需求”，以避免执行过程中的灰色地带。

与业务共同制定阶段性目标

可以每季度初联合业务方制定本季度的重点目标，专项解决某一两个方向的问题，这样可以聚焦方向，避免需求零散，更加容易对业务产生高价值。

阶段性的目标，也可以作为评判某个需求是否准入的维度，如需求与核心目标不一致，且实现成本较高，则可暂缓准入。

已上是为了解决实际面临的提需问题而推进的新需求协作流程，流程并不复杂，本质是为了建立“需求过滤器”，避免产研成为“业务的附属团队”，而将精力耗费在低价值的需求上。