何谓需求？

　　马斯洛认为，人类的需求是分层次的，由低到高，它们是：生理需求、安全需求、社交需求、尊重需求、自我实现需求。 基本我们平常说的需求都可以在马斯洛需求中找到对应的分类。

　　主要是想讲需求从产生到实现需要经过哪些过程。

　　一、发现用户需求

　　它包含了收集用户需求（被动），发现用户需求属于主动一类。通过客服或一线员工收集到的情报（建议/意见）整理成表格，我们称之为”用户需求管理表”。一般内容包含需求编号、需求来源、功能模组、会员ID、会员身份、会员原话、收集人、是否采纳、处理状态、预计完成时间、回访会员结果等。

　　二、用户需求分析

　　这里用到了”用户需求分析表”，在上篇文章中有贴需求分析表的样表，这里不再多讲。这份表存在的目的主要是帮助收集需求的相关资料，为需求评审做铺垫。分析一般尊重以下几个原则：

　　1、利我原则（对我们网站有什么好处）

　　2、利他原则（对用户有什么好处，解决了用户什么困难）

　　需求分析中要明确我们要达到的目的是什么。此阶段一般是由一名产品负责完成。然后将分析后的需求放到”产品需求管理表”中。”产品需求管理表”一般分为以下几项：用户需求编号、提交时间、需求来源、需求类型、用户身份、产品需求内容、商业价值、开发时间、优先级别、处理人、开始处理时间、处理完成时间等。

　　需求分析中比较忌讳的一点是不能将我们要达到的XX需求与达到这个需求的方式放在一起分析，这样很容易当你选择的方式被fire掉的时候，连同要完成的需求也一起fire掉。

　　一般在这个阶段，会产生两份文档：一份PRD文档（Product Requirement Document），也是“产品需求说明文档”，一份是“产品需求交互说明文档”，交互文档简单来讲是说明每个需求“从哪里来，要到哪里去！”这两个文档一般是用于重要的需求，文档的书写的好坏决定了工程开发是否明确了需求的功能，且需求说明文档也可以当作后续需求完成之后的测试模版。

　　三、需求评审

　　需求评审的是“产品需求说明文档”和“产品需求交互说明文档”，需求评审一般会成立需求评审小组，一般参与人有：产品、工程、上级领导（部门主管）。工程存在的目的是评估产品需求开发时间。假如需求涉及营运相关，必要时也需要有营运的加入。评审主要是评估：

　　1、需求描述是否清晰、简洁、无二义，其中无二义我认为是重要的，让大家对需求描述的理解是否达成了一致

　　2、需求与需求之间是否有冲突和重复

　　3、描述的每个需求是否都在项目范围内

　　4、现有的资源是否能在预计时间内实现所有需求

　　5、交互说明文档中主要是三部分：滑鼠、链接、提醒讯息之间的状态描述

　　认真评审可避免后续需求的返工。

　　四、需求设计

　　这个视情况而定，有些是在”产品需求文档”中已经通过Axure实现高保真原型设计，直接交付工程开发，有些则需要重新设计高保真的设计稿。像我们这样的团队，一般是直接在书写文档的时候直接将UI一起设计了。

　　五、需求开发

　　这个阶段一般是由工程师负责，按照之前列出的需求优先级开发即可。其实条件允许的话，根据经验，好是前端和后端一起合作开发，能节省不少时间。我觉得需求在开发的时候，做完一个需求上线一个需求是比较好的方式，除非是新项目需要一起上线。假如是完善旧功能，或者是旧功能改版什么的，快速迭代是好不过了。在整个过程也能增强大家的信心。

　　六、需求测试

　　这个可以按照”产品需求说明文档”与”产品需求交互说明文档”对照测试即可，可以减少遗漏。不过在测试方面，我觉得比较蛋疼的是IE6。不过一般情况下是直接放弃了。从google文档那边来看，我们的用户使用IE6的只占到了6%？（明天查下数据确认下）且修复一个BUG却产生了另外一个BUG也是很纠结蛋疼的事。唉..测试不提了..

　　七、需求上线

　　当测试人员测试完，将测试文档交给工程修复好所有BUG后，需求可以上线了！此刻，一个孩子终于诞生！需求的一生也结束了，算是破茧成蝶了吧…至此，孩子的爸妈也可松口气了！呼……