1. 为什么要做产品需求
所谓需求，就是分析用户的需要什么，它是决定项目的成功与失败首要因素。大量的人力，财力，物力投入后却得到了一个用户不想用的产品，无论代码多好，流程多完美，这个产品都是失败的，所以产品需求是项目本身的导向和基点，是项目的首要环节。
2. 如何去做产品需求
2.1 产品需求的内涵
2.2 284117
2.2.1 任务
简而言之，需求的任务就是解决“做什么”的问题，全面的理解用户所需要的各项功能，并能准确的表达所接受的用户需求
2.2.1 步骤
需求建立的过程包括：问题识别，分析与综合，制定规格说明书，评审，迭代。
a) 问题识别：
从系统的角度理解软件功能，确定所开发系统的综合要求，并提出需求的实现条件，以及需求应该达到的标准。主要内容包括：功能需求(做什么),性能需 求(需要达到什么指标)，环境需求(机型，操作系统)，可靠性需求(不发生)，安全保密需求，资源使用需求，用户需求，资源使用需求，软件消耗成本和开发 进度；
b) 分析与综合：
逐步细化软件功能，找出系统元素之间的联系，接口特性，和设计上的限制，分析需求满足度，提出不合理需求并增加必要需求，最后综合系统解决方案，给出开发的详细逻辑模型；
c) 制定规格说明书：描述最终产品需求的文档；
d) 评审：
对功能的正确性，完整性和清晰性，以及其他需求给予评价。评审通过进行下一步的工作，否则，重新进行需求分析；
e) 迭代：对评审结果进行针对性的需求迭代，以达到尽量接近真实需求的目的。
2.3 需求分析的方法
2.3.1 方法
原型化方法，尽可能快的建立一个粗糙的系统实现项目需求中的某些或者全部功能，但是这个系统在可靠性，界面友好性，或者其他方面存在缺陷，建造一个 系统的目的是为了考察某一方面的可行性，如算法，技术，是否满足用户需求等。之后可以以这个系统为模型，综合客户的其他意见改进当前的模型。
2.3.2 目标
2.4 需求分析的法则
ü 分析人员要使用符合客服语言习惯的表达
ü 分析人员要了解客户的业务及目标
ü 分析人员必须编写软件需求报告
ü 要求得到需求工作结果的解释说明
ü 开发人员要尊重客户的意见
ü 开发人员要对需求及产品实施提出建议和解决方案
ü 描述产品使用特性
ü 允许重用已有的软件组件
ü 要求对变更的代价提供真实可靠的评估
ü 得满足客户功能和质量要求的系统
ü 给分析人员讲解您的业务
ü 抽出时间清楚地说明并完善需求
ü 准确而详细地说明需求
ü 及时作出决定
ü 尊重开发人员的需求可行性及成本评估
ü 划分需求的优先级
ü 评审需求文档和原型
ü 需求变更要立即联系
ü 遵照开发小组处理需求变更的过程
ü 尊重开发人员采用的需求分析过程
3. 产品需求的误区
3.1项目和求实
毋庸质疑的，每个人都会为自己的一个新的Ｉｄｅａ而激动万分，特别是当这个Ｉｄｅａ受到一些根本不知道你原本要干嘛的人的惊赞时。但是请注意，当你 激动得意的时候，你可能已经忘了你原本是在描述一个需求，而不是在策划一个创意、创造一个概念。很多刚开始做需求分析的人员都或多或少的会犯这样的错误， 陶醉在自己的新想法和新思路中，却违背了需求的原始客观性和真实性原则。
需求不是空中楼阁，是实实在在的一砖一瓦。
3.2解剖的快感
几乎所有搞软件的人，做需求分析的时候，一上来就会把用户告诉你的要求，完完整整的作个解剖，切开分成几个块，再细分成几个子块，然后再条分缕析。 可是当用户迷惑的看着你辛辛苦苦做出来的分析结果问你：我想作一个数据备份的任务，怎么做？这时，你会发现，需要先后打开三个窗口才能完成这个任务。
分解是必需的，但最终的目的是为了更好的组合，而不是为了分解。
3.3 角度和思维
经常听到这样的抱怨：“用户怎么可以提出这样苛刻的要求呢？”。细细一了解，你会发现，用户只不过是要求把一个需要两次点击的功能，改成只有一次点 击。这样会导致需要改变需求、改变编码、甚至重新测试，增加工作量。可是，如果换个角度来想想，这个功能，开发的时候只用了几次、几十次，可是用户每天都 要用几百次甚 至几千次几万次，改动一下就减少了一半的工作量，对他来说，这样的需求难道会苛刻吗？
没有任何需求是不对的，不对的只是你的需求分析。试着站在用户的思维角度想想，你的需求分析就会更加的贴近用户，更加的合理。软件应该是以人为本的。
3.4程序员逻辑
从程序员成长为系统分析员是一个普遍的轨迹，但并不是一个好的程序员就必然能成为一个好的系统分析员。一些程序员的固化逻辑，使得他们在做需求分析 的时候往往钻进了一些牛角里面。比如说１／０逻辑（或者是说黑白逻辑），认为不是这样就是那样，没有第三种情况。可实际情况往往是，在一定的时候是这样， 其它时候是那样。又比如穷举逻辑，喜欢上来就把所有一二三可能的情况列举出来，然后一个一个分别处理，每个占用三分之一的时间；可是实际的情况往往是，三 分之一的情况占了９９％的比例，其它两种情况一年都不会遇到一次。
需求分析和程序设计不尽相同，合理、可行是才是重要的。跳出程序设计的圈子，站在系统的角度上来看问题，你的结论会截然不同。
4. 我们的执行方案
4.1 需求在我们的团队中
4.1.1 团队需求中的产品需求
我们的产品类型的需求要做到以下几点：
1. 将业务的目的和流程功能化，模块化。因为它将成为项目计划制定的基础。
2. 成为项目计划的制定基础，项目计划的制定需要根据需求列表和功能点划分，也就是在项目计划中体现的技术问题和相应的管理，需要需求中的功能点来确定。
3. 需求和质量管理分别提供Bug权重比和Bug指数作为绩效评估中的质量与缺陷的判别点。
需求本身为整个团队服务，从业务到计划，从质量到绩效，所有的东西都与需求息息相关，也要求需求的质量必须过硬，同时也需要各个团队成员的协助，一下首先提示我们团队制定的粗略流程
4.2 我们的流程
1) 需求功能列表每次完成后，会多次和业务确认，并在业务签字后确认实施，作为项目计划分配。（①②）
2) 根据分配人,确认难易度等级,以及启动和完成时间.并加入项目计划制定中.（③④）
3) 项目功能列表提交给发布人员,根据项目计划以及列表中确认的开发完成时间,制定首次发布时间,签字确认（⑤⑥⑦）
4) 发布时间确认后,提交给质量管理,用于制定代码走查计划（⑤⑥）
5) 开发完成,发布前,质量管理回复,签字确认质量过关（⑧⑨⑩）
6) 发布时,提交给发布,确认发布成功(包括功能,流程,业务逻辑),确认签字.（⑾）
7) 文档备份
a) 问题1：根据实施中遇到到底问题添加步骤，责任人要首先提示功能可能涉及到不同模块，需要的协助者。
b) 问题2：由于要求提供可能牵涉的功能模块，导致无论多小的修改点，都要求前该功能模块的开发者修改。（需要明确，功能需求分配和协助者的关系，不能一味的 切分需求点。功能点的责任人就是负责本次开发任务的，代码本身就有耦合度。可以寻找支持，但不能“分配任务”，除非功能点可能关系到多个模块的逻辑修改， 更不能因此修改需求功能列表）
4.3 我们的数据模板
为了具化我们的执行准则，每个组都提供了自己的数据记录模板和执行方案。
产品需求组【执行方案】如下：
1. 需求列表模板
| ID | 应用模块 | 需求描述 | 需求概述 | 技术等级(难易度) | 优先级 | 启动时间 | 完成时间 | 原开发人 | 实现人 | 状态 | 相关修改文件 | 原需求 | 备注 | 自估工作量(时/人) | 标准工作量(时/人) | 平均工作量(时/人) | 实际工作量(时/人) | 权重比例 |
以上是需求列表模板需要的字段：
ID： 需求序列号
应用模块： 预订前台(yd.sozhen.com),客栈后台(kz.sozhen.com),管理后台(service.sozhen.com)图片服务W
需求描述： 样式，业务，异常，投诉，优化，关联(表示可能由大到功能点划分出的功能点)
需求高数： 描述需求需要的功能内容
技术难度等级： 10: 开发时间超过4个工作日
9: 开发时间超过3个工作日
8: 开发时间超过2.5个工作日
7: 开发时间超过2个工作日
6: 开发时间超过1.5个工作日
5: 开发时间超过1个工作日
4: 开发时间不超过8小时
3: 开发时间不超过5小时
2: 开发时间不超过3小时
1: 开发时间不超过1小时
优先级： 紧急，重要，一般，低。
状态： 未完成，已完成，不可实现，留到下期
相关修改文件： 相关开发者修改的文件内容（用于质量管理的代码走查和review）
自估工作量： 实现人估计工作量
标准工作量： 项目计划人估计工作量
平均工作量： （自估工作量 +标准工作量）/ 2
实际工作量： 实际开发使用的工作时间
权重比例： （1-（技术等级+工时）/100）* 110% + (标准工作量-自估工作量)/100 + (实际工作量-平均工作量)/100
2. 实际中的问题：
1. 提交的需求列表过多，不利于工作量，需求点的统计。
2. 没有明确给出质量管理和发布在需求列表中的流程反映。
3. 无法给予发布人员明确的线上统计。
4. 没有给予质量管理明确的管理时间段的提交和测试用例的提供。
3. 新版的需求模板列表(新增)
| 质量管理（代码走查） | 验收期 | 上线 | 完成 | |||||||
| 计划开始时间 | 计划完成时间 | 实际完成时间 | 验收完成时间 | 代码走查关联文挡 | 验收确认人 | 计划上线时间 | 实际上线时间 | 发布相关文挡 | 上线确认人 | 备注 |
Ø 在原基础上添加质量管理和发布流程体现。方便确认流程责任人，以及找到相关阶段的负责人。
Ø 关联质量管理文档和发布管理文档。
Ø 不在每次添加一个新的需求列表，只在月底提交需求功能列表，用颜色区分每次需求点集合
4.4 需求计划组绩效考评KPI：
1) 客户满意度
如何知道我们的需求分析是否正确，如何让我们看到自己的需求在别人心目中的位置？需求分析一个过程，但是最终决定它的含金量的一让是业务的感受。
什么是客户满意度？它应该包括沟通的次数是否足够，沟通的方式是否得体，需求是否完善，业务期望值是否达标等
我们可以在项目上线后提供项目回访问卷调查的方式，提供内容可以如下;（5分制）
沟通次数 ：
a) 经常（4.5-5）
b) 一般（3.5-4.5）
c) 偶尔（2-3.5）
d) 从不（1-2）
沟通得体 ：
a) 很好（4-5）
b) 一般 (3-4)
c) 差 （1-3）
d) 恶劣(0-1)
需求是否完善 ：
a) 完善（5）
b) 很好（4-5）
c) 一般（3-4）
d) 差（2-3）
e) 非常差（0-2）
业务期望 ：
a) 超出预期（5）
b) 很好（4-5）（达到80%-90）
c) 一般（3-4）（达到60%-80%）
d) 不好 (2-3) (30%-60%)
e) 差（0-2）（30%以下）
反映度：
a) 响应很快（5）
b) 一般 （4-5）
c) 慢 （3-4）
d) 延迟（0-3）
信赖度：是否按照承诺的时间以及内容完成
a) 提前完成（5）
b) 按时完成 （4-5）
c) 延时完成（2-4）
d) 未完成（0-2）
同理度：服务人员能够随时设身处地地为客户着想，真正地同情理解客户的处境、了解客户的需求。
a) 设身处地的为客户着想（5）
b) 基本为客户着想（4-5）
c) 一般（2-4）
d) 没有很好的为客户着想（1-2）
e) 完全没有为客户着想（0）
2) 需求覆盖率
此处的需求覆盖率与测试中的概念不同，此处表述的是客户需求的扩展以及期望与实际反映中的差距。
比较内容：
a) 原需求与现有需求是否有关联
b) 原需求达成原因是否是在和业务交流以后产生的
c) 需求内容是否是考虑业务的切身利益添加的
d) 不合理需求是否在建议业务人员后依然要求提交的
e) 确认需求与BUG的区别
