結合《決勝B端》，談談民微方案設計

編輯導語：民生微實事，是各個小范圍內的居民為改善身邊環境而提出一些建設方案，由社區來評估出資落地方案。本文作者結合《決勝B端》這本書，談談如何進行民生微實事的方案設計，希望對你有幫助。

一、總體介紹

在閱讀決勝B端這本書的時候，正巧有民生微實事的需求（這是一個坎坷的需求），就結合書內的內容，開始了民生微實事前期的產品方案設計。本文既是對民微方案設計的思路總結，也是對決勝B端此書的閱讀觀后感。（本文解析內容的版本為舊版，非后續與客戶再次溝通所更新版本）

簡單介紹下民生微實事，我的理解是各個小范圍內的居民為改善身邊環境而提出一些建設方案，由社區來評估出資落地方案。（http://www.szshequ.org/home/wssjj_mswssjj.html）

民生微實事的產品整體方案設計遵循自頂向下拆解的思路而設計。先確定整體方案，再進行自下而上的細節方案設計。

• 核心業務流程：產品最核心的業務、主干脈絡
• 產品定位：產品針對誰提供什么支持
• 應用架構：所有系統的整體結構和布局
• 業務架構：系統包含的業務場景、功能規劃
• 字段整理：梳理業務實體，各個實體的字段
• 頁面梳理：系統功能的各個頁面結構目錄梳理

二、核心業務流程

首先先確定產品的核心業務流程，要思考業務的各個參與方、涉及的系統（如果業務流程已經存在系統）、業務，可用泳道圖描述核心業務流程。

根據多次與客戶的需求溝通，可以總結出民生微實事的主要使用對象為社區群眾、社區黨務工作者。且當前客戶較為重視的業務為提出訴求、投票、項目流程，因此考慮將原有民生微實事的街道推薦、街道審批流程簡化省略。

業務上主要為社區群眾向社區提起訴求，社區對群眾的訴求做響應，響應的方式有三種：①辦結回復；②轉給微心愿小程序；③轉成項目。根據這三個響應方式做補充，可繪制出基本的核心業務流程圖。

三、產品定位

產品定位實際上可以用一句話概述，「誰」使用「什么」做「什么」？

在上一步我們已經確定了民生微實事的核心業務流程，現在我們繼續進一步的定位。

首先考慮下業務的起點：社區群眾，社區群眾要提出訴求、投票、查看項目、評價項目，比較雜又不夠系統化，考慮到便捷性，客戶也想把民生微實事品牌化，故沒有在原來的H5頁面加應用，而是在微信小程序實現。

其次，考慮到黨務工作者需要對訴求做大部分的管理工作如：打標簽、訴求回復、投票管理、項目管理、公告管理，可以在PC端增設管理后臺，由于管理操作過多，故不增加移動端操作。經過梳理，可以總結出，民生微實事產品包含兩個小系統：微信小程序、管理后臺。如下：

• 民生微實事（微信小程序）：為社區群眾提供訴求入口，社區群眾可在小程序內參與社區項目投票、查看項目、評價項目等關注社區項目功能。
• 管理后臺民生微實事部分（PC端）：主要為社區、街道提供訴求管理、事項管理、投票管理、項目管理及業務輔助功能。

四、應用架構

應用架構也可以理解為整個產品的架構，整個產品由什么系統組成，需要與什么系統對接，會使用到什么基礎能力，如何與現有的系統做融合。 畢竟很多時候一套系統的一些基礎能力是現有的系統或者產品，可以直接復用，無需重新建設。

從上一步我們知道，民生微實事分了兩個系統，一個是微信小程序，一個是管理后臺。

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

而在管理后臺部分，按照客戶的設想，管理后臺包含了民生微實事管理功能、戰疫先鋒管理功能、微心愿管理功能。

在第一步確認核心流程部分，我們也知道了，有部分訴求因為不符合民生微實事的建設要求，會轉派到微心愿去處理。所以需要與微心愿進行任務數據對接

在用戶數據這一部分，一般來說是產品自己建設，但是現有背景是，客戶這邊在2020年初已經建設了戰疫先鋒，并且積累了一定的用戶數量，這些用戶與民生微實事部分目標用戶重疊（社區黨務工作者），所以用戶數據可以與戰役先鋒對接，也便于用戶使用，不用重復注冊，減少重復性的工作。

五、業務架構

業務架構也可以理解為功能模塊，前面三步我們已經確定了民微的骨架，接下來我們要根據實際場景和客戶需求來規劃業務功能。簡單來說，就是思考用戶現有的問題要用什么功能來解決。當我們把所有功能羅列出來后，不可能一次性完成所有功能，所以在規劃業務架構時，可根據業務優先級規劃好版本，一般優先實現好基礎功能確保基礎流程閉環，再逐步實現亮點功能。

民生微實事是一個微信小程序的C端應用，群眾可在上面完成訴求提出、項目投票、項目進度跟進查看等操作，也需要完成自我管理，而民生微實事又是從社區出發。因此主要包括首頁、社區主頁、個人中心三大部分。

民生微實事管理后臺主要給社區黨務工作者使用的管理平臺，社區黨務工作者需要對群眾提出的訴求做處理，并針對一些訴求生成方案，當投票確定方案后，還需要簡便記錄項目信息，且需提醒黨務工作者及時處理對應事項。所以主要包括訴求管理、方案管理、投票管理、項目管理及消息中心四大部分。

六、字段梳理

前面已經確定了整體方案設計，接下來開始細節方案設計。整體方案是一開始我們不知道要什么，所以需要自上而下設計，從抽象到具體。進行細節方案設計時，我們已經有整體方案來指導著設計，我們是知道想要什么，所以需要由下往上設計，確認了底層每個細節，往上搭建的時候才不會出錯。

字段整理在書里叫做業務數據建模，翻譯成大白話就是業務功能里有啥實體，實體與實體間的關系，梳理各個業務實體的字段。（可百度【E-R圖】）這一步很基礎也很重要，如果你對現實世界的業務實體理解錯誤，會導致后續一系列設計都是錯的。我常用的梳理步驟如下：

• 確定產品內所有的業務實體
• 確定業務實體間的關系，一般有一對一、一對多、多對多
• 確定實體的屬性，此處只考慮業務所需字段，其余技術所需字段由開發側思考。

七、頁面梳理

業務數據建模結束后，就可以結合根據流程來梳理頁面流轉圖，我認為頁面流轉圖也是對業務架構的細化，相當于你對功能的細化拆分結合。這一步也沒什么好說的，是一個基礎產品規劃能力。至此，就做好了畫原型前的準備。

本文由 @科科 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議