我们在做一个网站的时候，往往需要先分析用户的需求，全面把握决策的方向，才能让网站的建设的执行过程中更加顺畅。史特结合自己多年的建站经验与大家来探讨下，如何在建站之前先做好四步基础步骤—

—确定、分解、评估、决策，在网站建设中全面推进了解客户的需求，做一个让客户满意的网站。

确定

首先要先搞清楚网站的产品模块，需要解决哪些问题，事先要先做好调研工作，多了解一些信息，才有可能真正了解一个网站真正的需求是什么，在确定环节中，这只完成了一半的工作；接下来我们需要知道对应这

个需求，会有哪些角色来使用，我们需要能够对这些角色涉及到的不同需求做出细分。

分解

分解的意义在于把大问题化解为小问题，变成一个个可控的模块，注意这里是说的可控是指你可以通过一定的约束条件和已知存在的变量来实现对问题的描述。通常有两种分解的方法：

第一，流程驱动：根据业务流程和业务需求建立对应的uml，或者也可以对应每个角色建立起一个虚拟人物，把整个业务流程完整走一遍，这样可以模拟出实际操作中会出现哪些具体问题，在完成最终的业务目标前，

可能会出现的阶段性目标有哪些，同时又会有什么样零星的小需求出现。很多这些过程中的需求是业务部门不会提及的，你有责任告诉他们这些情况。

第二，公式驱动：以应用类产品举例，如果一个公司可以同时向用户提供两种服务A和B，二者的利润不同，同时又会受到市场季节性需求变化和产能供应量的限制出现数量上的波动；现在要求我们能够找到合适的资

源分配方式，来让公司获得最大的盈利。这其实就是一个根据制约条件来找到A和B两种服务对应各自需要有什么变量的问题。不妨列出一个公式，看看究竟各个制约条件之间是如何影响的，从而找到合适的解决办法

。

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

标明其中的里程碑功能，大约需要哪些功能支撑、需要设计多少个页面或频道、组件，对应的管理后台需要有哪些对应的调用。

先做完流程图，一方面寻找答案，一方面也可以完善你的流程图。如果能够一路坚持走下来，基本上可以做到很完整地了解自己要解决些什么问题了。这时候你面对的就不再是一个总的需求，而是一个个细节的问题

。接下来要做的就是对各个问题进行评估，

评估

如果我们把分解理解为找问题，那么评估就是为解决问题做准备。例如，你打算使用多少个页面、会有多少个功能点出现。这些经过分析提炼后的内容可以用PRD或者低保真原型的方式展现给相关的开发人员和业务部

门。

评估最重要的工作是需要对这些即将展开的工作做出排序，可能会舍弃一些原本精心构思的内容。对工作的排序是产品自己无法完成的，需要尽可能和开发部门配合。开发人员对于业务需求有着自己的一套理解，同

时由于涉及到很多实现细节的问题，也需要在达到共识的基础上才能继续推动。

在真正展开具体的产品设计工作之前，需要能和开发人员进行沟通，尽可能做到以下几点：需要多少个功能点来支撑这个产品或满足需求；这些功能点都是可以在规定项目时间内开发完成的吗？

开发人员对于自己要做的事情有足够的判断，知道哪些应该先做，哪些要后置；对于暂时无法实现的功能，是退回给需求方，还是产品重新构思或者延至2.0版本完成，需要说明清楚。对于没有技术背景的产品，这时

候很容易陷入被动，尽可能找到一个能和你顺畅沟通的技术经理。

决策

首先是制定项目计划，针对每个细分功能拿出具体的实现策略，给出产出物的交付时间，绘制原型图和PRD文档。从产品整体框架到页面布局、频道功能再到按钮的位置，弹出层的设计。设计的创意才在这里真正迸发

，你所有知道的界面设计、导航架构、交互形式的知识和才能都会在这里得到淋漓尽致的体现。

暂且撇下你的设计创意不表，如何把评估阶段的成果应用好是我们是否能顺利进入决策阶段的关键。总会有一些功能被砍掉，也有一些新功能提出来，原本想好的某些流程也可能要重新调整。在决策阶段，你需要抛

弃一些东西，适当做一些让步，才能保证产品的核心功能延续。

总结

通过确定、分解、评估和决策把需求分析阶段要做的事情做一个梳理，也为后面的设计和开发开了一个好头。但是在实现上可能需要做一些变通，项目一旦进入到开发编码阶段，时间会非常紧凑，你能做的就是根据

新提出来的想法迅速协调好利益相关部门，在开会之前你就能要准备好几套方案，全面协调与兼顾各个部门的需求。