万字干货，分享B端产品经理从0-1数字化项目实操过程

边亚南 2023-07-26 15:19:54

今年年中，笔者主导一个实体企业全链路数字化开发项目。项目功能涵盖了9大模块，140+功能项，需求文档将近4万字，共150页。作为整个项目的负责人，针对项目中业务需求沟通，产品设计方案，团队配合和整体项目管理，总结了些许实战实践经验，分享给大家。

如果你是B端产品经理或项目经理，欢迎一起讨论交流；如果你是传统行业CIO或老板，有计划或者也在做数字化升级项目，多了解数字化项目，或许对您也是有帮助的。

项目背景：

我们为国内知名家居品牌提供用户全链路业务数字化业务定制开发。目的是将用户的所有触点，从接触，销售跟进，踢单成交以及交付后全部的服务和业务流程实现数字化，以此提升用户体验，提升全链路业务效率。

产品经理，产品经理网站

一、关于方案设计

1. 穷尽拆解低耦合：复杂逻辑的处理原则

对于复杂的产品项目，从业务流程梳理-抽象设计方案-逻辑流程梳理-交互细节设计-部分底层框架的设计，对产品经理来说是非常考验大脑的思考力，(当然逻辑能力是基础)。

尤其是链路较长，涉及条件较多的逻辑，在梳理方案时候，需要做到”持续思考力“（虽然这听上去像是一句废话）。但是我相信有很多产品经理都会遇到有方案瓶颈但是中断的情况。

中断思考等于前面做的思考全部作废，还需要再重新梳理逻辑，低效率且低效果。如何减少这种情况呢？可以试试穷尽拆解法（有点类似金字塔模型的MECY分析法）。

产品经理，产品经理网站

在做复杂逻辑梳理+需要做设计方案决策时，有时候困住你的可能是设计决策，或者是逻辑本身。可能你想直接找到答案，但是此时效率最高的方案是将所有的情况全部可视化梳理出来，将所有有关联的维度因素梳理出来，交叉确定每个逻辑，或许解决方案会自然出现。

举个例子，我们有一个业务流程有9个关键业务节点；每个节点有多个条件判断并且有正负逻辑的流转；同时这9个业务节点有三种不同类型的业务主体。

在处理这种方案时，如果不独立拆解到最小颗粒度，很容易遗漏逻辑或设计出耦合的方案。对方案的灵活性带来很大的影响。高内聚低耦合，是系统设计的基本原则。

我们的方案是，把全部的逻辑（哪怕有重复的流程）用流程图的形式全部可视化展示出来，整个逻辑一下明朗起来。

2. 设计工具：服务蓝图

服务蓝图是服务设计师常用的工具，在数字化项目，涉及到多端交互且有关联的流程时，非常适合确定主业务的服务流程；确定服务流程后，再深入到交互，逻辑，以及架构设计。

用户旅程地图是用户体验设计经常用到的设计工具，服务蓝图是服务设计领域常用的设计工具。我将二者做了简单的合并，以用户和一线人员的交互为主线，找到服务流程中的设计关键的点，针对关键触点，围绕”用户体验和”销售效率提供解决方案。

3. 设计陷阱：客户提供解决方案还是需求？

警惕方案设计陷阱：用户调研获取需求过程中，始终理性分辨：客户提供的到底是解决方案还是需求？（很多客户都喜欢给解决方案?）同时设计师要警惕大脑中的“第一自然方案”，而是通过用户的表达了解他的需求场景是什么？他的核心诉求是什么？如何能满足？不断深入分析寻求最合适的方案。

B端产品经理和c端产品的工作流和能力要求有些差别，但是对业务调研和需求了解的过程中，我认为都是一致的。充分的了解客户的最终诉求，用专业的解决方案满足。

我们的整个项目围绕销售数字化，用户体验数字化，用户服务数字化“来进行。在销售数字化过程中，我们为销售提供了一个专门服务客户的小程序。当时在探讨提升销售效率的方案时，销售提到了一个场景，希望我们做一个微商城小程序，这样每个商品都可以直接购买。

