阅读排行榜

评论排行榜

最新评论

总感觉那个叫啥晓峰的回复,总是不那么切题,貌似只看到了最基础的用处 --【匿名用户】:E-works热心网友
这是个好建议! --【匿名用户】:E-works鐑績缃戝弸
所以国内企业要的就是灵活不是标准。 --【匿名用户】:E-works热心网友
写进BOM的都是标准成本,实际业务中按照标准成本来的有多少啊。 --【匿名用户】:E-works热心网友
这个有这个复杂? --【匿名用户】:E-works热心网友
建议还是挺好的。 --苌晓峰
这个分享还是蛮不错的吗! --苌晓峰
太简单了啊 --苌晓峰
分享 --苌晓峰
真正用得时候,谁还会想到这个啊 --苌晓峰

读《改变世界的机器》,解软件研发趋势与管理模式保障<转>
本文标签: 软件 改变 

有段时间,工作需要进行了《改变世界的机器》文章的通读,这是一本有关80年代,美国寻求学习日本汽车业成功的因素研究的一本学术书籍,解答了世界不是供大于求,而是求新、求变、求个性的消费心理对供应市场的一个颠覆性要求下,西方不采取精益方式的危机。日本丰田等公司在多品种、短产品生命周期内实现快速的占据市场,并且搭上了个性化、物质大丰富的战后一代,精益的思想在后续20年大行其道。

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

他如是说:他们(指日本汽车公司)不能总是维持这样的速度,而且消费者很快会对短周期和过多的选择而感到厌倦。这个让笔者想起,国内业内软件服务提供商内部也有此类似的声音。版本更新太快,客户要的不是过多的应用,而是稳定。实际上,这暴露了服务商自身的对于自身产品不完善,市场跟进速度过慢的问题,低估对客户自我信息化消费的判断能力。

在编程技术日益变得商品化的今天,对于进入应用程序的设计的门槛不再是高不可攀,难以逾越的,随之而来的,就是对于软件应用产品的进一步的行业内部的零件(软件业内是否称之为Component)通用化,产品开发的协同化,以及交付和应用的服务分工细化。

或者一句话而言之,软件开发行业作为未来世界的新的主体经济和运行支架之一,业内分工将进一步扁平,原有的单一公司完成所有应用产品从底层到应用层的集成产品设计模式,将会迅速的崩塌为多个专业公司/细分行业的协同产品设计模式。

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

(1)首先:从企业信息化初始启端,个性化的需求,从未中止过。首先是企业个性化,其次是行业个性化。一边是企业业务作业的方式方法个性化,一边是企业而且在不断个性化的终端最终消费市场的不断冲击下,形成LongTail的新的企业收益模型。如此,客户在运作上也不得不更多的为满足个性化的需求,而在组织、流程、资金、人力运用上更具个性特质。以至于会有没有最佳实践(the Best Practice),只有最适实践(the Adaptive Practice

(2)其次:应用软件的技术基础已经具备了类似于工业企业车铣刨磨的工艺工具的大批量出现,同时这些工具也在不断的专用化和通用化之间进行演化,这点深谙软件开发技术演进的人员能够了解,所谓编程语言之间的鸿沟已经越来越狭小。而这些都针对专门领域的专用构件,各自提供组件的标准衔接和适配,形成完成专业程序的工具。此外对于程序产品的设计、开发、测试产业在不断分工中,各显专业。这种情况在工业化产品的零部件衔接分工中,已经如火纯青。

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

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

精益中强调的浪费,在软件研发中如何体现呢?开发中的浪费是除去技术因素之外,极大影响应用软件公司的敏捷开发的主要因素。简单列举可以包括:多余的开发,返工,浪费的业务协作,人力资源浪费,时间的浪费以及积压的需求。

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

看《影响世界的机器》P119-P126,我们可以从以下4点讨论软件领域实现精益的组织保障和落地方法。

1)好的产品设计绝对不是花更多的钱和花更多精干聪明的人员投入。首先重要的就是领导方式对于整个设计团队的巨大作用。领导者的巨大魅力和相关权力使得整个设计具备了核心的方向和价值。本田称之为主查。主查是日本公司内部最为让人羡慕的职位,因为能够领导、协调所有的技艺设计出精湛的产品来,“……掌握着大权……”,文中这么描述对于日本精益领导方式的定义。对于西方大批量生产方式下的团队开发负责人,权力有限,职责是:“……称之为协调员更为恰当……说服团队成员工作……”,如此这样,项目团队的负责人是内部实施项目最为脆弱的职位,胜利劳而无功,失败有目共睹

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

2)团队工作。这是各大管理学派大为推崇和说烂的一个领域。最为主要的问题是当团队成员来自于各个职责组织的时候,团队成员仅仅认为自己就是一个工作程序中的一分子,而非团队整体一份子。类似于我的作用是将营销部门的工作成果传递到工程部门的工作成果承接者,团队成员从隶属上是部门内人员,仅仅是参与到设计团队中的一个代表,考核、绩效、晋升都是部门说了算。这样的团队无法实现精益和高效的开发。日本式团队中成员,在项目完称之前,考核直接在主查的控制之下,核心的少数人成为团队的中坚。从书中人数对比来看,这种成本节约和团队的成长是巨大差异的,西方团队平均要900人,而日本仅要485人。

3)信息交流:西方团队成员不愿意直接面对争论的问题,前期做含混不清的承诺,后期问题突然出现,又不得不解决。日本的团队则签署正式契约,所有资源和优先权都是在项目开始获得确认和发现。西方的团队工作的方式,设计过程从一个部门到一个部门的进行传递,而不是保留在团队总部内部,从而导致信息交流的问题,在团队内形成部门墙隅,无法通畅。人数方面,一般来说由于事先要进行大量问题和承诺的签署、评议,日本团队设计前期参与人数最大,而后期人数慢慢减少,相关专项设计逐步退出团队;而西方团队正好相反,接近投产期,人数反而大规模增加,来解决前期应当解决的问题。

精益思想就有一个思路就是发现问题,立刻解决,大批量生产则是事后监控检测,才能发现问题。这方面是类似的。

4)同步开发:无非就是产品多个领域人员,在确定各自的资源和任务阶段之后,能够同步进行生产部分就开始进行作业,而不是等到所有设计完成之后,再进行顺序生产。如此可以大幅度的缩短时间。同步开发中需要做流程处理,保证各研发流程细条。通过协调产出节奏与生产流量,降低产能过剩或过多库存。软件发布计划有助于对项目进行优先排序,能够防止为满足新要求而引起的延误中固有的浪费。

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

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

发表于: 2009-02-05 22:13 秋声 阅读(898) 评论(0) 收藏 好文推荐

发表评论(网友发言只代表个人观点,不代表本网站观点或立场。)

您尚未登录,请先【登录或注册