有人说过：分析与综合是综合是思维方向相反的过程。一般是先分析后综合，没有分析就没不能有综合；没有综合的分析也只是片面的分析。

作为一个产品经理，如果你曾经遇到过产品设计考虑不全，被业务、被开发挑战，而不断修改原型；如果你曾被领导询问产品价值而哑口无言；如果你曾遇到过拿到新业务而无从下手，不放花几分钟时间，看看这篇文章，也许会给你一丢丢的帮助。

一、为什么做需求采集、分析

作为一名纯正或者不纯正的”产品狗”，需求分析和产品设计都是我们日常工作中最重要的事情。整个流程我们也都熟记于心：需求采集、需求分析、产品设计……（后续开发流程我们暂不考虑）。反思一下：我们做需求采集、分析的目的是什么？是画出来产品的低保证？是给领导讲清楚我们产品设计的思路？是给开发讲清楚他们要实现的功能？好像都是，有好像都不全？为什么？

遇到问题先搞清楚为什么。搞清楚为什么（5W2H也好，3W2H也罢，最重要的就是Why），也就是搞清楚做事情的目的以后，我们才能提供有效的方式方法来应对。现在尝试来回答一下：我们做需求收集、分析的目的是为了进行架构设计，从而达成需求进，架构出的目标。

二、架构设计六步走

需求采集、分析的目的是进行架构设计。结合我们产品设计的步骤，尝试着来整理一下达成“需求进，架构出”目标的步骤。

步骤一：需求采集

产品设计第一步一定是做需求采集，没有需求（此需求为业务需求，被需要的意思）的产品设计等于浪费。但是我们要知道需求往往不是单一的，而是一个集合，需求采集就是要把需求都收集到。请别说收集有效需求或者高价值需求，还没有到那一步呢。

步骤二：需求分类

需求采集过来以后，往往是不能拿来直接用的。就像我们常说的：要挖掘用户的真实需求一样。即使我们挖掘到的是真实的需求，我们也不能拿来直接用，而是需要对其进行分类，维度基于不用的场景而有所不同，但是可以尝试以：业务、用户、开发的方式进行分类。

步骤三：寻找约束

需求收集过程中可以谈天说地，不必限制。但是在我们拿到需求以后，可不能让需求的马在草原上狂奔，我们需要给马套上缰绳，质量和约束就是最好的缰绳，比如技术限制、比如成本限制等等，从而完成“信马由缰”的转变。

步骤四：需求定级

需求收集过来了，分级做好了，约束也有了，最终是要进行需求到产品的转化，这个时候就到了我们所谓的“先做有价值的、优先级高的需求”这一步了。毕竟我们都知道，不是所有的需求都要满足，不是所有的功能都要实现，他们是有优先级的：需求很多，先做后做要考虑，定级从核心、必做、高风险、独特出发。

步骤五：寻找关联

需求和约束、需求和需求，约束和约束都不是独立存在的，他们都是有关联性的，我们在做产品设计的过程中，往往会遇到做了需求A，影响了需求B，做了需求B，影响了需求C，就是因为没有考虑到其中的关联造成的。在做产品设计的过程中，我们需要找到他们的关联性，从而进行全局考虑，避免互相影响。

步骤六：检查

以上步骤都做完了，很好，我们已经可以进行产品架构设计、产品设计了，设计完成以后，千万不能忘记检查，如果我们自己不检查，业务会帮我们检查、领导会帮我们检查、开发会帮我们检查…..质疑驱动架构进步不是空话，检查检查再检查，我们共勉。

从小处着手，了解全貌是分析，基于分析进行架构是综合，毕竟任何作为复合整体的复杂事物都有架构，产品设计更甚。拿到需求的第一时间我们不是要做出来，而是要考虑为什么要做？以及知道我们最终产出的结果是什么？这比按时画完原型移交开发更有价值。

需求进、架构出，各位产品大大共勉！

本文由 @ 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务