这个客户的用户购买模型属于购买客单价较高（平均2万元），购买决策周期较久（大概在2周-3个月不等），在和销售人员沟通的过程中，他们提到，前过用户的产品购买路径可视化的功能很好，但是希望在最后踢单和成交阶段也可以在小程序内完成，所以希望可以把这个小程序做成一个微商城小程序。

其实这个方案和我的第一直觉方案很契合，在考虑解决方案的时候，也自然的顺着这个思路在深入设计方案。但是在深入设计场景时，隐隐感觉哪里不对。

首先我意识到，如果我按照客户的建议做成一个简单粗暴的微商城小程序，那么针对购买需要做很多完整的链路功能才能形成闭环，因为社区零售等行业的购买模型和运营模型与他们完全不同；另外我突然意识到，用户提出的并不是需求，而是解决方案，我们需要继续深挖，了解用户本后的需求本质到底是什么。

方案卡壳，可以进行用户访谈，寻找购买的关键决策因素；与一线使用人员进行访谈，寻找业务流程痛点；

此时可以通过调研后，梳理出服务蓝图，用户服务蓝图，以用户为中心，将服务业务全链路可视化展示，有助于设计方案。（关于用户服务体验蓝图有多好用以及如何使用，后面会专门找一篇文章来写。）

产品经理，产品经理网站

通过用户服务旅程图+服务蓝图工具，和销售人员一起，将用户接触后的流程梳理出来，解决方案豁然开朗。

因为客户成交的特殊性，用户的购买决策影响因素有两个，一个是花色（客户是家居产品），另一个是价格。而在家居行业，一般踢单的形式有两种，一种的膨胀优惠券，一种是膨胀定金。

在导购的销售流程中，如何和用户发起沟通，如何推动抓到了这两个关键点，我们一起确定了功能简单，闭环链路短，以及灵活满足需求的功能。

我们并没有简单做一个连锁微商城的小程序，而是为销售在智能导购功能的基础上，提供了收订金，以及一对一推送优惠券的功能。并且提供了商品卡片，可以灵活的配置商品卡片，以及用户的操作路径可视化，并实时给销售发通知，收取的订金还能直接转化为后续订单中的预售款。收取订金的金额由销售主导，并且支持设置付款后实际抵扣的金额。

用这种形式，最大自由度的满足了销售踢单和锁客的最后一步。而这种解决方案也非常满意。

整个方案的开发成本很低，满足的场景足够灵活。而如果一开始根据销售的建议，或者根据直觉方案做一个商城小程序，需要做很多额外的功能才能满足自由灵活的销售流程。

4. 利其器：好用的工具和表格

我们提供给技术人员的文档是PRD+交互图，PRD文档中很好用的工具有几种：

关于角色权限表格针对特定身份的人拥有不同的操作权限。用表格的形式，开发同学在实现时候，可以很清晰记录技术方案；
列表状态-操作表格后台系统列表的管理页面非常多；对于复杂的列表，状态对应操作最好的表述方式也是以表格的形式展示。针对每一个操作需要再逐一说明流程；
业务流程图业务流程图是帮助开发同学整体了解工作流，处理好判断条件和对应条件的处理方式，可以更好的理解项目业务，提高开发效率。

5. 细节至上：需求管理中需要注意的TIPS

1）冗余还是关联？

B端产品设计时，很多数据库字段是技术同学设计数据库时非常关心的部分。多个数据库表存在时，有时候技术会直接利用关联表进行数据查询。但是对一些记录型的功能页面内。数据需要冗余记录，不能实时连表查询。这个细节需要标清楚。

常见的冗余数据，例如订单信息，用户改了手机号，或者商品后续改了名称，订单内的信息不会实时更新；结算信息，不会因为商品改了价格而实时更改结算数据等。

关联数据例如用户的头像，如果用户更换了头像我们在会员的微信卡上的头像也会随时的更换。工作人员的手机号进行了更改，会员联系导购时也需要最新的数据等。

2）隐形的数据处理规则

很多时候技术很容易根据需求和交互中的字段来设计数据库，但是有一些关键的数据可能并不会直接填写在页面上，但是是非常重要的数据。

常见的比如创建时间，创建人，更新时间，更新操作人等，若不标志清楚，经验少的技术人员很有可能会出现后续需要找数据时，数据库没有记录某些关键数据的情况。数据库关键字段和页面字段之间的gap，需要产品经理提前梳理好并标清楚。

