售前阶段主要由商务对接目标客户，同时售前/解决方/实施顾问工程师配合给客户做售前测试

非标准B端产品与传统B端产品相比，可以说项目即是产品，在推进过程中会有大量需求提出、需求变更，甚至推翻原有模块的场景发生，每一家客户到最终验收后的产品展现天差地别。

目前对于B端的非标产品市面上没有比较好的需求管理方案，本介绍本人负责非标项目的整体生命流程，希望读者能对B端非标产品有相应理解。

一、整体介绍

流程介绍：

1. 售前阶段

售前阶段主要由商务对接目标客户，同时售前/解决方/实施顾问工程师配合给客户做售前测试，主要内容集中于我方产品/系统可实现功能介绍；由于客户建设管理系统一般从0开始，所以实际测试内容较为简略，即让客户有相关概念即可。

2. 需求收集、最小版本确定

一般的企业系统客户同时会比较多家服务厂商产品，项目中标后签订销售合同，售前工程师/解决方案会和产品经理一同与客户确认大体项目范围，结合客户实际生产需求制定个性化内容；此时的个性化内容一般为客户提出的管理方案痛点或急需解决的问题，客户各个中后台管理部门的需求小而杂，甚至不切实际。

由于项目暂属于初期阶段，所以方案制定一般以乙方为主，甲方客户借鉴其他家客户的成熟标准模块居多，这个阶段需要售前工程师/解决方案工程师有充足的行业及项目经验，引导客户完成初期需求制定。

项目经理/实施顾问在这个阶段负责熟悉客户环境（组织架构/部署系统环境/项目组人员安排等），理解客户整体需求，必要时给出建议或指引。

产品经理在该阶段的工作主要是判断并梳理初期版本中需要个性化开发的内容及需求排期。

不得不说本人所在的事业部，当前个性化的IT企管项目中，产品经理角色的重要程度与解决方案和项目经理相比并不高；因为解决方案专家有着更为丰富的行业经验，可以引导客户制定需求，是初期项目框架PRD文档的主要编写者。

项目经理多由实施工程师担任，在整个项目周期中与客户密切配合，及时传达项目需求及项目进度把控，对客户的实际需求理解更为透彻。

产品经理把控着所有客户产品开发需求，但由于个性化过高，产品经理很难把精力放置在每一家客户的项目推进过程，对于各家客户的管理模式、业务场景、需求趋向、实际业务需求也没有办法都照顾到；所以目前产品经理只做每一家需求汇总并在需求池中进行大版本排期，对于单个项目的需求整理、需求紧急度、需求定义则交由项目经理负责。

这种模式的优点在于产品经理不需要对每家客户的管理模式及需求做深入了解，需求紧急度、优先级交由现场把控，对于产品经理来讲节省了大量的精力去应对几十家客户的个性业务模式。

缺点在于项目经理实际担任了产品经理，负责与客户进行需求沟通这项主要工作。

产品最终以项目的形态开展，久而久之产品经理对于客户的业务不熟悉，客户有需求时也更青睐去寻找项目经理沟通，最终产品经理变成了一个需求管理员，加上本人所负责的金融行业产品；若后续产生统一监管变更，对于产品标准化也会产生很大难度。

3. 项目推进

基于第2点，当最小版本需求说明书与客户确认完毕后遍进入了项目推进阶段，此时解决方案及销售人员可以暂时脱离项目，把精力投放在新的商业机会中。

产品经理制定版本开发排期计划发往现场客户及项目经理，项目经理根据产品组研发计划评估实际工程规模，制定整体项目计划；项目计划以产品经理提供的需求排期为主，将整个项目的生命周期里程碑穿插入其中。

当最小版本（即满足整体框架版本）提供至现场后，才是整个非标项目难度的起始，非标的IT项目很难按照传统瀑布模式进行推进，大量的个性化需求会在基础版本上进行填充。

以本人经验为例，在参与系统建设的客户骨干试用最小版本后，项目经理需要与客户各个部门对接人进行需求沟通，从产品流程管理、项目管理、资金管理、合同管理、干系人管理、报表管理等多个维度进行梳理；项目经理作为替代产品经理直接对接客户需求一方，需要谨慎把控需求，尽量将客户的个性化需求往标准模式上靠拢，避免过于个性化的需求大量占用项目整体资源。

同时由于产品的个性化属性，项目的UAT测试结果是否通过是由客户全权把关的，由于合同标书及初期PRD文档描述的颗粒度不够详细，有系统建设经验和对产品水准要求较高的客户会故意压制上线时间，期间需要不停做版本迭代直至需求满足甲方IT领导上线需求。

加上本人负责项目为企业核心业务管理系统，项目的KOL属性会更强，即满足了客户IT部门的要求后，客户还需要向其总经理或董事长进行项目汇报，达到高层领导允许后方可进行上线；这类项目如果能做好KOL，在行业内的企业沟通交流中也会产生新的客户和机会。