软件项目产品化之路.pdf

1、 软件项目产品化之路 作者：阎伟 日期 2008-10-28 软件项目产品化之路 目 录 1. 前言. 5 2. 产品化之路. 6 2.1. 困惑. 6 2.2. 光明之路还是不归之路？. 6 2.3. 光明之路也是荆棘之路 7 3. 软件产品化解决之道 8 3.1. 企业经营. 8 3.1.1. 有所为有所不为. 8 3.1.2. 市场可行性分析. 8 3.2. 企业管理. 9 3.2.1. 组织结构变革 9 3.2.1.1. 由销售为中心转化为以市场为中心9 3.2.1.2. 技术部门的细分和演进 10 3.2.2. 项目和产品之间的关系.10 3.2.2.1. 开发过程中的项目目标与产品

2、目标 10 3.2.2.2. 辩证处理项目与产品的关系 11 3.2.3. 对人员的激励和考核.11 3.3. 软件技术12 3.3.1. 软件技术方案与框架.12 3.3.1.1. 稳定技术方案和框架 12 3.3.1.2. 技术方案和框架的演进 13 3.3.1.3. 技术方案和框架的常见误区 13 3.3.1.4. 技术传播和转化 14 3.3.2. 行业领域知识.15 3.3.2.1. 要比客户还要专业. 15 3.3.2.2. 要基于业务又要高于业务. 15 2/46 软件项目产品化之路 3.3.2.3. 要重视对领域知识的管理. 17 3.3.3. 软件开发过程.17 3.3.3.

3、1. 产品化开发过程 17 3.3.3.2. 软件开发过程选择. 19 3.3.4. 软件开发组织机构20 3.3.5. 软件生产工业化21 3.3.5.1. 传统工业化内容 22 3.3.5.2. 软件生产工业化 22 3.3.5.3. 实现软件生产的自动化 23 3.3.6. 软件产品质量.24 3.3.6.1. 客户全程参与 25 3.3.6.2. 人机交互体验 25 3.3.6.3. 业务场景模拟实验室 26 3.3.6.4. 自动化技术测试实验室 27 3.4. 软件人才27 3.4.1. 人才结构问题.27 3.4.2. 对关键人员的依赖问题.28 3.5. 本章小结29 4. 案

4、例分析30 4.1. 案例背景30 4.2. 企业经营与发展问题.31 4.2.1. 企业发展战略.31 4.2.2. 供应链管理系统32 4.2.3. 电子商务平台.33 4.2.4. 专业化物流软件34 4.2.5. 小结.35 4.3. 企业管理问题.36 4.3.1. 企业文化36 4.3.2. 组织结构问题.37 3/46 软件项目产品化之路 4.3.3. 业务发展37 4.3.4. 技术管理38 4.4. 软件技术38 4.4.1. 软件技术方案和框架.38 4.4.2. 行业领域知识.39 4.4.2.1. 领域知识的管理 39 4.4.2.2. 物流运营模型 40 4.4.3.

5、 软件研发管理实践41 4.4.3.1. 软件开发过程 41 4.4.3.2. 每日晨会制度 41 4.4.3.3. 产品进度公告板 41 4.4.3.4. 测试人员驱动开发. 42 4.4.3.5. 文档与代码. 42 4.4.4. 软件生产的工业化43 4.4.4.1. 模型驱动开发 43 4.4.4.2. 自动化生成技术 43 4.4.4.3. 可复用组件技术 43 4.4.5. 软件产品质量.44 4.4.5.1. 客户全程参与 44 4.4.5.2. 测试数据工厂 44 4.5. 软件人才44 4.5.1. 技术团队的建立44 4.5.2. 技术团队的培养45 4.5.3. 技术团队

6、的使用45 4.5.4. 技术团队的保留45 4.6. 小结46 4/46 软件项目产品化之路 1. 前言 本文阐述了软件项目产品化过程中所面临的困难和问题，对问题的根源进行了分析。在此基础上提出了软件产品化的解决之道，并针对某物流软件项目产品化的案例进行了具体分析。 在第2章对产品化道路中常见的问题进行了故事性描述。第3章对软件产品化解决之道进行了具体理论阐述，并围绕着企业经营、企业管理、软件技术、软件人才四个方面进行了详细讨论，以及对软件产品化的过程中存在的问题进行了系统化的分析。第4章选择了一个物流行业的具体软件产品化的案例，通过对案例的细致分析，对第3章的理论进行了具体解说。 本文适合

