上文跟大家讲了B端产品的准备阶段，看如何洞悉问题明确目标，本文主要探讨的是立项阶段，看整体方案如何设计。

完成第一阶段的问题识别和目标定位，下一步需要确定整个项目的系统定位、框架设计等提纲挈领性工作，包含系统架构、功能蓝图、核心业务流、需求清单、任务拆解、资源预算等。

当所有方案确认以后，公司通常会进行立项评审，项目经理将准备阶段的工作做总结，依次论述项目背景、业务痛点、解决方案、目标计划、软硬件资源预算、实施计划等，并由项目管理委员、业务发起人、技术专家组做评审和确认后，方可执行开展。

立项阶段：整体方案设计

1. 方案设计

（1）系统定位

这个阶段的工作，建议由产品经理和研发经理一起完成。因为对系统的定位、应用框架的选择，研发经理相对能提供更专业的建议和选择。

根据之前的调研，我们基本确定了以下几个角色：客户、商家、派送员、市场专员。基于以上角色的不同诉求，考虑通过4套系统来支撑。

客户端（小程序）：面向客户，支持下单和售后；

客户不希望下载新的APP，培养客户的使用习惯也不是一件容易的事情，包括放弃已有平台的流量红利更不是一个明智的选择。所以原下单平台建议保留，通过外部接口的形式，实现第三方平台的业务流转即可。

但将最关键的流量入口单方面的依托于第三方平台也不是一个长久之计，故自建平台也不能放弃。考虑到研发周期、以及用户体验的问题，APP、小程序、H5中，小程序无疑是更好的选择。

另外，公司可建立公众号，面向客户发布公司宣传信息，公众号菜单等便捷入口可绑定小程序，借助微信自带流量同步实现宣传、吸粉、流量转化。

商家助手（小程序/H5）：面向商家，支持查看配货量和账单；

在当前第三方平台中，一个学校只有一个店铺，并且不同学校上架的店铺有公司统一的名称【xx餐】。对于客户而言，公司就是商家，而公司所谓的商家端更像是采购方或者供货商。作为供货商，商家关注的重点是签订合同、货物配送、定期结账。

而其中线上店铺的创建、编辑、菜单的组合、定价等工作，一是相对于一般的餐饮服务从业者而言过于复杂，二是作为供货商他们并不太关注于这部分工作，都是交由市场专员做处理。

所以面向商家，有一个可以方便、及时查看配货量、结算帐单的平台即可。既然已有微信公众号，保留一个商家端信息查看的入口即可。同时，根据之前我们对业务合作模式的了解，短期内，这个方案应该是满足业务现状的。

派送助手（小程序/H5）：面向兼职派送员，支持出勤排班、任务查看、处理和工资提现；

派送员主要是学生兼职，它主要通过宿舍楼匹配等方式进行直接分配，不存在抢单、售后服务等功能，对于他们而言，最主要的工作还是查看及处理派送任务、以及工资提现的问题。考虑学生的身份，以及及时性随时性的要求，通过小程序抑或是H5平台来搭建兼职派送端，是最适合的方式。

另外在公司的业务模式中，派送员采用学生兼职团队。一是因为高校管控的严格性，外部社会人员很难进入学校甚至是寝室；二是考虑下一步发展兼职业务的可能，通过提供更多的兼职机会或是自主创业机会，来形成新的业务链。那下一步，兼职端也有自建APP的可能。

运营管理后台（PC）：面向市场专员，支持商家、门店、兼职的管理和订单管理等基础功能；

整个任务的工作重点，创建一套方便操作的管理后台，因为涉及到大量的商品编辑处理、账号、门店管理等功能，所以选择PC版本实现。另外，考虑当前主要面向角色是市场，其工作地点可变化性较高，所以不能限制外网访问权限。同时，虽然对移动版本的需求也不低，但综合研发周期、资源投入等问题，移动版暂不列入当前研发计划内。

从当前的现状来看，公司主要及需运营管理的角色是市场部门，需要做商家管理、门店管理、兼职管理；而随着公司下一步发展，面向运营专员的营销活动策划、反馈；面向客服专员的售后服务、理赔等都需要独立的系统去支撑。如果业务蓬勃发展，这几个平台在短时间也有创建的必要。

不过从现阶段来看，可以先搭建运营管理后台，后续有必要，再创建独立的客户管理后台、营销管理后台等其他相关系统；

（2）整体架构设计

根据以上内容，我们可以绘制出公司当前的应用架构图，包括对外的客户端、商家端、兼职端以及企业公众号；以及对内的运营管理后台，主要面向商家、店铺、商品等管理功能。

以上是本次项目所要建设的内容，但针对一个从无到有的企业。还需要哪些环节需要建设，才能保证企业内部正常运转呢。

首先，有关职能支撑类：

• 公司内部信息发布、职员休假、入职、离职、物资采购、登记等等最基础的功能，需要一个OA（Office Automation办公室自动化）系统去承接，通常每一家公司基础的办公需求都差不多，所以OA系统可以选择外采；
• 其次，招聘、员工入职、档案、异动、薪酬、绩效、考勤、组织架构等信息的管理，需要创建一个HR（Human Resource 人力资源）系统，这套系统通常也具备普适性；
• 再有就是企业邮箱，它和OA、HR共同构成办公软件三大件，属于职能支撑系统，都可以通过外采实现。

第二，有关基础支撑类：

