3.3.3 理解PAM的抽象级别

原文描述了过程评估模型、方法和执行的关系，有兴趣的可以查看。

我们还是按照阅卷这个思路来理解，阅卷准则（过程评估模型）告诉你什么是“好”文章，写作目标是什么；写作方法（方法）是指导你如何去写一个论点，如何描述一个人物；敲键盘或写字（执行）就是具体写作的过程。

反过来的话，你写了一篇文章，别人看你文章总结或你自己总结出一些方法，但这方法可能适用你却不完全适用于别人，这就是为什么要裁剪，为什么要结合公司实际业务确定流程体系。

阅卷老师看你的文章，根据阅卷准则搜寻得分点，并按照评分细则给分，最后得出你的文章分数，定出了你的写作能力等级，这就是ASPICE评估的过程。

4

过程参考模型和实施指标（等级1级）

前面三个部分讲了ASPICE的基本运作逻辑。

这里接着写第四章，就是我们所说的作文提纲或模板（参考模型：3个过程类别，8个过程组，32个过程），它同时也引出了作文所需要的基本要素（实施指标：BP和WP），就像议论文的论点论据论证都要有，也没跑题，达成完整成文的目标后算是1级，所以叫基本实践。

我们回到标准，下图显示了过程描述的样子（作文提纲或模板），以下所有子章节描述的8个过程组都是一样的结构。对照我们实际工作，这就是描述了一个流程，你要做什么、为什么这么做、做到什么程度及输出什么成果。

既然是品读，我们也不必把原文都誊上来，具体的细节可以直接查阅标准，文章里侧重于摘出实践中的关键信息。

4.1 获取过程组（ACQ）

这个ACQ被翻译成了获取，但业内习惯叫法是报价，基本都是发生在新项目报价时的OEM对Tier 1或者Tier 1对Tier 2，也就是客户与供应商。

一般来说，客户采购会通过供应商销售这个口子将询价的各类需求（比如叫RFQ或SOR之类）送达，并限定报价时间。

销售呢，转手将相关文件分发给工程、工厂、物流等角色去分析，各个责任人与客户或内部采购或供应商对应接口将方案、风险等确认后，再协同对应部门的成本一起汇总给销售，销售综合之后，向客户报价。

这是个简单的理论路径，实际上，报价阶段项目组介入不多，参与者多是销售或项目经理等少数人，流程也不会非常规范，会有各种操作。

4.1.1 ACQ.3合同协定

当走到这一步，前期工作基本做得差不多了，要准备定点给这家供应商了，后续要走商务合同的签署，明确好双方的权利与义务，也就是本节所谓的“合同协定”。

商务合同涉及到法律条文，所以多数是定式，修改里面部分项目信息即可，但是在报价阶段形成的和与项目相关的技术协议、技术方案、各类承诺文档乃至邮件，其实都是可以作为合同的附属物来约束双方。

甲方爸爸的威严和乙方孙子的挣扎很多时候需要台面上的这些东西来维护和推进。

商业社会，项目经理或销售都需要有敏感的法律和契约意识，邮件不乱发，字不乱签，话不乱说。

尽管合作成熟的甲乙方不怎么会对簿公堂，但“扯皮”是极为常见的，因为某方乱承诺或没有留好证据，导致自己陷入被动和胶着是非常常见的。

4.1.2 ACQ.4供应商监控

监控这个词放在汽车行业的语境里是不够精准的，其实就是日常项目开展中，客户对供应商的管控。

比如，根据客户行业地位的高低和前期的约定，进行开会盯、评审看、电话催、微信问、邮件投诉各类常规操作，就是客户要想办法让供应商按时保质地完成他的各种要求，包括但不限于上一部分的合同协议涵盖的内容。

4.1.3 ACQ.11技术需求

需求与技术需求这两个概念本身都不复杂，但后面章节还专门细分了系统、软件需求，所以这里的需求实际上更侧重于报价阶段宏观的、描述性的、概要的需求定义。

理论上或期望上，我们追求在报价阶段就将需求范围锁定，做什么，不做什么，什么时候做，一清二楚。显然，又是不太可能的，一来报价阶段持续时间很短，介入的人不太容易涉及到各方专家；二来这个阶段的很多信息还不清楚，无法做决定。

风险和不确定性一定存在。

那么，怎么做呢？其实，就是基于经验、项目复杂度及重要程度，关于到底带多大的风险而进行的权衡。

