从项目化到产品化

saturn 2012-09-21

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

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

项目需求提升为产品需求

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

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

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

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

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

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

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

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

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

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

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

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

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

产品的复用性与自动化

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

项目质量提升为产品质量

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

解决对关键性人员的依赖

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

相关推荐