客户通过新平台下单，需要调用当前客户位置信息等、调用第三方支付系统。当前客户端选择的小程序，这些都可以先选择使用微信方所提供已有功能。

当公司有包含微信公众号、小程序、APP、官网等多客户渠道时，会需要统一认证平台，确保客户信息的唯一性、避免客户多方登陆信息不同步等问题；当客户的业务逐步扩展，比如早餐业务从校园市场扩展至社区服务市场等，会需要GIS、地址库等基础单元存储客户的地址信息；当做节假日季节性营销时，也会需要Msg统一短信服务调度功能，给客户发送营销短信。

GIS、Pay、Auth、Msg这些系统，根据当前的使用场景，可以先由相关业务系统自主研发，后期都应抽象出基础支撑单元，供多系统调用服务。

第三，底层数据：

这点和基础支撑单元类似，当公司只有一套业务、一套核心系统时，像客户主数据、地址数据、订单数据等基础数据，可以由业务系统自己存储。但随着业务发展，逐步扩张有多套支撑系统时，通用的数据信息，一般都会抽象为底层数据，做统一的存储，一是避免重复造车、二是方便集中调用分析、三是减轻核心业务系统的运行压力。

第四，有关管理后台：

在一开始我们就分析过，为了扩张市场，吸引更多的用户，公司可能会有一些打折、满减等线上营销需求，针对一次营销活动的创建、运营、复盘，需要整套的营销中心系统来支撑；如果市场扩张顺利，用户暴涨的情况下，也相应会引发售后问题的暴涨，那有关工单创建、受理、结同时随着公司一步步发展。

据此，我们可以绘制成一张相对成熟的应用架构图。虽然在短时间，这些产品并不能够全部搭建完成，但是从一开始就考虑到公司可能发展的一个方向，并为此创建一张应用框架图。有利于架构师搭建一个相对健壮的系统框架，避免后期重复改造；二是提早设立规范，为每个独立系统设计一套统一的方案，方便后期集成，同时也让每个独立系统在一开始创建时，就考虑到其他板块可能需要的服务和调用。三是避免重复造车，像用户、权限、角色、登陆、支付、认证、信息推送等，每个系统都可能使用到，做成基础模块共用，可以节省不少时间。

上图中标注有颜色的模块，是公司初期需要建设的部分，其中OA、HR、企业邮箱建议外采，Pay和Msg建议抽象出来，以后供多方调用；当前项目的建设任务，主要集中在客户端、兼职端、商家端、公众号、运营管理平台的搭建。

（3）核心业务流程图

根据系统交互图，我们可以确认不同子系统之间的依赖关系、以此设计上下游接口之间的数据传递方式等问题。在业务调研阶段，我们已经绘制了线下业务流程图，那将这些动作转换到线上系统操作，流程过程如下：

（4）功能蓝图

确认了系统架构、核心业务流后，我们可以在此基础上，拆分出需要建设的功能模块图，也可以叫做系统规划图，它是每个独立系统建设的基础。

（5）功能清单

根据系统蓝图，我们将系统需要建设的功能拆分成不同的模块。下一步需要将这些模块内需要建设的功能清单进一步列出，作为评估开发工时的一个依据。功能清单拆分时颗粒度需要有统一的要求，一般详细到三级功能（增删改查）的维度，一个任务项所需开发时间在1-3个工作日内。

最终呈现如下图的一个清单：

（6）资源预算

有了更细维度的功能拆分，我们就可以据此来评估项目的总体工期。再结合CEO要求的完成时间，可以判断出该项目需要投入几名研发、几名测试、几名产品（通常一个工程的产品研发测试会按照1:3:1或1:4:1来配置）。

通过计算每个项目成员月平均薪资以及投入月份，可确认项目的人力资源预算。再加上软硬件资源预算，差旅预算，培训预算等项目，基本上可以评估出该项目的整体资金预算。

项目发起人、相关公司高层、技术负责人一般都会根据项目的产出，来评估该项目的投资回报率，以此来决定是否要启动该项目。

（5）立项汇报

将项目的背景、范围、方案、功能架构、技术架构、目标、里程碑、任务清单、成本效益、风险举措以汇报的形式产出文件。邀请发起人和相关人，挑选一个风和日丽的一天进行立项汇报。评审通过后，就可以进入正式的研发阶段。

小结

一个好的产品，一定是团队协助的产物。所以我一直乐于和研发、测试、业务同事进行充分的交流，只有参与到项目中的每一个人都有相同的目标和认识，大家才可能朝着一个方向使劲。另外，让团队相关同事都参与了解到项目的背景目标，也可以充分调动大家的积极性和责任感。这一定是项目成功的必备条件。

回到方案设计这个阶段，产品经理一定要动员研发经理一起参与其中。这有利于研发经理去了解业务现状，设计合理的逻辑架构、开发架构、数据架构。

举几个例子，像下面这些都是研发经理要考虑到问题：

• 系统的目标用户是谁？关键业务流程是什么？
• 高峰期在什么时间，高峰期有多少人在使用，平均有多少人在使用？
• 系统有哪些性能、质量、安全性、扩展性需求？
• 有哪些周边子系统？系统和其他子系统之间有什么交互？上下游接口有哪些，rpc、http还是MQ，同步还是异步？
• 系统有哪些模块，每个模块的数据量有多少？是否需要分库分表？
• 系统有哪些数据同步任务？大数据框架的使用情况如何？

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

题图来自Unsplash，基于CC0协议