敏捷开发宠坏了客户

 

项目或产品使用敏捷开发方法带来的益处是多种多样的，比如敏捷提高了客户满意度、缩短交付时间、缩短响应时间、让我们泰然应对需求的变化等等；最近一直在实践敏捷开发，不过有一个问题困扰我好久，那就是如何避免宠坏客户。

 

敏捷嘛，所以经常逼着自己和客户面对面交流，打电话联系那更是频繁，而这个过程中认识相对统一的需求跃然而出。原来客户只是要规划一张图，能随手查就可以了；好，需求有了，合同签了，合同额50万确定了。这个简单，2个人三、四个月，也就是6-8人月就做出来了，50万的合同额我一定有的钱赚，还赚了关系。

 

说干咱马上开工，两个开发人员全程参与，四周后把一个桌面系统第一个版本交付给客户看。客户一看，嗯，大体就是这个样子，不过这里系统名字不能叫一张图，应该叫**系统；另外，这个随手查不是这个样子，应该怎样怎样，还需要加一个新功能……嗯，咱们不是拥抱变化嘛，客户既然这么要求，当然该改的改，需要加的咱就加啊，并且这也不难。

 

过了两周，第一版本的修改和新增的功能都写好交付给客户用。客户用了直夸我们技术人员厉害，这么快就修改好还把新功能加上了。不过有点问题是，这系统是桌面系统，我是希望系统的查询结果也能展示在网页上。

 

嗯……项目范围变了，并且是需要B/S系统，需要添加人手，毕竟之前的程序员主要是做AE开发，现在做B/S，需要专门做ArcGIS Server开发的人员参与进来，原来一个桌面系统现在也变成C/S+B/S架构。哎， 50万这样肯定没得赚了，不过毕竟是关系客户，别赔太多还是能接受的。现在开发团队变成2个做C/S,22个做B/S，另外算上产品经理、项目经理、售前三个人，现在整个项目组投入人力7个。

 

六周过去了，一个基于混合框架的多层系统的一版交付出来，客户非常满意。又经过2次迭代，一个四周又过去了。如大家所料，需求又变了。

 

客户说现在都是移动互联网，没有移动端怎么能行呢？客户现在是希望拿着ipad平板随时随地随手查。安卓还好说，我们有技术人员储备，单位搞IOS的人本来就不多，并且都被其他项目占着，只有一个新手可用，怎么办？能怎么办，客户的需求咱们得适应啊，并且客户一直在催催催，新手也只好硬着头皮上了。然后又是八周的快速迭代。

 

最后终于交付出去了，整个项目组成员都垂头丧气。可不是嘛，我们有平台软件，从最后交付的产品来看，做这种定制的系统一般投入人力通常都是10个人月，合同额200万上下；这个项目是个拉关系的项目，本身没赚多少钱，加上之后范围的膨胀，最后支出合计超过80万，不但占了十几个人月的人力资源，而且还赔了30万，损失惨重，这个项目无疑也是失败的。

 

钱是赔进去了，我们也的确宠坏了客户，那么以后如何避免呢？首先是不管上不上敏捷，一定要给项目定边界，哪怕是一个较为笼统的边界，但这个基线必需要有；其次是就算做敏捷也要把需求落实在文档上并让客户签字，如果被客户的需求变更牵着鼻子走，项目建设会很被动；虽然我们提倡拥抱变化，但变化也是有条件的，只允许在一个大范围内变，而不是客户让我们干什么就去干什么，导致项目边界膨胀剧烈的变更一定是要尽可能规避的。当然，沟通过程也需要掌握一定的技巧，项目成功的标志是项目主要干系人满意，我们不要把自己给忘了，所有的沟通也都是围绕让我们自己满意开展的。

 

作者：忆辛，写于羊城，于2014年12月1日 15点16分发表在ITeye网站，任何单位和个人未经作者书面许可，禁止转载、复制本文全文或文章的任何部分。

 

评论

14 楼 windshome 2014-12-22  

两个极端都是错误的：

一是强顶，什么合同上怎么写的啦，什么需求客户签了字啦，不能再变啦，都没有用，需求变得太快本身就是你们要认真仔细分析用户的需求，是开发团队或者售前的错误，不是用户的错误。

没有时间和安排认真分析用户需求是敏捷开发的最大弊病。没有时间和安排作出充满弹性的架构设计时敏捷开发实施时的最大缺憾。一个系统，最本质的难度是搞清楚需求，最大的风险在于设计，而现在的项目、产品最大的事情是实现，问题多多难以避免。


二是客户什么都答应。不管什么敏捷不敏捷，项目要成功，客户与开发团队，销售、售前、设计、开发、测试还有领导，一定是愉快的合作，而愉快就表示多方之间一定要有节制，需要有技巧的告诉相关方，你的建议和要求很好，但是我们本期没法包含这个功能。如果抢死把活都做上，可能影响其他部分的质量，出了事情大家都不好交差。其实，我十年的经验来看，客户大多数也比较理性，如果系统老是出问题，他们下面做事的人也很烦恼。

能否像楼上那位老兄说得，一个电话，一个饭局搞定，得看事情不同而定，但是
一定不能把这个事情烂在开发团队内，得让相关环节去想办法，例如让领导、售前、客户大家一起努力。

其实，严谨的敏捷方式和积极拥抱变化的传统开发方式，都非常好。但是前提是愉快的合作代替争执、压力、冲突。这包括开发团队内部以及开发团队和周边环境之间。

13 楼 james_lover 2014-12-19  

syyixin 写道

我们经常遇到强势的甲方，这些客户比较特殊，一次弄尴尬或者关系弄僵企业的生命周期里面很难再有机会接到类似项目了，面对这种客户时比较难处理。

