编辑导语：产品经理在日常工作中经常会遇到从0到1的项目。面对这样的项目，他们需要产品经理进行全流程的执行和落地，所以团队合作和全流程的把控非常重要。在本文中，笔者分享了关于如何从0-1做好后台业务系统。让我们来看看。
设计一个从0到1的系统，是一个产品经理成长的必经之路。
这几年积累了很多内部业务系统从0到1的经验。本文以抽象总结为主，总结掉进去的坑以及如何解决。
#一.概述
如果企业内部系统需要从0-1设计，一般场景如下：
*创业公司业务不完善或公司有新业务需要支持时；
*原来的商业模式基本是线下人工操作；
*公司原有系统已经无法支撑业务发展，迭代成本已经比较高；
我们要解决的问题一般在于：
做到以上两点，其实和用户端的0-1性质没有区别。但是每个环节还是有一些区别的。接下来，我们将介绍详细情况。
#二。需求研究
现实中一般是领导决定战略层面，做不做，高级产品经理来执行。
一般来说，我们通常要做的是寻找最优路径，也就是制度设计；在找到最优路径之前，有时候我们需要了解实际情况(A在哪里)才能完成，这样产品方案才不是空中楼阁。
无论是起点还是最佳路径，关键点还是要理解业务流程。我们有两种方法：
这两种方法都有各自的困难：
*当系统用户较多时，内部调查容易出现多方意见不一致的情况。这时候就要多方学习意见，总结，多思考，找到正确的路径；
*在进行外部研究时，不是系统本身和竞争产品基准，而是业务模式。我们可以和其他人交流，也可以通过一些软件服务商的开放软件服务，吸收他们设计的精华。
完成上述研究后，制作业务流程图至关重要。如果比较复杂，可以用车道图；如果流程简单，可以直接用ppt。
坑和攀登坑：
1)业务方口径不一致：多听多想多总结，多方说清楚；
2)新系统完全没有想法：拆解其他系统，了解其设计思路，找出优缺点。
3)业务方说法不一致：注意输出的业务流程图，一定要和实际操作人员确认。
如果通常是战略项目，一般可以先和业务领导沟通，再指派其他同事详细沟通。分配者很可能不是实际操作者，而是实际操作者的领导。这时候要注意和实际操作者沟通确认(细节决定成败)。
#三。方案设计
找到A点，知道B点在哪里之后，接下来就是设计最优路径了。在这个环节中，考验的是产品经理的设计能力，最后的输出是原型和prd的交付和开发。
为了更好地理解我们的想法，我们实际上可以使用以下这些内容：
## 1\.功能架构图
功能图可以帮助你了解系统包含哪些功能模块，以及哪些系统之间可能存在交互。如果是工具型项目，可以用我之前画的发票系统的案例。
如果一个页面功能不多，基本就是很多后台交互，可以用下图的形式表现出来。
这个图和流程图的区别在于省略了很多细节，重点表达了哪些系统之间有交互，便于更清楚的理解哪些系统之间有交互(这里的案例是我之前做项目的时候画的，系统名称和交互描述都是手工编码的。)
坑和攀登坑：
功能架构图应该是一个完整的思路，然后用颜色区分这次要做和不要做的内容，方便以后迭代。
## 2\.流程图
常见的流程图是车道图。但是有时候，泳道图的感觉比较重的时候，也可以用时序图来表达。在这里，我在网上随便找了一个时序图，有兴趣的同事可以自行查看。
坑和攀登坑：
*如果和外部系统交互，外部系统已经有现成的接口，具体是哪一个可以在流程图中说明。
接口，否则很可能会用错接口，或者与最初设想有所偏差。* 流程图要足够细！异常情况要考虑清楚，否则就会在异常里了。
## 3\. 功能点列表
如果系统细节太多，一定要有功能点列表，此处不止方便下游同事理解，也方便自己查看设计疏漏。
系统模块功能功能点功能点说明优先级
## 4\. 原型
原型要把重点内容进行标注，交互要画出来，不要都是静态页面。
坑与爬坑：
有时候后台的开发人员不太会写太复杂的页面交互，大多是用现成的控件。所以非必要的复杂交互可以删除。
## 5\. prd
有些观点认为在原型上的标注能够代替prd,但我认为还是值得花时间去认真写；此处将帮助自己再次检验在有限的时间里自己的方案还有没有疏漏，而且是交付下游的重要凭证。
以上都是工具和表现形式，而通过以上工具和表现形式，最重要的是传达出自己的设计思想和全部的设计细节。
在从0-1的设计中，由于细节太多很可能会有一些细节遗漏，所以我自己做了一份产品走查表，用于审阅自己的设计有没有缺失，此处大家也可以自己做一份属于自己的走查表。
# 四、项目落地
从0-1的系统设计，找到了最优路径只是万里长征的第一步，接下来的落地过程才是一脑门官司。前面的设计做的越完善，在落地过程中就会越少问题。
此环节如果想要更顺利，我的经验是需要和开发负责人配合紧密，更大的去促使开发负责人的发挥能动性。而为了我们的设想能更好的落地，产品经理最好不要当甩手掌柜，越深的参与越能让系统的实现和自己的设想偏差越小。
相信大家在这个环节都被遇到过很多坑，不一一言表，此处说几个重要的地方怎么避免：
1）开发评估时间过长
在方案设计环节一定要完成好功能点的拆解，这样在这个环节会更快的完成功能的省略。
2）在开发过程中加人
此项是项目管理中应该避免的，但是有些时候为了赶工期确实会存在这样的情况。这个时候产品经理最好主动给新进入人员讲解背景和需求，不然此处会是一个出现问题的点。
3）开发过程中发现产品细节疏漏：挺起胸膛，这是产品争取但是不能完全避免的，所以发现记得加，在修改的地方标注上改动和日期。如果影响了工期，记得要评估好为什么会影响，看是不是确定一定要影响。
4）验收环节发现系统实现与设计偏差过大：这个环节再发现就搞不赢了，一定要在前期开发设计的时候参与开发方案的评审，以及在测试初期看一下开发实现，避免出现这个情况。
# 五、结语
业务系统的设计最重要的是符合并引导公司内部运营需要，能节省业务操作，并且能支持业务扩展；所以系统设计更多的需要我们理解商业模式和业务模式，依靠我们的逻辑思维能力，找到属于我们的最优路径。
本文由 @举个栗子 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
