编辑导语：民生微实事，是各个小范围内的居民为改善身边环境而提出一些建设方案，由社区来评估出资落地方案。本文作者结合《决胜B端》这本书，谈谈如何进行民生微实事的方案设计，希望对你有帮助。

一、总体介绍

在阅读决胜B端这本书的时候，正巧有民生微实事的需求（这是一个坎坷的需求），就结合书内的内容，开始了民生微实事前期的产品方案设计。本文既是对民微方案设计的思路总结，也是对决胜B端此书的阅读观后感。（本文解析内容的版本为旧版，非后续与客户再次沟通所更新版本）

简单介绍下民生微实事，我的理解是各个小范围内的居民为改善身边环境而提出一些建设方案，由社区来评估出资落地方案。（http://www.szshequ.org/home/wssjj_mswssjj.html）

民生微实事的产品整体方案设计遵循自顶向下拆解的思路而设计。先确定整体方案，再进行自下而上的细节方案设计。

• 核心业务流程：产品最核心的业务、主干脉络
• 产品定位：产品针对谁提供什么支持
• 应用架构：所有系统的整体结构和布局
• 业务架构：系统包含的业务场景、功能规划
• 字段整理：梳理业务实体，各个实体的字段
• 页面梳理：系统功能的各个页面结构目录梳理

二、核心业务流程

首先先确定产品的核心业务流程，要思考业务的各个参与方、涉及的系统（如果业务流程已经存在系统）、业务，可用泳道图描述核心业务流程。

根据多次与客户的需求沟通，可以总结出民生微实事的主要使用对象为社区群众、社区党务工作者。且当前客户较为重视的业务为提出诉求、投票、项目流程，因此考虑将原有民生微实事的街道推荐、街道审批流程简化省略。

业务上主要为社区群众向社区提起诉求，社区对群众的诉求做响应，响应的方式有三种：①办结回复；②转给微心愿小程序；③转成项目。根据这三个响应方式做补充，可绘制出基本的核心业务流程图。

三、产品定位

产品定位实际上可以用一句话概述，「谁」使用「什么」做「什么」？

在上一步我们已经确定了民生微实事的核心业务流程，现在我们继续进一步的定位。

首先考虑下业务的起点：社区群众，社区群众要提出诉求、投票、查看项目、评价项目，比较杂又不够系统化，考虑到便捷性，客户也想把民生微实事品牌化，故没有在原来的H5页面加应用，而是在微信小程序实现。

其次，考虑到党务工作者需要对诉求做大部分的管理工作如：打标签、诉求回复、投票管理、项目管理、公告管理，可以在PC端增设管理后台，由于管理操作过多，故不增加移动端操作。经过梳理，可以总结出，民生微实事产品包含两个小系统：微信小程序、管理后台。如下：

• 民生微实事（微信小程序）：为社区群众提供诉求入口，社区群众可在小程序内参与社区项目投票、查看项目、评价项目等关注社区项目功能。
• 管理后台民生微实事部分（PC端）：主要为社区、街道提供诉求管理、事项管理、投票管理、项目管理及业务辅助功能。

四、应用架构

应用架构也可以理解为整个产品的架构，整个产品由什么系统组成，需要与什么系统对接，会使用到什么基础能力，如何与现有的系统做融合。 毕竟很多时候一套系统的一些基础能力是现有的系统或者产品，可以直接复用，无需重新建设。

从上一步我们知道，民生微实事分了两个系统，一个是微信小程序，一个是管理后台。

在小程序这一端，目前只有民生微实事小程序。

而在管理后台部分，按照客户的设想，管理后台包含了民生微实事管理功能、战疫先锋管理功能、微心愿管理功能。

在第一步确认核心流程部分，我们也知道了，有部分诉求因为不符合民生微实事的建设要求，会转派到微心愿去处理。所以需要与微心愿进行任务数据对接

在用户数据这一部分，一般来说是产品自己建设，但是现有背景是，客户这边在2020年初已经建设了战疫先锋，并且积累了一定的用户数量，这些用户与民生微实事部分目标用户重叠（社区党务工作者），所以用户数据可以与战役先锋对接，也便于用户使用，不用重复注册，减少重复性的工作。

五、业务架构

业务架构也可以理解为功能模块，前面三步我们已经确定了民微的骨架，接下来我们要根据实际场景和客户需求来规划业务功能。简单来说，就是思考用户现有的问题要用什么功能来解决。当我们把所有功能罗列出来后，不可能一次性完成所有功能，所以在规划业务架构时，可根据业务优先级规划好版本，一般优先实现好基础功能确保基础流程闭环，再逐步实现亮点功能。

民生微实事是一个微信小程序的C端应用，群众可在上面完成诉求提出、项目投票、项目进度跟进查看等操作，也需要完成自我管理，而民生微实事又是从社区出发。因此主要包括首页、社区主页、个人中心三大部分。

民生微实事管理后台主要给社区党务工作者使用的管理平台，社区党务工作者需要对群众提出的诉求做处理，并针对一些诉求生成方案，当投票确定方案后，还需要简便记录项目信息，且需提醒党务工作者及时处理对应事项。所以主要包括诉求管理、方案管理、投票管理、项目管理及消息中心四大部分。

六、字段梳理

前面已经确定了整体方案设计，接下来开始细节方案设计。整体方案是一开始我们不知道要什么，所以需要自上而下设计，从抽象到具体。进行细节方案设计时，我们已经有整体方案来指导着设计，我们是知道想要什么，所以需要由下往上设计，确认了底层每个细节，往上搭建的时候才不会出错。

字段整理在书里叫做业务数据建模，翻译成大白话就是业务功能里有啥实体，实体与实体间的关系，梳理各个业务实体的字段。（可百度【E-R图】）这一步很基础也很重要，如果你对现实世界的业务实体理解错误，会导致后续一系列设计都是错的。我常用的梳理步骤如下：

• 确定产品内所有的业务实体
• 确定业务实体间的关系，一般有一对一、一对多、多对多
• 确定实体的属性，此处只考虑业务所需字段，其余技术所需字段由开发侧思考。

七、页面梳理

业务数据建模结束后，就可以结合根据流程来梳理页面流转图，我认为页面流转图也是对业务架构的细化，相当于你对功能的细化拆分结合。这一步也没什么好说的，是一个基础产品规划能力。至此，就做好了画原型前的准备。

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

题图来自Unsplash，基于CC0协议