本文作者对一个B端项目进行了复盘，偏重从流程视点对项目进行拆解，论述其间需求留意的当地。

入行以来，偏要点都是倾向前端即所谓的C端，较少触及后台项目，细细数来不过三四个罢了。最近再次从0到1完成了一个后台项目，感触颇多。

借总结复盘之机，共享一些自己的领会。不管是流于外表也好，或是对你协助天然更佳，一起共勉前行。

目录：

一、项目布景

产品定位：满意内部孵化项目后台办理、统计剖析需求，代号为PGD后台办理体系。

方针用户：母公司的质量协作商、现已协作的渠道商、孵化项意图运营人员。

痛点：重要的用户数据、买卖数据、产品数据布置在第三方渠道，且散布涣散，无法构成有用的办理和统计剖析。

产品方针：经过线上、可视化渠道然后下降操作门槛、协作约束，削减中心资源的投入和依靠，然后有用提高渠道的渠道商入驻率和产品的质量。终究，构成渠道性的影响力和品牌效应。

二、项目生命周期

（可点击扩大）

如上图所示，后台项目产品的流程与前端项目比较而言，有些节点仍是存在差异的。

一般来说，能够分为六个阶段：

（可点击扩大）

三、阶段拆解分述

3.1 发动：产品需求发掘

（可点击扩大）

产品需求发掘，假如从岗位区分来说是产品司理的责任领域。可是作为领会规划师，你假如不参与这个进程，在某种程度上，后续在了解事务深度上是有或许存在误差的。

所以，主张相关用户领会规划师在产品需求初立，即参与评论。当然，这个恐怕需求结合不同公司，不同协作团队来看哈，有些产品不一定愿意领会规划师提早介入。

3.1.1 方针用户剖析

不管是B端产品，仍是C端产品，都离不开客群用户。

KCL项意图用户集体，其实有些不同。如上图所示，分为三大集体：地点内部孵化渠道运营人员、入驻渠道商及渠道商部属的门店相关人员。不同集体又触及不同的利益相关者，这就需求在进行方针用户剖析的时分，留意不同用户需求问题的搜集，并设置不同的挂号编号。

3.1.2 用户方针剖析

改版或许旧版架构联系如上图所示，渠道关于服务商部属的门店没有影响和操控力，门店呈现服务差评或许用户投诉的时分，只能够经过门店的上层服务商进行处理，这种状况极大的影响了渠道品牌传达。

因此，项目渠道期望新版后台项目能够加强关于产品、门店、商户的影响和操控力，防止由于入驻商户或门店的服务，影响到渠道自身的品牌建造。

改版用户方针

3.2 发动：功用需求发掘

功用需求发掘的中心，在于需求的办理和排序办理。

当然，关于清晰方针用户相同重要。方针用户客群，是挑选需求层级的标准要素之一。

由于与C端不同，B端的决议计划者、购买者、运用者一般不会是同一波人，而且价值优先级为决议计划层办理层履行层。故在权衡决议计划产品时，不只需求从多层级来进行归纳平衡，需求愈加重视对决议计划层和办理层的价值。决议计划层，或许是事务方的boss们，也或许是上级主管层。

而咱们获取需求的办法，一般首要分为事务需求、技能需求和功用迭代优化需求。事务需求又分为内部需求和外部需求。例如地点KCL项目来说，咱们除内部KCL事务场景的需求，还有母公司分配过来的需求。

技能需求的基数一般比较小，这种需求首要存在于外部需求状况下会发生技能类需求，一般都是由事务需求发生技能类需求。各种需求汇集成需求池，关于需求的优先级排序就显得极为重要。

3.3 履行：规划、立项、评定

其实这个阶段，我暂时未参与。上图中关于立项的细节，首要是经过一高档产品朋友获悉。

关于规划立项这个，听说一些大厂有的是由产品来推进，有的是由高档领会来推进立项。立项经往后，需求担任人和谐各个部门资源去推进立项的细节，上线之后的目标会直接影响终究的查核。

论题跑远了，关于立项这个环节，依不同公司和项目团队自定，非必要环节。但每次主张需求时，也需求清晰产品的价值，怎么去衡量收益，是否与项目、公司方针有相关，是否共同。

这个关于接下来的需求排序和交互计划规划，有偏重要的参阅依据价值。

3.3 履行：需求、规划、评定、测验

3.3.1 需求评定

由上一个阶段挑选开端需求优先级之后，需求进行需求评定。

需求评定的参与方，一般包括事务方、产品司理、用户领会规划师、视觉规划师（非有必要）、研制（此阶段可不参与）。之后，依据建立当时版别的迭代规划，开端交互计划规划。

至于界面规划，需求看后台项意图实践状况，KCL项目来说，由于并未选用比较闻名的规划言语结构。所以，需界面规划师介入。假如选用了例如antdesign规划组件的时分，界面规划师一般不需求介入的。

B端产品更多是经过技能完成互联网信息化办理，对企业流程进行优化晋级，然后到达降本增效的意图。而C端比较寻求极致的简略好用，在整个产品规划上比较偏重用户的感触，倾向精心打磨页面与交互，尽量少让用户做挑选，以坚持产品的易用性与流畅性。

3.3.2 规划

在考虑交互计划规划的时分，需求分外留意产品的信息架构规划。这其间菜单结构规划、菜单功用父子级整理，内容信息布局——上下结构、左右结构、上下（左右）结构又是重中之重。所有这些，有必要都是依据事务流程来考虑。

如上图（渠道办理员权限图），在不同等级功用权限设置上，需求考虑的是契合用户的操作预期和渠道自身的运营本钱。