7、软件行业从业人员、IT企业中高层管理人员、IT行业研究人员、计算机专业学生阅读。本文涉及企业管理、IT技术、IT管理、市场营销、工程制造等多个领域方面的话题和知识，需要读者进一步去了解这些方面的知识。 本文所阐述的内容，都是作者多年的知识沉淀和工作经验积累，希望能给读者一定启示作用。由于本人知识、阅历和能力所限，所表达的观点和所涉及的知识领域如有错误，欢迎读者指正。 未经作者书面许可，任何人不得以任何形式复制、转载、散布、引用、变更、传播或出版该文章之全部或局部内容。 5/46 软件项目产品化之路 2. 产品化之路 2.1. 困惑 软件项目产品化是大量软件企业，特别是应用型软件研发企业所必须面

8、临的问题。不论是小型的软件公司和中大型的软件企业，在面对软件项目和软件产品，都有诸多困惑。到底是做项目还是做产品？ 2.2. 光明之路还是不归之路？ 在企业发展过程中，往往开始是项目驱动型，有一个好的项目，一个公司就这样发展起来了。有了这个项目做基础，公司自然会接到越来越多的项目。但当同类项目越接越多，人员队伍开始扩展，项目周期无法保证，产品质量问题、用户需求把握不准确等一系列问题都接踵而至。 这时候，企业开始考虑将项目进行整理和整合，进行产品化开发。这将是个十分痛苦的过程。因为一开始软件就没有按照产品的思路来设计，为了赶时间进度，满足客户的一些“独特的”个性化需求，代码的可维护性很差，文档基

9、本上没有，就算是有也是过时的。开发平台也是一个项目一个样，这个管理系统Java,那个是业务系统是VB.NET，门户网站是PHP，客户要求（没办法啊）。除了对原有代码推倒重来，基本上没有其他可行的道路。 历经几次痛苦的过程，产品终于相对成型了，整个技术构架和功能都相对于原有项目都有较大提高，开发语言和平台也基本统一，代码的质量相对从前有较大提高。但相关的问题又随即产生。 问题1（小型公司更为常见）：在产品销售和实施的过程中，客户的差异性很大，不论是技术方面还是业务方面都有很多个性化的需求。现有产品如果去满足客户的要求，改动成本相当大，很多模块的业务代码都要重新开发，部分需求，产品现有框架不能满足

10、；如果不改，现有产品又不能满足客户要求，将失去订单。怎么办？ 公司从业务考虑，往往是先把项目接下来再说。但难题就摆在研发人员面6/46 软件项目产品化之路 前。如果按照客户要求来做，基本上和做项目没啥区别；如果按照产品方式来做，在客户要求的时间要求上，基本上不可能。由于项目压力，只好先做出来再说。所谓产品化，只好先扔在一边。毕竟公司考核你的是能否完成客户的项目，大家的绩效奖金和此息息相关。阳春白雪（产品化）虽然好，但关系到切身利益，下里巴人（顾自己腰包）才是实实在在的。 问题2（中大型公司更为常见）：由于产品化往往是专门的部门来负责，产品的内部行销往往成为问题。具体项目开发部门和项目组，常反感

11、自己的项目成为产品的试验田，都不愿意做白老鼠，因此推行很困难。产品所涉及的基础技术框架，需要有较长的学习成本，培训、推广等都很花时间，大家手上项目都很忙，哪有时间来学这东西。另外，往往技术比较优秀的开发人员，个性都比较强，对别人做的东西，看不上眼，不买账，有抵制情绪。产品化在企业内部进行推广，步履维艰。 最终，产品化热闹了一阵以后，大家又恢复到项目方式，产品化，只剩下房间角落柜子中的一堆文件和光盘而已，公司为了眼前利益，对此也是睁着眼闭只眼，产品化也没有人提起了。 幸福的家庭往往都是相似的，不幸的家庭各有各的不幸。上面的这段情节，年复一年的在一家家软件公司中重演，演绎着各自的故事。 软件产品化

12、到底是光明之路还是条不归之路？ 2.3. 光明之路也是荆棘之路 软件项目产品化是企业发展到一定阶段，必然碰到的问题，这一问题不可能回避。由于软件需求的个性化差异，特别是应用型软件的研发，从本质上决定了软件产品化道路的困难性。因此，很多企业在面临业务迅速发展的情况下，项目化开发是问题多，产品化开发问题更多 产品化是软件企业在发展过程的必经之路。解决的好，公司业务就会上到一个新的台阶，解决不好，公司因此停滞，甚至倒下都是很有可能的。所以，产品化道路是条光明之路也是荆棘之路。 因此，如何解决项目软件产品化过程中存在的问题，找到一条通往成功的道路，是摆在所有软件公司面前的课题。 7/46 软件项目产品

