B端产品开发全流程管理指南

详细介绍了B端产品开发的全流程管理，包括立项评估、产品评审、开发执行、测试及上线验收等环节。在立项评估阶段，强调了从技术和业务两个角度对项目可行性进行评估的重要性；在产品评审过程中，通过初评和详评确保方案的合理性和技术实现的可能性；开发执行阶段则需要产品经理持续配合解决开发中的问题；最后，在测试和上线验收环节，确保产品的质量符合预期。整个流程旨在提高产品开发效率与最终成果的质量。

立项评估环节

在立项评估环节，分为两个部分，一个是从业务角度看此项目是否合理，而是从技术角度看次项目是否可行。

如果评价合理和可行，基础标准如下，但特殊情况特殊看待，也不一定适用于所有项目。

1、立项评估流程

在这个流程中需要完成一个很重要的目的，就是评估该项目可行性

这种可行性的评估主要包含2个方面：

1.1、产品初步方案从业务角度看是否合理

一般会面临评审方的各种质疑：

Q1：该需求是否涵盖在我们的产品战略内的？是否偏离、不重要？

比如我们的产品战略是打造一个专业的医疗管理系统，那么医疗机构内部的员工打卡（偏oa）的功能是不在产品战略之内的，不是一件重要的事，而且做了之后也会对产品整体调性产生影响，偏离了战略航向。

Q2：该需求是否非常明确？

什么是明确？就是非常清楚什么用户在什么样的具体场景下遇到什么样的问题，它是因为什么原因导致的，用户又想要如何解决这个问题。

Q3：该痛点、需求在实际业务场景中是否真实存在？

有些需求是伪需求，怎么判断是不是伪需求：

（1）用户嘴巴上说想要，其实该痛点并不会对用户造成严重的影响，而且属于比较边缘的场景，用户实际上内心并不重视；

（2）用户想要改善A功能来解决当前的困境，但其实是因为他的业务上游、业务关联方、自身业务流程的问题所导致，其实A功能本身是非常合理的；

（3）用户今天心血来潮提了一下需求，但是单个客户提出的次数和所有客户提出的总量都很小，属于非常零星的需求；

（4）需求是强还是弱，弱需求一般只是帮助客户锦上添花，并不会对核心业务带来质的帮助；

（5）用户自己没有想清楚，线下业务模式还不成熟，还在不断的变化和调整，这种情况下很多需求都是用户自发的探索性试错需求，很可能在不久的将来就会被废弃掉。

Q4：该需求用现有功能是否能够变相满足？

比如办会员实体卡要收20元押金，但是系统只支持充值或消费满1000自动成为XX会员，并没有办卡收费的功能，这个时候可以建一个单价20元的虚拟商品，然后让客户购买，这样退实体卡的时候退钱即可。

Q5：该痛点、需求的优先级是否是现阶段最高？是否现在去实现是最合适的时机？

需要明确该需求是否在当面阶段是最重要的一批需求，因为每个版本能上线的主要功能就那么几个，如何在短时间内让新功能为更多的人所使用，让其发挥出能够最大程度解决用户痛点的作用，这是产品经理需要重点斟酌的。

一般根据如下的思路来筛选优先级最高的：

反馈客户最多的真实明确的非伪需求->属于核心业务环节->目前闭环流程中缺失的一部分->符合产品短期策略方向

此外还要额外考虑一点：对于客户非常紧急的需求另特殊对待

Q6：用这样的方案是否能够真正解决绝大部分同类型的需求？

往往针对同一类需求，每个客户对需求的具体要求又都有所区别，比如大家都想要有电子优惠券的功能，但是有些客户想要免费的、有些想要收费的；有些要折扣券、有些要求要满减券；有些只要支持单店、有些则要求支持连锁。

我们的方案必须能够支持绝大部分此类需求，而不是单一的只能解决某个、或者某几个客户的需求，否则这个功能的价值就会很弱

Q7：该初步方案是否属于优选方案？性价比最高？或者能够产生什么收益、或价值

针对6所述的电子优惠券需求，设计方案会随着场景模型的复杂度不断增加而变的巨大且臃肿，最后成了一个囊括所有场景、适用所有类型客户的大型解决方案。

