编辑导语：随着企业的快速发展，现有的企业管理系统已经不能完全适应企业的发展了，企业需要个性化发展和需求，并且新的B端产品对于需求以及流程都有一些改变；本文作者分享了关于个性化企业定制系统生命周期介绍，我们一起来了解一下。
本人先前就职于某金融IT服务企业，主要负责金融企业管理个性化定制系统的项目管理推进、需求对接等工作。
非标准B端产品与传统B端产品相比，可以说项目即是产品，在推进过程中会有大量需求提出、需求变更，甚至推翻原有模块的场景发生，每一家客户到最终验收后的产品展现天差地别。
目前对于B端的非标产品市面上没有比较好的需求管理方案，本文介绍本人负责非标项目的整体生命流程，希望读者能对B端非标产品有相应理解。
一、整体介绍流程介绍：
1. 售前阶段
售前阶段主要由商务对接目标客户，同时售前/解决方案/实施顾问工程师配合给客户做售前测试，主要内容集中于我方产品/系统可实现功能介绍；由于客户建设管理系统一般从0开始，所以实际测试内容较为简略，即让客户有相关概念即可。
2. 需求收集、最小版本确定
一般的企业系统客户同时会比较多家服务厂商产品，项目中标后签订销售合同，售前工程师/解决方案会和产品经理一同与客户确认大体项目范围，结合客户实际生产需求制定个性化内容；此时的个性化内容一般为客户提出的管理方案痛点或急需解决的问题，客户各个中后台管理部门的需求小而杂，甚至不切实际。
由于项目暂属于初期阶段，所以方案制定一般以乙方为主，甲方客户借鉴其他家客户的成熟标准模块居多，这个阶段需要售前工程师/解决方案工程师有充足的行业及项目经验，引导客户完成初期需求制定。
项目经理/实施顾问在这个阶段负责熟悉客户环境（组织架构/部署系统环境/项目组人员安排等），理解客户整体需求，必要时给出建议或指引。
产品经理在该阶段的工作主要是判断并梳理初期版本中需要个性化开发的内容及需求排期。
不得不说本人所在的事业部，当前个性化的IT企管项目中，产品经理角色的重要程度与解决方案和项目经理相比并不高；因为解决方案专家有着更为丰富的行业经验，可以引导客户制定需求，是初期项目框架PRD文档的主要编写者。
项目经理多由实施工程师担任，在整个项目周期中与客户密切配合，及时传达项目需求及项目进度把控，对客户的实际需求理解更为透彻。
产品经理把控着所有客户产品开发需求，但由于个性化过高，产品经理很难把精力放置在每一家客户的项目推进过程，对于各家客户的管理模式、业务场景、需求趋向、实际业务需求也没有办法都照顾到；所以目前产品经理只做每一家需求汇总并在需求池中进行大版本排期，对于单个项目的需求整理、需求紧急度、需求定义则交由项目经理负责。
这种模式的优点在于产品经理不需要对每家客户的管理模式及需求做深入了解，需求紧急度、优先级交由现场把控，对于产品经理来讲节省了大量的精力去应对几十家客户的个性业务模式。
缺点在于项目经理实际担任了产品经理，负责与客户进行需求沟通这项主要工作。
产品最终以项目的形态开展，久而久之产品经理对于客户的业务不熟悉，客户有需求时也更青睐去寻找项目经理沟通，最终产品经理变成了一个需求管理员，加上本人所负责的金融行业产品；若后续产生统一监管变更，对于产品标准化也会产生很大难度。
3. 项目推进
基于第2点，当最小版本需求说明书与客户确认完毕后遍进入了项目推进阶段，此时解决方案及销售人员可以暂时脱离项目，把精力投放在新的商业机会中。
产品经理制定版本开发排期计划发往现场客户及项目经理，项目经理根据产品组研发计划评估实际工程规模，制定整体项目计划；项目计划以产品经理提供的需求排期为主，将整个项目的生命周期里程碑穿插入其中。
当最小版本（即满足整体框架版本）提供至现场后，才是整个非标项目难度的起始，非标的IT项目很难按照传统瀑布模式进行推进，大量的个性化需求会在基础版本上进行填充。
以本人经验为例，在参与系统建设的客户骨干试用最小版本后，项目经理需要与客户各个部门对接人进行需求沟通，从产品流程管理、项目管理、资金管理、合同管理、干系人管理、报表管理等多个维度进行梳理；项目经理作为替代产品经理直接对接客户需求一方，需要谨慎把控需求，尽量将客户的个性化需求往标准模式上靠拢，避免过于个性化的需求大量占用项目整体资源。
同时由于产品的个性化属性，项目的UAT测试结果是否通过是由客户全权把关的，由于合同标书及初期PRD文档描述的颗粒度不够详细，有系统建设经验和对产品水准要求较高的客户会故意压制上线时间，期间需要不停做版本迭代直至需求满足甲方IT领导上线需求。
加上本人负责项目为企业核心业务管理系统，项目的KOL属性会更强，即满足了客户IT部门的要求后，客户还需要向其总经理或董事长进行项目汇报，达到高层领导允许后方可进行上线；这类项目如果能做好KOL，在行业内的企业沟通交流中也会产生新的客户和机会。
产品上线后便到达了试运行阶段，此时是个性化需求爆发的第三个阶段（前两次发生在售前沟通和内部UAT测试阶段），此时产品意味着正式面临客户前中后台所有用户的考验；由于大部分用户在先前阶段没有参与沟通和测试，所以即使进行上线操作培训、编写用户文档后也会存在大量的意见和问题。
项目经理需要和客户IT部门负责人及时对接操作用户提出的新需求和建议，在合同标书范围内的需求要尽可能把控；因为大量的需求均为用户操作不当或不会使用造成的，而用户的真正需求则需要结合实现难度先进行筛选，结合项目实际情况进行优先级排期，同时避免功能的过分改造导致项目延期。
而产生于合同标书之外的需求则不在本期项目的验收范围内，项目经理需整理后提交给内部产品组，由产品经理和销售部门一起对这部分需求进行定价及排期；若定义为日常变更需求，则放置在项目验收后的日常迭代版本中，若定义为合同外需求，则需要额外签署合同以后期任务形式推进。
4. 项目验收及售后事项
项目试运行阶段通过后，则到达项目验收阶段，此时项目经理整理合同完成需求内容，后期待交付需求及项目整体文档，通过公司内部文件审核流程后交付给客户方；将相关交接文档，后续待上线日常需求列表、客户业务情况转交给售后维护部门跟进。
项目经理签署项目竣工报告，销售部门确认收入，至此项目告一段落。
二、写在最后本文以介绍个性化产品生命周期为主，故历史数据迁移及环境搭建部分不做过多描述；上述的每一个阶段，或是产品中的每一个模块均可开展进行详细介绍。
对于非标产品至今也没有一个较好的管理方案，在推进项目及需求管控中基本都会有项目延期、资源分配不足、客户满意度不高的情况发生；所以组内领导目前也在思考如何规划部门分工，调整平衡产品经理的工作职责。
后续我会整理分享自己在工作中遇到的各种问题和小技巧，本文中哪些地方可做改进或描述不合理还请各位老师多多指点。
本文由 @范小闹 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
,
