在我面试几百个产品经理的经历中，我发现很多产品新人都在学习一些质量不高的教程。这些教程通常用前大半截的篇幅来介绍一些形而上的理论，真的到了实操阶段却草草收尾，只教你一些表面的东西，例如流程图长什么样、动态面板怎么画，很少去讨论在真正的工作中，一个PRD到底是怎样诞生的。所以我想做一些教程给你们看，让你们能够真正掌握实操的过程。
但在我整理过去作品的这段时间里，我发现很少作品可以写成图文教程，因为我采用的都是面向对象的设计方法，每个模块都是静态的，模块之间是互相成就的，不存在一个“线性的流程”。用几小时视频加上我的嘴炮旁白是可以做到的，但是用图文的形式就很难表达清楚。
每当这种时候我都很希望能掌握电影《降临》中外星人传授给地球人的表意文字。一个水墨状的圆弧上，每一个突触都代表一个事物，突触之间的位置关系代表了它们在这个故事里的角色。这个故事没有开头和结尾，你可以用一万个声音去叙述这个故事，而故事本身却并不复杂，因为时间的一维方向性在这里被打破，只有角色，和角色之间的所有的关系。
不过这个系统是个例外，它是我上家公司政务SAAS系统中的一个小功能，叫做简易表单系统。顾名思义，它比较简易，因此它有机会写成图文教程。
写这篇教程之前，我花了半天的时间来整理它的提纲，然后花了一天半的时间从以前的文档里慢慢找到配图并PS。从提纲来看，虽然没有介绍到全部的思路，但是我在叙事结构上做了一些取舍，让你可以更轻松地跟着我的思路走下去，所以现在我们进入正题。
注：本文在第3章之前都是抽象逻辑探索，你可能会觉得枯燥而跳过。但是当你看完后面的原型章节之后，你会发现，你还是得返回来重看一遍。
立项和整理需求
我不会人五人六地告诉你我是怎么调研市场和研究竞品的，因为这个项目不存在。在实际的互联网公司工作中，很多痛点是痛到不行的，但是很多时候大家对痛苦的忍受程度、愚钝程度也是超过你想象的，越大型、人均头发数量越少的公司越是这样。
这种时候，产品经理也很容易因为压力而随波逐流，但你的使命就是去做指路人。只要把你的方案表述出来，告诉别人怎么你是怎么解决老板和大家的痛苦的，你就可以立项。调研报告和各种炫彩的ppt不是必须的，它们通常是因为你的策划案不够漂亮，或者大家还不够相信你。没有什么ppt能比一个漂亮的落地计划直接甩在大家脸上更有说服力。
上图是某个银行给我们的Excel表，他们想把这套表格搬到线上来。图里只是其中一个合作银行的一部分的表格。而且，我们当时在做的也不光是银行的线上表单，刚好还有某个地区政府的科创局也需要上线一个系统，让企业用在线表单填写信息上传上去。
当你看到这样的可怕的表格，不是上图这一份，而是十几份，你会怎样做？
“让我们直接一页一页画成原型，然后交给程序员一个字段一个字段开发吧！”——在我看到我的产品经理莫名其妙地加班、程序员也在莫名其妙地加班之前，他们就是这样做的。我现在截图给你看，你会觉得这样很愚蠢，然而当你身临其境的时候，每天被老板分配的任务压到喘不过气的时候，你真的会很容易失去跳出来说皇帝没穿衣服的勇气。
显然你要去制作一个通用的表单系统，这个表单系统能照顾到这些不同的数据填写需求，让程序员开发出来，然后撒手不管，丢给客户或者运营去配置具体的数据。
很多产品经理不知道去分辨老板哪些指令是专业的，哪些是业余的，自己甘心做一个“需求翻译器”，还纳闷为什么自己的需求不被人好好执行。其实你的方案能让大家少加班，还能让大家出品更好，你的威信就在不断建立，大家就会把你当做指挥官。
当遇到客户或者老板丢给你十几张Excel表的时候，你首先要看这些表格是不是规范的。如果是一张大宽表，所有的数据都被整理得井井有条的，那就不需要去梳理它，可以直接走下一步。但是如果你遇到的是我这样的，不同的几个机构给的不同的表格，而你想把它们都做成一个表单系统，那你就需要先去好好梳理这些数据了。
梳理数据时不要挑软柿子，而是要去挑那些最硬的柿子。比如有些表格要求用户上传各种附件，有些表格的行数是不确定的，有些表格的层级数量特别多……你并不是要把所有客户给的数据项全部整理到xMind，而是把这些难点在梳理的过程中理顺。一旦把这些都理顺了，就不需要再继续梳理下去了。
我在第二步（右图）尝试着把梳理出来的数据转化成业务模型，新手不要这样做。因为画这种模型的基础，是你已经可以很娴熟地撰写业务逻辑文档，从而能够直接凭空想象这些文档，在大脑里直接把它图形化。这种能力对我来说，是在我写过至少80万字的文档之后才产生的。
撰写后端逻辑文档
大部分产品经理不会撰写后端逻辑文档，而在传统的游戏界，这个技能是普遍存在的。这跟互联网行业资金太多，产品经理门槛太低有直接关系，会用墨刀就能做PM，这是多少培训班的谎言。我这么说有的人可能不服，“我明明也写了很多文字类的文档啊”。但是大多数这些文字类的文档，都是对原型的补充说明，是前端层面的，而不是接口层面的，更不是后端层面的。
抽象后端逻辑是我快速落地一个项目的法宝。考虑周全的后端逻辑直接带来后端大佬的好心情，后端大佬的好心情直接带来好的接口，好的接口直接带来前端大佬的好心情，前端大佬的好心情直接带来好的用户体验。
跟后端程序员开会的时候，我大部分时间只跟他们讲后端逻辑文档，至于原型长什么样子，其实除了接口方面，后端程序员根本不关心。如果你不能把后端逻辑说清楚，而是一味地说“这个按钮点了之后就去到哪一页”，证明你还是在用外行人的眼光来分解一个产品的构成。
在你不熟悉后端逻辑文档的情况下，你可以把本章内容放在原型画完的下一步来做。当你娴熟掌握之后，你会发现，先写逻辑文档可以省下你很多由于业务逻辑不清晰而画出错误原型的时间，对于后台产品来说尤其如此。
不管一个线上表单玩出什么花样，最终的颗粒都是不同类型的字段，我把它们称作“简单字段”。简单字段没什么好探索的，无非是文字、图片、附件、选择题、联动选项等等一些不同类型的字段。这里的关键点是下图所示的“复合型字段”。
为什么要设计这些复合型字段？
因为在前面梳理这些Excel表的时候你会发现，很多字段之间是有内在关联的，而我们设计一个后台系统不管它再复杂，最终也是为了让用户填表的时候心情更爽。
联合字段的目标：在用户端把几个字段连在一起，消掉它们之间的间距，让用户知道这几个字段是一起的；主从字段的目标：几个字段也是一起的，但是它们之间有从属关系。这个时候哪个字段在最上面，就代表它是老大。例如，主字段是“总营收”，而两个从属的字段是“其中高新科技收入”和“其中医药产品收入”；多条组的目标：我们不知道用户要填多少项数据，只能粗略地设定一个上限，让用户自由添加条目。例如我们要求用户填写他公司的股东信息，我们只知道用户每个股东的信息都要填写姓名、职位和占股比例，但是具体用户要填多少条，是用户自己点“添加”按钮的次数来决定的；二维表的目标：有些数据是由横纵交错的行和列组成的，例如财务报表，纵向是具体的财务报表数据，横向是时间轴。这种表格显然不管是在网页端还是手机端，都应该跳转到一个单独的页面来填写。
所以这个时候就可以写字段部分的后端逻辑文档了。不管这些字段在手机里的交互能玩出什么花样来，我们现在这一步只需要
本文编辑：佚名
转载请注明出地址 http://www.guwmh.com/szyy/21702.html
