谁：“我顶——（你个肺）！我搜集具体的需求先。”
众所周知，网站的新产品或升级需求，通常是由领导者（CEO、COO、UFO……）提出的。而领导者一般只会给出目标和概念，无法提供细节描述。首先这不是他的职责，其次他没有时间，领导总是忙的（哦…哦…俯卧撑正做到第3个）。当然，最重要的是，他不是真正的用户。
作为产品经理、项目经理或需求分析师，需要与最初的构思人、实际操作者、面向用户群以及有类似产品经验的相关人员细致沟通。虽然你不一定在做爱做的事，但一定要交配交的人。这样才能了解到真实需求，设计开发出优秀的产品，打个漂亮仗。
一、地雷总埋在粗糙的需求中
为了节省时间不做详细的需求分析，往往会付出更多时间。由于敌情不明，设计开发过程中你会发现不断有新的需求冒出来，而且总是不停地在做修改。因为你不知道前面埋了多少雷，以及有多大，而且不是用鼠标玩扫雷可以解决的。
结果：
1、 你无法准确预估项目时间，老板对你很失望；
2、 你不能在规定的期限内完成，老板开始对你绝望；
3、 当你完成以后发现——其实一切才刚刚开始，上帝也绝望了；
4、 产品终于上线，需求方对你的满意度-100，信任度-150，合计250；
5、 最后一关，终极Boss（总是比你大很多倍那个）开始考虑该把你降职降薪还是炒个菜——鱿鱼；
6、 总之，你完了，你的团队也跟着你背黑锅。
唯一可以庆幸的就是，你不是炮兵炊事员，不用戴绿帽。不过，如果你经常为这个项目加班……咳咳，可能我没猜中结果。
二、你该侦查什么？
知己知彼，百战不殆。你只有知道哪些情报对这次战斗是有用信息，才能打好仗。所以一定要施展你的三寸不烂之舌，把需求相关的问题重复一千遍，直到它变为真理。
情报：
1、 目标任务
领导者和构思人对这个产品的目标定义和期望，通常是概念性的需求，比如“为人民币服务”，好一点就是“我们要做一个人际关系社区”；
2、 用户需求
操作者和用户群肯定会用它做什么？可能做什么？和他们好好聊聊，确定他们不会在Twitter里面写Blog，做好任务分解；
3、 功能需求
需要开发人员实现哪些功能？一定要保证用户需求能够通过它们实现，往往操作方式和展现形式也要确定；
4、 非功能需求
除了功能性，产品需要达到什么标准，遵守什么规范？虽然我们不是性工作者，但总是不得不和性打交道，它们通常是——
1)
2)
A.
B.
百科一下：ACID，指数据库事务正确执行的四个基本要素的缩写.包含:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。一个支持交易(Transaction)的数据库系统，必需要具有这四种特性，否则在交易过程(Transaction processing)当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。
3)
A.
B.
4)
5)
三、怎么做好侦察兵
沟通能力是优秀的产品经理和项目经理必不可少的一项能力。不过话说回来，力量越大，责任越大。你只有遵守以下军规，才能保证完成你的任务。
1、 尽量避免专业术语
你不是在构建巴比塔，所以在和需求方沟通时，必须使用他能听懂的语言。要假设他什么都不懂，包括你眼中的常识。但是，你必须能够听懂对方的专业术语，因为它们会在你的产品中用到。
2、 了解用户的专业领域和目标
你需要知道实际操作者是怎么工作的，以及为什么需要这个产品？尝试在他的岗位工作一段时间，恶补专业知识。如果有面向的用户群，就不能以单方面的需求为准，必须全面了解。
3、 合理的采纳需求
及时作出决定，对于用户的需求有条件要上，没有条件也要创造条件上。尽量不被客观理由限制，例如找技术上不能实现等借口。不过由于这是你和需求方达成的有效协议，所以对于不恰当的需求，要尊重技术做出的可行性分析和评估。
4、 实现功能的同时解决易用性
找出以前的产品（如果有）有什么优点和缺点，同类产品是怎么满足用户需求的。我们不需要“界面美观、操作方便、提高效率”这样的形容词，不能主观臆断，而是从用户哪儿了解他们对需求的具体定义及其特性。
5、 提供最好的解决方案
由于需求方对技术不了解，可能会提出一些错误的需求解决方法，例如逻辑上自相矛盾。你需要发挥专业优势，帮他找出最佳的产品设计、开发方案（可供选择），而不是一味地迁就。即便是你的领导，你也要敢于说不。
6、 划分需求的优先级
大部分产品最初的规划，都是庞大而复杂的。你需要配合需求方、开发人员对功能需求分级：必须的、重要且紧急的、紧急不重要的、重要不紧急的、不重要不紧急的。在没有足够的时间和人力来完成每个细节时，尊重开发人员的意见作出取舍。
7、 需求的变更要及时、谨慎评估
你应该预设规则避免或减少需求变更。越早发现需求的变更，带来的损失越小。因为夜长梦多……，而且用户在变更需求时，往往不知道会带来什么后果。你有必要跟他讲清楚利弊，包括时间、成本、性能、质量等等，帮助用户进行决策。
8、 沟通是个漫长的过程
要有足够的耐心和用户打交道，你可能随时需要他们的协助。只有保持不间断的沟通，才能减少不必要的修改。反复的修改原型页，就是最好的例子。
9、 做好需求分析报告
你搜集到的情报，要以多样化的文档形式来展现（包括原型页甚至设计稿），例如HTML、Word、PPT、PPG、LiuPP……它在设计、开发、测试等多个环节都会用到。
通俗易懂的文字和简洁明了的图表，能保证你的老板、老板的小蜜、设计制作、开发，以及智商低至25-高达250的用户都能看懂。
你必须保证图表上的每个元素都能被需求方理解，例如原型页的每块内容怎么调用，每个链接指向哪里，都做好详细说明。只有双方都能完全明白对方的意图，才能确保需求真实。
你还得保证报告中没有未知或待定的需求，一定要在第一时间沟通完毕。
10、 评审需求分析
完成需求分析后，我们要请出需求方做出最后的确认。采用越正式的方式，需求方就会越认真的对待。当然最好的方式就是签字画押——拉勾，上吊，一百年不许变！
四、侦察完成
当对方在需求分析报告上签字时，我们的侦查任务似乎就可以完成了。但不要忘记，军情瞬息万变，战斗才刚刚打响呢。
现实生活中，大部分签字者都不把这当回事儿。除非是有法律效应的文书，否则你就当他们在练习签名吧，如果可能的话还会附送唇印。
“你们需要我签，我才签的”
“不签你们就不干活，我急着要呢”
“我根本就没看懂，太信任你们了”
当然，你也可能反戈一击：“黑纸白字，再改我们可没门”。如果这是求你办事的兄弟部队，也许可以臭脸挡回去。换成是你的总司令呢？
五千年的悠久历史告诉我们，如果你不能反抗，那么就默默的享受吧。签字的实质意义就是告诉你：“我认可当前的文档说明，如果有新的需求和更改，我们再一起商量时间、人力、金钱、美女吧”。
没有最好，只有更好。既然我们的目标就是满足用户需求，坚决完成任务。所以在产品上线以前，你仍然需要保持和用户的沟通，时刻通报最新进展。尽可能提供Demo给用户，让他们能够帮助我们完善需求和改进产品。
直到产品上线，我们才可以松一口气，高声大呼——
改版尚未成功，同志仍需努力！
插入表情