从0到1：业务系统设计复盘

水问 2023-07-25 12:48:42

一、项目背景

公司介绍：一家互联网房产平台公司，主要的客户群体是房产中介。

销售模式：地推模式，需要每天到各个中介门店拜访沟通。

业务背景：随着房产市场降温和竞对公司发展，公司业绩急速下滑。为了提升销售业绩，所以公司老板要求一方面加大产品创新投入，另一方面强抓销售过程管理。

业务现状：目前对于整个销售过程管理没有线上化，全部依赖于销售每日线下反馈的拜访日报，所以存在大量虚报拜访的情况。

二、项目过程回顾

这种从0到1的项目，大多工期很紧。幸好笔者之前整理了一套产品过程管理的模板，快速梳理了产品的工作任务及粗略的时间计划。这个模板能适用各类从0到1 或者重构项目，建议大家收藏。

下面的内容就是项目过程的具体回顾。

三、项目启动

1. 战略层调研

调研目的：明确产品建设目标。业务系统是为了支持业务目标的达成，所以第一步要梳理清楚顶层管理者的战略目标，进而明确产品的目标。
调研内容：战略目标、核心客户、业务模式、盈利模式、核心策略、产品期望等。
调研对象：顶层管理者（包含不限于：老板、业务线负责人等）。
调研方式：面对面访谈。

本项目的战略层调研结果：

调研对象：集团总经理、销售副总
战略目标：销售额同比去年增长30%，突破XX亿
核心客户：房地产中介经纪人
业务模式：定位还是房产信息平台，中介经纪人入驻平台后可发布房源信息，C端通过平台获取房源信息，然后通过平台产品连接，再切换到线下沟通交易
盈利模式：向经纪人收取平台入驻费用，同时提供相关的付费广告服务
核心策略：维持我爱我家、链家这些大型房产中介公司，但今年要进一步覆盖中小型社区门店。为此要加大对销售过程的管理，加强销售覆盖量和提升销售转化

产品期望：

将整个拜访过程线上化，能实时监控到销售的拜访情况。彻底规避虚假拜访的情况，保证拜访动作的有效执行。
能通过数据分析，能销售提供智能的拜访建议。

2. 产品现状梳理

目的：明确产品的边界和对上下游的依赖。因为业务系统的上下游众多，所以即使是从0到1设计一款业务系统，前期也需要把相关的产品现状梳理清楚。
内容：相关产品的功能架构、实体关系等等
方法：找到对应的产品和开发，梳理相应的产品功能架构图和ER实体关系图。

本项目的产品现状梳理结果：

相关系统：只有3套系统，一套是简易的客户信息系统，一套是供应链管理系统，最后就是C端房产前台。其中客户信息管理了公司-门店-经纪人这3层的信息；供应链系统管理了产品、订单、收款、履约等信息。C端就是大家熟悉的房产平台，展示经纪人的房源信息。具体的内容就不再展开了，大家了解这个环节主要做什么就行。

3. 竞品学习

目的：借鉴竞品好的设计，加快产品建设的效率。同时通过对竞对的研究，规避一些因考虑不全导致的设计漏洞。
方法：就是竞对研究的常用方法，不赘述。

注意：

尽可能选择业务模式相近的产品作为竞品。
不要停留于产品功能的研究，更要深入了解背后的设计思路和业务策略。

4. 项目规划方案

目的：对整体项目有大致的规划，用于指导后面具体的项目工作。
内容：背景、目标、方案概述、项目团队、里程碑节点、沟通机制等等。

这部分不做展开，基本大家把上面几部分的内容梳理清楚就可以了。

5. 项目启动会

目的：上下同欲，拉着项目成员一起把目标确定下来，任务分配下去，正式开工。
内容：项目规划方案里的内容，加上领导们致辞。
参会人：领导+全体项目成员

这一步非常重要，千万不能省略。因为笔者见过太多没开启动会就开始干，大家目标都没有对齐，过程中各种撕逼，最终项目以失败收场。

四、需求调研

