软件产品线中的架构级别

十几年前我研究过软件产品线并应用在公司的管理软件研发中,当时看了几本经典书籍,其中有一个软件产品线的评估框架FEF。Family Evaluation Framework 是欧洲工业界和学术界经过六年时间从众多项目整理出来的一个评估框架,如下图,该评估框架有5个级别, 覆盖了软件工程的四个评估维度(业务、架构、流程和组织),每个维度有三到四个方面,本篇将介绍一下架构维度。

摘自《软件产品化和平台化》内训讲义

三个方面

BAPO对架构着重从以下三个方面考虑:

 Asset reuse level : 资产重用级别
• Reference architecture::参考架构,作为应用架构的基础架构
• Variability management::可变性管理(这个是捷创成咨询认为规模定制化to-B产品的一个重点和难点)

Level 1: 独立开发(Independent Development)

总体说明:只有针对单个系统的架构
• Asset reuse level : 没有或者毫无系统级别的重用
• Reference architecture: 没有软件产品线架构
• Variability management:不做可变性的管理

Level 2: 标准基础设施(Standardised Infrastructure)

总体说明:没有正式的可重用领域资产,重用集中在第三方基础设施。
• Asset reuse level : 使用通用的第三方基础设施(例如开发控件等)
• Reference architecture:产品线架构基于第三方基础设施,主要致力于使用这些基础设施
• Variability management:有时会受到第三方基础设置提供的可变性限制,大部分可变性还是由应用架构提供

Level 3: 软件平台(Software Platform)

总体说明:捕获了领域通用性并在平台中实现,所有应用可以共用一个参考架构,通过配置平台可以适用与多个不同的产品,但是对可变性管理还是没有很好的支持。
• Asset reuse level : 定义了多个通用资产,在平台和架构下进行有计划的重用
• Reference architecture:参考架构作为应用架构起点
• Variability management:参考架构决定了核心资产支持应用开发需要进行哪些配置,有明确的应用生产计划

Level 4: 可变性(Variant Products)

总体说明:在产品线中明确提出可变性管理,能够很好的进行进行领域共性和可变性管理

• Asset reuse level : 应用开发可以进行明确的可变性管理
• Reference architecture:参考架构支持可变性管理,明确的表明使用参考架构如何支持应用架构的变化
• Variability management:应用工程的可变性进行很好的统一管理

Level 5: 可配置(Configuring)

总体说明:参考架构占主导,只有少量的应用架构,更多的是使用建模、脚本、工具和配置从参考架构自动生成产品。
 Asset reuse level:系统的规划和重用资产库
• Reference architecture:参考架构完全决定了应用架构,可以通过自动配置后生成应用
• Variability management:变体完全集成在架构中,变体被描述为模型,通过有语义的语言进行管理

如果你对软件产品线感兴趣,可关注捷创成咨询的软件产品线公开课。

产品生命周期

完整阶段

简单的产品生命周期包括3个主要阶段:开发产品、运营产品、下架产品。但这过于简单,下图给出了产品生命周期的更完整的视图。

摘自IT帮第一季布道系列课《产品管理方法论

产品启动阶段

产品管理、工程或运营部门提交一个新服务或对现有服务进行修改的请求。这些请求由项目管理办公室(PMO)接收并确定优先级。一旦确定了优先级,各个管理团队就会对请求进行审查,以根据业务需求和组织战略评估请求的影响和可行性。如果获得批准,该请求将获得必要的资金和资源,以便进入可行性阶段。

可行性阶段

对一个想法进行更深入的探索,以确定在业务需求范围内设计所需服务的可行性。治理委员会在启动阶段批准的请求将在工程和产品管理级别进行评估。从工程的角度,对服务进行技术可行性评估。初步技术服务说明概述了拟议服务的总体架构。在这一阶段还进行了可行性分析和稳定的商业案例。这些文件总结了时间和成本估算以及决定是否继续产品开发过程所需的其他投资信息。

设计和计划阶段

