Atitit 产品化法通则
目录
3. 产品金字塔 通用（跨行业）》垂直行业应用（跨公司）》公司 3
4.1. 完整的自定义（ui界面自定义 流程自定义 数据模型自定义 3
软件产品化，即客户无需为软件添加或调整代码和语句即能完成软件的安装配置、应用初始化、系统管理、用户使用的全过程，并且软件至少能满足80%以上的用户某一组应用需求
盒装的微软office或杀毒软件等这些通用型的软件产品，其实管理应用软件也可以实现产品化，也可以成规模地生产、复用和推广。大独立软件商早已在管理软件领域实现了产品化。的确，软件复用率提高意味着开发成本降低，周期缩短，维护费用节省，迅速普及占领市场，有效改善客户满意度等益处
从客户方面来看，项目化交付在技术或产品不成熟或相对短缺的年代是高端客户的唯一选择，但这样的选择的代价是非常痛苦的
其次，由于大部分软件都是针对用户具体情况定制，日后软件的维护和升级都需要单独修改、重新开发，这些都意味着较高的维护成本。在没有大量后备资金的支持下这类项目的最终归宿将由于缺乏可持续的不断增值的服务和升级，使得绝大多数该类项目在2-3年以内基本停滞或废弃
最后，软件稳定性较差，容易出现故障，自然就更谈不上实用性了，无疑是高风险和高成本的。
从厂商的角度来看，首先，项目的商业模式是以最低成本、最短时间交付客户需求，因此绝不会在项目的可持续发展方面进行研究和构架。随着项目的结束，下一个目标是下一个项目快速交付而非对上一个项目的优化和发展。
其次，即使厂商拥有长期优质服务的理念和实力，但由于不同项目之间的差异性，使得对项目的服务有心无力，兼之项目主导人员变动、文档遗失等因素使得个性化服务基本成为空想。
最后，项目越多，对厂商的资源需求越多，厂商基本没有足够的资源用于新技术研究跟踪和研发。长此以往，对产业的最大影响是功利性低水平重复，是对客户和厂商两败俱伤式的结局。
通用平台 行业子平台（手机骑车行业） 具体公司产品项目
通用（跨行业）》垂直行业应用（跨公司）》公司（跨部门）》》部门应用（跨个人）
提出了一个需求，想要一款报表软件，但是具体的功能他不清楚，就是希望我们能优惠一点，而且马上拿出来。这是做服务的经常遇到的问题，就是需求不明确，所以价格也很难明确。最后花费很大精力，拿出来产品并不是实际需求的产品。而一旦产品化后，很多问题就影刃而解。
。通过模块化和标准化有利于我们快速的将方案变为产品。这种优势在单个技术转换成多个产品时体现的尤为明显。
基于需求分析提炼和规划产品平台，然后在产品平台的基础上，划分产品系列，从而形成平台产品或产品版本。在贯彻平台化开发思想的过程中，应注意在差异化和通用性上取得平衡。可以说，复制是软件利润的唯一来源，所以软件重用度的目标甚至要优先于差异化的目标，因为只要有足够大的重用度，就能够大幅度降低成本，企业只要在核心需求上满足了客户，再加上价格和速度的优势，必将在竞争中处于不败之地。
在具体操作时，到底用户的某个特性是否需要加入产品规划中，到底某个需求是否应当纳入到产品功能开发中……如何在标准产品与客户最终产品之间取得平衡，这仍然产品化开发模式下最为头痛的问题。有些需求一旦纳入标准产品之中，对产品可能是致命的打击。
在平台化开发模式下，产品架构和模块/组件设计将更多地考虑开放性、通用性和冗余设计，从局部来看会影响产品开发的进度和效率，尤其对新产品系列的第一个产品，将需要更长时间才能推向市场，这是企业必须认识和接受的代价，但换来的是后续产品开发速度的大幅提升。另外，产品平台化开发还会来自内部高手的挑战和开发人员习惯的阻力。高手们总是希望按照自己的思路规划和开发产品，要让大家都统一到一致的平台架构和开发模式下绝非易事。开发人员也不喜欢条条框框，总是想弄点什么新的东西，但平台化则需要更多的标准化和规范要求。综上，要解决这些难题，企业需要足够的决心和耐心。
显然，软件产品化不仅仅是技术上的问题，然而技术也是其中关键的一环，包括架构设计、技术平台、模块化构造、数据结构、函数/算法、接口技术等。例如技术平台的工作一般包括
(9+条消息)关于软件产品化的几点思考【转】 - 平凡的心 - CSDN博客.html