如何面对客户的紧急需求
2012-05-10 19:27
1111 查看
今天看一篇园子里面的文章,刚好手上碰到这样的事不少,最近也有个项目遇到了这样的情况,感触之余,就写了篇文章算是交流一下吧。 客户常常有很多很急的需求,很多客户不是软件开发专业的,常常拿他们平常所见的软件与我们的产品或项目作比较,认为这样或那样的功能在臆想中应该一天或短时间就能完成的,殊不知在写代码的时间很短,但了解需求,版本管理和沟通确认的时间是要得到充分保证的,否则只有一个后果,返工的机率大大增加,辛苦写的代码成了废品。这时,谁能体会我们心在流血的感觉呢,那么多的一个个加班和心血都没有了。
所以,沟通确认是为了让客户明白,需求一定要明确要细致,明白了客户的真实要求,双方达成一致意见后,再以书面的形式确认下来,客户可能会认为麻烦,但这种麻烦是必须的,一方面保证需求有据可查,另一方面客户会通过这种认真,知道我们的专业精神。 我举一个最近的例子 某客户是有名的快速执行的主,最近很多需求,从集团人力资源部,从分子公司,从各个层面象雨点一样扑面而来,怎么办,我们采取的办法是,一一记录下来,用标准的文档,里面以图片加文字加原型设计的格式来说明各个需求,统一由集团人力资源部的管理者确认。确认后我们再动手,再急的需求也必须有记录,哪怕是为了客户不扣钱而加急赶的工,事后也要和客户确认一下。客户的态度也慢慢从当初的马上就提需求到现在的思考后再提需求。从中间得到的经验和教训是: 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
所以,沟通确认是为了让客户明白,需求一定要明确要细致,明白了客户的真实要求,双方达成一致意见后,再以书面的形式确认下来,客户可能会认为麻烦,但这种麻烦是必须的,一方面保证需求有据可查,另一方面客户会通过这种认真,知道我们的专业精神。 我举一个最近的例子 某客户是有名的快速执行的主,最近很多需求,从集团人力资源部,从分子公司,从各个层面象雨点一样扑面而来,怎么办,我们采取的办法是,一一记录下来,用标准的文档,里面以图片加文字加原型设计的格式来说明各个需求,统一由集团人力资源部的管理者确认。确认后我们再动手,再急的需求也必须有记录,哪怕是为了客户不扣钱而加急赶的工,事后也要和客户确认一下。客户的态度也慢慢从当初的马上就提需求到现在的思考后再提需求。从中间得到的经验和教训是: 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
相关文章推荐
- 如何面对客户的紧急需求
- 面对客户太多需求,如何在范围和时间上达成一致?
- 面对客户,如何做公司(工作室)介绍?
- 如何拉动内需,击中客户深层需求,4个经典案例分析!
- 以过桥算法来谈如何满足客户的需求和程序设计步骤
- 设计和开发如何获取真实的客户产品需求
- 项目如何开始:怎样和客户一起搞定需求
- 如何写CRM需求——客户服务管理篇
- 项目如何开始:怎样和客户一起搞定需求(转自---西乔的九卦)
- 如何获取客户设计需求
- 项目管理中如何更好的控制客户的需求?
- 技术部门如何对业务、客户的新需求进行取舍,做到优雅相处?
- [转] 项目管理---项目经理如何应对客户的需求变更?
- ★如何引导客户需求?几个经典的案例分析!
- 大陆晶圆代工业如何追赶世界大象(选择一条放缓资本投入,以市场为导向,紧贴客户需求的道路,适时调整发展策略,抓紧产品质量和运营效率的提升,从现在来看这一选择是非常正确的)
- 客户提出一些硬性需求,无法验证,该如何应对
- 如何理解客户需求,市场需求,业务需求,功能需求,产品需求,设计需求?
- [转]项目中如何更好的控制客户需求
- 如何面对客户评价Oracle EBS界面难看,不符合操作习惯
- IT项目中如何更好的控制客户需求