3）复用组件的UI一致性提前确认

大型项目开发时，前端在多个功能模块中会涉及到相同的框架和组件的使用，框架仅提供了功能层面的复用性，但是在UI层面如果未约定，则后期会出现页面不一致的情况。所以花时间梳理好复用的组件，例如表单，列表，弹窗，浮层等，在多功能并行完成后，会实现一致的交互，磨刀不误砍柴工。

二、关于团队

1. 效率为王：和技术同学的沟通方法

产品和技术沟通时，了解前后端不同技术人员的关注重点，沟通起来会更高效。

后端同学负责主要的业务逻辑实现，他们关心主业务流程，功能逻辑和流程，数据流转，以及数据库设计时的字段和数据；

前端同学关注的是页面交互和跳转，UI的实现，以及和后端配合的技术实现。了解这些，在做需求沟通时候，可以有重点的和不同端同学沟通。抓住不同段同学最关注的点，帮助他了解需求本质，效率会提升很多。

2. 避免技术思维的“逻辑陷阱”，产品经理要大胆做决策！

B端复杂的业务逻辑，需要和技术频繁沟通。技术思维有时可以提供解决思路，但是所有的B端产品经理需要注意一点：避免被技术的极端逻辑思维把讨论重点和产品思路带偏。

技术在考虑问题时，第一直觉是从纯逻辑层面考虑，极端情况是非常重要的一个环节，但有时提出的极端情况在实际的业务场景中出现的很少甚至不会出现，但是如果技术方案实现，可能会耗费大量的时长。

此时产品经理需要大胆的做决策，通过人为确定极端情况的确定处理方式，降低项目成本，同时可以很好地支持业务流程。

举个例子：有一次在讨论一个用户预约安装地板的情况时，如果有用户未安装完成，需要有一个特殊的安装工逻辑处理，如果把这种逻辑全部用技术实现出来，投入的时间会很久。

当时我突然意识到技术又陷入了“逻辑陷阱”，当时立即提出“简化逻辑”的产品方案。和客户沟通后完全可行；和技术沟通很快可以实现，以此既不影响业务的流转，也实现了高效率的实现功能。产品经理适合时的做决策，通过产品优化可以降低技术方案的复杂性。

但是这种功能情况下，产品经理需要明确自己的设计原则。一味的妥协方案会牺牲体验。做决策的基础在于对业务场景的理解和熟悉程度上，有不确定的情况时候，可以回归到一线的访谈和沟通，辅助确认方案。

3. 指挥家：善用团队的能力

在整个项目的实现过程中感受最大的是，团队的协作是最大的生产力。个人的能力再突出，没有团队的配合，也无法拿到非常好的成果；个别的能力偏弱，通过团队的配合，也可以实现惊喜的结果。

设计方案时候，善于利用技术同学的逻辑能力和技术思维能力，可以找到高度效率的解决方案。

比如我们在设计一个审批流方案时，因为涉及到全国的门店，不同类型门店例如直营加盟，不同大区的审批流程不一致；并且相同的产品可能在不同的审批流中的价格也不一致，在设计方案时，技术同学提供的存储数据以单条存储，将复杂的方案最小颗粒度保存，给交互设计提供了很大的发挥空间；一下就让方案清晰了很多。

前端同学对技术的熟悉和经验，在细节交互上可以提供很多细节的提升。

比如一个长表单页面提交时候，空值的提醒，前端同学可以直接定位到空值位置；有的同学可能说这些不都是应该的吗?其实这和经验有关，有的团队没有交互团队，可能产品不会花太多精力在细节交互上，此时前端同学的体验经验可以很好的弥补体验的缺失。

整个产品就是在一点一点的细节体验中，丰满起来的。

三、关于项目管理

1. “云”项目启动会

大型的数字化项目或软件开发项目，不管是甲乙双方的合作，或者是公司内部重要项目的启动，都需要一个“仪式感”的会议，代表项目正式的kickoff。关于项目启动会的流程，包括ppt内容，网上搜索可以搜到很多。但是我们当时在项目启动时，还在特殊时期，所以使用的在线的“云项目启动会。”