13、化之路 3. 软件产品化解决之道 软件产品化所面临的困难和挑战，不仅仅是技术层面的问题，而是一个牵涉到企业整个发展过程各个方面的综合性问题。因此，解决软件的产品化，也不仅仅是从技术层面来解决这一问题，而是要从企业经营、企业管理、软件技术、软件人才四个方面综合性的进行分析和解决。 3.1. 企业经营 很多公司产品化失败，表象上是软件产品的质量和功能问题，其实究其根本性原因，往往是一开始就是错误的。项目开始起初，对项目所涉及到业务的发展没有进行过认真、科学的分析和论证，是导致后续苦果的始作俑者。 3.1.1. 有所为有所不为 在企业接到一个项目的时候，为了生存或为了利益，往往对项目没有选择性。有所

14、为有所不为，这句话说的容易，当面临生存压力或利益诱惑的时候，做起来却很难，特别是对于一些中小型企业和还在初创期的企业。 有所为有所不为，汝今能持否？ 不考虑自身的特长，自身的积累，只要是有项目就做，有钱就赚，这是很多公司，特别是创业之初的中小型公司所常犯下的错误。 因此，项目一开始，经营管理人员就要认清自我，能有做到有所为有所不为，才能为企业发展奠定良好基础。 3.1.2. 市场可行性分析 项目一旦成功，这时候企业所常常犯的第二个毛病往往就要出现了：头脑一热，在没有冷静分析的基础上，就一头扎进去。 软件产品化的第一个问题，不是如何进行产品化，而是是否需要产品化。 在进入该产品市场之前，必须认真

15、做好产品市场的可行性分析。在产品化8/46 软件项目产品化之路 之前，最好不要仅仅只根据一两个单个项目来下决定进入某个市场，而是要在进行这些项目的过程中，不断的进行产品的市场调查和分析，来论证产品化的可行性。 项目所涉及的目标市场是否有足够大，而有必要进行产品化？ 这个市场是处于怎样一个竞争情况？是现金牛，还是瘦狗？ 在这个市场是否有其他竞争对手，他们的实力如何？ 我们是否有进入这个产品细分市场的技术研发能力？ 因此，做好产品所涉及的市场可行性分析，扎实认真做好市场调研，科学严谨的进行市场分析，是软件产品化能顺利成功的前提保证。 3.2. 企业管理 项目软件产品化的过程，往往也是企业迅速发展的

16、时期，在这个过程中，如何有效的进行管理方法和手段的调整，解决企业由项目向产品转化过程中碰到的问题，对于能否顺利进行产品化，是重要的保障。 3.2.1. 组织结构变革 由于软件产品化的需要，原有的以项目为导向的企业组织结构往往不能适应这一变化，需要进行重新调整。在这一过程中，会碰到很多组织管理性的问题，需要经营管理者来调整和理顺。 3.2.1.1. 由销售为中心转化为以市场为中心 项目型的软件公司，是以项目为驱动的，所以在整个项目过程中，往往是以销售为中心的运作方式。在项目型软件公司，销售部门的话语权是最大的，因为他们是给公司创造利润的核心。而在软件产品化的过程中，企业会逐步从以销售为中心转化为

17、以市场为中心。这时候，市场部成为公司的核心部门，销售和技术等部门都要以产品为单元进行运作和管理。 因此，由销售为中心向以市场为核心的转变，是企业要过的第一关。这一9/46 软件项目产品化之路 关如果没过好，会对企业的经营产生重要影响，导致产品化的进程受阻甚至失败。 在这个转化的过程中，需要调整好销售、市场等其他部门之间的利益冲突，调整好人员的工作职责和重心，要转变原有的工作习惯和方式，这些都是在转化的过程中需要特别注意的。在这个转化的过程中，改变员工的思维方式和做事习惯是最难的，但也是最为重要的。 3.2.1.2. 技术部门的细分和演进 在软件产品化的过程中，技术部门为了适应产品化的要求，也存

18、在进一步细分和演化的需要。 原有的单一的研发部门往往不能同时满足项目开发和产品研发的双重需要，因此需要成立负责项目开发和产品研发的单独部门。 项目开发部门负责项目的具体开发和产品的实施过程，产品研发部门负责将在项目开发部门在开发过程中积累下来的软件资产进行产品化，并帮助和和指导产品在项目过程中的实施。 因此，项目开发部和产品研发部是相互协作，相互依存的，并不是割裂和独立的。在项目的实施和产品的研发活动中，都需要两个部门的协作，只是二者角色不同、职责不同。 在研发队伍的不断扩大的过程中，涉及到项目管理、质量控制与质量保障、基础技术与构架、项目维护和服务、组织过程改进等活动，都需要逐步成立专门的部

19、门进行专业化分工和管理。如何在产品化的同时，完善和提高公司技术管理水平，是摆在每个软件公司面前的课题。 3.2.2. 项目和产品之间的关系 3.2.2.1. 开发过程中的项目目标与产品目标 在项目软件产品化的过程中的开发活动，往往不是仅仅具有项目目标或产品目标，而是综合了项目目标和产品目标的。在项目软件产品化的过程中，这种双重目标性，将是软件开发活动的重要特征。根据具体开发任务的不同，10/46 软件项目产品化之路 可以分为以项目为重点和以产品为重点两种。 以项目为重点的开发，主要发生在外部项目中。重心是以按照项目时间、进度、成本完成项目。因此产品化的重点是产品在项目中的具体应用。在碰到产品不

