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

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

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

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

问题

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

方案

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

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

方案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年就能搭建一个他也梦想过的产品，他就能下决心了。

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