这一点一点也不用纠结，双方关系关键在于双方决策层的关系，甲方一个小职员（甚至中层小领导）的小需求满足不了，不会影响大局。一般情况下，非核心需求，都是甲乙双方的基层人员在纠结，尤其是UI，交互，性能以及实现方式。
因为大家都会过分考虑上级的想法，领导要个5，基层会照着10去做。
这些纠结的地方上升以后，也就是一个电话，饭桌上一句话的事。
决定不了的事，及时提给上级就行了。

12 楼 syyixin 2014-12-19  

我们经常遇到强势的甲方，这些客户比较特殊，一次弄尴尬或者关系弄僵企业的生命周期里面很难再有机会接到类似项目了，面对这种客户时比较难处理。

11 楼 windshome 2014-12-19  

我有一个不同的见解：

产品的开发应该是以我为主导的，关键是在“拥抱变化”时，我想怎么变化，而不是客户要求怎么变化，市场要求怎么变化。

项目的开发中，直白的说，是项目结果（钱）让我们怎么变化我们就怎么变化，而不是客户让我们怎么样。

10 楼 syyixin 2014-12-19  

7、8、9楼都切中要害；PM肯定是失职了的，一味的妥协让项目范围急剧膨胀，而时间、人力等各种资源成本是与之正相关的。
确实如7楼所说，好，我有点小需求变更反正你都会给我改，慢慢的变成习惯性索取，这也是我所说的把客户惯坏了。
因为盲目相信敏捷，造成8楼所说的结果，没搞变更管理，只是固执地认为用户参与进来了，那么用户的需求我们要拥抱，给用户解决这些问题是我们迭代的目的，于是太空版出来了。
其实这个失败的案例主要是希望能启发PM进行一些思考，也就是9楼说的找一个平衡，利益干系人的利益平衡。平时用传统方法开发软件，我总是画个鸭蛋拿鸭蛋的钱给客户交付一个鹅蛋，甲乙双方均满意；而这个案例里成了客户要一个鸡蛋，而你果真准备交付个鸡蛋然后拿了鸡蛋的钱，因为各种因素影响，最后交付出去一个鹅蛋；当然有的项目也会存在拿了鹅蛋的钱给客户一个鸭蛋甚至鸡蛋的。这是一个学问，需要去不断实践，最后找到一个主要干系人均满意的一个平衡点。

9 楼 james_lover 2014-12-18  

这个话题真不错。
传统软件外包敏捷与成本怎么平衡。
但是话说回来。
敏捷本就不是解决成本问题的，甚至会牺牲效率（增加成本）。
博主的例子里就大的问题是没有项目范围。
一般需求都分为功能需求 、 优化需求（这是个大框，交互，UI，性能等）。
功能需求通常很好界定，多少个功能，收多少钱。
优化需求很难，比如UI做成什么程度才能验收。
比较简单的办法是，合同按不同需求 不同定价规则。
功能需求按功能点收。
优化需求按实际开发工作量收。

8 楼 abingpow 2014-12-18  

需求改进是合理的。但毫无控制的变更是项目陷入混乱、不能按进度完成、或软件质量无法保证的主要原因之一。如果不控制范围的扩展，每个建议都采用，项目可能永远完不成。

这是摘自需求管理的一段话，项目做到这种程度完全是项目负责人的问题好吧，一个C/S项目居然能免费扩展出B/S和IOS，人家说宇航员也需要用这个软件，你是不是还要做个太空版？

7 楼 flex_莫冲 2014-12-18  

沒有原則的妥協讓步，不會帶來關係的改善，免費的午餐沒有人會珍惜，反而覺得是理所當然的。這種讓步對該客戶的其他後續項目反而會造成不良的後果，讓客戶習慣性的索取更多。確定需求邊界是PM的基本職責。這種處理方式對團隊的培養也是不利的。

6 楼 syyixin 2014-12-18  

flex_莫冲 写道

這種PM早該拉出去槍斃了

那到不至于，项目流产、失败毕竟很常见。项目流产、失败的原因不是唯一的，PM对项目控制力的丧失有时候是被迫的，比如甲方非常强势……或者本文中所说的拉关系项目。但无论如何，项目走到这种地步，PM确实负有很大责任。敏捷所提倡的一些东西很多是彼此矛盾的，没处理好会导致灾难性影响。不是批敏捷不好，是要谨慎是用。

5 楼 flex_莫冲 2014-12-18  

這種PM早該拉出去槍斃了

4 楼 syyixin 2014-12-18  

ykssky 写道

经是好经, 歪嘴和尚给念歪了, 关经神马事...

嗯，经是好经，但要谨防歪嘴和尚给念歪；

3 楼 ykssky 2014-12-17  

经是好经, 歪嘴和尚给念歪了, 关经神马事...

2 楼 syyixin 2014-12-17  

cs6641468 写道

客户要的是结果，他们才不会关心你们怎么开发，敏捷也只是一种开发的流程，而不是让客户感觉你们活力四射，反应灵敏，要啥啥都做。
需求边界都没有定好，是PM过失，任何开发方式碰到这种情况，后期都会悲催，这跟敏捷已经没关系了。

很赞同，不过敏捷的一些宣言也确实更宠着用户，搞得自己很被动，轻则少赚，重则项目流产。

1 楼 cs6641468 2014-12-17  

客户要的是结果，他们才不会关心你们怎么开发，敏捷也只是一种开发的流程，而不是让客户感觉你们活力四射，反应灵敏，要啥啥都做。
需求边界都没有定好，是PM过失，任何开发方式碰到这种情况，后期都会悲催，这跟敏捷已经没关系了。