跨职能团队记录与服务开发相关的所有细节。虽然核心文档(如营销服务描述、技术服务描述和设计规范)已经稳定,但其他组(包括运营、QA和客户服务)开始指定其支持服务的需求。所有这些文件都由项目组批准和签署,设计和计划清单在进入开发阶段之前提交给治理委员会进行最终批准。

开发阶段

完成服务的实际工程。随着这项服务的发展,其他职能小组继续为测试和引进阶段进行筹备工作。支持客户关怀、培训、供应商和客户的大部分文档都是在此阶段创建的。此外,质量保证小组通过记录测试计划和测试规范以及配置测试环境来准备测试移交。在这个阶段,决策门径确保测试所需的所有工件都已完成。

以下是通过决策门径的要求:

  • 从系统集成测试的角度看为测试阶段做好了准备
  • 文档完成
  • 测试环境完成
  • 代码完成
  • 满足供应商需求
  • 集成测试和结果完成

一旦项目团队批准了服务的准备就绪,开发检查表就被编译并提交给治理委员会,以获得批准,从而将服务转移到测试阶段。

测试阶段

测试阶段的大部分时间用于验证服务中涉及的硬件和软件更改。这项服务将在实验室环境中接受多项准备就绪测试。运营部门还进行必要的系统和网络测试,以确保部署前的运营准备就绪。一旦QA测试结果和运营准备测试结果完成,服务可以在产品管理的指导下进行现场试验。测试阶段决策门径基于QA测试结果、操作测试结果、现场验证、变更请求和业务需求。

产品发布阶段

产品发布阶段协调新的或修改的服务的部署。当服务由运营启用时,支持组织启动支持流程来维护服务。一旦部署,项目团队和项目管理组织将进行服务检查,以确保服务可用。如果发现服务不成功,将执行预定的取消启动过程。如果服务是在没有事故的情况下启动的,那么项目团队将评估发布的稳定性,并将服务转换为生命周期管理过程。

运营阶段

运营阶段通常是最长的阶段,因为一旦产品开发出来,在更新或下架之前,它可能会运行相当长的一段时间。运营阶段需要一个组织来管理产品、跟踪问题和缺陷,并及时和经济高效地响应客户关于产品的问题。多层产品支持模型用于确保产品的运行方式能够实现RASM(可靠性、可用性、安全性和可管理性)。

退役阶段

退役阶段发生在产品生命周期的结尾。 虽然退役阶段似乎可以安全地忽略,因为如果将产品退役,可能会遇到更大的问题,但事实是,许多产品都已停止使用。 即使公司破产,合理,有序地关闭产品或服务对于管理公司资产也很重要。

企业级产品研发管理体系的构建

产品管理对于希望以产品制胜的企业来说都显得至关重要,所以大部分企业现在普遍更多关注单个产品的管理。这在单品制胜时代是非常有用的,然而,在解决方案产品时代我们除了关注单产品之外,企业级产品研发管理就显得至关重要了。

北京捷创成咨询 周金根

[toc]

产品管理现状概述

很多公司都很重视研发工作,但对研发管理却缺少经验,团队和个人都是在跟着感觉走、跟着经验走,在工作中带来诸多问题,例如越来越复杂的流程,导致工作效率大幅降低,产品开发周期反而拉长;只关注研发流程,不关注市场和需求,导致产品开发脱离客户需求,为研发而研发,失去市场机会;片面强调跨部门团队,为管理而管理,导致流程制度和实施两张皮,很多工作为了应付流程制度而作等。这样公司的研发往往面临着发展不起来,很难形成竞争优势等问题,只有长期处于研发小作坊阶段。

为了改善上述局面,每个管理者现在就要开始思考如何去构建企业级的产品研发管理体系。北京捷创成咨询认为,从产品战略、产品规划、产品开发到产品上市这个完整生命周期阶段都是我们需要整体考虑的。

很早在公司做产品经理的时候,对产品经理的认识是很不够的,一方面是没有人去告诉你什么是一个好的产品经理、产品经理分为几个阶段等,另一方面是自己也陷入了日常的细节工作中,并未跳出来站在另一个高度去思考如何解决手头上的问题。

摘自《NPDP补充版》课程讲义

