长期受制于强势客户怎么办？[20120525]

文章来源地址：http://blog.csdn.net/cheny_com/article/details/7559913

这是敏捷开发一千零一问系列的第十七篇。（在这里提问，之一，之二，之三，问题总目录）

这个是在一次面向电信行业供应商的公开课上提出的问题，被评为本场最佳问题。

对于这类“供应商”而言，一方面业务根深蒂固，一般固化在某些专有领域因此很有必要产品化；另一方面又受制于客户总是来回改动，很难有自己的自主权。两者的矛盾，可以通过逐步推广敏捷开发而解开，也需要大量的周边技术、管理、市场手段来辅助。

甚至应该反过来说，敏捷开发知识辅助这些技术、管理、市场手段的执行。

问题

长期受制于强势客户怎么办？

方案

多数情况下，受制于客户会导致开发活动长期以“无法复用的项目”存在，而不是以“一本万利的产品”存在。所以本文会更多地说说项目开发，而非产品研发，但会循着项目产品化的道路走，因为这个几乎是项目型公司的“只此一条”的出路。

老规矩，前面的方案最简单，几乎立刻就可以开始执行；而后面的方案才是终极之道，虽然很难。

方案1：从技术上把项目产品化

产品化是个大话题，投入和风险都很大，没有老板拍板，不是谁想做谁就能做的。
方案1说的“从技术上”，就是连技术人员都能做主，不用问老板“我们要产品化吗”。具体手段，就是把项目中可复用的部分，抽出来做成可复用组件使用。
很多人认为“做产品可以谈复用，但做项目很难，因为每个项目都不一样”，其实不然。在产品开发中，由于所有功能都只会做一次，其实很难在高层次上做复用；反而是项目，倒有可能在多个客户处做很多相似的乃至相同的功能，更应该复用一下。

如果一个项目只会在一个客户那卖出一次……说实话，公司正面临险境，不是任何方法能轻易解救的。
复用分为多个层次，为了更生动一点，这里大致说一下《火星人》中的复用层次，基本上由浅入深。

1.1 纯技术层次，大约1000行代码
1.1.1 MFCUI（Martian Foundation Class UI），处理Web上常见的图片、链接、图片链接、Ajax调用、弹出菜单等内容。
1.1.2 MFCRepository/MFCCaches，增加任何表后，只需1行代码，就能处理数据库表的增、删、改、查和表级别的缓存；缓存会自动和数据库同步。
1.1.3 ……
1.2 准业务模型层面，大约3000行代码
1.2.1 Items库，用于处理任何以父子关联层次存在的数据（产品线-产品-版本-发布，公司-部门-团队-小组，子系统-模块-业务数据-业务操作-增强，任何目录……的底层都是它，大约有10种树状数据）
1.2.2 UDC库（User Defined Column），不用编写任何代码，就能为任何Item增加自定义字段（大约有10种数据类型，各自的显示和编辑界面也都是预置好的）。
1.2.3 ……
1.3 通用业务层面，大约3000行代码（方案2中详解）
1.3.1 MFC范围内的，用于处理用户，角色，权限，分配任务、工作量，日历，团队，个人中心，通知……这些任何产品都需要的功能。
1.3.2 DLC范围（Downloadrable Content可下载内容）的，处理插件类内容。
1.3.3 ……
1.4 专用业务层面，大约1000行
1.4.1 处理用户故事、迭代、意向表、产品这些只有敏捷开发才具备的业务。

实际统计数据中，整个火星人有89%的代码处于可复用库范围内，剩下的才是只能用在我们看到的“敏捷开发管理工具”中的代码。
这样做的好处也是显而易见的，尽管这么多库只在“1000”行业务代码中被“复用”过，但火星人的代码效率还是达到了业界的3倍左右（注：业界每功能点对应50～75行C#代码，火星人是20行不到），生产效率大约是业界的2～3倍（注：业界生产400功能点大约需要500人天，火星人是200不到）。随着日后业务增加，复用次数增加，这一差距还会继续扩大。
所以如果是人年级别以上的项目，抛开是否“产品化”不谈，仅仅是复用就能产生巨大的收益。
复用库可以很快搭建下一个项目，而无需一切从头开始，可以认为是一个“非官方产品”。
这个方案，在本质上是有风险要平衡的，因为“可复用”库的成本很高，远远高于一次性使用的代码，所以我自己有个习惯：第一次使用的代码最多只封装到函数级别，能支撑第一次能“干净地”使用即可，绝不多考虑日后的参数是否会多样化，是否会增加方法之类的；之后用到第二次再说。

方案2：提炼半成品

即使完全被客户牵着鼻子走，也会发现尽管每个项目的主要业务不同，但某些功能仍然可以被大块地、完整地封装起来，比如前面提到的1.3通用业务层面，也就是：

1.3 通用业务层面，包括模型和界面，大约3000行代码（方案2中详解）
1.3.1 MFC范围内的，用于处理用户，角色，权限，分配任务、工作量，日历，团队，个人中心，通知……这些任何产品都需要的功能。
1.3.2 DLC范围（Downloadrable Content可下载内容）的，处理插件类内容。
1.3.3 ……