如果面对相对成熟的或重要级别没那么高的项目，会使用参考或假设的描述，比如，对于尚不清晰的部分，可以说基于某款量产的整车空间和某款量产ECU的技术要求，增加某项功能，参数范围是多少，并按照哪一标准完成实验，如后续有超出的范围，另行谈判……通过这样的方式，框定一个范围，并留有一定的余量，虽说带一些风险，但后期总是有办法吃掉的。

但如果面对的是新型的或很重要的项目，可能会引入更多的职能角色进行更细致的分析，结合历史LLs和新的要求考虑得更全面，尽量避免难以掌控的情况出现。

4.1.4 ACQ.12法律和行政要求

这个属于项目红线，相关角色要绷紧神经。

一般涉及到出口国家的法规、认证、运输等各类需求，或者本国的法律、行业的强标以及专利侵权的一些考量。

比如，有些产品受到政治限制是无法出口到伊拉克之类，或者型式认可（上公告）需要特定状态的产品，或者UI文言涉及到国家主权之类的……

4.1.5 ACQ.13项目需求

这部分包罗万象，除了技术的、法规的、资质的等特定需求部分，其余所有需求都可以划归到这里，所谓万事皆可项目，万事不离项目，万事都可找项目经理。

具体来说，要看具体的产品特点和以往项目的运作模式，双方的项目接口人员与内部团队在共同协定下，定义好怎么推进问题、怎么跟踪进展、怎么分配任务、怎么划分职责、怎么沟通交流、怎么交付软件或样件、怎么付款、怎么进行风险或缺陷管理、安排什么资质的工程师……

期望的做法是不仅仅停留在口头上和不正式的临时约定上，要落实成规则、流程。

4.1.6 ACQ.14提案要求

在汽车行业，将其粗略理解为RFQ或SOR包更好些。

采购发包时会将很多需求包含在内，除了前面提到的项目、技术、财务、人力、法规之类，报价本身也会有一些特殊的要求，可能会对R&D成本有特别的拆分需求，可能会有多家供应商竞标的要求，可能会有供应商能力评定的要求，可能会有售后支持的要求……

标准里的描述很宽泛，仅仅给了一个概念上的框架。实际操作中，会有不同的类别的要求通过该阶段发布给竞标供应商。

4.1.7 ACQ.15供应商资质鉴定

这和ASPICE、16949以及所有考级或认证的考试或评定一样，在建立好的一套评估体系里给它打个分、划个级别、贴个标签，以便于后续选择时作为参考。 

采购部门里一般会有供应商的库，可能会有不同的标签标记，比如红黄绿或者首选次选之类。

然而，无论如何，供应商资质只是一个很低的门槛，选定一家供应商有诸多无法尽述的明暗规则。

4.2 供应过程组（SPL）

4.2.1 SPL.1供应商投标

这里不作详述，因为这部分和ACQ实质上是混杂在一起的，招标与投标是协同做一件事情。

4.2.2 SPL.2产品发布

换句话说，产品发布就是供应商将样件或软件交付给客户的过程。

在此过程中，会涉及到软件版本号定义、样件标签定义、供应商内部批准、Release Note编制、测试报告提交、客户认可……一系列管理过程，目标是将客户需求的软硬件正确及时地交给客户。

4.3 系统工程过程组（SYS）

系统工程和软件工程组的整体思路是从需求、设计、验证三个角度逐级拆分并形成追溯对应的层次化，从客户一句话到一段代码，颗粒度越来越小，做得越来越精细。

就像做十字绣，从想要“家和万事兴”的一句话，到一张布画出很细碎的格子，再到明确每个格子谁来用什么线与什么针法。格子越细，越容易标准化，越容易分工，出错的概率越低，难度越低，越容易重复成功。

4.3.1 SYS.1需求挖掘

需求是我们开展项目的目标，所谓目标导向，就是需求导向。

这里所讲的需求不仅仅限于客户需求，是指所有相关方的需求，领导的、工厂的、采购的、销售的、开发的、测试的……也会以各种形式存在，明示的、暗示的、文本的、邮件的、微信的、电话的……总之，所有有关系的人的想要的都要被考虑到，只是有些不那么重要的人的需求往往被忽略和平衡掉。

需求挖掘的几个核心点是要沟通、要理解、要达成一致，而后要持续跟踪、变更要被管理、是否实现要定义清楚等。