随着工作中的实践和自己对产品的反思,不断加深了单产品及多产品的管理,IT帮认为以下是每个希望构建企业级产品研发管理体系管理者都需要考虑的主题。

1. 集成产品开发管理,产品扩展型企业不可跨越的阶段

摘自《NPDP补充版》课程讲义

说到企业级产品管理,IPD是值得去了解学习的。除了了解IPD的历史来源,它的核心思想更是我们需要去花时间思考的。例如:新产品开发是一项投资决策、基于市场的开发、跨部门跨系统的协同、采用公用构建模块、异步开发模式、结构化的流程、资源线和产出线分离。

2. 产品及周期优化法,创造一种改进产品开发的成功途径

摘自IT帮《产品研发管理体系》线上课

在了解IPD时就会提到PACE是鼻祖,而PACE的核心研发理念就是产品开发的7个要素,理解这些要素可以很好的给我们建立企业级产品研发管理体系建立好理论基础。

  • 四个项目管理要素:这些要素对于每一个产品开发项目都是必要的。掌握这些要素可以使一个公司缩短产品投放市场的时间,准确安排项目完成的时间进度,提高研发的工作效率,减少对不进入市场的产品的投资。
  • 在掌握了项目管理要素后,一个公司通常要提出新的问题:即我们如何才能发现最好的产品机遇?我们如何能更好地将技术开发综合起来?我们如何从战略和策略的角度为各个项目配置资源?产品策略、技术管理和管道管理这三个跨项目管理要素,提供了必要的基本管理框架来管理产品开发项目,并将这些项目在企业内部整合成一个整体。这些跨项目管理要素如上图右侧所示。

3. 研发组织体系,让大公司像小公司一样运作

摘自IT帮《产品研发管理体系》线上课

大多数小公司都希望发展壮大,以发挥规模优势。但是,规模大了又难以像小公司那样灵活应对客户需求和市场竞争。是不是有一种有效的组织方式,既能发挥大公司的规模优势,又能像小公司那样灵活、高效运作呢?答案是肯定的,精心设计的矩阵组织就是唯一的解决方案。我们应该建立以产品为中心、面向客户的组织体系。实施矩阵管理必须进行产品线与资源线建设并实施六大分离,产品线建设立足于产出,资源线建设立足于核心技术的提升和专业人员的培养。

4. 产品战略管理,衔接公司战略规划

摘自IT帮《产品研发管理体系》线上课

大部分企业没有把各层级战略、策略和行动计划的制订作为一个体系来管理,缺乏一致的规划方法论和流程,没有组织和人力资源保障。最终即便有各层级书面计划,却没有规划过程,导致难以做到公司行动一致,也就是不能做到四个对齐:1)上下对齐:高层、中层和基层的对齐。 2)左右对齐:不同产品线和部门之间的对齐。 3)长中短期对齐:长期规划(3年以上)、中期规划(1~3年)和短期规划(年度计划)的对齐。 4)外部对齐:整个公司的计划要能满足客户和市场需求,适应外部环境变化。

5. 产品市场管理,从客户需求到产品路标规划

摘自IT帮《产品研发管理体系》线上课

市场管理流程通常分为两个子流程、六个阶段,两个子流程分别为市场需求管理流程产品路标规划流程。市场管理完成从需求收集到需求分析,然后根据竞争和公司总体战略的需要,明确产品的总体策略是开发新产品、还是増加渠道或提高服务和营销能力。当明确确定需要开发新产品时,这时要进行客户群的细分,选择进入什么样的客户群,确定开发什么样的功能、规格及卖点;当确定功能规格及卖点后,确定总的技术特性,根据需求分成基本需求,竞争需求和可有可无的需求,完成大产品开发的路标规划,并完成细分客户群的产品开发的任务书。

6. 产品营销管理,建立产品意识、需要和品牌

摘自IT帮《产品研发管理体系》线上课