20、能很快解决的问题的时候，往往不能等产品研究解决方案，而是需要先解决问题优先。 以产品为重心的开发，主要发生在内部产品开发中。这时候的重心是产品的功能、技术构架优化、新技术的引入，项目需求的融入等。在产品开发的过程中，对在项目开发过程中积累的产品的不足或新的需求，在产品开发的过程中，进行进一步的分析，选择有普遍性和创新性的需求，重点引入到产品功能中去。 因此，除了一些面对终端消费者的套装软件，可以采用纯产品的方式进行开发，绝大多数具有行业特点的产品软件，都需要在实际实施的过程中进行定制化开发，因此就形成了上述项目和产品双重目标的研发过程。 3.2.2.2. 辩证处理项目与产品的关系 产品化并不是

21、否定项目的价值和重要性，要看到其对立统一的辩证关系，处理好其相互转化和相互影响的过程。项目在积累到一定时间和数量后，会逐步向产品化进行过渡和转化，而产品在所服务的目标客户和市场发生变化时，也会按照项目的方式进行演进。 3.2.3. 对人员的激励和考核 原有以项目为导向的员工考核指标和激励办法，在进行产品化的过程中变得不能适应新的需求。因此，对销售人员、市场人员、技术研发人员的考核标准都要进行调整，以适应软件产品化的要求。 解决绩效考核和激励机制的问题，具有十分重要的意义。如果在这一点上没有解决好，产品化将是一句空话。当涉及到人的切身利益的时候，如果企业目标和个人利益发生冲突，不可否认的事实是，

22、绝大多数人都会选择后者。 由于产品相对于项目具有较长的生命周期，因此，在绩效考核和激励机制上，既要考虑到近期利益，也要考虑到远期影响。绩效考核指标要包含项目11/46 软件项目产品化之路 方面还要包含产品方面，绩效的兑现时间要分为项目结束后和结束后一段时间，包括项目完成情况和对产品化发展的贡献。 3.3. 软件技术 在软件产品化的过程中，软件技术水平的发展和提高是一个必然过程。由于软件以项目运作的方式所带来的技术问题，是产品化必须面对和解决的。 3.3.1. 软件技术方案与框架 由于项目型软件开发，开发语言和平台往往五花八门，开发人员在各个项目中疲于奔命。这个项目用C+，换到另外一个项目组用J

23、ava，同时进行的另一个项目用ASP.NET，这就是一些软件公司的真实写照。稍微好一点的公司，技术平台相对稳定，例如使用.net 或 java，但所谓的重用，就是把原有的项目代码拷贝过来，小的改动就修修改改，大的改动就干脆重写，根本上谈不上所谓的产品化。 上述情况，往往就是摆在我们面前的真实写照，是软件产品化必须面对和解决的问题。 3.3.1.1. 稳定技术方案和框架 产品化首要一点，就是要根据产品的特性，选择并建立一套相对稳定的技术方案和框架，并在后续产品研发和项目实施过程中不断演进。要注意到没有一套技术方案和框架能解决所有问题，要根据业务的不同和对技术的要求，选择适合的技术方案和框架。在选

24、择技术方案和框架时，要考虑其可扩展性，能应对不同层次和不同方面的应用要求。当公司扩展产品范围和业务方向时，要对新的产品方向进行系统化评估，以决定是否在现有框架上演进，还是建立新的技术框架和平台。 技术方案的发展，切忌不能受技术高层管理人员的变更带来的影响。不能来一个和尚，念一个经，这种调整，如果没有充分的理由，将是对企业的巨大伤害。 12/46 软件项目产品化之路 3.3.1.2. 技术方案和框架的演进 技术方案和框架并不是一成不变的，而是要在产品研发和项目实施的过程中，不断检验、不断改进、不断提高。 一套技术方案和框架往往在初期，可以适应项目的需要，但随着产品的发展，提出更高的性能要求，提出

25、更大的数据容量，提出更高的处理能力，提出更多的业务需求的时候，往往就不能满足项目要求了。这时候需要对技术方案和框架本身要进行发展和演进。 因此，技术方案和框架的演进，是和软件产品化过程交织在一起的迭代式演进过程，通过产品和项目的实践和反馈，不断提升技术方案和框架的技术能力与成熟度。 由于需要处理的业务问题和技术要求不同，因此存在多套技术方案和框架是很正常的。通过提供不同层次、不同方面的技术方案和框架，来灵活应对复杂多变的业务需求，才是软件产品化的正确道路。在这方面，汽车、通讯等行业有很多成熟的经验可供软件行业学习和借鉴。 3.3.1.3. 技术方案和框架的常见误区 一提到技术方案和框架的狂热，