调研结果将直接决定后面的产品架构设计，笔者刚做产品那会儿曾经因前期调研不到位，花费大量资源开发出来的产品被用户吐槽、甚至是被用户弃用。所以千万不要因为项目工期紧张，而潦草应付这个环节。整个过程一定要详细调研，力求获得真实全面有效的信息。

1. 业务调研

目的：了解实际的业务场景和需求。

对象：业务环节上的所有角色，例如本项目需要调研一线销售、销售主管、销售经理、销售运营支持、客户（中介经纪人）等。

内容：包含但不限于以下几点：

组织架构及岗位权责
工作流程及规范
绩效考核规范
核心数据指标
当前的业务执行痛点和需求

方法：面对面访谈、亲自参与体验工作流程。

强烈建议B端产品经理能亲自体验核心用户的日常工作流程，因为大部分用户难以清楚表达自己的需求，很多时候用户说出来的其实是他们认为有效的产品方案，但却不一定是最佳方案。只有产品将自己放到用户的角色中去体验，才能设计出真正有效且好用的产品。

2. 业务调研总结汇报

目的：进一步确认业务场景和需求
内容：前期调研结果的汇总分析
方法：组织各个角色的核心代表一起进行调研结果，尤其是对核心场景和流程再次进行确认

五、概要设计

接下来我们正式开始产品的设计工作，首先把主体框架设计出来，确认主体设计没问题后，再做进一步细节设计。

千万不要一上来就画原型、抠UI，这样不仅会严重影响项目进度，甚至会因为陷入细节而忽视全局，导致项目最终失败。

笔者曾经跟过一个对UI要求极高的产品leader，当时也是做一个重要系统的重构。前期就是跟老板简单沟通了之后，就开始要求画高保真原型图，然后一遍一遍扣细节。结果最后通宵达旦的加了2个月班，虽然出来的产品页面样式精美且交互流畅，但是用户实际应用过程中整个环节跑不通，使用起来极其不方便。最后整个项目团队被老板拉到一个超大的会议室足足骂了一个小时，半年度绩效工资也基本都没了。

通过上面这个case，笔者深刻意识到作为产品需要有极大的责任感及使命感。因为产品是带领开发测试设计等团队成员拿结果的人，如果我们工作不到位，极有可能让整个项目成员的努力付之东流。希望看到这里的同学，能自省共勉。

下面讲讲在概要设计环节，我们具体要做什么。

1. 系统用例图设计

目的：清晰的定义出系统边界，即服务哪些用户及并提供哪些功能。
方法：具体用例图的设计方法，大家可以网上搜索下UML了解。

下面放一张本项目的拜访计划模块用例图，大家参考下。

2. 功能架构图设计

目的：进一步明确产品的功能范围，为下一步产品演进蓝图做准备。
方法：分角色将线下的业务动作，分场景梳理拆分就可以了。

下面是本项目的销售过程管理功能架构图，大家可以参考。

3. 产品演进蓝图

目的：梳理产品功能优先级，以明确后续产品设计和开发的节奏。
方法：分析业务发展阶段，投入产出比和前后依赖关系，然后优先当前业务需求且ROI高且必须前置开发的功能。
本项目的优先级，我们经过跟业务侧的沟通明确如下。

第一阶段目标：实现Do和check的管理线上化

第二阶段目标：实现Plan管理线上化

第三阶段目标：实现Goal管理线上化

第四阶段目标：实现销售赋能智能化

最后明确了整体的产品演进蓝图，如下：

六、详细方案设计

1. 实体建模

目的：这一步相当于打地基，把系统内各个实体的关系明确下来。例如门店、拜访计划、拜访记录等各个实体的对应关系。这一步如果设计不到位，后面会非常痛苦。
方法：从实际业务场景和未来业务发展的角度来梳理，要同时兼顾当前开发成本和未来扩展性。这里强烈推荐大家看这篇文章http://www.woshipm.com/pmd/4079449.html

本项目的E-R关系图，笔者找不到了，所以就不展示了。大家重点关注此环节的设计方法。