项目启动会是数字化项目非常重要的一个环节。其目的不单单是将项目计划告诉所有参与项目以及甲方的领导或高管，最重要的是让大家了解项目的重要程度，对项目过程中需要配合的积极配合，以及让所有的高管和参与人员统一思想。

云会议的形式，本身会让沟通的效果打折，那如何做好云项目启动会，让这个会议达到应有的效果和价值，这是我们面临的第一个问题。

我们通过两种方式达成了比较好的效果。

第一个，在项目启动会的开头，比较重要的是总裁和总经理的讲话内容，我们为了让这个环节充满”仪式感“，在课件上放置了领导者的形象照片，和正在发言的状态，让在线参会者直观感受到总裁和总经理的讲话。这种形式后来被公司云启动会作为标准模板。

可能有同学会问为什么不用视频会议？此次会议时，对方多数项目成员在家办公，有部分成员在公司会议室多人一起参会；视频会议的形式容易分散注意力，而且如果视频会议对方没有特别正式的背景，会让整个会议显得不正式。不如直接在课件内容上打造出正式的会议氛围更能提升效果。

第二个在会议前，和项目关键人提前沟通，将对项目的期待和问题做了充分的沟通，在项目启动会时，可以让关键负责人在双方的项目组成员前，可以针对项目很好的发表自己的想法和看法。

讨论和沟通的过程就是认可的过程，这个过程，既有助于关键人提升团队的认可，也能让对方提升对项目的认可程度，这种方式在事后的沟通过程中也被证实是非常有效的形式。

2. 打怪升级：项目风险

任何项目都存在风险。项目负责人需要做到的是保持对风险的敏感性，并立即推动应对方案。而在项目进行过程中，随着陷入到项目的细节流程中，很有可能会出现不能第一时间识别风险，或者识别风险后没有立即的应对策略情况，项目负责人应该有意识时刻保持对风险的嗅觉。一般项目中的风险来源于几种：

1）需求变更

需求变更不可避免。降低需求变更带来对项目影响以及控制需变带来的成本是项目经理需要整体考虑的。若控制需求变更需要保证：

底层逻辑足够灵活；需求调整时可以灵活应对；
核心逻辑反复沟通，最核心的关键逻辑确认；只要项目的主功能模块的主线逻辑没问题；各自功能模块的主线逻辑没问题，需求的变更可能是修改数据库字段或者增加状态等层级的需求变更；
需求的确认到位和业务方的需求确认，沟通到位，也是降低需求变更风险的方式；我当时有一个功能模块因为“想当然”，导致业务方对一个需求点的理解不到位；后来需要新增一个模块才能保证业务流程的完整；这对双方来说是成本；
沟通技巧项目初期给客户埋下“需求变更是很严重的事情”的预期锚点，让客户非常严肃的认识到前期需求确认的严谨性；并且在需求已经确认后期进行变更时，将变更后的解决方案和对方确认，以及将可能产生的人天成本告知；这种严格的控制可以降低需求变更的概率。当然，如果客户有钱任性，随意改；或者需求迟迟无法确认；需要将需求延期带来的影响告知。

2）第三方合作导致不确定性

不管是对内还是对外的项目中，有可能您的项目需要和第三方的开发合作，而和第三方合作的项目不可控性大大增加。前期控制好不可控信息，确保项目推动得心应手。

合作周期不放在主合同内约定项目上线时间：和第三方的合作周期有时间风险，建议在确定项目上线时间时，将此部分的上线时间单独计算。
合作过程中，做好定位：若项目推动过程中，第三方的时间无法保证，则需要确认清楚在问题中三个合作方的定位是什么？是主要的推动人还是积极配合即可？如果应该推动的事情不推动；或者不应该自己推动的事情自己来推动，前者会造成项目延期风险；后者会让自己“吃力不讨好”，也有可能无法达到预期的效果。
以文档形式确认三方的方案和沟通内容：我们遇到了一个比较大的坑，对接方承诺可以提供的接口在方案已经确认之后，后期表示无法提供；导致部分业务逻辑的调整和部分对接接口的更改。所以每一步的流程都需要双方或者三方的签字确认。控制“技术需变”是对自己团队的保护。