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

本文作者依据工作中项目实践的所思所想，结合案例等分享了B端管理后台相关的知识，供大家一同参考和学习。

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

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

目录

1. 产品简介
2. 产品全周期
3. 阶段分解
4. 总结

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

一、产品简介

• 产品定位：合规相关、企业管理类的公司内部后台产品，代号为数据管理系统。
• 目标用户：主要用户为公司GA（Government Affairs-政府事务），次要为GA的技术支持团队（也就是我们）；
• 痛点：因数据为线下化管理，操作门槛高，会造成以下占用研发核心资源，数据保存不当，部门壁垒的等；
• 收益：通过线上、可视化平台降低操作门槛，减少核心资源的投入和依赖，提升GA工作效率。

GA的核心是为企业保驾护航，主要职能是政府对接、政策研究、政策影响、危机应对、政企合作。详细内容，请参考：https://zhuanlan.zhihu.com/p/32576810

二、产品全周期

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

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

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

三、阶段分解

1. 启动-需求挖掘分析

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

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

（1）需求分析

需求分析需要特别关注用户是谁，识别用户角色（3个层级-决策层、管理层、执行层），用户特点（群体特征），用户规模。

• 用户角色：与C端不同，B端的决策者、购买者、使用者通常不会是同一波人，并且价值优先级为决策层>管理层>执行层，故在权衡决策产品时，不仅需要从多层级来进行综合平衡，同时关注对决策层和管理层的价值。决策层，可能是业务方的boss们，也可能是顶头上司。
• 用户特点：B端产品，特别是公司内部、强业务相关时，群体特征会十分明显。之前负责的KFZJ平台，由于KF本身业务处于不断变化中，普遍较年轻，用户对平台的包容性很强。本次产品的核心用户是GA经理们，他们长期和ZF打交道，特别关注平台的稳定，数据安全与权限控制。
• 其他：从场景、目标、任务来分析，B端与C端类似，需要考量场景是否存在与频次如何，直接目标与间接目标，需要做什么、有哪些方案以及最佳方案是什么。

（2）需求采集

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

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

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

（3）需求管理

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

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

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

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

需求优先级：可以用作优先级的方法有很多，在这里推荐用户等级分析法，金字塔模型法，MoSCoW排序法。

• 用户等级分析法中，将用户分为核心用户，中间用户，外围用户。除了考虑覆盖用户量，还要考虑覆盖用户类型。核心用户的需求优先级更高。B端的核心用户，我认为是管理层，因为这一层承担着承上启下的重要作用，下对执行层负责，上与决策层的影响息息相关。
• 金字塔模型法，源自马斯洛需求层次理论，从低到高对应产品的层级为能用→易用→好用→爱用→传播。虽然划分了B端，C端，不过B端亦是由一个活生生的人而组成的，除了有口饭吃，也可吃得好，吃得爽。B端，特别是公司内部产品，不缺用户，做到能用是否就可以了？私认为终极目标依然是NPS达到8分及以上。

图3-3 马斯洛需求层次理论 #来自网上

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

MoSCoW排序法的详细介绍，请参照https://zhuanlan.zhihu.com/p/63863515

2. 规划-评审

图3-4 规划-评审脑图

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

（1）立项评审

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

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

• 内部系统的收益常见为流程线上化，提升效率，保证准确性；
• ROI分析为可量化数据，例如样本覆盖率0.3%提升至30%，节省人力成本X元；

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

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

（2）需求评审

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

• 一期的产品中，UI参与了首页设计，其他页面采用了Antdesgin这个UI框架，所以未涉及到UI交互评审，故仅针对首页的效果、文案与业务方进行了沟通确认；
• 目前公司内前端研发采用的框架也是Antdesgin，原型设计时也可参照这一框架，既规范也便于沟通交流，提升效率。

Antdesgin地址：https://ant.design/docs/react/introduce-cn

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

• 在一个规模化的产品团队中，研发资源共用，版本时间固定时，产品内审如其名，是产品团队内部组织的评审，每个PM轮流简述自己的需求。
• 外部评审则会涉及各相关方，包括运营、终端、后端、各方QA等。目前所在为技术团队内部，所以产品内审是团队内部预审，包括我的老板，各技术同事，外部评审则会有业务方参与。

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

• 参照事不过三的俗话，内审两次为佳，可以留一些小尾巴，但不适宜还需要开第三遍内审，否则会认为产品能力太差……
• 评审+开发时，原型和PRD相比，都是图（原型）优于字（PRD），简洁明了，研发们也是常常参照原型进行coding；
• 会议纪要责无旁贷地是由产品经理来负责的，包括达成一致的内容和todolist。既方便后续回溯，也可帮助记忆，谁能保证一定记得前2个月都讨论了什么呢。

图3-5 原型截图一角

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

• PMP中常有这么一问，如果相关方经常变更，如何做比较好？答曰尽早请相关方参与。在产品设计和实现时也会遇到同样的情况，平台上线了，业务方反馈我不需要这个，这里XXX，可不可以XX。建议是在需求评审时，务必请业务方参加，当他看到原型时，才能准确地知道他要什么，不要什么。提前反馈，提早修改，提高可用性，降低改动成本。
• 充分沟通包括正式的会议，也包括非正式、一对一的沟通，涉及到产品经理与业务方、产品经理对现有业务的了解等等内容。沟通是拉齐、统一，达成共识的载体，即使复杂，也请各位产品经理在前期多花费些精力与时间。

沟通复杂度，即潜在沟通渠道的总量为 n*(n-1)/2，其中，n 代表团队的人数

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