通常很多公司产品开发进行到一定阶段,开发和验证完成以后就直接将产品“扔”给销售,没有一个发布阶段,这样做可能会出现以下问题:1.对新产品的前三单不进行总结,导致营销策略不确定,靠销售人员的个人能力销售,很难完成新产品的市场开发和财务指标。2.没有完成产品的商标、命名及产品的定位,没有对销售人员统一进行培训,很难营造一个新产品进入市场大量销售的环境。产品命名、商标及样板点建设是产品开发团队的责任,公司层领导前期要参与产品营销的策划,设计卖点和建立样板点。

7. 产品开发流程,实现全流程、全要素的统一管理

摘自IT帮《产品研发管理体系》线上课

企业流程不能为流程而流程,必须将产品开发作为主流程,同时将研发生产、市场、采购、营销、财务管理和项目管理以及绩效管理等活动融入产品开发的主流程中去,以实现全流程、全要素的统一管理。除了介绍传统IPD开发流程之外,还应该了解敏捷环境下的新型产品开发流程。

8. 产品开发项目管理,将单项目和多项目管理分离

摘自IT帮《产品研发管理体系》线上课

以往我们更多关注的是单项目管理,而在企业级研发中,需要把单项目和多项目管理分离开来,这样才能把项目当做投资来看待,也能更好的从企业到产品线到产品经理的衔接。除了传统IPD流程之外,还应该了解敏捷框架Scrum是如何进行项目管理的。

9. 产品平台管理,基于核心技术构建产品平台开发竞争力

摘自IT帮《产品研发管理体系》线上课

企业想要敏捷的创新,必须建立在高质量的平台基础之上进行开发。如何进行产品平台管理是每一个数字化企业现在都要面对的挑战。并不是技术越多越好,而是越具有核心技术越好,企业预研必须基于核心技术进行立体研发,反对核心技术外包,一般技术和通用技术自己开发,同时要建立平台,基于平台进行开发。形成平台有两条路,一条路是根据需求形成平台规划,另外一条路是总结和沉淀。

10. 质量管理,在设计中构建质量体系,而非事后缺陷管理

摘自IT帮《产品研发管理体系》线上课

通常大家将产品开发的质量管理理解为传统的质量管理,主要包括产品的问题管理和缺陷归零管理,很多企业事前不做大量的质量工作和预防,事后花大量时间完善产品质量。通常这些企业在质量管理方面会存在很多误区,例如:(1)将质量管理片面理解为事后纠偏和缺陷归零管理,而不是努力在设计中构建质量优势的系统思考 (2)很多企业花大量的时间做评审,但没有评审要素,而且对评审人没有绩效考核,评审走过场;(3)大量没有经验的人直接做设计;(4)几乎没有公共共享模块和成熟度评估的概念,重复的错误一犯再犯。由于以上误区和问题的存在导致企业经常不惜花大量成本改进质量管理“头痛医头,脚痛医脚”,没有从系统职能体系的角度考虑问题,不是从设计中构建质量管理体系的角度考虑问题。研发质量管理不是事后缺陷管理,而是在产品设计时综合考虑CBB、评审、测试和验证等过程质量管理方法。

11. 绩效管理,在组织基础上再谈个人绩效管理和激励

摘自IT帮《产品研发管理体系》线上课

来自美世咨询公司的一项研究表明,只有约34%的受访企业认为他们企业实行的绩效管理是有效的。由于研发人员的绩效考核要综合考虑能力、过程和最终结果,同时还要让研发人员完成组织绩效,因此研发人员的绩效管理包括以下综合应用的五种手段。在组织绩效成功基础上再谈个人绩效,针对不同层级人员也需要区别对待,例如产品开发人员、平台开发人员等,应该通过任职资格、行为准则、PBC、KPI和KCP等手段分别进行管理和激励。

12. 成本管理,关注技术开发成功的同时关注财务的成功

摘自IT帮《产品研发管理体系》线上课

研发人员要树立综合成本概念,综合成本不仅包括物料成本还包括研发设计成本、维护成本、生产成本、共享成本、批量器件采购带来的成本降低,同时在方案设计时,要综合考虑成本和价格的关联,以低成本、高质量满足市场的竞争要求。

企业级产品研发管理体系

上面的内容对于新手来说会感觉内容太多,我们用一张图来表示一下这些模块之间的关系,你可能就会觉得对产品研发体系更为清晰一些:

摘自IT帮《产品研发管理体系》线上课

实践1:VRM

企业级产品研发管理体系构建虽然是一个体系,但是我们可以采用迭代升级的方式去构建。你也可以先选择一些要点进行实践,例如VRM版本规划。通常V版本以产品平台表示,是划分产品线的重要因素,通常V版本是R产品的集成平台和标准应用组件仓库,是R产品的开发平台。VRM版本规划背后是你需要了解什么是平台架构。

摘自《BangEA实践公开课》讲义

下图是我之前所在公司的产品线实践,也是上面细腰图的一个实现:

摘自《BangEA实践公开课》讲义

这种分层的产品体系中包括平台建设。平台处于IT帮常说到企业架构的技术架构层次。当平台做好之后,就能快速的进行开发

摘自《BangEA实践公开课》讲义

为了帮助更多人了解并掌握技术型企业的产品研发管理体系的内容,IT帮开设了一门《产品研发管理体系构建》的线上课程。内容包括以上的12次课程,现在已全部录播完毕,可购买收听学习

其他相关学科

除了以上介绍内容之外,如果要真正的应用企业级产品研发管理体系管理企业不同类型的产品,企业的产品研发和敏捷、架构紧密相关。

捷创成在实践中梳理的产品架构、敏捷框架都是对企业级产品研发管理体系的很好补充。

图片摘自TOGAF9学习网

Scaling agile – Spotify讲义

现在很多公司都在使用敏捷,一开始都是从几个小团队试试看开始的,然后发现了一些显而易见的成效,于是大家开始有了一些深层次的问题,例如:“怎样才能将这些适用于小团队的经验和流程放大到适用于项目群或整个企业?” “怎样才能让多个部门共同协作、且更高效的开发和交付软件?”还有一些企业希望从企业战略层次提出“如何在快速变化以及创新需求的环境下,如何落实敏捷企业?” 于是规模化敏捷被越来越多的提及。

规模化敏捷通过列出可以覆盖团队和项目群的、灵活的和标准的关键精益和敏捷的规则和实践来帮助团队和企业去解决上述这些问题。

虽然规模化敏捷能给企业带来很多好处,但我们还得承认,实现跨组织的敏捷实践是一个重大的改变,这是一个旅程,需要我们去解决过程中遇到的一个又一个障碍。

多年前践行Scrum之后,随着企业规模和能管控的组织扩大,我开始更关注规模化敏捷。之前发过一篇 Spotify的规模化敏捷模式 ,主要是为了让更多人能够更好的认识Spotify模型。很多公司听过并想采纳,但是可能连基本的组织结构和组织领导力都不清楚,所以我对外的Spotify的课程讲义分享给需要的人参考一下。

IT帮也推出了一个相关课程:Scaling agile & Scaled Agile(Spotify & SAFe),另外此课程支持定制,可单独讲Spotify或者SAFe。之所以把这两者放在一起,是因为可能你的企业需要结合这两者发展出你们企业自己的规模化敏捷之路,这个课程分为两部分:

  1. Spotify:当我研究Spotify之后,我特别喜欢这家企业,是因为我被它的文化所吸引,我对Spotify的课程标题取名为:Scaling agile @Spotify,是因为我觉得它们是一家持续改善的敏捷企业,大家以前看到的几个经典工程师文化之后它们也在不断提升,所以我用进行式表示它们的规模化敏捷。
  2. SAFe:Scaled Agile Framework,那就是SAFe。之所以用Scaled,是因为它是面向公众的一个版本化演进的框架,每个版本都是定型的。

如果你的企业也正在思考如何规模化敏捷,那么以下的部分授课讲义可供参考。如需要原版全部非水印讲义,可前往IT帮微店购买。如需培训和咨询,可加我微信:zhoujingen1

























作者简介:周金根,一个自在快乐、勇于践行的布道者。IT帮创始人,资深敏捷教练和培训师,十七从软件研发一路走来,做过程序员、技术专家、业务分析师、架构师、产品负责人等,致力于推广敏捷思维到更多领域中。

推 荐 导 读