26、莫过于Java语言的应用开发。不论是J2EE型的重量级解决方案，还是轻量级的SSH（Spring + Hibernate + Struts），好像一说技术方案和框架，无非就是这三板斧。难道技术方案真的就是这样的吗？ 技术方案和框架要解决的问题不是具体性业务问题，而是要解决一类通用性问题。因此，技术方案首先要对原有的一系列项目的业务进行分析，分析其共通性，要从具体业务现象中抽象出其本质活动，将需要解决的问题进行归类和抽象化。然后，在技术框架的基础上，对框架进行扩展和实现，既保证技术方案的可扩展性，又能满足实际应用开发过程中的个性化需要。 技术方案和框架既具有一定的业务独立性，又同时具有行业性特点

27、。只有真正能和行业特点相结合的技术方案和框架，才有真正的价值也意义。单纯技术层面的技术方案和框架，不是真正意义上的技术框架，而是技术方案和框架的实现方法和细节。 13/46 软件项目产品化之路 在这一方面，一个很好的一个例子，就是Eclipse平台。作为开源的IDE（集成开发环境）平台，类似于IBM、Borland、Adobe、Oracle、Bea等越来越多的开发工具厂商，抛弃原有私有的IDE，选择Eclipse作为其开发工具的平台就是最好的证明。Eclipse的众多开源项目，给开发IDE工具提供了良好基础支撑，而Eclipse 基于OSGI规范的插件化体系结构，也保证了其平台的开放性、可扩展

28、性和先进性。 图表 1 Eclipse OSGi Framework 1 3.3.1.4. 技术传播和转化 在从技术方案与框架到产品化软件再到具体项目实施，这个过程中涉及到技术知识的传播、学习和掌握、以及再反馈的过程。在一般较为正规的产品型软件公司，基础技术的研发、软件产品研发、软件项目实施往往是由不同部门负责，因此，如何有效的将技术、产品在实际项目中进行实施，是软件产品化的关键问题。 在这一技术传播和转化过程中，加强部门的沟通和协作十分重要。这一沟通，不仅仅是指已经做好的技术方案的推广、已经完成的产品的培训工作，而是指在技术方案与框架、软件产品的研制的整个生命周期内，都需要各个部门的参与，形

29、成跨部门的项目型小组进行运作。只有通过全过程的沟通和协作，才能最大程度上消除部门之间的隔阂，充分吸收各个部门的知识，发挥各个部门的特长，减少推行过程中的阻力，而形成一个良好的产品研发环1 图片来源于www.eclipse.org 网站 14/46 软件项目产品化之路 境，建立有效率的产品研发机制和流程。 3.3.2. 行业领域知识 在一个企业开始某个项目，往往是进入到一个新的行业或业务领域，在项目型软件开发过程中，往往是开发方一般没有这方面的专业领域知识，往往是跟着客户学，客户说啥就做啥。很多软件公司都存在忽视业务知识的积累的过程，做了很多项目，但行业专业知识仍然是非常薄弱，往往人员变动和流失

30、，这些知识就不知不觉的流失了，结果到头来，往往还是重新开始。 软件产品化的一个重要标准就是领域知识的积累和完善，这是软件产品化的重要步骤和关键要素。一个公司要想成功完成产品化转变，就要不但让自己成为技术专家，还要让自身成为行业专家。 3.3.2.1. 要比客户还要专业 真正优秀的行业性产品和解决方案提供商，例如IBM、Oracle、SAP、BPCS、Infor等厂商，不仅仅只是卖产品，而是通过自身的专业行业知识、帮助客户建立适合他自己的业务解决方案，这是软件产品化的更高阶段，是软件产品化成功的重要标志。 在上述成功企业当中，都有一支专业化的行业专家和业务顾问，帮助客户诊断自身企业问题，提出业务

31、流程改造方案，并结合IT技术进行实施，而到达企业信息化的目的。因此，软件产品化的一个重要措施，就是要培养和建立一支懂技术、懂业务的专家队伍，通过不断建立和完善这样一支队伍，真正成为行业性专家，做到比客户还要专业。当然，如果企业不具备建立这样一支行业专家队伍的条件，也可以考虑和一些行业咨询顾问公司进行合作，来弥补自身在业务知识领域的不足。 3.3.2.2. 要基于业务又要高于业务 做行业型产品应用，常常陷入的误区就是就项目而产品，没有跳出客户需求本身来思考问题，造成的结果就是所谓的产品是客户需求的超大合集，往往不成体系，并没有体现其产品的行业先进性。 15/46 软件项目产品化之路 因此，在做软

