今天准备谈下DevOps产品解决方案PPT材料的制作和修订，在前面实际我分享过云原生和DevOps的相关技术解决方案材料，但是实际在和客户交流后并没有达到很好的效果，简单总结来说就是材料太偏技术化，没有围绕客户真正述求来展开。

　　今天谈DevOps售前解决方案PPT材料的编写，更多的是理清售前解决方案材料的制作思路和关键逻辑。在讲具体的方案PPT目录结构的时候，我准备从问题驱动出发来谈下一些关键思考，以供大家参考。

　　

　　任何一个售前方案，首先就是要搞清楚你卖的是产品还是解决方案，这将直接影响到你做的方案材料的侧重点。产品和解决方案如果简单来说区别可以理解为：

　　解决方案=前期咨询规划 + 产品 + 实施 + 管控治理

　　如果你卖的是产品，那么重点就是产品本身的核心架构，功能介绍和成功案例；如果是解决方案，那么前期的咨询规划，实施，管控治理等内容都需要谈到。

　　产品类的方案材料需要突出的是产品核心功能，竞品对比和差异化优势等，而本身会弱化具体的实施方法论，管控治理等。一般来说，客户往往知道自己已经进行了前期的业务场景，问题需求分析，定位到了某类产品往往才会找你去交流。因此在这种情况下，你并不需要回答客户为何需要用这个产品，你需要回答的是提供这类产品的供应商中我是最好的。

　　而对于解决方案来说，实际上可能是客户也不清楚具体用哪个产品，你是对客户已经或可能遇到的问题，需求进行分析后，得出一个结论需要使用我们的产品，同时满足客户在成本，效率等方面的目标述求。

　　对于DevOps来讲，在前期我们重点在介绍自研的DevOps支撑平台的核心功能点，但是实际上DevOps研发运维一体化更多的是解决方案，不是简单地提供一个产品，而是需要咨询+实施+管控治理一整套的解决方案来落地。

　　

　　记得一次和客户的售前交流结束后，对方的领导找到我说到，架构师讲解的内容都挺好，但是相对技术化，我们的技术团队觉得这个产品应该面对大型IT团队或项目，而类似我们这种小规划的IT团队并没有实施的必要。

　　而实际上对于DevOps我在很早就强调过，对于20人左右的团队就完全可以开始实施DevOps，这个不是简单的持续集成和效率提成，更加重要的是加强组织级对研发过程的管控能力。也就是说我们经常谈到的企业研发资产应该是属于组织级的，而不是个人。这次交流下来对我触动很大，即如何基于客户或干系人的述求来准备解决方案PPT材料。

　　比如DevOps解决方案，你可能面对的是大集团企业也可能是中小企业，可能是完全IT外包企业，也可能是自己拥有IT自开发团队；可能你讲诉的听众是企业CIO和高层，也可能是具体的架构和核心开发人员。对于每种情况实际上PPT都应该有所修订或侧重，而不是一个PPT内容满足所有的客户或交流场景。

　　如果你面对的是高层领导，那么讲解重点一定是如何通过DevOps来沉淀企业核心研发资产，加强过程管控能力，提升研发效率和质量等。而当你面对的是技术人员的时候，那么重点一定是核心的技术亮点，通过自动化后能否真正减少重复工作等。

　　在很早我就提到第一次售前交流最好的方式不是讲解完整的PPT方案材料，而应该是先开放式的沟通，了解清楚客户的真实诉求和目标期望，再有针对性的准备材料。

　　只有这样才不会犯先入为主的错误。

　　在最早的DevOps解决方案介绍材料中，我们首先也会先介绍下DevOps的基础概念，DevOps的发展过程，但是这些介绍后客户最多也只能了解到DevOps是原来的持续集成和交付，敏捷研发，自动化测试等最佳实践的整合。

　　而这个了解本身仍然是技术层面的理解，也就是说你介绍完DevOps后，客户还是很难和大的环境或大的企业数字化，技术发展趋势匹配起来。那么更好的方法应该是先介绍整个地图，然后告诉客户你现在的位置，你准备到哪里去。

　　也正是这个原因，引入DevOps更好的思路实际涉及到从大到小两个递进

　　其一是整个企业数字化转型和产品互联网构建

　　其二是云原生和企业全面上云将成为重要的技术发展趋势

　　因此，在这个之前可以先给出整个数字化框架如下：

　　

　　数字化转型核心仍然是围绕连接，数据，智能三要素的业务价值链构建。对于连接解决基本的业务链协同问题，通过连接下的业务协同形成数据沉淀，通过数据的存储处理，管控治理形成数据服务能力反哺业务。同时数据持续积累又进一步为机器学习，深度学习等智能化分析应用提供服务。

　　在整个数字化转型中，云原生是核心的技术支撑能力。

　　因此再介绍下整体云原生的概念和整体发展趋势，从整体云原生架构框架里面就可以看到实际DevOps支撑平台是核心的云原生关键构成要素。是将软件开发，运行，运维三个状态打通和协同的关键支撑；同时也是实现企业内部私有云和外部公有云集成和持续交付的关键。如在原生整体解决方案构图如下：

　　

