B端管理后台复盘：从0到1的新平台

本人前App端测试，现产品新人一枚，有幸作为产品负责一个公司内部的新平台。经过两个多月时间，目前一期已上线稳定运行，二期三期也陆续进入开发阶段。

鉴于后台产品资料有限，尽管业务不同，做个复盘，即是个人的总结，也是小小的分享。经验尚浅，还请各位看官拍砖，不慎欢喜~

产品简介

产品全周期

阶段分解

总结

为避免公司敏感信息泄露，以下平台名称、功能名称均为化名。

产品定位：合规相关、企业管理类的公司内部后台产品，代号为数据管理系统。

目标用户：主要用户为公司GA（GovernmentAffairs-政府事务），次要为GA的技术支持团队（也就是我们）；

痛点：因数据为线下化管理，操作门槛高，会造成以下占用研发核心资源，数据保存不当，部门壁垒的等；

收益：通过线上、可视化平台降低操作门槛，减少核心资源的投入和依赖，提升GA工作效率。

图2-1产品全周期流程图

以上是产品经理的基本工作流程，从初期需求收集到中期的开发，再到上线后的效果评估，都可以看到产品汪的身影。产品经理需要有一颗强大而坚定的心。

基于节点时间、主要内容、相关方，将上述流程划分为五个阶段，分别是启动-需求挖掘分析，规划-评审，执行监控-开发测试验收，收尾-发布，收尾-最终效果评估。

图3-1需求挖掘分析脑图

需求挖掘分析对应流程图中的从开始至需求池部分，进一步可拆解为需求分析、需求采集、需求管理。

（1）需求分析

其他：从场景、目标、任务来分析，B端与C端类似，需要考量场景是否存在与频次如何，直接目标与间接目标，需要做什么、有哪些方案以及最佳方案是什么。

（2）需求采集

从B端来出发，Top1类的需求是为了适应业务发展的合规、提效、安全类的业务需求（也包含老板需求）。

当平台扩展到一定规模时，会涉及到技术需求中的重构、扩展、安全。除了需求本身，也需要结合用户特点，有利于提升产品的效果与收益；

B端带有强烈的行业特征，产品经理需要不断地加强业务学习，提升自身判断。多体验，感知用户、抱怨；多分析，感受形势，分析结果；在观察、学习中逐渐实践，沉淀。

（3）需求管理

需求识别：在《人人都是产品经理2.0》一书中，作者苏杰强调，用心听，但不要照着做。

在需求识别时尤其要注意这一点，通过全面的需求分析等方式杜绝不存在不合理的伪需求，造成无用的功能上线，导致资源的浪费。

对于用户“异想天开”的需求、想法，更多的去挖掘背后的问题，而不是简单粗暴地给乌鸦更多的石子。

图3-2乌鸦喝水来自网上

MoSCoW排序法，是英国项目管理PRINCE2中提倡的一种方法，其名称是4个级别的首字母缩写。这4个级别分别是：必须有–Musthave；应该有–Shoudhave；可以有–Couldhave；可以做的/可以有的；现在没有–Wouldnothavefornow。所有规定为必须有和应该有的，是产品验收时要达到的。

图3-4规划-评审脑图

图1-1中的3个评审统一收在了规划评审阶段，包括立项评审，需求评审，技术评审。

（1）立项评审

立项，结合PMP中定义，可初步理解为公司授权启动，确认目标收益和资源投入。

在公司立项评审会结果通晒中，立项申请包括项目名称、立项结果（通过与否）、方向（项目+客户+收益）、负责人、项目背景痛点、范围、时间里程碑、目标，ROI分析，关键资源（业务、运营、PM、技术、数据、设计、PMO、上线后移交方）。

内部系统的收益常见为流程线上化，提升效率，保证准确性；

ROI分析为可量化数据，例如样本覆盖率0.3%提升至30%，节省人力成本X元；

立项评审，一般大项目项目管理规范的部门会接触到。目前我也只是在KFZJ项目中有收到过立项会邀和立项评审通晒。

做为初级PM，一般不会参与到立项中，但每次发起需求时，也需要明确产品的价值，如何去衡量收益，是否与项目、公司目标有关联，是否一致。换位思考下，如果你是老板，是否会同意启动这个项目。

（2）需求评审

需求评审包括了产品内审、外部评审、UI交互评审；

目前公司内前端研发采用的框架也是Antdesgin，原型设计时也可参照这一框架，既规范也便于沟通交流，提升效率。

产品内审、外部评审的主要区别在于是否涉及组外成员，包括业务方（需求方）、技术团队等。

在一个规模化的产品团队中，研发资源共用，版本时间固定时，产品内审如其名，是产品团队内部组织的评审，每个PM轮流简述自己的需求。

外部评审则会涉及各相关方，包括运营、终端、后端、各方QA等。目前所在为技术团队内部，所以产品内审是团队内部预审，包括我的老板，各技术同事，外部评审则会有业务方参与。

以目前来讲，产品内审是由产品经理作为会议的组织者。为此需要做好充足的准备，包括前期的会议室预定、评审资料分发，会中的时间、主题把控，会后的总结。

参照事不过三的俗话，内审两次为佳，可以留一些小尾巴，但不适宜还需要开第三遍内审，否则会认为产品能力太差……

评审+开发时，原型和PRD相比，都是图（原型）优于字（PRD），简洁明了，研发们也是常常参照原型进行coding；

会议纪要责无旁贷地是由产品经理来负责的，包括达成一致的内容和todolist。既方便后续回溯，也可帮助记忆，谁能保证一定记得前2个月都讨论了什么呢。

图3-5原型截图一角

外部评审，因技术团队可自闭环，故只涉及到业务方。外部评审中的重点是关键相关方参与，并进行充分沟通。

充分沟通包括正式的会议，也包括非正式、一对一的沟通，涉及到产品经理与业务方、产品经理对现有业务的了解等等内容。沟通是拉齐、统一，达成共识的载体，即使复杂，也请各位产品经理在前期多花费些精力与时间。

正式的评审会议建议控制在2次，不仅仅是个人能力的问题，更涉及到所有参与的相关方（包括业务方、运营、研发）的时间成本。

（3）技术评审

技术评审是技术专业性很强的会议。虽然为前app端测试，有微弱的技术背景，但真正参与到其中依然有些吃力。但作为产品经理，还是需要参与到技术评审中去的，应该了解涉及的技术都有哪些方面，才能在排期中识别风险，了解各依赖活动，确认关键路径。

图3-6关键路径示例图说明：图3-2，3-3源自网上，如有侵权，请私信。

本文由@凉凉Lxy原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。