小伙伴们有没有这样的经历？领导让你负责从0开始做一个业务系统，你木有相关项目经验、也没有竞品可以借鉴，不知道从何下手？抑或是自己写的PRD，在评审阶段总是暴漏出各种问题，这里没考虑清楚，那里也没考虑清楚？项目历经千辛万苦上线了，业务方/需求方各种吐槽，不满足需求？恭喜你，你将在本文找到上述问题的解决之道。本文以一个web新闻站点为例，演示如何打造完美的业务逻辑。本文重在方法论的演示，请勿在意案例细节。
1.分析用户角色：业务系统的用户有几种角色？各自的需求是什么？
角色分析
角色分析比较容易做，但每个角色的需求很难一次梳理到位、没有遗漏。怎么办？
角色需求分析
例如你花了5分钟的时间整理出了上图中的需求点，有很多遗漏的需求点，例如作者提交后的二次编辑、编辑查询站点的PV/UV/阅读量等。山人以为，从0开始做一个业务系统并一次满足所有角色的全部需求是不现实的、不现实的、不经济的。需要进行取舍，建议采用MVP原则，把有限的精力和资源投入到关键功能、关键业务流程上，次要的功能后续逐步迭代实现。
但是，如何避免遗漏关键需求那？以下方法可供借鉴：
- 内部需求收集：向编辑、审核人员、管理层等内部用户收集需求；
- 同类/类似产品分析：虽然可能没有完全一样的业务系统竞品可以借鉴，但单个功能模块还是应该能找到类似的产品的。例如：作者在线写文章模块可以参考下QQ空间的写日志；审核可以参考今日头条的审核，自己提交提交一个文章走一遍审核通过、审核不通过的流程，然后推测出业务流程。
2.解构功能模块：理清每个功能的前置条件、输入、处理、输出、异常。
根据第一步角色需求分析的结果，梳理每个功能的前置条件、输入、输出、异常。以作者提交文章为例：前置条件是登录；输入是已填写标题、正文；处理的动作是点击提交、后台往表中插入数据；输出是文章存储成功并且状态变成待审核；异常包括：网络异常、包含非法字符等。作为老司机，需要提醒下小伙伴们，有时候需要非常大胆地逆向思维才能发现一些关键的异常，比如这里的前置条件登录就存在异常–未登录。未登录时不显示写文章等模块的入口？还是显示入口并引导登录？
3.设计业务流程：先确定主角色和主流程，理清楚其它角色、其它流程与主流程的关系。
基于功能模块解构分析的结果，识别出关键角色、关键业务流程，并投入的较多的精力进行产品设计和review。对这个案例而言，作者提交文章；审核人员的审核；以及编辑发布是最重要的功能和业务流程，需要重点关照。针对这一关键业务流程，可通过绘制流程图的方式理清业务流程及异常处理流程并形成闭环。
关键业务流程：提交–审核–发布
主流程确定了，其它的业务流程一般很容易搞定。有时候在梳理一般业务流程的时候也会发现主流程有遗漏分支流程或者异常状态的情况。
如果关键业务流程涉及多个部门的协同及分工，建议在流程确定后及时与相关部门的干系人（leader、执行岗）沟通确认，避免在开发阶段或者上线后出现相关部门挑战流程、质疑分工的问题。古语说的好——小心使得万年船~~~
作为老司机还有提醒下小伙伴们，涉及业务支撑响应周期的问题，例如本案例中的审核周期，一定一定一定要让业务部门书面确认，然后PM们才能把相关信息在前端页面展示出来。
4.设计系统架构：系统架构要充分考虑功能的相关性及权限管理的便利性。
设计系统架构时需要充分考虑功能的相关性及权限管理的便利性，建议把同一角色需要使用到的功能放到一个一级菜单下，把操作对象相同的功能放在一个页面。比如：用户名、密码都是与用户ID关联的，这两个功能可以放在一个页面。审核和删除的操作对象是文章，有相关性，需要放在同一个一级菜单下。
5.尽早验证并完善：
上述4步完成后，就到了小伙伴们最喜欢也很擅长的环节了–画原型、写PRD。有了第2步的基础，写PRD时基本上就是码字。有了第4步的基础，画原型就是摆控件、调对齐，基本不用动脑了。只强调一点，原型完成后可以小范围与关键执行岗位进行沟通。
这步完成后接下来才是需求评审。相信经过了前面2轮的沟通和确认，需要评审环节一定会很顺利，大家问的问题你都胸有成竹、对答如流。这样完美的需求评审，有利于提升PM在团队中的威信、树立专业的形象、增强PM自信。
上述方法论适用于从0到1的打造业务系统，也适用于分析一个业务系统。
最后，安利一句话，与小伙伴们共勉：你必须非常努力，才能看起来毫不费力。