32、件产品化的过程中，必须跳出原有项目的视角和局限，站在行业的角度和思考，参考一些国际性规范和标准，并结合实际业务进行实践，这样才能开发出真正优秀和领先的产品化软件。 以电信行业为例，其IT系统的建设过程中，这一点是特别突出的。以电信的各类业务运营支撑系统为例，就有“电信管理论坛（TMForum）”提出的下一代运营软件和系统（Next Generation Operation Software and System，简称NGOSS）。 图表 2 NGOSS下一代运营软件和系统 2 下一代运营软件和系统（NGOSS）是TMF提出的新一代OSS体系。NGOSS从系统（即插即用规则）、过程（企业事务过程

33、模型）、信息（关联处理公用数据）、产品四个方面保证OSS体系具备标准化、能够逐步演化、保证互连互操作（开放）、实现端到端的管理和高度自动化的特点。NGOSS提出一系列的文档、信息模型和代码，分析研究企业核心业务流和信息技术，提出一套指导OSS建设的系统框架和设计即插即用的OSS组件方法，帮助开发商迅速开发支撑系统，满足电信运营商对OSS系统建设的需要，从而使OSS系统设计、开发从满足个别运营商的个体需求到分析电信运营商的整体需求的范围上来，2 图片来源于TM Forum网站 16/46 软件项目产品化之路 进一步使OSS系统的设计、开发进入到一个崭新时代。贴近运营商需求，使系统开发变得更迅速、

34、更灵活、成本更低是NGOSS的目标。3 由此可见，充分吸收行业先进知识和理念，对于项目软件产品化具有十分重要的意义。在具体吸收和借鉴的过程中，不要盲目崇拜，要认真分析和对待这些理念和标准，秉承拿来主义的思想，有选择的进行吸收。 3.3.2.3. 要重视对领域知识的管理 对于行业领域知识，一般的软件企业虽然口头重视，但往往没有有效的管理和积累，造成领域知识的混淆、残缺和流失。即使对行业领域知识做了比较好的整理，而软件研发人员对行业知识不感兴趣，只关心技术，了解业务知识，只是为了工作而已，使得领域知识的传播效果很差。 因此，做好对行业领域知识的管理，并建立一支懂技术、懂业务的技术团队，是软件产品化

35、的成功保障。 对于领域知识的积累和整理，需要有专人进行负责，对行业知识进行系统记录和整理。要建立长期培训和自我学习机制，请内部或外部的行业专家给研发人员进行培训，帮助研发人员系统化提高行业领域知识的水平。要鼓励和奖励知识分享，形成一个良好的学习和讨论氛围。 3.3.3. 软件开发过程 产品的生命周期往往要大于项目的生命周期，因此，对于产品化软件开发过程也不同于项目开发过程，需要对项目级别的软件开发过程进行修订和扩展，才能适应产品化软件开发的需要。 3.3.3.1. 产品化开发过程 纵观软件开发过程其发展历程，不论是早期的瀑布开发过程，到后来的V模型，增量与迭代式开发过程，统一过程（UP），直到

36、最新的强调敏捷思想的XP、Scrum、模型驱动开发（MDD）、测试驱动开发（TDD），都是围绕着3 本段引自中国通讯网NGOSS在业务支撑系统中的应用一文。 17/46 软件项目产品化之路 项目级别的软件开发过程，而关于如何进行产品化开发，几乎没有涉及，缺乏具体的方法和行动指南。 为了弥补软件开发过程在产品化开发方面的缺陷不不足，一些行业专业人士也提出了相应的过程和模型。这中间比较著名和有参考意义的有EUP（Enterprise Unified Process 企业统一过程）、 Zachman 框架等等。下面以EUP为例子做一个简单介绍。 Scott Ambler提出的 EUP在RUP的基础上

37、进行了扩展，对RUP的初始、细化、构造、交付四个阶段进行了增补，添加了产品化、退役阶段。对RUP的项目级别的活动进行了扩展，补充了项目级别和企业级别的活动。 项目级别的活动：运营与支持 企业级别的活动：企业业务建模、组合管理、企业架构、战略重用、人员管理、企业管理、软件流程改进 图表 3 EUP企业统一过程 4 EUP中所涉及到的软件过程与活动，对于将软件项目产品化是很有帮助和意义的，在软件产品化的过程中应该进行吸收和和借鉴。 当然EUP所涉及的范围对于软件产品化，仍然缺少部分过程，包括企业业务分析、产品设计、产品管理、产品组合管理等过程，需要在企业在产品4 图片来源网站 18/46 软件项目

