在需求分析和定义的过程中，作为产品新人的你也许和我一样陷入了误区之中，恨不得抽自己几个耳光？（参见前作需求分析与定义4大误区）

既然已经对可能的隐患有所了解，那么如何避免重蹈覆辙？

招式1：目标驱动，结构分解

在整体功能模块（亦即范围层、结构层）的设计上，应该以目标为导向进行结构化分解，意思是要问自己：我做这件事情的目的是什么？然后，再根据这个目标倒推应该做哪些工作或任务。特别地，关于结构化思维，推荐阅读前麦肯锡顾问芭芭拉明托的《金字塔原理》。

所谓结构化分解，有3个重要的原则：以终为始、MECE、二八法则。我们在做任何一个新的功能需求之前，都应该问问自己

——它是为达成什么目标而存在？吸引新用户？保留老用户？提高用户活跃？产生营收？

——为了达成这个目标，应该有哪些需求？需求是合适的、完整的吗？

——这些需求中，哪些是具有更高影响力的，虽然只占到20%的比重却决定了80%的结果？

没有目标驱动，则难以保证投入的效率和效果，因为自己都搞不清楚为何而做、将去向何方。

对于单个需求的增加，我们还应该进一步打破砂锅问到底——为什么，为什么，为什么？否则可能会简单地说目标是“满足客户需要“”满足发展需要“。我这里有一个经典的例子（行业不同，道理相通，对策即需求）：

只有这样，才能对症下药、从本质上解决问题。

招式2：轻重缓急，分步实施

发现肯定需要实现的需求有点多？鉴于时间、资源的约束性，一口吃成胖子是不现实的，这时候优先级就该出场了。可以从2个维度评估需求的优先级高低：（1）需求的重要度（或紧急度）；（2）技术实现的复杂度。每个敏捷开发周期/目标版本阶段都应重新评估。

否则，如何排定开发计划？阶段目标什么时候实现？实现到什么程度？开发人员可能就根据自己的理解率性而为。

招式3：流程先行，建立主干

确定了当前阶段的需求优先级，赶紧对高优先级的绘制原型图？别急！！！在界面可视化之前，设计好该需求的业务流程，才能磨刀不误砍柴工。该流程：

——在什么场景下适用？

——从哪里开始？到哪里结束？

——需要什么输入、将产生什么输出？

——通用流程有多少步骤、哪些是用户操作、哪些是系统自动化实现、哪些是核心环节？

在思考的过程中，用Visio把流程图绘制出来，以便修改、完善和讨论。下图是我以前给人培训流程梳理所使用的基本符号，其实用到这些也够了。

通过线框图绘制或UI设计使原型可视化固然重要，但流程可视化必将大有裨益，不管是用于分析合理性、补充完整性。

招式4：细化规则，充实内容

流程的主要操作步骤、流转顺序既然已经梳理出来，各环节的业务规则需要进一步明确。简单一点的例子就是：用户注册，账号输入区要求的是手机号，那么

（1）合法性，必须是手机号，应限制为长整型数字、字符长度必须为11位

（2）唯一性，不允许用户重复注册已经存在的账号

（3）可信性，通过短信动态验证码确认是真实号码、且是用户本人

招式5：考虑例外，封堵漏洞

设计产品、定义需求是产品新人如我应该都容易理想化吧？但是林子大了之啥鸟都有，用户未必会按你设计的理想流程、常规操作使用产品。这时候化身为“挑战者“，对各个环节进行例外分析，用”如果……会……“的讨论识别出可能的异常，并针对异常设计处理策略。

招式6：文不如表，表不如图

终于是时候操起Axure（或其他软件）设计原形了。在想清楚流程和业务规则的基础上，你会发现原型图的绘制思如泉涌、一往无前。至于是低保真、还是高保真，取决于你的时间、精力和水平，取决于你的团队风格。

如果第一步就绘制原型，会有很多的疏漏。

招式7：一人计短，二人计长

一个人思考终归是有很多局限性的。功能流程、业务规则、演示原型皆已具备，就该召开内部评审，和设计人员、开发人员等对需求进行评审，以达成共识；或者找到一两个目标用户，向他们演示原型，观察对方的反应、倾听对方的感受。

说了这么多，其实核心还是想表达这张图：

先思考为什么、怎么办，最后再思考应该做生成么样；而不是一上来就操起Axure绘制原型，没有Why和How的思考基础，快感是一时的，痛苦将随着时间而增加。

而这，还远远未到开始，只不过是热身罢了。阶段开发的过程中，一大麻烦是老板的想法可能飘忽不定~而你知道，开发人员最讨厌的就是：改需求。这是后话了。

以上是我个人的见解，经验有限、纰漏难免，欢迎斧正~

部分图片来源于网络，如有不妥，请与我联系，我会及时删除。

特别鸣谢2位前同事：王佑先生、陈立云先生。

本文由PMCAFF产品经理社区作者  @Archun 原创，未经允许，禁止转载。