项目型公司的价值链（1）

--技术管理的核心：复用

企业的价值就是利润，而利润等于收入-支出。很简单的道理，但很多公司都没有做到把结果变成一个正值，更何况持续的变成正值。

典型的项目性公司一般有很多个项目，每个项目面对的是单独的客户，提供一对一的服务，在用户满意度上，能够做到很好，但自己的利润，就不好说了。

项目型公司的核心价值链可以聚焦为以下几个方面的管理：

1、市场管理

2、人力资源管理；

3、技术管理；

4、项目群管理；

以上几个方面，核心价值还是复用，项目型公司核心问题的解决，要时刻围绕着复用这个核心价值进行。

技术复用可以分为以下几个层次：

第一、（领域）知识，经验方面的成果；

第二、代码的复用；

第三、公司层面抽象出来的框架、组件、函数库；

第四、项目应用程序；（类似于直接买产品了）

项目应用程序层级的复用

要达到这个层面的复用，实际上相当于产品级的复用，即一个项目实施完成后，成果（主要是系统软件成果）直接应用于另外一个项目，基本上不需要改动或很少改动。

这个是所有做项目人的理想。但是很难达到，因为第一，我们的销售人员在进行市场销售的时候，没有针对性的把同类用户作为销售的重点，或者作为重点了，单子谈下来，和开始的完全不同。第二个原因是中国的用户特点，南方的讲求实用，北方的讲求特点。总是个性化要求很多，最后项目实施下来，用户满意度上来了，结果却完全不一样了。

我在项目实施过程中，只遇到了几次这样的情况，属于做了较少改动就复用到另外一个项目了。

优点：最大程度的复用；最大化的产值成本比；非常短的工期；获得较好的客户满意度；

缺点：对销售人员要求很高；对项目实施人员要求很高；要求客户成熟；要求具有很好的客户关系；对项目成果的产品化要去很高；

公司层面抽象的框架、组件或者函数库

一般的项目型公司，也不是什么类型项目都做，大概也会有一个或者几个面向的行业领域，所以，为了降低对复用性高的共用内容的开发，一般都要把这些内容抽象成为框架、组件、函数库或者包括这些内容的平台。

各项目的开发工作基于平台完成，各项目在平台的基础上完成项目开发工作，其中平台提供了统一的框架接口，为项目完成个性化的需求开发提供规范。同时，基于紧内聚，松耦合的各种组件，为项目提供共性内容的解决方案。

框架是提供了一组通用层次的集成机制和使用策略，向项目实施的开发人员提供基本的开发规范，这些开发规范以框架接口的方式定义下来。

开发为组件的共性的需求分成两个层面，第一个层面是系统管理维护，提供统一的技术架构等层面；第二个是业务领域的共性的需求。前面的一个通过统一的平台可以获得很好的解决，后面的内容需要最行业领域具有和很好的理解才能抽象出共性的内容，在实现这些共性内容是，要遵循平台框架的统一接口以便于进行集成，同时也要参考紧内聚和松耦合的原则拆分成组件，在实现内部在进行分层以应对复用的变化要求。

实际上，在这个共性业务需求复用的层级上，需要从横向的组件和纵向的分层分别进行考虑，以获得最好的复用性。注意在这些组件的开发上，使用各种设计模式以获得更好的复用度。

对于个性化的需求，通过分析设计之后，遵循平台提供的统一接口进行开发实现。注意这些内容的实现，仅仅是为了项目的目标，需要对开发过程进行控制，对于复用度，可维护性，对以前成果的参考和对平台中组件和函数库的复用都要进行控制。

这些平台包括的框架、组件和函数库应该采取公司统一研发的模式，有专门的队伍进行维护，并且要建立和市场，销售，项目实施等各单元的互动，而不是闭门造车。在平台成果形成后，对成果进行推广和应用是平台开发团队需要特别注意的事情。平台必须要具有生命力，这些生命力就来自于这个良好的互动。可维护性、扩展性、安全、性能等方面，首先来自于项目组的使用反馈，平台（产品）一旦形成，必须要保持持续的改进！

公司在进行项目实施，要有一些强制的手段作为保障，要求所有的项目必须要在平台上完成项目的实施，否则就要有公司的PMO或者TMO完成对项目技术的审核，另选技术路线。

优点：分层的复用级别；逐渐共性层次的复用，与企业的发展和管理水平相适应；专门的队伍对成果进行升级维护；

缺点：技术队伍容易陷入闭门造车；需求不容易从其他部门传递过来；当平台涵盖内容越多，对设计能力要求越高；对架构设计能力要求高；要求项目实施人员必须严格按照平台接口进行开发实现；

模块级和代码级的复用

之所以说模块而不是组件，就是因为这里定义的模块是项目成果。而组件是平台成果。

对于模块级和代码级的复用，在一定程度上要进行控制。从过程上来讲，有两个方面会导致复用后反而不如新开发。一个是实际的代码成果并不好，表面上看上去是满足的同样的需求，但实际上代码包含的细节太多，在界面风格，交互，内部逻辑以至于是否是同一平台接口开发出来的，稳定性，质量到底如何，需要仔细的评估，可能在设计的时候在扩展性上，两个同样的需求代码的适应性和扩展性在不同的地方，因此在满足未来扩展要求的时候，代码会变成鸡肋最终变成拖累。第二是这样的成果一般对人的依赖比较大。开发出来的代码，混入了很多人的思维，多大程度上的复用度也取决于多大程度的规范遵从度。往往要复用这样的成果，一般都要求人也一起过到相应的项目组，就比较麻烦。

因此，当不是代码和人同时被复用的时候，尽量避免这样的情况发生，是明智的项目经理和公司经营该采取的行动。

优点：成果容易获得，针对性强；

缺点：复用度取决于需求的匹配度和实现的匹配度；需要成果和人一起复用；

（行业领域）知识，经验方面的复用

思想的成果若没有被标准化和结构化，形式和结果是差别巨大的。就像每个人都读书，到底能收获多少呢？

而往往行业领域知识和经验复用的时候，表达他们的是文档成果。这些文档成果到底在多大程度上将承载的知识复用给读他的人，这个是千差万别的。当你不懂的时候，读它可能还是不懂；当你懂的时候，读它有什么用呢。最重要的，别误导了后来人呢。

因此，对于这个方面，个人认为重要的不是成果，而是过程。在团队的组件、机制、人员配备和项目实施过程中，有组织的将这些行业领域知识和经验，通过老带新，通过培训，通过实践将这些知识传递下来，而不仅仅是积累成文档成果。

经验永远是属于某些人的，无论他是否能够形成有形的文字或者其他形式。

仅仅建立知识库是不够的，还要建立知识的传递路径，建立相关的保障体系，保障知识有效的在公司内部传递才是知识和经验复用最核心的问题解决之道。

优缺点：当公司没有发展到一定阶段的时候，要尽量避免。

后记

需要特别说明的是，我所知道的很多公司，没有注意到这些复用层次的区别，而将精力错误的放在了后面两个层面的复用。对知识、经验的复用过分的强调成果，实际上成果是没有太多作用的。对于模块级和代码级的成果，注重在这个层面的复用属于聚焦错误，应该以对人员的能力建设代替对这个层级的复用。在这两个层面上，往往是吃力不讨好，花费了很大的精力，却没有取得很好的成果。

这里没有涉及到团队和管理体系的问题。后续在进行思考。

而复用的核心，就是领域模型。