38、产品化之路 化的过程中进一步的完善和补充。 3.3.3.2. 软件开发过程选择 随着XP/Scrum等敏捷软件开发过程的不断兴起，相对与传统重型软件过程（CMM/CMMI、MSF、RUP等），越来越多的人进入到敏捷软件开发过程中来。对于进行软件产品化，哪种过程更合适呢？ 相对于CMM/CMMI等重量级过程，产品化软件开发，应该更多的吸收敏捷软件过程的思想和精髓，注重产品的长远规划和近期目标，采用增量迭代的方式，逐步演进的进行开发。 需要注意的是，在产品的生命周期的不同阶段，是应该采用不同的开发过程的。在产品的初创阶段，应倾向采用XP/Scrum等更加敏捷的方法，鼓励发散性思维，强调产品的创新性

39、；在产品进入快速发展期的时候，应该倾向采用迭代增量式的开发方法，强调有计划的逐步产出；在产品的稳定期，由于各项需求都比较明确，可以考虑采用传统的瀑布模型或V模型；在产品衰退阶段，需要对原有产品进行二次创新，则应鼓励采用XP这类极端敏捷的软件过程。 因此，软件产品化开发不存在唯一的、一成不变的软件过程，应该更多的吸收权变理论的思想，根据具体客观情况的不同，灵活掌握和应用。 另外，一般而言，产品的规模越大，牵涉人员越多，牵涉的外部协作方越多，项目的干系人越多，对过程的重量级也要求越高。当然，但这一点并不是绝对的。 以波音公司研发波音777客机的过程为例，其研发过程中就抛弃了传统 “按图纸生产”过程

40、，而采用同步工程方式5，大量使用CAD/CAM技术，实现了无纸化生产，试飞一次成功，比传统方法节约时间近50%。6 在设计初期。波音公司和一些航空公司进行了广泛深入的讨论以确定和开5 同步工程（concurrent engineering），又称并行工程，是对整个产品开发过程实施同步、一体化设计，促使开发者始终考虑从概念形成直到用后处置的整个产品生命周期内的所有因素(包括质量、成本、进度和用户要求)的一种系统方法。它把目前大多按阶段进行的跨部门(包括供应商和协作单位)的工作尽可能进行同步作业。 6 本段和同步工程定义引自汽车研发中的现代化项目管理一文。 19/46 软件项目产品化之路 发新飞机

41、的结构布局、这些航空公司包括：美国联合航空公司、全日空航空公司、英国航空公司、日本航空公司和香港国泰航空公司，它们在航线结构客流量和服务频率方面全方位地代表了各航空公司现有的营运水平，均成为了开发777时的顾问航空公司。这些航空公司的参与保证了产品最大限度地满足全世界航空公司的需要。为了满足航空公司的要求，波音在777上采用了多项新科技。波音公司把这套哲学称之为一起工作（Working Together），因此777被称为是波音以客为本的产品之一。7 可以看出传统制造行业的最先进的产品制造过程，也再不是我们常认为的严格按照阶段进行的瀑布式生产过程，而是引入了和敏捷过程思想有很多共通特点（现场客

42、户、并行工作、可抛弃原型等等）的同步工程方法。反之，我们在设计和研发产品化软件的过程中也要更多的吸收其他行业的成功经验，要将内外部的协同、协作的思想贯穿到底。 3.3.4. 软件开发组织机构 产品化软件开发与商业化套装软件开发的最大不同，产品化软件开发必须同时处理项目和产品之间的关系，而商业化套装软件的开发基本上只考虑产品本身。由于产品化软件的销售基本上是以解决方案的表现形式，即既包括可以重复使用的软件产品，又包括客户化定制部分。因此，如何组织产品及项目的开发，并协调两者之间的关系，就是一件非常困难和非常重要的工作。 由于产品型软件开发，基础技术、产品研发、项目实施、产品管理常常分属不同的部门

43、，而产品研发或项目实施都需要不同部门的人员共同参与配合，因此采用传统集权式或层峰结构组织，都会造成部门割裂，官僚作风的产生。 针对产品型软件开发，应该采用矩阵式管理或更为灵活的自组织团队的管理方式，消除部门壁垒，加强人员沟通。在这方面可以借鉴微软的MSF软件过程。MSF软件过程的组织结构采用以特性（Feature）小组方式组成，每个小组包含产品管理、程序管理、开发、测试、用户体验以及发布管理等六个角色。 7 本段引自百度百科词条：波音777 20/46 软件项目产品化之路 图表 4 MSF项目团队和外部环境的沟通 8 针对产品研发和项目实施，也建议采用跨部门的多职能小组，根据是产品还是项目，采

44、用偏重产品或偏重项目的管理方法进行管理。 3.3.5. 软件生产工业化 项目型软件向产品化发展，不仅仅是指软件本身的发展，更为重要的一点，就是软件本身的生产过程，要向工业化的生产水平的发展，而一点常常被人们所忽视。如果软件本身的生产过程和技术水平仍然停留在单个项目的水平，那就算是你同类项目做了几十个，并把他们的需求整理成一套软件，完成客户的需求也相对变快，这并称不上产品，只不过是像欧阳修的所描写的卖油翁一样，“我亦无他，惟手熟尔”。 因此，软件的产品化不仅仅意味着软件产品的可复用，而是软件的生产过程也要进化到工业化产品生产水平。通过技术上的创新，解放开发人员，将其从简单重复性的工作中解放出来，