4.3.2 SYS.2系统需求分析

在识别出各位想要什么之后，不是满口答应，而是要去分析，要看它们对不对、能不能验、能不能做、值不值得做，还要将上一阶段相对杂乱的需求整理，进行结构化和优先级排序，要确保把相关方的需求很好地梳理了出来，形成了清晰、层次分明且不遗漏的技术语言。

4.3.3 SYS.3系统架构设计

要什么清楚了，然后就是设计，这步是架构的设计，比如要形成架构框图、接口定义、时序图等，还要进行与需求的追溯。相当于你要装修房子，店家给你弄了个效果图。

4.3.4 SYS.4系统集成与集成测试

从技术上来讲，系统集成就是根据BOM在硬件上刷新软件，并搭建好相关的整车或网络环境等。集成测试的目标是确认架构对不对，可能会关注到系统组件之间的正确信号流、信号流的时效性、时序依赖性、接口的动态交互等。

4.3.5 SYS.5系统合格性测试

系统合格性测试也叫系统测试或者系统需求测试，就是看看系统需求有没有做到位。

4.4 软件工程组（SWE）

4.4.1 SWE.1软件需求分析

软件需求和系统需求类似，就是将上一层级的系统需求与系统架构再细分为更贴合编码的软件需求语言。

4.4.2 SWE.2软件架构设计

架构设计呢，也就是针对最后一层的需求——软件需求，进行的方案和架构设计。

4.4.3 SWE.3软件详细设计和单元构建

根据架构划分的模块，软件开发人员就可以进行详细的编码设计，会形成一个个的可执行文件。

4.4.4 SWE.4软件单元验证

软件单元设计完后，依然需要验证，只不过这里更多是针对本身设计合理性进行的，比如静态分析、依照编码规范的检查等。

4.4.5 SWE.5软件集成和集成测试

将一个个可执行的单元文件集成到符合软件架构的完整的集成软件，而后进行集成测试，以确认其是否符合软件架构设计。

4.4.6 SWE.6软件合格性测试

同系统测试类似，也就是针对软件需求进行的测试。

4.5 支持过程组（SUP）

4.5.1 SUP.1质量保证

特别是在国内环境下，这个角色其实一直处于相对比较尴尬的境地。

理论上的定义是，作为独立第三方去保证工作产品（不单单是软件产品，还包括其他各类要交付的文档等）和流程符合规定和计划，但达到这个目标的前提是有脱离于具体场景的标准（即不是具体问题具体分析）和执行标准的文化，显然这很难具备。

ASPICE似乎也意识到了，所以有这么两句话“建立了将不符合项升级到适当管理层的权限“和”管理层确保已升级的不符合项得到解决”，但这两条里提到的管理层多数并无这样的认识。

“实事求是”、“具体问题具体分析”、“成王败寇”是中国的经典智慧，但执行起来就是给质量保证工作当头棒喝，如果事情以结果论英雄，凡事可讨论，质量保证很难有发挥空间。

不过，到什么山唱什么歌，什么环境按照什么样的方式做事，这个角色依然可以拓展到不同的领域。

4.5.2 SUP.2验证

这里的验证和软件的测试是不同的概念，它具有更广泛的涵义，是指对确认每个工作产品是否满足定义的要求的行为，包含但大于测试，比如，同行评审、领导签字、第三方审核等。

4.5.3 SUP.4联合评审

这个概念单独拿出来，其实是侧重于整体的项目状态和多个相关方的需求满足得如何的确认，所谓联合就是整体，所谓评审就是确认。

大家一起理理清，对对齐。

对照实际的工作，基本可以等同于质量组织的各个里程碑的质量阀评审，这部分也是质量保证工作难得的发声场景。

4.5.4 SUP.7文档化

标准定义的目的是“开发和维护由过程产出的记录信息”，关键词在“信息”，尽管大家往往比较反感这部分工作，但至少截至目前，我们找不到更好的信息传递的方式，数字化可能能解决一部分传统文档化的弊端，但由于其工具使用有一定的门槛、编辑展示不够灵活、未足够普及、技术尚未成熟等不足，并不能取代文档。

无论是敏捷变更也好，还是数字化转型也好，文档的优化都是一大课题，后续我们可以继续思考探讨。

4.5.5 SUP.8配置管理

关于配置管理，我们前面写了好几篇文章，这里不赘述了。