如果把火星人中敏捷开发的那1000行代码删除，一个用户仍然可以登录、加入部门或团队、查看自己的工作空间、分配任务（虽然无任务可分）等，俨然是一个通用的原型。
其实，在游戏界这已经不是新技术了，多数大型的游戏公司都发现游戏里边的登录、人物、商店、买卖、帮会、服装……之类的系统都大同小异，因此早就开始搭建自己的半成品了。其中有一家公司做得“太好了”，以至于有些玩家批评他们几个游戏“看上去差不多”。
另外一家公司也在搭建他们的半成品游戏，目的以便缩短新游戏的开发周期，让他们一上来就能开发核心玩法，而不是从头开始。

分析：再谈共振（一）

很多程序员都梦想有一天老板一声令下，大家2年不卖东西，埋头开发一个自己心仪的产品，两年之后石破天惊，一家所向披靡的产品公司出现了。可惜，老板没眼光，所以你看，我现在还在这里接客户的一个一个电话改代码呢……
可复用库和产品化是一个思路的两个层面，如果一个人平时都不积累可复用的东西，却天天嚷嚷产品化，就是做白日梦。
因此，应该在自己能控制的范围内，先做好产品化的准备，如果准备充足了，老板发现用可复用库3个月后而不是2年就能搭建一个他也梦想过的产品，他就能下决心了。

本文所说的技术方法在一定程度上可以缓解变化的问题了，但是于下一篇提到的业务方法相比，就差得远了。

 

这是敏捷开发一千零一问系列的第十七篇。（在这里提问，之一，之二，之三，问题总目录）

方案3：培养产品经理，想到客户前面

被客户牵着鼻子走本来不是坏事，还少了做需求分析的工作，但关键是客户一会牵着向东，一会牵着向西，好像自己也没有主张的样子，这就令开发团队郁闷了。
这时候，无论是不是产品化了，都应该培养一个人，看到客户前面去，看他自己是不是都迷路了。
客户“迷路”大体有两种情况，一种是有路但自己不知道。
曾经去过一家银行的研发中心做咨询，开发人员访谈时抱怨业务部门每个月都只扔一点点需求过来，大家就像玩拼图游戏一样猜测业务的整体，经常中间变化猝不及防；而业务部门则抱怨研发中心只关心需求不关心业务，“对整个业务缺少全面了解”。听到这里，连和我们一起参加访谈的质量管理部的人员都笑了。后来才知道，有个“战略规划部”其实每年都会做2次业务布局，只是他们的布局在业务部门被分解为需求，而最后拿着详细需求去找开发的业务接口人，并没有传达整个业务布局。
如果我们作为乙方被这样的甲方牵着乱走，建议问问他们是否有一个“一年规划”或“半年规划”之类的东西。其实，答案是一定有的，政府、银行、电信是最喜欢做计划的了，而且还很喜欢按计划办事。
另外一种是客户真的迷路了。
以前只有做互联网、游戏的新潮公司才会迷路，现在政府、银行、电信也开始迷路了。因为政府开始上微博了，银行得这个月卖黄金下个月卖白银了，电信套餐也是一个推出好几种了。这时候，就需要有个产品经理，能想到客户前面，知道，或哪怕是差不多知道客户业务潜在的动向。
“找到或培养合格的产品经理很难”，但是比“在没有产品经理的时候把企业做好”还是容易多了，所以值得一试。

方案4：培养产品总监，做好客户定位

比被一个客户牵着鼻子走东走西更不幸的，是被两个客户一个牵着鼻子向东，另一个拽着耳朵向西。
小公司在创业之初，难免地什么赚钱做什么，有多又少都想干，结果是长期饿不死也吃不饱。要想突破这一点，就应该去钻研一个方向的业务，达到在此处独树一帜的状态。负责把握这个方向的人，就是产品总监。
产品总监的工作主要包括：细分客户群，预测主营行业的客户动向，分析这一方向上市场中存在的竞争对手，设计竞争策略，设计产品路线图……这种基于众多客户进行分析的结果，使得产品总监能够比单一客户更能了解他们需要什么产品。
这一点做得比较好的是IBM，他们在金融领域基本上做到了能引导客户的状态——千万不要想：“他们可是IBM啊，我们公司还小”——不要这样想，这是因果倒置的分析结果。这家“国际商用机器公司”最早的产品好象是家用烤面包机，他们不是生下来就控制了金融业市场的；相反，正是他们主攻这个领域并做到了前面所说的引导客户的能力，才控制了金融业市场。

方案5：共同创业，共同运营

