从项目化到产品化

软件公司一贯都是以项目实施的方式来完成业务需求的交付，项目型的软件开发中，开发语言和平台往往五花八门，开发人员在各个项目中疲于奔命。稍微好一点的公司，技术平台相对稳定，如使用.Net或者Java，但所谓的重用，只不过是把原项目的代码拷贝过来，小的改动就小修小改，大的改动就干脆重写。项目做得多了，软件技术水平在不断发展和提高，人员也在扩张，软件产品化是一个必然的需求。然而以项目运作的方式所带来的技术问题，是软件产品化需要面对和解决的。

公司平台历经三年的开发和营运长跑，技术方案和框架趋于稳定，人员扩展成长，也走到了产品化的路口。作为公共组，对项目化到产品化做了一些研究，整理了一些走向产品化需要提升或完善的阶段。

项目需求提升为产品需求

项目是面向单一用户或者几个用户，满足特定的需求，主要是体现个性化；希望在规定的时间完成相应的功能，使得产品能正常运行，项目是一个过程，有明确的起止时间

产品是面向大众或者行业，是大面积普及应用的需求，主要是侧重市场需求，有广泛性。包含若干项目，最终给用户使用，知道什么时候开始但并不知道什么时候结束。

产品化需要额外考虑以下几点：更高性能、更大数据和更快处理。

建立稳定的技术方案和框架

没有一套技术方案和框架能解决所有问题，在产品化的过程中，需要对目前系统进行评估。

技术方案是指首先对原有的一系列业务进行分析，分析出其共通性，从具体业务现象中，将需要解决的问题进行归类和抽象化，然后在技术框架的基础上，对框架进行扩展和实现，既保证技术方案的可行性，又能满足实际应用开发过程中的个性化需要。技术方案既具有一定的业务独立性，又同时具有行业性特点。只有真正能和行业特点相结合的技术方案和框架，才有真正的价值意义。单纯从技术层面的技术方案和框架，不是真正意义的技术框架，而是技术方案和框架的实现方法和细节。

如Eclipse的产品化，支付宝便民缴费平台的产品化，Tomcat的产品化，有其行业特点和应用市场。他们被称为产品是无可争议的，但是Spring，iBatis等，一般认为技术框架成分较多一点。

建立了技术方案和框架之后，还需要对其进行演进和发展。产品是只有开始没有结束的，所以产品涵盖的方案与框架都需要有演进的特征。学习汽车、通讯等行业成熟的产品经验。

项目到产品化再到项目实施

项目化到产品化，是一次技术方案和框架的评估与整改，在这之中是技术的传播、学习和掌握。产品化之后，这些经验成果是再反馈到项目实施过程中的，用来改良项目实施的过程。

产品化的进程中，需要将现有项目的工作进行划分，将基础性技术的研发、软件产品的研发与软件项目的实施进行分离，其中如何有效的将技术、产品在实际项目中进行实施，是软件产品化的关键。

了解领域知识，比客户还专业

通过自身的专业知识，帮助客户建立适合他自己的业务解决方案，这是软件产品化的成功标志。基于业务又要高于业务，跳出原有项目的视角和局限，站在行业和客户角度进行思考。这需要我们除了关心技术之外，也要以业务为基础，建立领域知识的管理体系。

产品的复用性与自动化

通过技术上的创新，解放开放人员，将其从简单的重复性的工作中解放处理，来处理更高级和更关键的问题。推进软件生产的自动化，包括代码自动生成、自动构建、自动测试、自动部署。

项目质量提升为产品质量

通过客户全程参与、人机交互体验、业务场景模拟、自动化技术测试，来提高软件的质量与用户体验

解决对关键性人员的依赖

      项目中往往只有少数几个关键人，决定着项目的成败与质量。需要通过技术方案的实施，推进自动化的开发、测试，将复杂变简单，将关键人员的知识和经验，除了转换为文档保存，更重要的是转换为技术方案和框架、领域知识，以及相应的自动化工具，从而解决对关键性人员的依赖。