　　在这个图中基本就看清楚了DevOps在整个数字化转型，云原生解决方案中的位置。通过这种大背景的介绍，客户往往更加容易清楚你的产品在大框架中的具体位置和作用。

　　

　　问题到解决方案之间的逻辑匹配可以讲是最核心的一个点，这个需要真正了解清楚客户的真实述求，并进行了问题或需求分析后，才能够最终提出完整的解决方案。

　　或者讲一个解决方案本身是可以和客户的需求或问题点进行完整映射的，也就是说客户的期望和目标通过解决方案提供的完整架构，咨询或实施过程都可以解决。

　　在这里实际有两个关键点。

　　其一是对客户的需求或目标进行分解和分析，形成一个个独立的需求点或问题点，并对每一个问题点都给出一个完整的解决方法。其二是当给出了所有的解决方法后，你还需要自底朝上的进行糅合，形成一个完整的框架逻辑结构，体现整体方案的完整性。

　　比如一个大的平台建设项目，基于前期调研沟通，我们发现了客户存在基础数据不一致，接口混乱无法关联，端到端流程存在断点无法贯通，接口改造在多方联动的时候经常导致问题而回退，业务人员在处理业务的时候不清楚一个完整的业务流走到哪里了？可能还有很大问题。

　　我们经过分析后给出了一个完整的平台方案，里面包括了技术平台，MDM主数据平台，SOA集成平台，BPM流程平台，门户和4A管理几个大的组件。那么就需要讲清楚这些子模块是如何衔接起来的？其次要讲清楚客户的需求或问题是如何通过提供的子系统解决掉的。这个整体解决方案客户理解清楚后，客户就有了一个完整的概念和框架，然后再展开详细描述就容易了。

　　一个完整的框架逻辑，一定是符合金字塔结构的，也就是说从整个PPT一开始就应该是一个完整的自上而下展开的金字塔结构。解决方案更像一个方法论层面的动态内容，因此在制作解决方案的时候，顶层架构逻辑最好是基于方法论进行按阶段的动态展开，然后再逐个分章节进行阐述。

　　在我前面分析MDM主数据解决方案的时候就给出过一个方法论PPT页供参考。

　　

　　整个解决方案PPT本身也正好是分了四个大章节进行描述。

　　基于上述分析，对于DevOps解决方案，可以从数字化转型和云原生的大背景切入，并且说明云原生或DevOps是整个企业IT架构演进的一个必然趋势。

　　在这个介绍清楚后再给出完整的DevOps产品解决方案，在进行产品介绍的时候首先应该介绍整体的架构设计，然后再细分到具体核心功能点介绍。

　　整个产品解决方案讲清楚后，需要开始介绍企业如何去实施，如何去落地，因此会有详细的咨询实施方法论介绍，在整个实施方法论介绍完成后最好是再举一个详细的例子进行说明更加容易理解。

　　实施讲解完成后最好再介绍下整体的管控治理体系，管控治理体系中包括了标准规范，技术架构，流程，组织等各个方面的内容。

　　基于以上思考，重新对DevOps解决方案梳理如下：

　　第一章：概述

　　1.1 企业数字化转型和产业互联

　　1.2 云原生概述和核心要素

　　1.3 DevOps概述和发展过程

　　1.4 DevOps能力成熟度模型

　　1.5 云原生和DevOps符合企业IT架构演进过程

　　第二章：DevOps产品解决方案

　　2.1 云原生技术中台整体架构

　　2.2 DevOps支撑平台整体架构-体现子系统

　　2.3 产品功能架构

　　2.4 产品集成架构

　　2.5 产品的数据架构和数据模型

　　2.6 产品技术架构（技术栈和工具链）

　　2.7 产品功能架构详细介绍

　　2.7.1 敏捷研发管理

　　2.7.2 CI/CD和流水线

　　2.7.3 自动化测试

　　2.7.4 安全和质量门禁

　　2.7.5 源代码和配置管理

　　2.7.6 资产库和数据资源管理

　　2.7.7 持续交付

　　2.7.8 容器云

　　2.8 产品非功能性架构设计

　　2.8.1 高可用设计

　　2.8.2 集群和高扩展性设计

　　2.8.3 多租户和隔离

　　2.8.4 安全性设计

　　2.8.5 跨云融合能力

　　第三章：实施方法论

　　3.1 整体实施方法论介绍

　　3.2 咨询规划

　　3.3 方案设计

　　3.4 实施和遗留IT迁移

　　3.5 监控(资源，中间件，应用，服务）

　　3.6 运维

　　3.7 标准规范体系，组织，流程

　　第四章：案例分享

　　4.1 传统IT架构和问题分析

　　4.2 微服务划分和服务识别

　　4.3 技术平台建设

　　4.4 敏捷研发过程建设和实施

　　4.5 持续集成和交付

　　4.7 度量分析

　　4.8 实施前后关键KPI指标和收益分析

　　从以上框架搭建也可以看到，实际一个完整的PPT解决方案首先还是需要类似写作一样完整的文档结构，以保证逻辑完整，其次才是逐步展开呈现。