B端SaaS产品工作流程

　　产品和项目两手都要抓，两手都要硬，方是真B端产品。
　　产品流程
　　产品研发流程大体分为：立项阶段、设计阶段、开发阶段、测试阶段、上线阶段、运营阶段。
　　1。立项阶段
　　主要分为需求搜集和PMO（或产品委员会）立项。需求搜集阶段可以很长，包括如下内容：
　　如果是从0到1或者彻底重构的产品，要先进行BRD的输出。包括整体行业的分析，到竞争对手分析，再到roadmap和对应资源匹配。用BRD进行宣讲，才能向上申请资源进行立项。
　　然后，可能是MRD的输出或者拆解执行。MRD在很多公司会以年度规划的形式提前进行输出，主要是产品roadmap和进度计划。到了某个立项阶段，会根据市场、战略、竞品、技术、渠道等情况，调整版本实现的功能模块以及优先级。当然，还有最重要的项目里程碑计划。
　　最终输出物基本是立项报告，然后邀请PMO或产品委员会进行立项评审。
　　2。设计阶段
　　主要分为需求池和PRD两大块：
　　基于立项阶段的MRD、上版本遗留问题和运营反馈的问题，列出概要清单。
　　然后召集项目成员，进行概要评审。这个评审一般是可行性、优先级以及成本的评审。评审通过的功能，细化成功能清单。
　　也存在研发业务背景较弱，概要已经要很细，功能清单要更细，以评估合适的工作量。上述的一个概要，需要拆成：
　　列表显示（实体的相关信息、列表需要显示的字段、数据规模以及分页）
　　查询（哪几个条件，条件对应的类型）
　　高级查询（哪几个条件，条件对应的类型）
　　新增（表单录入字段，校验规则）
　　编辑（只读信息、可编辑信息、校验规则）
　　启用（规则）
　　停用（规则）
　　删除（规则）
　　3。PRD阶段
　　主要输出物是原型和需求规格说明书，部分小版本甚至不输出需求规格说明书，业务流程、页面流程、交互说明和异常处理都会在原型上体现。
　　B端比较重视文档，在部分敏捷开发的C端，原型也是以逐个拆解的线框图为主。
　　这样有以下好处：
　　一目了然，开发、UI设计不容易遗漏页面
　　UI设计、研发实现工作量评估更加到位
　　UI设计师可以设计更好的UE效果，有更大的发挥空间
　　节省产品经理自己的时间，高保真原型性价比太低
　　绘制原型之前要进行整体的业务建模，力求梳理清楚全部的业务流程和必要信息。
　　在绘制草图时，要多和UI设计师交流，找到更合适的呈现形式。
　　在原型评审的时候，先介绍这些流程，再看具体的原型页面。原型评审结束，前端研发可以开始部分页面的UI开发，UI设计师准备视觉界面的输出。
　　需求规格说明书，需要拆分各业务领域进行输出。一个产品一个需求规格说明书，整个文档会非常的大。加上大量的修订和批注，产品人员维护起来很痛苦。编写需求规格说明书期间，要保持和架构师（开发经理）的沟通，在文档中完善业务逻辑。为了保障文档质量，目前文档是基于用例的形式编写的：
　　这样能更好的和测试进行沟通，减轻测试用例输出的工作，更专注于自动化测试。
　　需求规格输出完成，需要进行需求评审。由于内部项目动辄3个月，这个会议至少需要12小时。拿着几十上百页的文档过，开始还好，半小时后大家就注意力涣散了。
　　目前使用PPT进行需求评审，只关注业务流程和关键因素，反馈效果很好：
　　具体文档可以回去后进行查看，配合项目管理工具登记具体的问题，产品人员进行修复。
　　4。开发计划阶段
　　主要是进行项目的计划排期，不展开讲。内部有开发经理角色，可以将这个任务交给开发经理。
　　5。概要设计
　　如果不是第一个大版本，基本是业务时序图、数据结构的设计。由研发输出，测试、产品进行评审。
　　6。编码实现阶段
　　该阶段事情最为繁杂的，包括但不限于：
　　原型、交互形式的改动
　　用户需求规格的补充
　　追踪推进进度，进行阶段性的测试验收。如客户管理的列表查询和新增编辑功能今天都能完成，要早上找到对应研发人员询问进度情况。进度理想的情况下，下午让研发先自测，然后去进行检查。进度不理想要找出差距，寻找追赶的办法。
　　7。测试验证阶段
　　主要有以下工作：
　　把握测试环境的部署和更新节奏
　　守好需求验证的关卡。根据主业务流程，编写需求验证清单，对产品进行需求测试。如果连主业务流程都跑不通，没必要让测试人员进行测试。
　　修复前期遗漏的业务逻辑。不排除经过原型评审、需求评审、编码实现，还有部分逻辑不在需求规格说明中。例如某个异常情况，需求规格没写处理逻辑，研发按照自己的想法做了。还是需要产品确认，并在需求规格中补充的。
　　8。发布运营
　　发布运营阶段很重要，工作也比较零散：
　　演示环境的搭建，准备数据的初始化
　　针对营销线的方案宣讲，输出解决方案和功能模块清单
　　针对实施、客服的系统实操培训，输出用户操作说明书
　　APP上架文案和相关事项追踪
　　EDM的设计
　　APP更新机制策略的评估，是灰度发布、提示更新还是强制更新
　　用户的反馈进入需求池，为后续迭代做准备
　　支撑验证客户项目，包括方案讲解、需求调研等
　　项目流程
　　B端客户一般有定制化诉求，会以项目交付的形式进行落地。并且公司内部要求每个版本有验证客户，完善产品到实施的知识转移。工作流程如下：
　　整个大流程里面，产品经理可能会在涉及以下工作：
　　在意向阶段介入，协助售前一起完善解决方案（一般是大客户）。
　　在投标阶段初期切入，替代售前进行解决方案的讲解，以及产品的演示（行业龙头客户）。
　　在投标阶段后期切入，负责客户POC功能的调研和规划落地。需要协调各方资源，在实施开发环境进行功能改造，并追踪整体进度（此时未立项，替代项目经理）。
　　在项目立项阶段切入，作为公司的产品部代表出席立项会，维护客情。
　　在蓝图规划阶段切入，支撑需求调研工作。如出差客户现场，主导调研并输出部分PRD。提供最新产品原型、PRD和组件库，赋能实施人员。最后，还可能参与蓝图方案的输出。
　　在系统建设阶段切入，可标准化的功能将由产品部实现。此时需要分配任务跟踪进度，确保标准功能分批实现，满足客户诉求和各项目上线节点。同时关注客户测试环境，确认稳定可靠。
　　在上线推广阶段切入，主要是客情维护和系统培训。另外，也需要输出产品的用户说明书，为一线实施人员提供弹药。此阶段已上线客户生产环境，需要安排服务经理跟进，并做好出现紧急情况的预案。