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