例如KCL项目，产品的操控，开端是考虑商户相同具有操作权限的，可是在后续与事务方交流之后，发现就其实质来说，渠道上售卖的产品财物状况现已归属于渠道。之所以会需求商户入驻，首要是为了处理C端用户购买之后，去线下核销的时分，承认财物合法性的。

在交互规划或许界面规划进程中，还有一点比较重要的便是组件化。组件化建立规划界面关于规划后期维护，关于减轻研制的本钱都是有十分大协助的。

要建立组件化项目，需求考虑两种状况：一是从0到1的时分，这个时分一开端就承认建立组件化规划和研制是最为理想化的；二是从1到N的进程中，这个时分，要么一点一点修正前端显现和模块化功用，要么便是会集别的一组人力且有一个牛逼架构师，快速建立新的渠道，后续搬运数据。

规划进程中，最好需求考虑CRUD准则（crud是指在做核算处理时的添加(Create)、读取查询(Read)、更新(Update)和删去(Delete)几个单词的首字母简写）和RBAC模型（RBAC，依据人物的权限操控，模型的中心是在用户和权限之间引入了人物的概念，取消了用户和权限的直接相关，改为经过用户相关人物、人物相关权限的办法来间接地赋予用户权限），特别是关于后台项意图规划领会有很大协助。

3.3.3 交互评定

关于交互评定，此处不同团队又有不同状况。

UED团队比较小的，一般都是产品兼职交互计划规划。此刻，计划需求在产品部分内部进行内审，这个内审，一般超越两次为佳。不管是内审仍是外审，都最好自己规划一个自我审查表，走查一遍，以防止不要的初级过错呈现。

关于中大型UED团队，交互计划一般都是用户领会规划师来主导，也是由领会规划师主讲。

3.3.4 测验

这儿的测验，与后续技能测验无任何相关性。此处的测验是以交互计划或许界面计划为根底，设置跳滚动效逻辑之后，行程与正式功用相差无异的操作领会测验。其意图在于，及时发现计划中不合理或许存在的问题。

3.4 履行：开发、测验、检验

开发技能评定，主张是尽量能够参与的就参与。这也是在KCL项目中，感触颇深的一个领会。

尽管说研制内部评定的时分，更多是评论技能可行性，以及工时预估等。可是，假如能够及时并依据每个人分到的模块，能够有用操控deadline的危险，以及上线排期和排队批阅流程。

特别是产品或交互计划规划的要害流程，要熟知是哪位研制担任。后续交流中，假如呈现问题，也能够及时和谐资源进行弥补。

技能测验的时分，作为领会规划师或许PM，最好与测验同学就各种细节，和衡量目标进行有用的交流。否则，彼此之间或许会呈现一些小误解。存在依靠联系的API是否现已敞开完毕，非要害流程的数据目标没有及时产出，是否搬运下一期……问题无法逐个言明。

还有一点，需求留意的是技能侧，重视的是功用的可用以及部分和反常处理，关于项意图全体和领会并不会重视。所以，关于交互领会，仍是需求领会或PM亲身检验的。

关于产品检验和领会规划检验，正如上文所说，与技能偏重视点不同。要点在于界面视觉元素的布局是否契合用户预期和运用习气，功用操作是否契合用户的认知，信息获取是否添加了学习本钱等。

检验完毕，一定要输出一份检验记载。记载当时遗留问题和已完成功用，首要是为后续迭代规划或许移送作业留存记载。

3.5 收尾：发布、数据监控

当各项检验根本无问题（主流程走通=上线标准），App端常常会用到白名单、灰度、A/B test等办法进行小范围实验，然后开端逐渐放量，用很多的数据来验证作用。

例如：今天头条十分喜爱搞A/B test，然后经过两个计划的数据对比来决议终究哪种计划。关于Web端的产品，由于没有版别这一层约束与阻隔维护，当服务上线时，更需求产品司理做好信息公告、用户反应的搜集作业，在服务搬迁时更是如此，才干做好渠道与数据的平稳过渡、快速应对。

在KCL项目中，首要是数据搬迁和上线放量内测阶段呈现问题较多。B端项目和C端项目测验有个很大差异——B端用户，运用你的体系或项目都是按部就班的，乃至试用半年以上都有。当然，假如品牌背书过硬，这个时间线就会比较短。

数据监测的软件十分多，能够依据团队选取合适的。由于母公司收购原因，后台数据监测经历过易观、数仓、还有集团内部的自研体系。

整体来说，个人觉得易观还好，其他的学习和掌控数据目标方面需求添加一些学习本钱。

3.6 收尾：复盘总结、迭代需求

关于复盘总结来说，假如团队作业状况答应的状况下，是十分有必要的。尽管作为B端产品来说，好用、易用不是首要衡量标准，可是假如能够领会更好，关于后续商场的占据也是一个优势。

与C端产品比较大差异的是，关于用户的感触，B端产品最好是能够与用户访谈交流的。由于是否有用提高了其企业内部的办理功率，实践的调研比单纯的诗句更具有说服力（C端产品另说）。

这个阶段，复盘总结和规划迭代的需求是相得益彰的。

迭代需求的规划，其实便是一个新的项目流程的开端。这点关于不同团队有不同的后续，有的做完从0到1之后，是规划下一版别（小版别两周一迭代，大版别一个月一迭代，遵从MVP）；有的团队，却是需求移送后续团队去运营，接下来是新的项意图从0到1流程。

四、总结剖析

这六个进程，从思想层来说，仅仅是自己从实践项目中考虑总结的一点个人观点。

关于PM或许领会规划来说，要点在于发动和收尾，把控好这两个阶段，关于项目来说最少成功三分之一了，中心首要看的是团队资源和实力。

从界面层来说，还有一个十分重要的点，便是组件化的标准。把握好组件的使用，对构建交互计划、与开发对接和交流会有想不到的收成。

作者：PGDWORKS；大众号：PGDWORKS