【转】对软件产品化的理解

产品化的时机是看业务的需要,不管是对前景的落实,还是项目转化成产品,这些都不是技术人员能考虑的,业务的发展和策划,如何进行市场细化等如果都由技术人员考虑, 产品化的风险很大。风险最大的是对于产品化的理解。

提到“产品化”,大部分技术人员,包括很多公司老板,首先想到的是可销售性,也就是免实施,“ 软件 产品的制造成本为零,微软就是这样发财的”,这是很多人跟我这么说,为什么要做产品。
     基于这种考虑,技术人员往往把主要精力放在体系结构设计,把焦点放在可配置性、零实施等环节,小型 软件 可能可以做到,而对于绝大部分中小 软件 公司,主要做的都是企业管理软件,采用这种思路会是一种灾难,企业管理软件是靠业务驱动的,即使是国外的成熟软件实施周期也不会比定制开发少多少,基于技术架构而不是业务来做产品开发,还没做出第一套就想着零成本复制,还没有业务应用,就想着软件提供的组织机构要支持复杂的矩阵式,甚至虚拟组织,基于产品的二次开发被看作是一种罪恶,从精益的角度上看也是一种过度设计,是一种浪费。如果基于这种想法来做产品,可以说产品失败的风险是非常大的,技术上对于一般的中小公司而言,是无法保证的。     
  通用类产品、中间件及系统软件的产品化,我没有这方面的经验,无法评论。

企业管理软件,切入一个行业和领域,是可以产品化的,不过产品化在很大程度上讲,我认为是一种商业名词,是一种结合管理思想、实施方法等个性化元素的东西,无法轻易复制和实施,不具备大规模的销售可能。公司想做好,靠的是咨询顾问,他们所要的是Best Practise,技术在这个领域对顾客的影响是微乎其微的,项目成功靠的是实施,我看国外的产品实施跟二次开发也没什么区别。

如果不是通用产品或者系统软件,做企业管理软件想零成本实施不太可能,产品所提供的功能永远无法满足客户的业务要求。而且靠销售软件产品挣钱,远远不及靠实施顾问挣实施费挣钱挣得多,后者才会给企业客户带来管理上的提升。

软件公司怎么做产品化?我的意见是:
    1、 找到合适的项目和合适的客户,多做项目;
    2、 在某一个领域积累行业经验,建立样板工程和成功案例,并将项目产品化(指商务概念上的产品);
    3、 提炼管理理念,并将理念和成功案例结合,整理实施方法论;
    4、 找到下一个项目,在项目开发过程中将原系统重构。

在刚开始的时候,别想着挣大钱,先老老实实做项目,只是要从业务的上多下功夫,对公司而言更重要的是抽象和提炼管理思想和业务规则,整理好实施方法和项目管理的经验,多做几个成功案例,产品化才有良好的基础。

时间: 2024-10-10 10:20:23

【转】对软件产品化的理解的相关文章

2014年度总结——软件产品化的简要理解

2014年度总结--软件产品化的简要理解 2014年转瞬即逝,真是让人感慨,岁月不是一天天在逝去,而是一年年:总结一年的工作非常有意义,觉得今年最大的变化就是从定制软件到产品化的过度:2014年做的几个项目基本都是根据客户的要求定制,团队成员付出了很多,大家都希望能够产品化,下面是我们对产品化的简要理解,希望有些借鉴价值. 微创新 现在比较受大众认可的创新概念是微创新,其核心价值就是用户至上:那么既然我们的软件项目有用户非常认可,那么我们就站在用户的角度,做最终用户喜欢的事情,最佳用户体验,更简

(转)软件产品化,国内IT人之痛

记得在网上看过一则印度软件的有趣故事,意思是先从印度6个不同城市的软件公司中选出6位软件开发人员,出一道千行程序的题目,让6位开发人员分别开发,最终拿出来的6个程序竟然完全一样:另一个测试是,将一个千行程序分成六段,让每位开发人员只开发其中指定的一段,结果6段程序合在一起就是一个完整的程序,不用做任何改动!简单太强了,阿蒙佩服得五体投地,心想如果我的开发人员也是如此,那将是多么美好的事情啊! 无论如何,这个故事至少说明印度的软件人才相当地统一化.标准化与规范化,难怪别人会成为世界软件工厂,而看看

(转)软件产品化,对客户意味着什么?

