精益软件研发

　　在求新、求变、求个性的消费心理下，企业应该采用什么样的研发方式，才能满足不同需求呢?

　　有一本描写80年代美国寻求学习日本汽车业成功的因素研究的学术书籍——《改变世界的机器》。书中阐述了一个现象世界不是供大于求，而是求新、求变、求个性的消费心理对供应市场的一个颠覆性要求下，西方不采取精益方式产生的危机。而相反，日本、丰田等公司在多品种、短产品生命周期内实现快速的占据市场，并且搭上了个性化、物质大丰富的战后一代，精益研发的思想在后续20年大行其道。

　　书中就产品研发有很深入的分析。有一段话，一位欧洲的决策者没有意识到日本在各个领域都采取多品种少数量的方式实现了产品市场的占有，并实现了产品从低端到高端的螺旋上升。

　　国内软件服务提供商内部也有此类似的错误认识。“版本更新太快，客户要的不是过多的应用，而是稳定”。实际上，这暴露了服务商自身的对于自身产品不完善，市场跟进速度过慢的问题，低估对客户自我信息化消费的判断能力。

　　应用软件行业分工

　　应用软件开发行业正在经历着类似于汽车这样的大规模组件化、模块化产品行业分工的历程。

　　首先，从企业信息化开始，个性化的需求从未中止过。其中包括企业个性化和行业个性化，一边是企业业务作业的方式方法个性化，另一边是企业在不断个性化的终端最终消费市场的不断冲击下，形成“长尾”的新的企业收益模型。

　　如此，客户在运作上也不得不更多的为满足个性化的需求，而在组织，流程、资金、人力运用上更具个性特质，以至于会有“没有最佳实践，只有最适实践”。

　　其次，应用软件的技术基础已经具备了类似于工业企业车铣刨磨的工艺工具的大批量出现，同时这些工具也在不断的专用化和通用化之间进行演化，这点深谙软件开发技术演进的人员能够了解，所谓编程语言之间的鸿沟已经越来越狭小。

　　而这些都针对专门领域的专用构件，各自提供组件的标准衔接和适配，形成完成专业程序的工具。此外对于程序产品的设计、开发、测试产业在不断分工中，各显专业。这种情况在工业化产品的零部件衔接分工中，已经如火纯青。

　　再次，面对广泛的，充满个性的应用市场，单个企业通用的产品和通用设计，在市场发生较大变化时候，仅能够满足部分相对通用的市场应用，而无法满足深入市场。在长期的时间范畴内，终将被挤出市场统治地位，而居于规模市场份额和足够资金的软件公司，不通过金融资本的运作，也很难保证在某些不曾注意的角落，出现一位颠覆者。

　　这些行业内外的各种因素，确定了应用软件行业正在经历着类似于汽车这样的大规模组件化、模块化产品行业分工的历程。为之应对的竞争策略，实际上可以考虑精益化的研发体制，以更快的速度，应对更快的市场需求，并努力做到更多更细的特性构件实现对不同客户的需求变化。

　　开发中的浪费是除去技术因素之外，极大影响应用软件公司的敏捷开发的主要因素。简单列举可以包括：多余的开发，返工，浪费的业务协作，人力资源浪费，时间的浪费以及积压的需求。

　　多余的开发指不必要的功能和已完成的功能若干时间内没有被应用，返工指开发阶段的变更和应用错误程序;浪费的动作指开发请求和实际优先级脱钩，维护支持优先级排序无序，以及工作安排不平衡;人力资源浪费指程序员的不同应用交叉培训有限，员工和现有资源利用有限;时间的浪费指同样的需求在不同产线间重复分析，关键资源不到位，支持问题信息不完整，反复协调。程序员闲置，测试资源工作波动大;需求积压指大量不断延后滞留后版的需求，未能一次性完成的应用等等。

　　精益的组织保障和落地方法

　　我将从以下4点讨论软件领域实现精益的组织保障和落地方法。

　　第一，好的产品设计绝对不是花更多的钱和花更多精于聪明的人员投入。最关键的问题是领导方式对于整个设计团队的巨大作用。领导者的巨大魅力和相关权力使得整个设计具备了核心的方向和价值。

　　国内在不断吸取西方。尤其是在吸取美国式管理模式的时候，这方面也存在此类问题。我接触过若干公司也是这种情况，项目经理尤其在推进产品核心价值和关键特性上的压力是非常大的，而协调力又常有不足。组织给予的职务前景和权力是关键因素。通过团队领导权的绝对集中，以及考核的整体流程的权威制定，才能保证研发中的激励统一到一个方向上。

　　第二，团队工作。这是各大管理学派大为推崇的一个领域。最为主要的问题是当团队成员来自于各个职责组织的时候，团队成员仅仅认为自己就是一个工作程序中的一分子，而非团队整体一份子。类似于“我的作用是将营销部门的工作成果传递到工程部门的工作成果承接者”，团队成员从隶属上是部门内人员，仅仅是参与到设计团队中的一个代表，考核、绩效、晋升都是部门说了算。这样的团队无法实现精益和高效的开发，

　　而日本式团队中成员，在项目完成之前，考核直接在主管的控制之下，核心的少数人成为团队的中坚。从书中人数对比来看，这种成本节约和团队的成长是巨大差异的，西方团队平均要900人，而日本仅要485人。

　　第三，信息交流。西方团队成员不愿意直接面对争论的问题，前期做含混不清的承诺，后期问题突然出现，又不得不解决。日本的团队则签署正式契约，所有资源和优先权都是在项目开始获得确认和发现。

　　西方的团队工作的方式，设计过程从一个部门到另一个部门进行传递，而不是保留在团队总部内部，从而导致信息交流的问题，在团队内形成部门墙隅，无法通畅。人数方面，一般来说由于事先要进行大量问题和承诺的签署、评议，日本团队设计前期参与人数最大，而后期人数慢慢减少，相关专项设计逐步退出团队，而西方团队正好相反，接近投产期，人数反而大规模增加，来解决前期应当解决的问题。

　　第四，同步开发。无非就是产品多个领域人员，在确定各自的资源和任务阶段之后，能够同步进行生产部分就开始进行作业，而不是等到所有设计完成之后，再进行顺序生产。

　　如此可以大幅度的缩短时间，同步开发中需要做流程处理。保证各研发流程细条。通过协调产出节奏与生产流量，降低产能过剩或过多库存。软件发布计划有助于对项目进行优先排序，能够防止为满足新要求而引起的延误中固有的浪费。

　　根据项目复杂度对项目进行细分帮助项目经理得到适合项目的资源，避免为简单的任务提供不必要的管理费用，从而消除浪费。而在质量方面应该不仅局限于测试组，应该扩大到业务部门、设计师，以及编程员和测试员。不幸的是，在大多数应用软件开发团队中，端到端的质量负责制还是分散在多个模块的开发测试团队中，而不是整体考核。

　　对于这四个方面的总结，每一个都是相互影响和彼此制约的，只有系统的实现人的效率、发展;团队组织的有效形态。畅通、无阻滞偏见的信息交换、以及有效的同步开发跟进，精益的研发才会在时间节约、人员节约、产品质量、市场表现和项目成功上有所实现，而所谓软件专业化，产业分工化的行业发展前景才能更快的到来。

　　作者：李华焰 来源：软件世界 2008年12期