确定

确定需求往往是承接需求调研而来，目的是搞清楚产品部门究竟要处理的是什么问题，有时候业务部门会要求你能为他们做到些什么，但这种要求往往过于含糊，你还需求再和他们多了解一些信息，才有可能真正了解他们希望得到是什么，避免发生买个MBP回来只为装了winxp玩扫雷这样的杯具……

在确定环节中，这只完成了一半的任务；接下来我们需求知道对应这个需求，会有哪些角色来使用，我们需求能够对这些角色涉及到的不同需求做出细分。这也是需求和业务/需求部门沟通好的。

分解：

分解的意义在于把大问题化解为小问题，变成一个个可控的模块，留意这里是说的可控是指你可以通过一定的约束条件和已知存在的变量来实现对问题的描述。经常看到的所谓需求拆解只不过是把业务部门的需求换个描述方式，这种糊弄人的做法要不得，山寨，害人害己。

大问题变成了小问题，我们就可以来讨论如何去实现了。

至于该如何把大的需求拆解，这里提供两种思路：

1. 流程驱动：依据业务流程和业务需求建立对应的uml，或者也可以对应每个角色建立起一个虚拟人物，把整个业务流程完整走一遍，这样可以模仿出实际操作中会出现哪些具体问题，在完成最终的业务目标前，可能会出现的阶段性目标有哪些，同时又会有什么样零星的小需求出现。很多这些过程中的需求是业务部门不会提及的，你有责任通知他们这些情况。
2. 公式驱动：以使用类产品举例，如果一个公司可以同时向用户提供两种服务A和B，二者的利润不同，同时又会遭到市场季节性需求变化和产能供应量的限制出现数量上的波动；如今要求我们能够找到合适的资源分配方式，来让公司获得最大的盈利。这其实就是一个依据制约条件来找到A和B两种服务对应各自需求有什么变量的问题。不妨列出一个公式，看看究竟各个制约条件之间是如何影响的，从而找到合适的处理办法。

要记得，在需求被拆解后的每一个问题有些是对应固定的角色的，而一些则是可认为是无所谓角色区分的特性问题，还有一些问题的处理结果会影响他角色。务须能分清楚来对待。

分解阶段另一件重要的事情就是完成流程图的设计，对应产品人员要做的是业务流程图，如果有核心开发人员也参与了前期的需求讨论分析，可以建议他们同步展开架构流程的思考。

在绘制流程图的时候需求尽可能标明其中的里程碑功用，大约需求哪些功用支撑、需求设计多少个页面或频道、组件，对应的管理后台需求有哪些对应的调用。这时候也需求一并带着整理。我的实践经验是，可以先做完流程图，然后把后面的这些问题带进去思考，一方面寻觅答案，一方面也可以完善你的流程图。

如果能够一路坚持走下来，基本上可以做到很完整地了解本人要处理些什么问题了。这时候你面对的就不再是一个总的需求，而是一个个细节的问题。接下来要做的就是对各个问题进行评估，

评估；

如果我们把分解理解为找问题，那么评估就是为处理问题做预备。

鉴于我们在分解问题的时候，其实曾经涉及了一部分评估的任务，这里不妨更深一层。例如，你打算使用多少个页面、会有多少个功用点出现。这些经过分析提炼后的内容可以用PRD或者低保真原型的方式展现给相关的开发人员和业务部门。

不过评估最重要的任务并不是要穷列出来究竟需求做哪些任务，而是需求对这些即将展开的任务做出排序，同时你可能必须舍弃一些本来精心构思的内容。

对任务的排序是产品本人无法完成的，需求尽可能和开发部门配合。开发人员对于业务需求有着本人的一套理解，同时由于涉及到很多实现细节的问题，也需求在达到共识的基础上才能继续推动。

因此，在真正展开具体的产品设计任务之前，需求能和开发人员进行沟通，尽可能做到以下几点：我们需求多少个功用点来支撑这个产品或满足需求；这些功用点都是可以在规定项目时间内开发完成的吗；开发人员对于本人要做的事情有足够的判断，知道哪些应该先做，哪些要后置；对于暂时无法实现的功用，是退回给需求方，还是产品重新构思或者延至2.0版本完成，需求说明清楚。

对于没有技术背景的产品，这时候很容易堕入被动，你可能会被技术提出的各种“不好实现”搅得心慌意乱。为了避免这种情况，你最好能找到一个能和你顺畅沟通的技术经理，很多问题其实并不需求你亲身上阵的。

决策：

在经过了前面几轮重重的折磨，才是产品人员真正发挥创意的时候，你将左右会有怎样的表现，你拥有整个产品开发的决策权。别人可以提意见，但是最终你才是那个决定事情该怎样做的人。

制定项目计划，针对每个细分功用拿出具体的实现策略，给出产出物的交付时间，绘制原型图和PRD文档。从产品全体框架到页面规划、频道功用再到按钮的位置，弹出层的设计。设计的创意才在这里真正迸发，你所有知道的界面设计、导航架构、交互方式的知识和才能都会在这里得到淋漓尽致的体现。

暂且撇下你的设计创意不表，如何把评估阶段的成果使用好是我们能否能顺利进入决策阶段的关键。总会有一些功用被砍掉，也有一些新功用提出来，本来想好的某些流程也可能要重新调整。在决策阶段，你需求有做减法的魄力和决心，抛弃一些东西，适当做一些让步，但是要能保证产品的核心功用不被阉割。对于核心功用，任何为了减轻任务量或者无法实现而要求绕道而行的借口都是可耻的；如果你有有充分的理由置信产品的核心功用，那就一定要坚持到底。

写在最后的话：

至此，我们通过确定、分解、评估和决策把需求分析阶段要做的事情做了一个梳理，也为后面的设计和开发开了一个好头。当然你仍然会面临业务部门的需求变更，设计或者开发人员在某个功用或表现方式上跟你死磕的局面，这时候你仍然可以使用这四个步骤来处理具体的问题，但是在实现上需求做一些变通，项目一旦进入到开发编码阶段，时间会非常紧凑，你能做的就是依据新提出来的想法迅速协调好利益相关部门，在开会之前你就能要预备好几套方案，否则会议就会变成一种折磨：低效，浪费时间，不处理问题。