本文全部转载自：http://blog.csdn.net/ioswyl88219/article/details/19167821
-------------------------------------------------分割线开始-------------------------------------------------------------
今天看一篇园子里面的文章，刚好手上碰到这样的事不少，最近也有个项目遇到了这样的情况，感触之余，就写了篇文章算是交流一下吧。
客户常常有很多很急的需求，很多客户不是软件开发专业的，常常拿他们平常所见的软件与我们的产品或项目作比较，认为这样或那样的功能在臆想中应该一天或短时间就能完成的，殊不知在写代码的时间很短，但了解需求，版本管理和沟通确认的时间是要得到充分保证的，否则只有一个后果，返工的机率大大增加，辛苦写的代码成了废品。这时，谁能体会我们心在流血的感觉呢，那么多的一个个加班和心血都没有了。
所以，沟通确认是为了让客户明白，需求一定要明确要细致，明白了客户的真实要求，双方达成一致意见后，再以书面的形式确认下来，客户可能会认为麻烦，但这种麻烦是必须的，一方面保证需求有据可查，另一方面客户会通过这种认真，知道我们的专业精神。
我举一个最近的例子
某客户是有名的快速执行的主，最近很多需求，从集团人力资源部，从分子公司，从各个层面象雨点一样扑面而来，怎么办，我们采取的办法是，一一记录下来，用标准的文档，里面以图片加文字加原型设计的格式来说明各个需求，统一由集团人力资源部的管理者确认。确认后我们再动手，再急的需求也必须有记录，哪怕是为了客户不扣钱而加急赶的工，事后也要和客户确认一下。客户的态度也慢慢从当初的马上就提需求到现在的思考后再提需求。从中间得到的经验和教训是：
1、需求必须要详细说明，必须要站在客户的角度描述，避免纯文字描述，能有图片尽量有图片，遇到有新功能还要辅以原型界面，这点时间的花费是绝对值得的
2、有些小改动不是大改动没有新增功能、不影响产品普遍适用性的，而且关系到客户工作评价的，譬如改个查询视图的排序之类的，在需求说明范围之内的，能速度解决的就速度解决，不需要再来回确认客户会明白的。不是任何工作都要客户确认一下，那样就失去了需求确认的意义了，我们做需求确认是为了双方的意思表达一致，并对结果预期（图片、原型）一致，不是人为搞那么多文档麻烦彼此的
3、文档写作是个细致的活，一定要站在客户的角度去想去写，不要怕麻烦，需求确认越清楚，后面的兄弟们写代码越轻松，越不会出现返工的现象。
4、需求说明文档必需对产品有深刻的理解人去写，一个人如果只负责自己这几个模块功能的，很可能考虑不全面
5、再横的客户也明白规范工作的意义，要掌握好平衡，对需求一定要据理力争先确认，哪怕是口头的沟通就开始做的很急的功能，也要在写代码时马上补好需求文档让客户确认，因为这时代码刚刚开始写，如果理解错了，还来得及纠正。
--------------------------------------------------分割线结束-------------------------------------------------------------
如何估算项目时间？ 在博客园上看到这篇 讨论和正文非常精彩的文章，特此加入此链接来记录：
http://www.cnblogs.com/baochuan/archive/2012/05/14/2499005.html