我们需要一次性完成这么巨大的任务吗？还是说我们需要在当前阶段反复衡量和论证第一期我们该做到什么程度，这包括涵盖的场景的度、适用客户的度、设计的具体细节的度。总体只做到30%，50%，还是100%，以及第一期做到什么程度都是需要考虑的。

如果只要做到全场景的50%需求量的方案，就能解决80%以上的客户需求，那其实这就是一个比较好的方案了

总结：主要通过以上问题来进行合理性判断，因此产品经理从业务角度去考虑初步方案的时候，需要自己心里清楚上述问题的答案

1.2、产品初步方案从技术角度看的问题

一般会面临开发方面的各种质疑：

Q1：该方案是否初步看下来牵涉的模块很多，开发工作量很大，涉及底层改动很大？项目整体体量和复杂度如何？

比如依然举上面电子券的例子，涉及到商品、用户、订单、电子券、统计报表等模块，是一个牵涉面相对较大的功能，特别是对于核心的订单流程具有较大的影响，改动较大，且涉及到底层改动。而且不同类型的电子券、不同的使用条件、不同的核销方式、不同的创建主体等等，多复杂场景会导致开发的工作量也会相对较大。

Q1：该方案会被要求在什么时间点上线更合理？

一般会有一个预期时间，这个时间需要综合考虑正常版本时间、公司阶段性目标节点、甚至是老板的期望时间、技术实现难度、外部依赖性而定

Q2：产品初步方案从投入产出比看是否合理？

预期产品该功能带来的价值，预期能有多少客户使用？有多少客户愿意购买该功能？有多少新增客户因为该功能而购买整个产品？

Q3：是否有足够的人力、或是技术实力来实现？

前提是大概能评估出技术实现难度，需要的人力资源

Q4：是否存在较大的研发风险

（1）涉及到和公司之外的第三方对接，会存在技术对接方案的沟通和确认，

（2）能否达成一致，以及能否统一时间；

（3）牵涉到大量的底层改动、多关联模块的业务改动；

（4）牵涉到复杂的技术攻关；

（5）功能开发工作量很大；

（6）开发资源明显不够。。。等等

产品评审过程

首先从评审人角度考虑：

评审人包括产品、前端、后端、测试等主要人员。

其中的每个角色都带有自己的“目的”，希望从这个评审过程中找到自己心中问题的答案，达到自己的“目的”。

为什么评审要分初评、和详评？

拆分成2个步骤是为了更好的规避错误，如果一开始方向就错了，辛辛苦苦的把详评做完，再一起评审，最后被一起推翻，那浪费的人力成本可就大了。

因此从这个角度来讲，拆分成2步更合理。

保证第一步的正确，能让第二步走的更稳。

2.1、初评

对于开发、测试来说，他们最想要了解的是这个功能解决了什么场景下的什么需求，大致了解产品想用什么样的方案解决这个需求，基于什么样的考虑选择了这个方案，以及整个产品设计的整体流程和主要结构等。

Q1：他们为什么想要了解这些呢？

很显然，了解这些有利于帮助他们搞明白这件事的大背景和大思路

对这次需求和产品设计有一个框架性的认知

继而，评估出需求的合理性、整体功能设计的合理性

同时他们能从中定性地评估出，后续要开发的功能的工作量以及工作难度，因为这是他们最关心的！

Q2：那么初评从整个版本的项目管理的角度来看，其目的到底是什么？

一次高质量的初评就是要使得这些前期的整理分析是相对准确的，头都开错了，后续很多付出可能会打水漂，因此初评就是通过团队的共创，帮助你发现你没考虑到，或者考虑不妥的地方，让整个项目的头开的更好，目标更明确，方向更准确，路径更清楚。

这就是初评的主要目的，其次则是大家在这个过程中找到自己关心的问题的答案，为下一步的行动建立统一的初步概念，提前感知和准备

Q3：基于这样的目的，初评需要输出哪些产物？

这些都是用来回答上述答案的，记住，一切都是基于目标！

这个功能是为了解决什么样场景下什么样的客户需求？

这个需求是否匹配了当前核心客户的核心迭代方向（即匹配产品目标）？

这个功能的方案是否是当前情况下最合理、最科学的选择？

没有目标感的初评很容易流于形式，而无法发挥真正的作用。