4.5.6 SUP.9问题解决管理

问题包括软件缺陷或其他项目相关问题，总体要求是要有特定ID、来源、发生阶段、严重或紧急等级、发生场景、发生版本、原因分析、解决方案、责任人等。

由于软件缺陷动辄几百上千，所以缺陷的管理流程是相对规范的，而且缺陷基本代表了软件产品的状态，相应地，受到的关注度也比较高。

后续我们会出一篇文章详细写一下缺陷管理。

4.5.7 SUP.10变更请求管理

变更是个老生常谈的话题，变更本身不具备特殊性，实际上会驱动一次简化的或完整的开发过程。

其中的关键点在于，变更要经过预先可行性分析和CCB上是否执行的批准。

4.6 管理过程组（MAN）

4.6.1 MAN.3项目管理

ASPICE并没有将项目管理讲出什么花样来，权威的论述还是要看项目管理宝典PMBOK。

这里其实想分享点对项目管理另外的看法，如果要挑选出前三点，一个好的项目经理最需要的素质是：积极的沟通、很强的抗压能力和全面的业务逻辑。其余呢，要靠经验积累了。

4.6.2 MAN.5风险管理

每次看到风险管理，总有种无语的感觉。除了比较流行的FMEA、FTA等工具，常规的项目经理维护的那个风险管理表格，确实有种应付交差的样子。

真正的项目推动，可以靠开口项，可以靠缺陷管理，可以靠变更管理，唯独风险，着实难以独立落地，并不是不存在，而是都融合到了其余环节，比如，识别出什么风险后，会首先定义相关的调整任务，而不是去做一下风险管理。

当然，有时候需要汇报项目状态时，或者做一个什么决策选择时，也会用到这个概念。

4.6.3 MAN.6度量

度量离不开数据，数据离不开真实、及时和完整。

这也是比较难做到的，但聊胜于无吧，越是关键的判断和决策越会关注数据的有效性。

之前看了马云的一个演讲，特别提到了数字化和数据在未来的重要性，这值得我们所有从业者认真思考一下这个课题。

4.7 过程改进过程组（PIM）

4.7.1 PIM.3过程改进

过程改进是个很有价值的点，最有机会的人是前线战斗的人，但这批人往往没动力，反正一个项目交付了就好了，所以这部分常会沦落为EPG自嗨的领地。

这很需要制度来驱动大家的积极性，最直接的是通过钱来鼓励大家动起来。

4.8 重用过程组（REU）

4.8.1 REU.2重用程序管理

这个概念和平台化与共享化很接近，核心在于如何最大化利用现有资源。

对于汽车行业软件开发，相当于裁剪，针对不同复杂度的项目，将部分活动进行裁剪，主要也就是进行复用或重用，比如A项目的某些测试结果可被B项目拿来重用等。

不算很详细地梳理了一下第四章，算是聊了下ASPICE眼里应该完成的基本任务和达到的基本目标在实际工作中怎么体现的，即一篇作文基本成文后是什么样子的，下一部分我们再来看看ASPICE认为的高水平以及满分作文应该是什么样的。

5

过程能力等级与过程属性

总算写到最后一部分了。按照前面的承诺，这篇我们会根据文章的得分点（过程属性）逐层递进到满分作文（等级5），看看是什么样子的，也就是ASPICE眼里的最高水平。

5.1 过程能力等级0级：不完整的过程

“过程未实施、或未能实现其过程目的。在这个等级只有很少或没有系统化实现过程目的的证据”。

也就是说，第4章节提到的那些基本实践都未完整做到，没能达成最基础的项目工作目标（ASPICE认为的），就像文章不满400字或议论文没论据，定为残篇，直接低类文，甚至价值观不正，零分走起。

要是严格按照ASPICE的思路，实践上很多公司在不做准备的前提下直接迎审，就是0级。

5.2 过程能力等级1级：已执行的过程

“已执行的过程实现其过程目的”。

5.2.1 PA 1.1过程实施过程属性

“过程实施过程属性是衡量过程目的实现程度的一种度量“。

前面我们也提到过，这第一个得分点其实是对基本成文（基础实践）的一个整体描述，本身不是一个独立的点，只有达到了这个条件，才有资格进行好文章的评定。

换句话说，就是目的导向，做成功了。不管白猫黑猫，反正抓到耗子了。