（3）技术评审

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

图3-6 关键路径示例图 #来自PMBOK

对于技术可行性，通俗来讲就是好不好实现，需要多久开发完成。

虽然有时候可以靠刷脸搞定复杂需求，但更多的时候还是技术上存在一定的问题，或者是研发并未完全认同产品设计，或是产品的价值；曾有开发反馈过费了好大力气的需求，半年都未见到上线的效果。

基于排期和技术可行性会影响产品方案的最终落地，比如可实现但工时长，不可实现时要如何调整技术方案。

对于前者，需要产品经理去把控优先级，哪些必须实现，哪些后续进行优化迭代，对于后者建议产品经理在制定方案时与研发进行提早进行非正式沟通。

3. 执行&监控-开发测试验收

图3-7 执行&监控脑图

执行针对的是开发、测试、验收这3个方的主体按照预期进行技术产出，监控所指的是对于预期研发阶段，由产品经理进行的进度跟踪等，从时间来看是否有延期风险，从产品范围来看是否存在频繁变更，从质量来看是否可达到上线标准。

在开发和测试阶段，除了进度跟踪，产品经理也需要做好支持工作。产品落地是一个渐进明细的过程，随着开发、测试的深入，或多或少会有问题需要确认。

比如依赖的数据指标无法如期产出，则不需要在本期中展示，比如初期定义的指标维度在实现时进行了扩展，接下来要如何让用户可以感知。

验收，会涉及到产品、UI&UE验收。在一期的产品中，没有UI&UE的人力资源，故未进行后者的验收，对页面的整体要求是基本可看。

对于有视觉疑问的地方，因为做不到像素级的肉眼，没有具体的优化建议，比如说间隔X像素，虽看着有些别扭，仍未对前端同学进行反馈。专业的人做专业的事，更能让人信服。

在一期产品中由于QA资源有限，由我进行了共计3轮的产品+功能的验收与回归。在验收之时，同评审阶段一样，需要做好验收纪要，特别是遗留问题和已完成内容，便于后续转交与迭代。

身为QA之时，看着PM验收，总觉得ta们验收的好快，发现的问题总是不一样。以前不明白，现在些许懂得了一些。

• Q：功能测试，产品验收的区别在哪里？
• A：前者关注功能是否可用，侧重于局部与异常处理；后者关注的是否好用，着重于整体与用户体验。

4. 收尾-发布

图3-8 收尾-发布脑图

产品验收达到上线标准时，会进入到整个流程的收尾环节——发布。

App端经常会用到白名单、灰度、ABtest等方法进行小范围试验，然后开始逐步放量，用大量的数据来验证效果，一般会进行版本控制，这样低版本的app则不会透传无关内容。

对于Web端的产品，因为没有版本这一层限制与隔离保护，当服务上线时，更需要产品经理做好信息公告，用户反馈的收集工作，特别是在服务迁移时更是如此，才能做好平台与数据的平稳过渡、快速应对。

• 在之前的KFZJ项目中，以周为维度进行功能上线，在信息公告这一块做得不够好。有大版本的新内容时虽以邮件形式通知了全部用户，但用户是否查收，是否看到内容，无法进行一一收集。后续调整为以钉钉内的消息通知关键相关方-各业务组长（管理层），但至执行层的信息透传仍然存在一定的遗失。
• 本次的一期产品，涉及到了服务迁移。从确认需要迁移到迁移完成，前后共计2周，迁移方案中涉及了现状概况，迁移步骤（数据录入->单节点验证->全量切换），备用计划，人员安排（共4人），遗留问题同步。在迁移中，共发现7个问题，涉及产品，技术，业务，数据4个方面。

5. 收尾-效果评估

图3-9 收尾-效果评估脑图

效果评估和发布的前缀都是收尾，为何要拆分2个？首先，我们常常会忽略收尾，一个完结之后就迅速投入下一产品，也就是俗话说的虎头蛇尾；其次效果评估是一个比发布艰难的事情。

对于效果评估，从3个层面来讲：

1. 对于个人，逐渐形成属于个人的最佳实践和方法论的沉淀；
2. 对于团队，一个项目的成败与团队成员息息相关，不论是经验，还是教训，都需要总结，避免重蹈覆辙；
3. 对于公司，考虑收益如何体现，以数据来说话的话，首先要有可测量的数据指标。

可测量就是个比较复杂的东东，特别是非主流程的优化。比如DiDi的彩色小车–乘客在app内看到的地图上小车icon会随着接单车辆的颜色而变化。

这个小小的产品可以帮助乘客更直观更快速的找到车辆，直观、快速如何用数据来衡量？开个脑洞，比如从司乘的IM、电话等对话内容来进行数据对比，从舆论数据来进行抓取。

图3-10 彩色大车

四、总结

在这五个阶段中，我认为产品经理的重点为启动-需求挖掘分析与规划-评审，前者对应的产品的自身专业能力，而后者则是整体掌控能力的体现。

产品的实现，离不开团队协作。在一期时面对的是新团队、新业务方，有公司老员工、新入职员工、实习生、原ZF干部。

新团队处于动荡期，彼此不熟悉，需要一定的磨合期，产品经理如何做好其中的润滑剂，提供支持？作为有责无权的PM，我的做法是以身作则，信任，借力。

在做QA时，期待有一个可以把控全局、哪里有问题哪里就有ta出现的产品。

虽然还有一些不足，我已在路上。

共勉，以上。

#说明：图3-2，3-3源自网上，如有侵权，请私信。

本文素材来自互联网