45、来处理更高级的和更关键的问题。 通过将软件生产提升到工业化生产水平，将大幅提高软件生产效率，提高软件产品质量，形成规模化经济效益。 8 图片引自edmond_wang 博客MSF团队模型 21/46 软件项目产品化之路 3.3.5.1. 传统工业化内容 传统工业化内容的定义，主要包括劳动资料、工业管理、劳动者和管理者的知识结构、工业部门结构、主要技术经济指标等方面的内容。 劳动资料的现代化。在主要工业部门实现生产过程的机械化、自动化，采用新技术、新材料、新工艺和最新科技成果。 工业管理的现代化。在工业管理中，采用现代化的管理体制、合理化的生产组织、科学化的管理方法和电子计算机化的管理手段，达到

46、优化资源配置，取得最佳经济效益的目的。 劳动者和管理者知识结构的现代化。劳动者和管理者的科学文化水平和专业知识普遍提高，在业职工构成发生变化，即在整个工业人员中，技术人员的比重将不断上升，直接生产工人的比重将逐渐下降；在工业管理人员中，具有专业知识的人员会迅速增加，而非专家职业的人数会减少。 工业部门结构的现代化。技术密集型工业的比重日益提高、新兴工业部门的建立与发展，是工业部门结构高度化的主要标志。 主要技术经济指标达到当代世界先进水平。例如，主要工业产品产量、劳动生产率、主要原料和能源的消耗水平、资金占用、先进机器设备的自给率等一些指标，都应该达到当代世界先进水平。 劳动资料的现代化是工业

47、化的核心，工业管理的现代化与劳动者和管理者知识结构的现代化，是实现劳动资料现代化的基础，工业部门结构的现代化9和主要技术经济指标达到当代世界先进水平，是工业化在结构上和功能上的综合反映。10 3.3.5.2. 软件生产工业化 参考传统工业化内容范畴，可以进一步得出软件工业化的重要标志，即研发方法的现代化、研发管理的现代化、研发人员和管理人员知识结构的现代化、研发部门组织结构的现代化和主要产品研发技术指标的达到世界先进水9 作者注：原文为“高度化”，应理解为“高度结构化”。为和前文统一，改为“现代化”。 10 本段内容引自智库百科词条：工业化 22/46 软件项目产品化之路 平。 研发方法的现代

48、化。主要包括软件生产的自动化和智能化，采用最新的研发工具、测试技术与工具、产品技术框架、开发方法、建模语言、编程语言等等。 研发管理的现代化。在研发管理中，采用现代化的软件过程与思想，科学组织研发管理团队，使用信息化的管理工具手段，人性化的管理，并为员工提供良好的学习环境和成长空间，从而达到尽可能大的发挥研发团队能力，激发员工的主动性，创造更大的经济价值。 研发人员和管理人员知识结构的现代化。研发人员和管理人员的专业知识、研发能力、管理水平普遍提高，人才结构发生变化，及高素质人才、专家、通才在整个员工比例中不断上升；而基础的编程、测试、维护人员数量逐步下降。 研发部门组织结构的现代化。从单一的

49、研发部门，到专业化的部门分工，例如基础技术研发部门、产品研发部门、项目实施部门、产品发展与创新部门、质量控制部门、质量保证部门、项目管理办公室、流程改进工作组等都。专业化部门分工，将标志着软件研发部门组织结构向现代化的迈进。 主要产品研发技术指标的达到世界先进水平。例如缺陷数/千行代码、代码产出率、无故障运行时间等，都应该达到当代世界先进水平。 研发方法的现代化是软件生产工业化的核心，研发管理的现代化与研发人员和管理人员知识结构的现代化，是实现研发方法现代化的基础，研发部门组织结构的现代化和主要产品研发技术指标的达到世界先进水平，是软件生产工业化在结构上和功能上的综合反映。 3.3.5.3. 实现软件生产的自动化 软件产品生产工业化的核心就是研发方法的现代化。借鉴工业化的发展的历程，其劳动资料的现代化的核心体现就是生产过程的机械化、自动化。那么针对已经高科技行业的软件行业其“机械化、自动化”又体现在哪里呢？ 仔细分析软件产品的生产过程可以看到，虽然软件行业属于高科技行业，但其生产过程，从需求分析、设计、编码、测试、配置管理、部署、项目管23/46 软件项目产品化之路 理等诸多活动，可以看到其大部分的工作仍然是手工作业为主，虽然有很多工具在这过程中进行使用，但