这其实是蛮有意思的，一般理解里，以目的为导向，以成败论英雄，似乎没什么问题，有时候甚至还被认为是至上哲理。ASPICE不这么认为，它认为这只是最低要求。在这里，大家可以感受下ASPICE的思路，后面会逐渐展开。

5.3 过程能力等级2级：已管理的过程

我们进入到了文章水平判断的第二阶段，批改老师们开始正襟危坐看细节，开始抓真正的得分点了。

“以管理的方式（计划，监控和调整）来实施前述的已执行的过程，并且适当的建立、控制和维护该过程工作产品。以下过程属性与先前已定义的过程属性一起来证明本级别的达成“。

目标达成了，我们要看是怎么达成的，是瞎猫碰到死耗子，还是有“预谋”（以管理的方式）地抓到的？

5.3.1 PA 2.1实施管理过程属性

“实施管理过程属性是对过程实施进行管理的程度的度量”。

这个得分点怎么理解呢？

我们抛开那些冗长的描述，最关键的是要提前做好统筹规划，搞清楚对方要什么、排好什么时间做、定好谁来做、需要什么资源（如设备、样件等）、定期或不定期的会议或工具跟踪、跟踪到异常及时调整计划……

实际上，这是管理一个项目或一件事项的基本要求，做得不好的呢，就是做到哪算哪，碰到啥问题，临时救火。

5.3.2 PA 2.2工作产品管理过程属性

“工作产品管理过程属性是对过程生成的工作产品进行适当管理的程度的度量”。

同样是管理，上一个侧重于整体的“做”的规划管理，这个是侧重于“做出来的东西”。前者更倾向于项目经理视角，到点拿到东西；后者更倾向于职能经理视角，要确保做出来的东西被良好管理和正确交付。

工作产品是一个比较抽象的描述，我们举个具体点例子，比如客户要求交付测试报告，我们要按照客户的要求，去用特定模板结构，选择专属用例，做好版本命名，在变更履历里做好记录，完成评审修改，并通过专门的工具进行发布和存档等。

更便于理解的方式是三个词：基于需求、文档化（含配置管理）、评审。

这个级别重点在管理、在受控，而不是随机成功。

5.4 过程能力等级3级：已建立的过程

“先述的已管理的过程，由能实现其过程成果的已定义的过程来实施。以下过程属性结合先前已定义的过程属性，证明达成该等级” 。

二级猫是有“预谋”地抓耗子，三级猫是要基于猫群里已经定义好的流程去抓耗子，不是仅仅脑子里的“预谋”。

5.4.1 PA 3.1过程定义过程属性

“过程定义过程属性是维护标准过程以支持已定义过程的部署的程度的度量”。

简言之，就是有详细的流程定义。比如经常用到Stages来配置整套的过程体系，一般会定义活动的前后次序、不同过程之间的交互、负责人、所需的工具等，整体组成可能包括画出来的流程框图、每个活动的具体描述与相关角色定义、输入与输出的工作产品，以及对应的指南或培训材料等，还有很关键或者很理想的一点是，需要有量化指标来评价标准过程的有效性和适用性。注意，这里和MAN.6的度量不一样，这里是评价过程好不好使，而MAN.6的度量本身就是一个过程，是看度量的对象好不好。

5.4.2 PA 3.2过程部署过程属性

“过程部署过程属性是，对标准过程作为已定义过程进行部署而实现其过程成果的程度的度量”。

在PA3.1的书面定义之后，就是在具体项目的落实了，也就是本节所讲的。

首先呢，我们在开展一个项目之前会进行裁剪，毕竟不是所有的项目都需要完整跑一趟全流程，裁剪就是定义本项目所要遵守的流程规范。

接下来，要安排相关的人员，如能力不足，还需要组织培训，并且准备相关的资源（如线束、台架等）或工作环境（如工具系统里开出一个项目区域）等。

随后，还要不断收集分析相关数据，评估过程是不是确实有用（不是运作得符不符合标准过程），如有问题，要进行流程改善。

这一步的逻辑很清晰，就是按流程落实，但往往在这一步会回退到结果导向的模式。

5.5 过程能力等级4级：可预测的过程

“先述的已建立的过程，在定义的限值内可预测地运作以达成其过程成果。识别量化管理需要，收集和分析度量数据，以识别波动的可查明原因。采取纠正措施来解决波动的可查明原因。以下过程属性结合先前已定义的过程属性，证明达成该等级”。

