项目已经进入到 第二次迭代末
发现一个问题： 原始需求 似乎离我们越来越远了 似乎是已经被大家渐渐的淡忘 多数时候 都是 根据最新提供的静态页面 进行设计和修改。那么我们最初 用来签合同 用来估算价格的原始需求去了哪了？需求如果控制不住 对项目的影响是没法估量的。
需求是最初的工作 也是最重要的工作之一，那么如何做好需求那？在这次项目中 有几点迷茫：
首先提出几个问题：
1 在最初（报价时）和 合同签订前 需求 应该明确到 细化到 什么程度？达到什么目的？依据是什么？注意什么？
2 在做需求的时候 有没有 套路套路可以依据？注意什么？先做什么，再做什么...
3 在做项目的过程中 如何 区分 哪些是需求的细化，哪些是新的需求？依据是什么？
4 在做项目的过程中 该如何 控制住 需求 （不增加，不要任意改动）依据是什么？如何处理？
需求的重要性 非同一般：
是最初的报价的依据；是合同的重要副本；是做程序架构和设计的基础；是程序开发中控制需求的杀手锏；是后期维护的重要参考。
对于如此重要的东西，是一定要整一套处理方案 才可以放心的。
首先 需求一定要成文档；而且 需要经过 各个部门的审核通过；并且 强调其重要性，要让客户知道，这个东西 在项目中的重要作用 并且 不是说改就改的！而且就是非要改也会很难！很常见的一种方式，就是 跟客户聊一下 口头说说 认为双方都明确了 就OK了。很多项目失败就是因为：需求在客户嘴里，那么 你永远不知道 你的目标。这样 不仅对以后的项目进展有好处看，而且 提醒客户 这个的重要性，也会认真准备，而不是想当然。
接项的大致流程是这样的： 客户：甲 我方：乙
甲：我这有个项目 大体 是这样的“**&&%￥%……&……” 你可以做吗？
乙：可以做，但是 这个需求 太笼统 我不好报价，有详细的需求吗？
甲：有，发给你：file.........
乙：好的，我先看下需求；会有些疑问 什么时间有空我们能再沟通?
甲：我随时在线
乙：OK 我会在下午5点前联系你 回见
......
...4h PM...
乙：还在吗？ 我看了下 有几个疑问。
甲：请说。
乙： 问题一... 问题二...问题三....
甲：Replay All
乙：我可以 给你一个大体的报价了：90w RMB 左右
乙：具体价格以及计算过程 和 详细说明 的报价单 明早 10点前 发给您 ；（从现在到明天的10点 乙必须给出一个详细的报价单 合理可靠 同时会产生新的疑问，但是问题是，现在乙需要做到什么程度 能 保证价格的合理可到那？）
甲：好的
......
......第二天 上午 9：40
乙：在吗？ 我的详细报价单 file...
甲：OK 我们看下...
从上面可看到，我们所得到的 也是 最先需要得到的是：客户的意愿，客户想要一个什么样的东西；这种意愿从何而来？（有助于我们理解需求）；这时候最好要几个事例（站点），因为 多数用户的灵感就是由于看了什么什么，想要一个跟什么什么类似的，但是我有我的特色...... 有了 参考 和 用户的目的，这样做 做需求就有了一个大致的方向。
而后，用户最需要的就是一个报价。那么 第一个难题来了，这个报价如何做？换句话说，怎样的需求 才能正确的 估算出价格？其实，这里面有两个学问：1 就是需求做的程度 2 如何做报价
1 需求做的程度 - A 限制好范围 B 不要放过任何一个疑点 C 考虑全面
最开始的需求 做到很细致是很困难的 而且也没有那个时间；所以 现在的任务就是 明确限制好 项目的范围，能够保证 不会超出 这个范围即可！这里需要注意两个事情 一个是：不要放过任何一个疑点（因为 每个不清楚的东西到后来可能无限增大）； 再一个是：考虑全面 一方面包括 用户没有提出的衍生的需求，另一方面，用户不是专家，你应该 根据用户的意愿 提出 更好的意见建议。
2 如何报价：思路：我做哪些东西 需要多少money 而不是 哪些我不做之后 需要 多少money
报价单保持：1 清晰 2 细致 3 全面 让客户知道 哪些东西 需要多少money 如果觉得不合算 可以去掉 或者想别的办法。
这些做好以后 我们就直接进入开发，接下来会遇到麻烦事：变更还是细化 -- 很晚了 待续 0911292354
-- 1 同样的功能 不同的效果 使用的工作量不同
-- 2 开始的时候理解失误 或者沟通 没做好 引起问题
-- 3 在做的的过程中 用户 发现以前的需求不完整 需要 补充
-- 4 由于 页面的调整 引起设计的改变