一般在项目型公司里边，都会认为有这么一个串行关系：乙方-甲方-甲方的服务对象，比如软件公司-地铁公司-乘客，或者电信集成商-电信运营商-用户，这种关系导致我们见不到最终系统的使用者，造成两个方面我们都要被甲方牵着鼻子走。
一个方面是由于我们只能通过甲方才能赚钱，所以市场上弱势；其次由于我们只能通过甲方才能了解最终客户的想法，业务或技术上都落后。有两种方法解决了这个问题。
共同创业是互联网行业的做法，说的是甲方不再雇佣乙方，也不直接收购乙方，而是通过投资或投入现成的资源，发挥乙方的创新性和甲方的资源优势。盛大18计划、巨人赢在巨人计划，都是这类；之后阿里软件、腾讯开放平台、百度应用、新浪应用，也都在做这件事情；苹果和Android市场也是。
互联网行业共同创业的结果是，甲方把产品的决策权下放给乙方，而乙方则要承担相应的风险。像苹果有59万个应用之多，如果苹果把需求定下来，然后要求供应商开发，且不说要多少钱才能够用，单说苹果有没有人能定义这些应用都很难。
不要认为这是互联网界的新鲜事，其实在传统行业这种事情也已经开始了，那就是共同运营。
早在04年去一家电信供应商公司工作的时候，他们的财务总监就提到一件事情：“数年前我们为Tom.com制造了一套“网络发短信”的软件，卖了500万；而现在（04年），Tom每个月就能用它赚1000万纯利。早知道这样，当年送给他们，然后联合运营……”
这件事情果然后来逐渐发生了，就是高版本的SaaS模式。一个突出的典型是神州数码。他们从原来简单地制造软硬件并进行销售，转变为帮助政府运营整个城市；这种运营不是原来那种“维护”，而是真的运营，然后向政府上缴利润；由于在运营过程中能充分接触最终客户，就能不断提升自己对业务的理解水平；而这种理解水平不断积累后产生出来的产品，就会逐渐超过下一个城市的政府从头思考的水平，就开始反过来引导客户。

“不可能的，我们的客户很强势的，他们不要最好的，只要他们想做的。”这句话本身没错，但脑子里只想着这句话的人或公司，没有未来。要盯着那些可能的事情做，才有未来。
本人99年就开始做自己的网站，和其他人一样使用FrontPage，制作完全与众不同的网站，然后发布到网站上，很像自己给自己做项目；但现在，再也没有人这么做了，大家开始使用WordPress、DotNetNuke制作“与众相同”的网站，很像直接购买一款产品。
产品化的积累，造成其技术水平和业务水平远远超过个性化的项目开发，刚开始可能不明显，但逐渐地信仰项目开发的甲方会发现自己的选择是愚蠢的，花了很大资金和精力打造的项目，功能完全比不上成型的产品，就不提中间潜在的工期之类的风险了。
用友、金蝶这类传统软件公司，最初也都是做项目出身的，但最后都走上了产品化道路，变成了强势的产品公司，再也不提本文标题的问题了。这种选择不是一两家公司的选择，而是整个行业的选择，那些当年惦记着“不可能”的公司，也就逐渐消失了。

分析：再谈共振（二）

失败者都认为要先控制行业，才能有实力引导客户；而成功者认为先要引导客户，才能有实力控制行业，两者造成了最终结果的差异。
而实际上，既没有人能上来就控制行业，也没有人能上来就引导客户，两者都需要逐渐共振。
“那我这种情况下……具体怎么做呢？”
本人在自己的行业里边工作了17年，其中有4年是与当前做的事情直接相关的，年年想天天想，1年前才刚刚共振出自己要做的事情“具体怎么做”。
所以不要相信有一个现成的答案存在，也不要认为没有答案，而是要相信只有自己才能创造答案。只要盯着“可能行”而非“不可能性”，再用共振的方法，几乎任何人都能找到点答案。

 

 

你发现被客户牵着鼻子走是因为你们做的产品没有切中客户的要害，你们是否认真分析过客户内心深处到底想要什么，电信客户本身的服务就在不停的变化，你们了解过电信客户的服务策略最近几年有什么变化了么？你们做的产品怎么能满足客户的要求呢？举个例子：3年前电信运营商的市场经理的A，A的策略的多发展客户来增加收入，如提供丰富的产品套餐，提供更高的补贴回馈来发展客户，今年电信运营商的市场经理换人了，换成B了，而B的策略变化了，他强调要用优质的服务，深层的管理来节约成本。这样的变化就是A打算用开源的方式来增收，B用节流的方式来增收。那么你们的产品在这方面是否有对应的变化，还是说一成不变的维持原样。A领导只想看看今天我们又发展了多少大客户，能为公司增加多少收入，而B领导很想看看我们今天花了多少钱，有多少钱可以通过管理变更后节约下来。我们只要做出来的软件能满足客户的不同需求就行了，客户提需求我们做，这种模式有个风险就是你能做这个，别人也能做出来，你依然没有优势。
最后，能否在需求分析方面更前进一步，提前敏锐的感知客户将来的需求变化？因为很多客户对自己将来的需求也没有具体想法，需要了就会提出来，那我们能不能引导客户的需求，在客户还没有提出之前就已经能提出来和客户讨论，主动帮助客户建立清晰的需求。这样的话相比其他供应商我们就有很大的优势了。

 

开发团队有两个特性一旦同时具备，就完蛋了。
一个是懒，就是不想去探究远景的发展，就想等客户说出来。
一个是怨，就是客户说出来了，又埋怨总是变。