这句话是指说什么呢？三级猫可以达到按流程抓到耗子，四级猫是有了更高的智慧，调用历史耗子作息规律和行进轨迹的数据库进行数理分析，能预测出几点到哪儿抓几只耗子了。

目前，据说只有德国博世平台达到了这只猫的水平（如有错漏，请指正）。

5.5.1 PA 4.1定量分析过程属性

“定量分析过程的属性是，定义信息需要、识别过程要素之间的关系以及收集数据的程度的度量”。

归根结底，ASPICE制定者想在这个级别达到量化的因果链条实现的管理，企业的终“果”是商业目标，所以第一个GP就是识别商业目标。

除商业目标之外，还有各利益相关方的需要也要被考虑到。此外，还要关注到不同过程要素之间的关系。

基于这些目标，来定义定量的目标和支持这目标实现的细化度量项。随后，就是进行数据收集和度量项的分析，并将这过程、项目、产品的结果提供给相关的人。

5.5.2 PA 4.2定量控制过程属性

“定量控制过程属性是对客观数据被用于管理可预测的过程绩效的程度的度量”。

“定量分析过程属性”相当于是只是给出来结果和限值，“定量控制过程属性”是要用这结果管理项目。比如，定量分析出来迭代速率和缺陷逃逸率，但光看这俩数字不知道意味着什么，就需要进一步利用一定数理统计方法或工具及业务理解来处理这结果，建立过程绩效分布，确认波动原因，并进行纠正。

如果这样不是很好理解，想一下机械产品的控制图（判断过程是否处于稳定所使用的带控制线的图），就很容易理解了。

写到这里，会发现什么呢？所谓定量，需要一个基础，那就是低变差、高标准。这又和那个提了几十年的“软件工厂”理念类似。

尽管现实项目里很少见到这样的实践，但还是思考一个问题，四级能实现吗？

基于机械产品大批量量产的成功经验，我想是能实现的。但是，有必要实现吗？或者实现后有价值吗？暂且留一个开放问题，一起思考下。

5.6 过程能力级别5级: 创新的过程

“先述的可预测的过程得到不断地改进，以响应与组织目标一致的变化”。

这下更厉害了，终于到我们满分作文了。不过，作文这个比方在这篇文章不太恰当，不太有助于理解，所以还是用猫抓耗子的例子。

四级猫会数学，五级猫就更神了，但也很不容易，这只猫发现耗子千变万化，甚至受“市场”影响，还得抓小鸡，它需要一系列的方法创新。

5.6.1 PA 5.1过程创新属性

“过程创新过程的属性是，从对过程的定义和部署的创新方法的调查中识别过程变化的程度的度量”。

这里比较简单了，一句话总结，基于新的商业愿景，在领导坚定拥护创新的前提下，分析现有数据和新技术、新概念识别创新机会。

5.6.2 PA 5.2过程创新实施过程属性

“过程创新实施过程属性是对过程的定义、管理和绩效的变化达成相关过程创新目标的程度的度量”。

这个冠的名号依然不小，实际就是基于PA5.1的流程变更管理，比如进行影响分析、执行、评估变更有效性。

到这里，看清楚了这满分作文或五级猫的真面目，有没有感觉有些失望？

我是有些失望的，我认为4级甚至3级的实现就没有了5级的土壤。可能也是ASPICE比较鸡贼，为了让自己生命力久一点和适用场合广一点，加了这么个级别，毕竟你再发展也需要创新啊。

6

说在最后 

ASPICE算是软件工程和项目管理的良好实践总结，特有的精华都在第4章的过程参考模型里，是一个系统且细化的软件工程化模型。

而所谓的评级，是针对成熟度的，而非优秀度，也就是说成熟不等于优秀，即并非级别越高越好。

一定程度上，1到5级基本映射了行业或业务的发展轨迹和需要，不同发展阶段会落在对应级别，但也可以说这个阶段需要这个级别所描述的运作模式，更高的级别不适合它。

也就是，初生混乱无序的0级；需要敏捷探索与目标导向，并能偶然成功落地的1级；积累了一定的成功经验，从而可被管理，并逐渐进入稳定有序的2级；技术日臻成熟，市场显现垄断，标准也明确且统一的3级；进入存量市场，需要高标准、高效率，甚至打价格战的4级；盛而入衰，不创新不求变就得死的5级。

       原文标题 : 万字长文解读让人爱恨交织的ASPICE