如何面对客户的紧急需求

本文全部转载自:http://blog.csdn.net/ioswyl88219/article/details/19167821

-------------------------------------------------分割线开始-------------------------------------------------------------

今天看一篇园子里面的文章,刚好手上碰到这样的事不少,最近也有个项目遇到了这样的情况,感触之余,就写了篇文章算是交流一下吧。

     客户常常有很多很急的需求,很多客户不是软件开发专业的,常常拿他们平常所见的软件与我们的产品或项目作比较,认为这样或那样的功能在臆想中应该一天或短时间就能完成的,殊不知在写代码的时间很短,但了解需求,版本管理和沟通确认的时间是要得到充分保证的,否则只有一个后果,返工的机率大大增加,辛苦写的代码成了废品。这时,谁能体会我们心在流血的感觉呢,那么多的一个个加班和心血都没有了。

     所以,沟通确认是为了让客户明白,需求一定要明确要细致,明白了客户的真实要求,双方达成一致意见后,再以书面的形式确认下来,客户可能会认为麻烦,但这种麻烦是必须的,一方面保证需求有据可查,另一方面客户会通过这种认真,知道我们的专业精神。

     我举一个最近的例子

     某客户是有名的快速执行的主,最近很多需求,从集团人力资源部,从分子公司,从各个层面象雨点一样扑面而来,怎么办,我们采取的办法是,一一记录下来,用标准的文档,里面以图片加文字加原型设计的格式来说明各个需求,统一由集团人力资源部的管理者确认。确认后我们再动手,再急的需求也必须有记录,哪怕是为了客户不扣钱而加急赶的工,事后也要和客户确认一下。客户的态度也慢慢从当初的马上就提需求到现在的思考后再提需求。从中间得到的经验和教训是:

     1、需求必须要详细说明,必须要站在客户的角度描述,避免纯文字描述,能有图片尽量有图片,遇到有新功能还要辅以原型界面,这点时间的花费是绝对值得的

     2、有些小改动不是大改动没有新增功能、不影响产品普遍适用性的,而且关系到客户工作评价的,譬如改个查询视图的排序之类的,在需求说明范围之内的,能速度解决的就速度解决,不需要再来回确认客户会明白的。不是任何工作都要客户确认一下,那样就失去了需求确认的意义了,我们做需求确认是为了双方的意思表达一致,并对结果预期(图片、原型)一致,不是人为搞那么多文档麻烦彼此的

     3、文档写作是个细致的活,一定要站在客户的角度去想去写,不要怕麻烦,需求确认越清楚,后面的兄弟们写代码越轻松,越不会出现返工的现象。

     4、需求说明文档必需对产品有深刻的理解人去写,一个人如果只负责自己这几个模块功能的,很可能考虑不全面

     5、再横的客户也明白规范工作的意义,要掌握好平衡,对需求一定要据理力争先确认,哪怕是口头的沟通就开始做的很急的功能,也要在写代码时马上补好需求文档让客户确认,因为这时代码刚刚开始写,如果理解错了,还来得及纠正。

--------------------------------------------------分割线结束-------------------------------------------------------------

如何估算项目时间? 在博客园上看到这篇 讨论和正文非常精彩的文章,特此加入此链接来记录:

http://www.cnblogs.com/baochuan/archive/2012/05/14/2499005.html

posted @ 2015-01-12 15:46  浩天之家  阅读(2299)  评论(0编辑  收藏  举报