该帖子同步发自：(悠闲的博客  访问该博客)

　　刚开始做产品的时候，总是拿到需求就开始着手画原型，遇到卡壳的地方就去参考竞品，看看别人是怎么做的，接着再继续画原型……，几个产品做下来，对于产品的了解仍然是微乎其微，对于如何做产品仍然是一知半解。后来通过阅读一些书籍以及产品设计的一些文章，不断总结了一些经验，不敢说现在做的就有多好，因为即使是现在每次做新的项目时也总会发现一些比较好的优化需求表达的方式。简单分享下自己的心得和经验，大家一起学习。

　　很多刚接触产品的同学都觉得会画图，会做原型，就是会做产品了。其实，这只是做产品的第一阶段。要想把产品做好，对业务需求的理解和表达是非常重要的(去抄抄竞品，东拼西凑做出的东西是不可能成功的)。那么，如何把握好产品的需求呢?

　　一.深入挖掘客户需求

　　首先向客户了解清楚产品的目标人群、使用场景、核心业务以及想要达到的目标，总之要详细了解清楚产品所涉及的业务，而只有深入了解了业务本身，才有助于发现使用场景，并为之提供解决方案，让用户用得爽。

　　尽可能让客户全面细致的描述产品要达到的目的和业务流程。在汽车还没有发明的年代，如果你问用户想要什么，他会回答想要一匹更快的马。永远记住：让客户尽可能全面细致地描述产品的目标以及实际业务流程，而不要让客户提供解决方案。由于客户经验和认知的局限，他所描述的只能是他能想到的符合业务需求但未必是最优的方案。

　　需求不明确的地方及时和客户沟通。一般我们拿到一个项目，从开始了解需求到输出需求文档之间的时间是很短的，遇到需求不合理或者不明确的地方一定要及时和客户沟通。不然，如果按照自己的理解或者YY出来的东西最终很大可能是不符合客户的需求的，最后提交给客户后还需要重新返工，费时费力。

　　二.确定原型架构

　　需求了解清楚了，相信这时候很多童鞋已经摩拳擦掌、跃跃欲试想要开始画原型了。先别急着画原型，过早的进入原型设计阶段只会让自己陷入细节设计的困扰中不能自拔，从而难以把握产品的大框架及方向，那么你前面所做的需求挖掘及分析在原型表现上将大打折扣。

　　原型架构的梳理与确定才是需求分析完成后的重中之重。

　　竞品分析。基本需求了解了，那么去看看同类型的产品，尤其是市场中优秀的产品。了解下别人的产品架构(当然也了解下同类型业务的处理方式，为后面的业务分析以及原型设计做准备)。

　　按业务需求划分功能模块，主要是按照商务整理出的功能需求清单以及和客户的沟通结果来进行模块划分。

　　细分每个大模块下的小功能模块。尽可能细化每个模块下的所有功能，如果可以的话涵盖所有功能。如：社交类应用，细致到对好友动态的点赞功能。这样做的好处是在开始画原型的时候便于检查是否有遗漏缺失的功能。另外，当你在构思原型架构的时候其实也是一个打腹稿的过程，架构图涵盖的越详细越便于后期的工作。

　　三.画业务流程图

　　架构图完成了是否可以开始画原型了呢?先别急。再梳理一遍业务逻辑，并用流程图的方式输出。一来这样可以检查自己之前的想法是否正确，二来在梳理流程图的过程中你有可能发现更优的处理方式。当然最重要的是需求做出来是要给到开发看的，业务流程图可以更好的帮助开发了解整个产品。

　　1.不同业务模块分别画流程图

　　每个产品都不止涉及一个业务流程。如借款的产品涉及的业务就包括：发布借款流程、投资流程、还款流程、提现流程等。当然，多个流程之间可能出现业务交叉的现象，但是尽量分开。这样做的好处是：一个主流程比较清晰，多个流程交叉在一起会降低可读性。如下图所示的流程图把整个产品的业务流程放在一起，就让人不明所以

　　2.文字简要介绍业务

　　在流程图旁边附上文字说明，简要说明业务流程。如借款产品：用户可以以游客模式浏览别人发布的借款，但是如果自己发布借款或投资就必须登录。因为有些规则不适合用流程图来表示，这个时候简单的一句话就可以表达的更清楚。

　　四.做好业务规则说明

　　很多产品中都会有例如积分、会员等级等激励用户活跃性的方式，而对于积分的获取和使用规则、等级的升级规则做好说明，则可以将需求确定清楚并做好限定。另外，有些规则在初期可能没有考虑清楚，有可能是不合理的。及早做好说明并在需求评审时和大家讨论清楚，能尽早发现问题并找到可替代方案。我曾经做过一个项目就是在初期没有将规则说明清楚，导致开发到最后才发现这个问题。

　　这个项目有一个充值优惠功能，当时我提出的方案是：按百分比的方式优惠，如优惠3%，充值100则优惠3元，提现的时候相应的减去优惠的百分比。但是该产品还涉及支付宝支付，如用户支付宝购买了100元的产品，但是又取消了订单，退款是直接退到该产品的账户余额的，这个时候就相当于我充值了100块，账户余额中英按充值优惠比例增加100/0.97=103.0927835052元。好吧，出问题了。因为我们之前定的规则是保留2位小数的。

　　所以，如果所做的产品有一些特殊的业务规则，请一定做清楚说明并和大家讨论是否合理，不然后期出错会造成更大的损失。

　　五.记录变更日志

　　需求做完之后不可能一次都不修改，每次改动后都会有开发问变更了哪些部分，于是我们只能一一回答改了哪些。但是很多时候只是大概回答改了哪个模块，有些小的改动还是被开发给遗漏了。那么每次变动后如何确保将所有的变更都告知开发呢?

　　在原型文件中直接附上变更日志，注明变更模块、变更原因及日期，以确保所有人都可以一眼看明白哪些地方做了变更，方便大家的工作又避免忽略一些变更。如下图所示：

　　以上都是个人的工作总结，还在持续改进中。有不妥之处，还请指正。

　　该文章主要针对外包项目而写。