确定

确定需求往往是承接需求调研而来，目的是搞清楚产品部门究竟要解决的是什么问题，有时候业务部门会要求你能为他们做到些什么，但这种要求往往过于含糊，你还需要再和他们多了解一些信息，才有可能真正了解他们希望得到是什么，避免发生买个MBP回来只为装了winxp玩扫雷这样的杯具……
在确定环节中，这只完成了一半的工作；接下来我们需要知道对应这个需求，会有哪些角色来使用，我们需要能够对这些角色涉及到的不同需求做出细分。这也是需要和业务/需求部门沟通好的。
分解：
分解的意义在于把大问题化解为小问题，变成一个个可控的模块，注意这里是说的可控是指你可以通过一定的约束条件和已知存在的变量来实现对问题的描述。经常看到的所谓需求拆解只不过是把业务部门的需求换个描述方式，这种糊弄人的做法要不得，山寨，害人害己。
大问题变成了小问题，我们就可以来讨论如何去实现了。
至于该如何把大的需求拆解，这里提供两种思路：
流程驱动：根据业务流程和业务需求建立对应的uml，或者也可以对应每个角色建立起一个虚拟人物，把整个业务流程完整走一遍，这样可以模拟出实际操作中会出现哪些具体问题，在完成最终的业务目标前，可能会出现的阶段性目标有哪些，同时又会有什么样零星的小需求出现。很多这些过程中的需求是业务部门不会提及的，你有责任告诉他们这些情况。
公式驱动：以应用类产品举例，如果一个公司可以同时向用户提供两种服务A和B，二者的利润不同，同时又会受到市场季节性需求变化和产能供应量的限制出现数量上的波动；现在要求我们能够找到合适的资源分配方式，来让公司获得最大的盈利。这其实就是一个根据制约条件来找到A和B两种服务对应各自需要有什么变量的问题。不妨列出一个公式，看看究竟各个制约条件之间是如何影响的，从而找到合适的解决办法。
要记得，在需求被拆解后的每一个问题有些是对应固定的角色的，而一些则是可认为是无所谓角色区分的共性问题，还有一些问题的处理结果会影响他角色。务须能分清楚来对待。
分解阶段另一件重要的事情就是完成流程图的设计，对应产品人员要做的是业务流程图，如果有核心开发人员也参与了前期的需求讨论分析，可以建议他们同步展开架构流程的思考。
在 绘制流程图的时候需要尽可能标明其中的里程碑功能，大约需要哪些功能支撑、需要设计多少个页面或频道、组件，对应的管理后台需要有哪些对应的调用。这时候 也需要一并带着整理。我的实践经验是，可以先做完流程图，然后把后面的这些问题带进去思考，一方面寻找答案，一方面也可以完善你的流程图。
如果能够一路坚持走下来，基本上可以做到很完整地了解自己要解决些什么问题了。这时候你面对的就不再是一个总的需求，而是一个个细节的问题。接下来要做的就是对各个问题进行评估，
评估；
如果我们把分解理解为找问题，那么评估就是为解决问题做准备。
鉴于我们在分解问题的时候，其实已经涉及了一部分评估的工作，这里不妨更深一层。例如，你打算使用多少个页面、会有多少个功能点出现。这些经过分析提炼后的内容可以用PRD或者低保真原型的方式展现给相关的开发人员和业务部门。
不过评估最重要的工作并不是要穷列出来究竟需要做哪些工作，而是需要对这些即将展开的工作做出排序，同时你可能必须舍弃一些原本精心构思的内容。
对工作的排序是产品自己无法完成的，需要尽可能和开发部门配合。开发人员对于业务需求有着自己的一套理解，同时由于涉及到很多实现细节的问题，也需要在达到共识的基础上才能继续推动。
因此，在真正展开具体的产品设计工作之前，需要能和开发人员进行沟通，尽可能做到以下几点：我们需要多少个功能点来支撑这个产品或满足需求；这些功能点都是可以在规定项目时间内开发完成的吗；开发人员对于自己要做的事情有足够的判断，知道哪些应该先做，哪些要后置；对于暂时无法实现的功能，是退回给需求方，还是产品重新构思或者延至2.0版本完成，需要说明清楚。
对于没有技术背景的产品，这时候很容易陷入被动，你可能会被技术提出的各种“不好实现”搅得心烦意乱。为了避免这种情况，你最好能找到一个能和你顺畅沟通的技术经理，很多问题其实并不需要你亲自上阵的。
决策：
在经过了前面几轮重重的折磨，才是产品人员真正发挥创意的时候，你将左右会有怎样的表现，你拥有整个产品开发的决策权。别人可以提意见，但是最终你才是那个决定事情该怎么做的人。
制定项目计划，针对每个细分功能拿出具体的实现策略，给出产出物的交付时间，绘制原型图和PRD文档。从产品整体框架到页面布局、频道功能再到按钮的位置， 弹出层的设计。设计的创意才在这里真正迸发，你所有知道的界面设计、导航架构、交互形式的知识和才能都会在这里得到淋漓尽致的体现。
暂且撇下你的设计创意不表，如何把评估阶段的成果应用好是我们是否能顺利进入决策阶段的关键。总会有一些功能被砍掉，也有一些新功能提出来，原本想好的某些 流程也可能要重新调整。在决策阶段，你需要有做减法的魄力和决心，抛弃一些东西，适当做一些让步，但是要能保证产品的核心功能不被阉割。对于核心功能，任 何为了减轻工作量或者无法实现而要求绕道而行的借口都是可耻的；如果你有有充分的理由相信产品的核心功能，那就一定要坚持到底。
写在最后的话：
至此，我们通过确定、分解、评估和决策把需求分析阶段要做的事情做了一个梳理，也为后面的设计和开发开了一个好头。当然你仍然会面临业务部门的需求变更，设 计或者开发人员在某个功能或表现形式上跟你死磕的局面，这时候你仍然可以应用这四个步骤来解决具体的问题，但是在实现上需要做一些变通，项目一旦进入到开发编码阶段，时间会非常紧凑，你能做的就是根据新提出来的想法迅速协调好利益相关部门，在开会之前你就能要准备好几套方案，否则会议就会变成一种折磨：低 效，浪费时间，不解决问题。