原文链接:http://soft.chinabyte.com/321/3070821.shtml 何谓软件产品化?软件产品化,即客户无需为软件添加或调整代码和语句即能完成软件的安装配置.应用初始化.系统管理.用户使用的全过程,并且软件至少能满足80%以上的用户某一组应用需求. 以前,一提到产品化软件,立刻就会想到盒装的微软office或杀毒软件等这些通用型的软件产品,其实管理应用软件也可以实现产品化,也可以成规模地生产.复用和推广.大独立软件商早已在管理软件领域实现了产品化.的确,软件复用率提高

对理想团队模式构建的设想以及对软件流程的理解

对理想模式构建团队的设想: 1.使用妥善定义的流程,流程的每一步都是可以重复,可以衡量结果的. 2.团队中的每个成员都能理解团队的目标,角色,产品. 3.尽量使用成熟的技术和做法. 4.尽量多收集数据,并参考数据做理性决定. 5.制定切实可行的团队计划. 6.增加团队的自我管理能力. 对软件流程的理解: 一群人在开发,运营,维护软件的过程中有很多级数,做法,习惯和思想.软件工程中把这些相关的技术和过程统一到一个体系中,叫做“软件开发流程”.软件开发流程的目的是为了提高软件开发,运营和维护的效率,

(转)关于软件产品化,平台化的思考

国内很多软件企业尤其是行业软件企业是从开发一.二个软件项目起家的,而且项目规模和复杂度也不大,依赖其中一两个高手,他们能够在客户适度满意的状态下成功完成项目.基于以往研究,成功的主要因素是项目具备以下特点: 如果是需求定制形的项目,项目需求明确且范围不大,变动不多.这样的项目要么客户方需求明确,要么企业对需求足够了解,这样,意味着项目双方至少有一个人对需求有全面并且细致的了解:双方合作氛围很好,这可以减少需求变更的量和避免冲突尖锐. 如是技术引领型的项目,则依赖于企业的独特技术. 企业有一两名技

理想团队模式构建的设想及对软件流程的理解

一    理想团队模式构建的设想: 软件设计是一项需要多人合作完成的工作,一个人是很难或者无法完成一项比较完备的软件设计的.因此,团队是必须的.但是团队是多人的,不可能有一个人的那种高度一致和自由性,因此,怎样构建一个较为理想的团队是提高工作效率的前提和基础. 团队有多种多样的模式,每种模式又有优缺点,但不管什么模式都基本遵循下列原则: 1.一个理想的团队应该有一个一致的集体目标,一个所有成员共同努力的方向. 2.分工明确,每个人都要有自己要去完成的任务,这样才不会茫然. 3.分工明确的同时要加

阅读《构建之法》,谈对理想团队模式构建的设想和对软件流程的理解

一.我们在开发.运营.维护软件的过程中有很多技术.做法.习惯和思想.软件工程把这些相关的技术和过程统一到一个体系中,叫做“软件开发流程”,软件开发流程的目的是为了提高软件开发.运营和维护的效率,以及提升用户满意程度.软件的可靠性和可维护性. 瀑布模型.瀑布模型是最早出现的软件开发模型,在软件工程中占有重要的地位,它提供了开发的基本框架.从瀑布模型开始的各种模型都有一个共同点:重计划,重事先设计.重文档表达.这一类的方法中集大成者要算Rational统一流程(RUP).RUP把软件开发的各个阶段整

对于理想团队模式构想及对软件流程的理解

软件开发是一项浩大的工程,单人开发一个软件是可以的,但无论从哪种角度来看,非团队开发软件在效率.稳定性等方面是远远不及团队开发软件的.然而就算是团队开发软件,团队运作模式的不同,也会大大影响软件开发的进程. 团队模式经过数十年的发展,已经摸索出了许多不同的模式,每种模式有其各自的特点,适用于不同的人员和需求.有些模式是以一人为中心进行研发,如:主治医师模式.明星模式等:有些模式是具有较高水平的一些人共同研发产品,有时虽有引导人但并不是如上一种模式那种居于核心地位,这几种模式有:特工团队.交响乐团

对软件开发的理解

软件开发是根据用户要求开发出软件系统或者系统中软件部分的过程. 本书讲的模型有以下几种. 一.瀑布模型 二.快速原型模型 1. 思想的产生 2. 原理 3. 类型 4. 运用方式 5. 开发步骤 6. 与瀑布模型的对比. 7. 缺点 8. 优点 三.增量模型 1.缺点 2.优点 四.螺旋模型 五.喷泉模型 六.敏捷模型 七.智能模型 八.混合模型 开发方法有以下几种 一.结构化方法 二.面向数据结构的软件开发方法 三.面向对象的软件开发方法 四.可视化开发方法 五.软件重用和组件连接 白话MSF