能做到以上几点，初评的目的就达到了。

2.2、详评

Q1：首先，我们依然要确定详评的目的是什么？

详评的目的就是为了让整个项目的所有流程、功能模块及具体结构、功能点、页面布局、字段、交互、业务逻辑等等所有的设计细节能达成多方共识且产品方案设计基本正确，为后续的研发工作打好基础

Q2：开发测试对于详评的诉求有哪些：

让开发、测试清楚自己要做哪些功能的开发和测试，具体范围边界在哪里，功能细节有哪些，具体的工作量有多大，以便于他们评估较为准确的开发时间，以及用于在实际开发过程中的参考

Q3：另外，在详评中研发关注的具体问题一般有哪些？也是我们需要解决的问题。

比如：

该方案是否后续还要继续升级，扩展？

该方案是否遵循高内聚低耦合的原则？

该方案是否存在很多意义不大但大大增加工作量、工作难度的设计？

该方案是否对未来产品可扩展性带来严重制约？

该方案的业务逻辑、流程是否存在错误或不合理、是否过度设计等地方？

所以其实在评审前，用上面的问题自查下，发现不合理的及时修正，会使得整个评审环节更加高效，目的性更强。

另外，需要注意的是提供的详评资料一定要足够的精细、全面、准确。

审核遗漏、粗糙、错误的原型细节都会导致开发评估时间出现偏差，开发过程中出现大量的问题，比如漏开发功能、按照错误的原型开发出错误的功能、原型不够详细导致开发按照主观理解进行开发。。。等

这些都会导致很大的沉没成本，而且往往会在进入测试期才被发现，甚至到上线后才被发现。

一个优秀的项目管理中，开个好头异常重要，头没开好，后面的很多工作可能都是无用功

Q4：详评具体要评什么？

包含详细的流程图（子流程）、结构图（功能结构到字段）、原型图、标注。前面的章节已经详细讲过

开发执行

发评审产品经理一般不需要参加，但是评审后其实也需要我们配合

一般开发评审后会产生一些对产品的疑问，比如产品设计错误的、过度设计的、标注不清楚的、结构有问题的等

我们需要再做一次审核，并且对不合理的原型进行修正，并通过邮件、或企业微信、原型修订记录等方式同步给研发小伙伴们

开发评审完后会根据产品功能范围按照模块、功能点分别评估研发时间

（一般来说，对于saas产品，一个研发负责1个，或者几个一级模块）

再由研发经理根据关联功能的顺序依次协调每个研发的正式开发启动节点，确定每个人的研发周期，通过整体性的排期来保证研发过程的顺畅，减少资源浪费。

完成排期，即确定了项目里程碑，进入开发文档编写环节，继而开始开发

在具体的开发环节中，产品经理也需要无缝的不间断的配合开发

需要针对开发在开发过程中提出的各项问题进行解答

这其中有可能出现各类问题：

（1）因为产品需求缺陷导致无法实现

（2）因为开发难度过大导致无法实现

（3）因为开发难度过大而寻求用简单方案处理

（4）因为产品原始需求考虑不周而导致的需求变更

（5）交互需求变更 导致产品需求变更

（6）外部环境变化导致的需求变更

（7）因为开发时间来不及中途砍需求而导致的需求变更

当双方讨论后达成一致意见后，需要在原型上进行修改，同时记录到修订日志中，并通知各类角色（前端、后端、测试），因为你和后端单独约定的改动可能会影响前端、也大概率会影响测试，如果没有通知到位，必然后续会引起很多问题

测试环节

测试环节需要产品参与测试用例的评审，针对测试撰写的用例，进行评估

（1）是否字段全面不遗漏

（2）是否业务逻辑理解的准确

（3）是否有遗漏的分支流程和逆向流程用例

在评审的时候务必形成和测试达成共识的一致标准和格式，不然会导致，测试认为这个用例这么详细就够了，但是你觉得还不够，甚至前期未达成的共识隐患会导致产品在测试体验环节爆发出更大的问题。

上线验收环节

最后上线验收前，则需要产品按照整个流程再使用几遍，主要以正向流程为主，确保整体流程、字段、数据、逻辑、交互均无误。

最后汇总送给大家一份完整的产品研发全流程管理图：