前言

不同于科研可以专研的很深而无需转化成生产力，工程化是一套将项目转化成产品从而达成生产力目标的科学方法论。架构师是业务与技术、产品之前的桥梁，除了熟练掌握软件开发的本质、方法论、技能、工具还应该具备工程化能力与项目管理能力，即任务的分析，拆解，计划，执行，领导，管控与团队的组织与管理。

工程化

工程化就是任务拆解

任务拆解是个有拆有合的过程。一个大的工程任务往往是由很多的小个的任务组成的，如何将一个大任务拆解成合适的小任务，能将大任务拆解成什么样的小任务，能拆解到什么粒度，拆解是否准确，这是”拆“。怎样对任务进行量化与质化，怎么将任务落地到具体的执行人员上，这是“合”。任务拆解比较的考验工程人员的工程能力，任务拆解是否成功是工程进度与工程交付能否成功的关键要素之一。

工程化就是取舍

工程化是取舍的艺术，工程受限于已有的条件，需要做出适当的取舍，才能解决实际问题。资源都是有限的，项目开工之前先搞清资源与人员能力，然后制定人员调配策略与合理的进度安排，需要计划让哪些人员去处理哪些问题，也需要制定合理的资源调度策略，从而才能稳操胜券。

比如“田忌赛马”就是一个经典的人力与资源的调配故事，精明的项目管理人员在项目开工之前就能彻底的预判结果，告诉资源掌控者我缺啥需要啥，满足这些条件才有取胜可能，然后再采用合理的策略从而抵达目标获取胜利。不同的人员会制定不同的策略，这也是工程人员的能力差异所在。

工程化就是组织与沟通

一个工程往往需要几十、几百甚至几千、几万人协同工作为达成一个共同的目标而奋斗，因此，在工程中人员的组织、沟通协调也非常重要，合理的人放到合适的位置，才能发挥其能力从而高效的解决实际问题，同时工程也讲究文档化、标准化、流程化与规范化。

工程化就是进度安排

将任务进行拆解仅是工程化解决问题的一个步骤，任务拆解之后还要区别主要矛盾与次要矛盾，进行优先级排序与里程碑确定，需要从时间上进行合理的安排与调度，最终让每一个子任务之间做到有效的协同与交付。

项目管理是工程化的子集

工程化是以现有资源与技术为基础，通过加人员、技能、知识组合起来，短时间内快速解决实际的复杂问题的一种方法。软件工程是指将系统化、规范、可度量的方法应用于软件开发的过程以及软件的运行和维护，其包括两方面内容：软件开发和软件项目管理。因此，项目管理是工程化的子集。

项目管理

项目铁三角

项目铁三角指的是项目管理的四个重要方面，即：

• 范围：需要做什么；

• 时间：什么时间做完；

• 成本：投入多少资源；

• 质量：做到什么程度才算达标。

范围、成本、时间三者之间任何一个变动均会对其他两项产生影响，如下图所示：

范围扩大（需求增加），做的事情多了，时间进度就需要延长，并且成本也会增加。如果做的事情多了而时间与成本投入又不变那么必然影响到质量。如果不打算减少所做的事情，就必然需要多投入成本（比如时间，人力），否者质量与范围又无法保证。范围、时间、成本之间的制约关系是必然存在的，但是也要依据实际情况而采取合适的方法，有的项目时间节点是固定的、有的质量要求严格、有的有固定的成本约束等，因此，需要根据情况进行合理的调整。

项目三重境

第一重，满足客户质量要求，这是项目管理的最基本的需求，在范围、时间、成本之间获取平衡是为了达到客户的质量要求；

第二重，满足业务的需求，项目管理人员需要懂业务，需要知道为什么需要做，什么是客户需要的，避免项目大方向的错误；

第三重，满足组织成员的需求，项目是由人实施的，其注入了人的精神与意志，因此也需要了解组织成员的需求，准确并且满足成员的需求，才能更好的推进项目。

项目拆解

道与法

架构师完成概要设计后就需要进行项目拆解，拆解的成功与否是项目能否按期交付的关键，在进行项目拆解的时候需要遵循以下的“一人二法三要素四角色”原则，

• 一人： 项目是由人执行的，人是项目里最关键的要素，合适的任务要拆解到具体的合适的人员上；

• 二法：量化与质化，任务拆解需要能量化（类似KPI，比如先赚它一个小目标：一个亿）有具体的时间、具体的数值，不能量化的需要质化（如同OKR，比如客户对这个质量感到满意，这个缺陷的修复方案QA已验证接受等，这个策略已经被客户所接受）；

• 三要素：即范围、时间、成本，在有限的成本、范围、时间约束下达成质量目标；

• 四角色：即RACI角色: 谁负责（R = Responsible）: 谁来干这活，谁批准（A = Accountable）：谁说了算，咨询谁（C = Consulted）：专家团，顾问是谁， 通知谁 (I =Informed)：谁需要被通知到，谁需要知道这个进度与风险。

术与器

如何进行拆解，能拆解成什么样的任务，这也比较考验项目管理人员的专业技能，这属于”术” 的范畴，同时也可以借助合适的工具（器）编排拆解的任务与进度。

项目计划

1，项目计划的本质是项目执行人员的承诺，因此，不同于产品与项目制定人员比较看重的是项目的价值，执行人员通常会比较关注项目的资源投入、技术难度、技术实现、里程碑、奖罚等，因此对于计划都会比较的谨慎；

2，计划本身没有太大作用的，但是没有计划却万万不行，如同“天气预报”，没几次预报会准确，但是好处是有了计划就有了可预测性；

3，大的项目计划需要拆分成合理的里程碑，每个里程碑都能对应到一个最小可交付版本（MVP）用于进行市场验证（PMF）；

4， 大方向与里程碑先保证正确，过程中进行小调整。

有时候计划的交付时间点是固定的，其由商业交付时间点反推，那么就需要在 “范围，成本与质量承诺”这三点上进行合理的取舍。

人员与组织

项目是由人完成的，了解团队成员的需求，满足TA所要的，这样具有保持团队稳定以及项目价值输出的可行性。

小结

本文从宏观角度概述了工程化与项目管理的差异，只会项目计划那是最初级的项目管理，更高级的项目管理是懂方法论，懂任务拆解，懂项目计划，懂业务、也懂人与组织等。在宏观上了解了工程化与项目管理，还需要微观上进行实践，手把手的操作过、练过、蹲过坑、吃过苦头才能叫做“实践出真知”。另作者能力与认知都有限，”我讲的，可能都是错的“，欢迎大家拍砖留念。

作者简介

常平，中科大硕，某AI独角兽深度学习首席软件工程师，前EMC 大数据资深首席工程师，主要工作背景在深度学习、流式大数据、云计算、分布式中间件以及Linux内核。

版权申明

本文的版权协议为 CC-BY-NC-ND license：https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用（以获利为准）以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

参考资料

[1] https://www.zhihu.com/question/26699139

[2] 《网易一千零一夜 - 互联网产品项目管理实战》 网易杭研项目管理部著

先有客户再有技术

技术不同于科学，科学是人类对自然的认知，它可以很前沿很理论也不用讲究工程价值，而技术更多指的是功能与工程得实现，更需要关注的是“利他”的常识。技术人员其比较关注的是技术架构、实现方式、技术价值以及开发成本，而比较容易忽略客户需求、使用场景以及产品价值与用户体验。忽略这些产品相关的内容而维技术论就容易犯错进而浪费有限的开发资源，在工程实现上维技术论常见的有四错：

• 第一错：“我为用户想”，这是研发人员最容易犯的错，其已经有用户意识，但是却没有进一步与用户沟通，直接替用户做决定，也不清楚用户的使用场景，因此容易造成”所想“实际上并不是用户真正所想；
• 第二错：追求有挑战的技术而非技术的实用价值，也非从合适的解决用户问题的角度出发，将技术上的自嗨当成客户需求，比如用户需要从A地到B地，简单一点给用户一辆自行车就可以解决的问题，而技术自嗨就容易非要先自行造个飞机，然后拼命的给用户推销这个好这个快，但是用户却不买单；
• 第三错：维性价比论，总以为又便宜的又好的就是真的好，性价比是大杀器，但是很多情况下其实客户也讲ROI(投入产出比)，比如双11秒杀活动，用户可以不计成本的采用最新进最前沿的技术，只要能扛得住双11的流量就可以不计成本，因为再大的成本，跟双11带来的收益对比都是毛毛雨；
• 第四错：闭门造车，不实事求是，不与客户做探讨，不做调查就把想象的或还处于概念上的东西当成客户需求。

因此，架构人员不能维技术论，维技术论就不是一个合格的架构师，架构师还需要关注客户价值，在实现一个架构之前先确定这个是对客户有价值的，同时平衡好客户价值与技术前沿之间的取舍关系。

什么是客户，又什么是客户价值

什么是客户

用英文单词表示，客户与用户其实是比较容易区别的，客户是 customers, 用户 是users，而中文二者都有个“户”字就比较容易混淆。To C产品客户可以是用户，但是To B产品， 客户却不是就等于就是用户。狭义的客户 = 买单的，广义上的客户 = 客户的客户 + 客户 + 客户的用户 + 利益链上的所有，用户也不就是一个角色或者某人，对to B产品来说，用户的本质是“需求“的集合。

什么是客户价值

“任何先进的技术、产品和解决方案，只有转化为客户的商业成功才能产生价值“ [1] ，客户价值就是对客户有用的东西，价值来源于价值的交换。技术的目的就是做对客户有用的东西，并且技术的进化方向是由市场所决定的。

以客户为中心，就是给客户创造价值，替解决用户难点、痛点、挑战点、为客户提供高质量低成本的产品，同时响应要及时。病根是需，药是求，拿出 “求” 解决 “需”，药到病除就是为客户创造价值[1]。

如何做到以客户价值为中心？

认知上做到技术要先从客户价值开始，那么执行上应该如何拆分？使得认知具有可量化的执行性？这里从以下三个方面对“如何做到以客户价值为中心”这个问题进行拆解：

• 价值探索 - 价值与交付双轮驱动思维模型，PMF-MVP思维模型
• 价值确定 - 三三制需求分析思维模型
• 价值输出 - 卡诺需求分级与分类思维模型

价值探索1 - 双轮驱动思维模型

价值探索的方法论之一是双轮驱动思维模型，其原则为：

• 以客户价值为前轮，前轮把握方向，解决的是需求探索、价值确定、特性探讨以及价值精炼的过程，需求输出需要去伪存真、去粗纯精、过滤提炼；
• 产品交付为后轮，后轮提供驱动力，解决的是开发、测试、运维以及获取客户反馈；
• 先有客户价值再有产品交付，客户价值又可分为主动式客户价值与被动式客户价值，获取客户需求的方式也需要合理取舍；
• 在双轮驱动模型里，二者谁都离不开谁，不是厚此薄彼的关系，而是二者互相协作从而推动产品往商业成功这个目标前进的关系；

价值探索2 - PMF-MVP 开发模型

如上图所示，PMF（Product-Market Fit）是讲究产品与市场匹配，是产品需要与市场需求相匹配，而MVP （Minimal Viable Product）是 最小可用产品，MVP讲的是每个版本的迭代都是一个可用的产品而非功能的堆砌，PMF-MVP开发法，讲究快速给的输出可用的版本给到客户，再由客户进行使用获取客户的信息反馈，再进行版本迭代。

价值探索的方法论之二是PMF-MVP开发法，其原则为：

• PMF-MVP 开发法可以帮助团队在早期快速确认客户的真实需求；从特性列表中确定产品（特性）的基本功能， 然后迅速开发MVP，再投放市场提前踩坑，收集用户反馈，然后再进行产品迭代，只有用户用起来，产品才有机会演化；
• 做MVP的时候，不是验证产品好不好用，而是验证产品/特性是不是用户真的想要的，减少开发成本，“闭门造车”式的开发经常会遇到“再来一次”;
• 跟目标用户产生互动和连接，每一步都收集用户的反馈，前期跟客户多交流，多沟通，“一元共创”与用户一起成长。

在价值探索之后就需要进行价值确定。

价值确定 – 三三制需求分析思维模型

公式： 需求 = 需（痛点、难点、挑战点、恐惧点） + 求 （产品、服务或解决方案）， 需即痛点、难点、挑战点，求即解决方案、产品或服务，求到需即完成，这就是有客户价值。依据三三制需求分析思维模型我们可以进行价值确定，三三制需求分析思维模型是一个价值确定思维模型，其如下表：

三三制需求分析思维模型进行价值确定之后即价值输出。

价值输出 – 卡诺需求分类与分级思维模型

这里采用KANO需求分类与分解思维模型进行价值输出，依据kano模型，需求可以分为：

• 基本需求：必须有的最根本的需求，没这个根本就没法谈，会阻塞产品交付；
• 增值需求：当提供此需求时用户满意度会提升；当不提供此需求时用户满意度会降低；
• 竞争力需求：若不提供此需求，用户满意度不会降低；若提供此需求，用户满意度会有所的提升，属于亮点要素；
• 可有可无需求：用户根本不在意的需求，对用户体验毫无影响；
• 有害无益需求：提供后用户满意度反而下降；

卡诺模型将需求进行了分级与分类，进一步的区分了需求的价值。

小结

本文首先确定了 “先有客户再有技术”的认知，再讲述了什么是客户，什么是客户价值，并且以思维模型的方式讲述了如何做到以客户价值为中心。日拱一卒，功不唐捐，分享是最好的学习，与其跟随不如创新，希望这个思维模型对大家有用。另作者能力与认知都有限，”我讲的，可能都是错的“，欢迎大家拍砖留念。

作者简介

常平，中科大硕，某AI独角兽深度学习首席软件工程师，前EMC 大数据资深首席工程师，主要工作背景在深度学习、流式大数据、云计算、分布式中间件以及Linux内核。

版权申明

本文的版权协议为 CC-BY-NC-ND license：https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用（以获利为准）以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

参考资料

[1] xx增长法

为什么需要写文档

软件工程师有两大难：1，没有文档；2，写文档。设计文档是用于描述如何去解决一个产品或特性的问题的，好的设计文档可以确保正在做的是正确的事情。

架构设计文档通常又可以分成概要设计文档以及详细设计文档。概要设计文档把握产品架构的宏观方向，而详细设计文档确定微观的代码实现。通常详细设计文档应该由具体负责这个模块实现的人员来完成，只有负责代码落地的人员才最清楚具体的微观问题，其他人员可以参与审阅设计方案、把握正确的方向。在工作中经常会遇到这样的情况：设计人员写完详细设计文档再把文档交付给写代码的人，去要求按这个文档写代码，经常会遇到的矛盾是：负责具体写代码的人觉得这个文档脱离实际没价值，而写文档的人又指责写代码的人员不理解他的意图。 因此，比较合适的方案是 谁负责写代码谁就负责详细设计（这对技术人员的能力要求也较高），其他人员提供检阅与建议，把握风险与方向。

那么如何撰写一个好的架构设计文档呢？这里提出一个常用的架构设计模板，以供参考，如下：

架构设计文档模板

动机介绍

描述需要完成的内容，介绍上下文以及需要达到的目标。

需求分析

以三三制需求分析模型分析客户、用户以及团队的功能、质量与约束需求，首要方针是“价值优先”。

目标非目标

目标与非目标主要是解释本文档做什么与不做什么，定义需要完成的任务与约束边界。

1
2
3

目标：定义本设计文档需要解决的问题以及需要达到的质量指标，是说明需要做什么。

非目标：说明本设计文档的约束，是说明不做什么。

里程碑

计划本身是“无用”的，但是没有计划却是万万不能，通过制定里程碑可以让文档的其他用户知道项目所需要的大概的时间周期。例如，可以按如下格式定义里程碑：

1
2
3
4

开工日期：2020年10月10日
里程碑 1 - 2020年10月30日，完成概要设计文档
里程碑 2 - 2020年11月30日，完成详细设计文档，并且编写完代码
结束日期: 2020年12月30日，完成自我测试、文档、质量保证以及特性交付

设计哲学

产品的设计哲学是产品的宪法，也是产品的灵魂与价值观，是产品的不可违背的最高指导思想，其把握了架构设计的方向，例如:

1
2
3

设计哲学
 - 以客户价值为中心
 - 以持续创新为竞争力

设计原则

架构交付的是功能需求，但是真正的差距体现在非功能需求（质量与约束），因此可以通过制定设计原则确定产品的非功能要素，设计原则是产品的法则，也是架构取舍的依据，例如:

1
2
3
4
5
6
7
8
9
10
11
12
13

设计原则
- 最佳物种原则
- 高内聚低耦合原则
- 可用性原则
- 可靠性原则
- 稳定性原则
- 可服务化原则
- 兼容性、可迁移原则
- 服务化、组件化
- 接口隔离与服务自治
- 用户触达成本原则
- 用户体验原则
- 持续演进原则

设计提案

设计提案可以从三个方面进行考虑：客户想要的、对手怎么做以及自身打算怎么进行，还需要分析每个方案的优点、缺点以及方案取舍的依据。

当前提案

当前方案需要分当前已有的提案、也可包括当前竞争对手的方案，以及客户/用户所期待的方案。

自身提案

提出自身的设计方案，可以提出多个设计方案：比如 提案1，提案2等，确定大的架构设计方向。

提案比较

提出以上方案后，制定技术提案评审表，分析提案的优缺点，确定最终的可选方案。

架构设计

这一部分是最重要、最核心的内容，属于架构设计文档的核心。在确定设计提案后进行概要设计，通常可以采用 4+1 架构设计法完成这一部分内容。如下图：

常用的4+1视图涵盖有物理视图、逻辑视图、处理视图、开发视图以及用例视图，其中与用例视图交叉的部分是描述共同的细节，同时每种视图中又有各自的需求，例如：

• 物理视图关注安装、部署、升级、运维的需求；
• 逻辑视图关注架构设计的功能需求；
• 处理视图关注非功能里的用户运行质量需求；
• 开发视图关注团队的开发质量需求；

跨团队影响

这里阐述需要的团队依赖以及对其他团队的影响。

详细的交付计划

这里可以以表格的方式，制定详细的交付计划。

开放问题讨论

提出需要讨论的问题。

作者与评审人员

确定作者与评审人员信息，例如：

小结

本文提出了一个常用的架构设计模板，希望这个设计模板对大家有用。另作者能力与认知都有限，”我讲的，可能都是错的“[1]，欢迎大家拍砖留念。

作者简介

常平，中科大硕，某AI独角兽深度学习首席软件工程师，前EMC 大数据资深首席工程师，主要工作背景在深度学习、流式大数据、云计算、分布式中间件以及Linux内核。

版权申明

本文的版权协议为 CC-BY-NC-ND license：https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用（以获利为准）以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

参考资料

[1] https://www.freecodecamp.org/news/how-to-write-a-good-software-design-document-66fcf019569c/

什么是奇点

物理学认为宇宙从无到有始于一个点，这个点叫做“奇点”，它积聚了形成现有宇宙中所有物质的势能，当这一个点的能量平衡被破坏后，宇宙大爆炸发生，从而生成我们现在的宇宙。如果把宇宙比作我们的产品，奇点就是这个产品赖以出现与存在的关键点。

产品创新与奇点理论

一个问题

奇点是这个产品赖以出现与存在的关键点，那么第一个需要回答的问题是：“你的产品的奇点是什么？”。一个企业就是一个产品，那么使命就是这个企业的第一原理点，价值观就是这个企业的奇点，是这个企业赖以存在的关键点。一个软件平台是一个产品，那么以客户为中心可以是这个产品的第一原理点，逻辑基石可以使这个产品的奇点，这个基石是这个产品赖以生存的关键点。

因此将奇点理论应用于产品创新的第一个关键步骤在于 找出你的产品的”逻辑奇点“，比如在AI训练市场，GPU是原来的产品的奇点，是原有的产品赖以依存的关键点，而XPU就是新生的产品的奇点，是新生产品赖以生存的基石，他们的第一原理都是客户的AI训练。

两重境界

创新 = 更好 | 不同 | 新生

• 更好，指的是市场是明确存在需求的，但是提供的新产品在质量、功能、渠道、价格等方面比原有产品更具优势，是用更好的体验来满足客户的真需求；

• 不同，指的是差异化竞争，”与其更好不如不同”，不同不只是技术面的不同，而是处处差异化不同，理念、技术、渠道，运营，销售等处处差异化竞争；

• 新生，指的是 从0到1，从无到有的创造一个新物种，是指用凭空创造出一个新产品来满足客户需求，这种形态的产品要么是颠覆式的创造带来巨大的商业上的成功，要么就是没有真实客户需求的新事物，商业上完全失败。

这里，AI训练芯片采用的是“更好与不同”这两个产品创新方法论，组合原有的技术开拓出新产品，规避风险，满足客户真实的需求。从GPU到XPU 体现的是“不同”的创新理念，而从XPU1.0到 XPU 2.0 再到N.0 体现的是“更好”的创新理念。

因此，这里提出：创新的第一重境界是“与其更好不如不同”，第二重境界是“与其不同不如更好”。

与其更好不如不同

生物学家通过分析人与猩猩的遗传基因发现人与猩猩的基因相比较仅有约1.2%的差异，但是就是这约1.2%的差异却造就出两个完全不同的物种以及生态位，猩猩呆树上吃果子，人类败走树上行走平地却成了万物之灵长。决定你是猩猩还是人类的差异只有那约1.2%的差异而已。

“与其更好不如不同”这句话讲的是错位竞争，远古时期要是人类跟猩猩拼命的争树上的好位置，做得再好也不过还是猩猩，也许如今都还在树上跟别的猩猩抢香蕉而已，但是，人类不跟猩猩争抢树上的位置，其不爬树了，开始出走平原，环境因素逼迫其直立行走进而进化成万物之灵长。

同样的道理，在AI训练芯片的产品市场里，如上图之左，GPU是其奇点，它有自己的生态位，有自己的壁垒，也有自己的第一原理点。一款产品要是跟GPU抢占同样的生态位，做得好也还在它的那个圈圈里，后来者再怎么的努力也难以突破它的那个圈圈。然而错位竞争，从GPU到XPU，击破GPU的奇点位置，从新定义自己的那个壁垒与圈圈，却使得产品有了新的生态位，新的可能。

与其不同不如更好

“与其不同不如更好”讲的是在重新定义好自己的奇点后，再进行进化，从奇点1.0到奇点2.0，再到奇点3.0。人类的进化也是经历了猿人类、原始人类、智人类、现代人类这四个阶段，体现的是一步步的更好。而不是一会不同成猩猩、一会不同成大鱼、一会不同成大鸟，这样永远难以出现代人类，或者需要多付出几百万年的代价才能得到现在的结果。

在AI训练芯片重新定义了自己XPU的奇点之后，需要的是以“市场需求”为进化的引力与方向，从XPU1.0到XPU2.0再到XPU3.0，从而才能进化出未来的XPU N.0。

三个步骤

如上面两图里的”奇点下移，破界创新“，依据奇点理论进行创新的步骤是奇点破界的三个步骤：“破坏，外延，重生”：

1，破坏，找到产品奇点并加以破坏。产品缺点不是奇点，奇点是产品赖以出现与存在的点，找到它，然后破坏它，类似于使得宇宙奇点能量失去平衡；

2，外延，产品奇点下移，产品边界外延，类似于宇宙大爆炸从而造成宇宙边界外延；

3，重生，重构产品奇点，形成新的产品体系，类似于新宇宙的形成。

以AI训练芯片的创新为例，这里只涉及技术面的创新，销售、渠道、运营、管理、商业模式等方面的创新不在本文范围。可以知道的是目前市面上的AI芯片的最大竞争对手是GPU，对其应用奇点创新思维模型的步骤有：

1， 破坏，找出产品奇点，然后破坏它的奇点。例如，我们知道GPU的赖以依存的关键点有：提供图像视频处理功能，依赖于图像视频横向扩展出AI训练功能，依据初代版本时间点的硬件特性进行软件的设计；

2，外延，产品奇点下移，破界，新的产品边界外延。针对以上GPU的三条关键点，提出AI芯片的新奇点：去除图像视频的处理功能简化软硬件的设计，从而节约成本。抓住技术进步的福利，去除历史包裹，依据当前最新的软硬件特性进行产品设计，使之更符合现代的市场需求；

3， 重生，最后更新的、更具有成本竞争力以及技术竞争力的、针对AI训练而实现的新产品”XPU“诞生。

这一套创新思维模型的关键点在于找出原有的产品赖以出现以及存在的“奇点”，然后破界重生。

阿基米德产品思维模型

阿基米德产品思维模型灵感来自于阿基米德的一句话:”给我一个支点,我可以撬起地球。“，因此我定义它为阿基米德产品思维模型，奇点创新思维模型是 阿基米德产品思维模型的子集，如下图：

在阿基米德产品思维模型里产品是一个圆，圆内的三角形是打造产品所需的技术，在产品圆里除了技术三角、还补充了企业文化、企业制度以及组织结构这三个要素，在圆之外还有奇点、壁垒、价值网以及一个支点、一个杠杆、一个作用力。

在这个模型里，支点可以认为是“以客户为中心”，关键能力可以是团队也可以是资本，还可以是二者的组合，产品离客户越远，需要的作用力就越大，产品离客户越近，需要的作用力就越小。企业文化、制度、组织关系是产品的关键要素，但不是决定要素，技术才是产品打造的决定要素，其面积占产品圆的近2/3，狭义上的技术指的是技能，但这里的技术不是，它是广义的，其涵盖：大势、理念、方法论、技能、工具与边界。

小结

本文结合奇点理论讲述了产品的创新思维模型，日拱一卒，功不唐捐，分享是最好的学习，与其跟随不如创新，希望这个思维模型对大家有用。另作者能力与认知都有限，”我讲的，可能都是错的“[1]，欢迎大家拍砖留念。

作者简介

常平，中科大硕，某AI独角兽深度学习首席软件工程师，前EMC 大数据资深首席工程师，主要工作背景在深度学习、流式大数据、云计算、分布式中间件以及Linux内核。

版权申明

本文的版权协议为 CC-BY-NC-ND license：https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用（以获利为准）以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

参考资料

[1]《第二曲线创新》 李善友

导言

架构师是业务与产品之间的桥梁，其应该具备技术与产品的商业意识并且需要有将技术转化为产品的能力。而当前软件架构师在工作过程中往往离不开开源的软件项目，因此经常面临两个问题：”什么是产品？“以及“如何将一个开源的软件项目产品化？”

一套科学技术分析方法的背后有一定有着深刻的理论基础和哲学背景。找到了这套技术分析的源头，才能从本质上把握这套技术，看清其全貌，明了其长处和短处，这样在具体应用中，才能得心应手，提高胜算，并不断的丰富和发展这套技术。基于此，本文提出了一套如何将开源软件项目产品化的方法论。

然而理论与实践是相互作用的，宏观角度知道方法论之后还需要从微观上进行实践，不然就如同知道很多道理却过不好这一生，知道很多原则却写不好代码一样一样的。

什么是产品

产品的定义：

产品是指做为商品提供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合。

从产品的定义中我们可以看到以下几点：

• 属性：有形的物品、无形的服务、组织、观念或它们的组合，因此产品自带有形或无形属性；

  • 有形属性：狭义上产品是被生产出的能满足人们需求的具有物理属性的有形的物品。在绝大多数人的认知里，对产品的理解是停留在这一层次的，产品具有看得见、摸得着的物理形态；
  • 无形属性：广义上产品是可以满足人们需求的任何东西，无形的服务、组织、观念或者它们的组合也是产品。广义上的产品定义对人的认知有更高的要求。服务是产品、企业是产品、团队是产品、认知是产品、本文是产品，这些东西的组合也是产品。万物皆产品，它目前不是产品，那只是没被产品化、或者不在对的时间与空间里；

• 价值：产品首先是商品，其具有交易的价值，能提供给市场，供人们使用与消费，所有不能交易的东西不在产品的定义范围之内，因此这里可以推导出产品是具有价值的，没有价值的东西不属于产品的范畴；

• 交易：产品是做为商品提供给市场，被人们使用和消费，因此具有交易的价值，能满足市场的某种需求；

因此基于以上的产品的公理化定义以及定理化推导得出产品的第一性原理定义：

1

产品 = 属性 + 价值 + 交易

从以上公式中可以认为产品是以属性为要素，以价值为连接，以交易为目的，属性又可分为有形属性与无形属性，二者之间有时候并不是割裂的，价值是能满足人们的某些需求，是物品与货币之间的连接关系，交易是产品生产的目的。

然而这些都是教科书式的 定义，对产品的认知到这一层次已经可以超越绝大部分人，但它也只是停留在”产品“层次，而不是“作品”，更不是“艺术品”。

在我看来 产品 还是具有灵魂的，产品是由人创造的，其自然会带有人的思想、人的创造、人的理念在里头，宗师与学徒画同样的一幅画，虽然东西都一样但是那个味道往往是不一样的。因此，要理解一款产品还需要理解其背后的人的设计理念，在此，我给产品注入人的灵魂，即“理念”，从而进一步扩展产品的第一性原理：

1

产品 = 属性 + 价值 + 交易 + 理念

开源软件是信息的载体，其表现形式是具有无形的信息属性，是作为计算机程序的形式而存在的，要将开源软件产品化就需要将开源软件的属性价值化、可交易化以及注入人的设计理念。

如何将一个软件产品化

价值与交付

如何将一个软件产品化回答的是“How” 的问题，在此之前还应该搞明白“Why”的问题，一个软件产品或者其特性为什么需要做也有一套方法论，这里我称之为 “产品交付之双轮驱动模型”（如下图）：

在这个双轮驱动思维模型里有以下几个原则：

• 以客户价值为前轮，前轮把握方向，解决的是需求探索、价值确定、特性探讨以及价值精炼的过程。首先是以客户价值为导向输入客户需求、但是这个需求还需要去伪存真、去粗纯精、过滤提炼，才能作为产品交付轮的输入，而不是只要是客户需求，不管是真需求还是假需求、也不管是有价值的、还是无价值的都全部输出到产品交付轮，无效的消耗产品交付资源；
• 以产品交付为后轮，后轮提供驱动力，解决的是开发、测试、运维以及获取客户反馈，再根据这个客户反馈的结果作为开发的输入的过程。在产品交付轮中很重要的一环是“反馈“，其角色是作为客户与交付之间的桥梁，开发需要依据”客户反馈”作为输入，而不是自个闭门造车；

• 客户价值又可分为主动式客户价值与被动式客户价值，获取客户需求的方式也需要合理取舍：

  • 主动式客户价值：有些客户”久病成医“，非常清楚自个痛点、难点、挑战点在哪里，也非常清楚自个需要什么样的解决方案可以药到病除，从而可以精确的输出自我的需求。这种客户对产品交付来说可遇而不可得，成本最低，需求最精确；
  • 被动式客户价值：这种情况下，光是在那里等待，从而期望客户能给出明确的需求作为输入，那是缘木求鱼、刻舟求剑，效率也非常低下。如同医院里的医生给病人看病一样，绝大多数客户其实只能知道表征，而不知道根因，因此就需要由产品交付轮以客户专家的角色提出解决方案，作为客户价值需求输入给客户，再看客户的使用效果得出反馈，再依据这个反馈调整解决方案。

• 在双轮驱动模型里，二者谁都离不开谁，不是厚此薄彼的关系，而是二者互相协作从而推动产品往商业成功这个目标前进的关系；

• 先有买家需求再有产品交付，而不是先有产品交付再找买家需求，需要明晰这个先后关系，为客户找出差异化需求才是产品交付的本质，寻求差异化、避免同质化，才是真正的以客户为中心。

因此，在将一个技术产品化之前，先花几分钟时间问问其价值在哪里，为什么需要做这个，这一点很重要，要能区分客户要的是能马上就能解决痛点的止痛片还是可有可无的无关紧要的维生素，从而以此进行任务排序，明晰产品交付与客户价值的双轮驱动关系，要能清楚的理解“以客户为中心”的价值理念以及让产品的获得“商业成功”的终极目标。

技术产品化

通常来讲开源软件的产品化可以从价值、交易以及理念这三个方面进行。价值：可服务化、无形化有形、价值竞争，交易：可度量化、个性标准化，以及融入人的设计理念：复杂简单化等。

可服务化

可服务化指的是从技术实现上支持可服务化，ToB产品常常是半产品半服务的，而且一般会签约服务质量保证协议SLA，因此除了团队需要有替客户解决问题的能力外，还需要从技术与流程上支持可服务化，其中包括：

• 可运维性：易用的部署（步骤量化）、升级（AB测试、in-place、replace、rolling-back等）、数据迁移、自动化运维支持等。在一个产品的全生命周期里，开发也许只占20%不到的时间，而将近80%的时间都需要运维，因此需要拿出近4倍比的开发重视程度，重视可运维的设计与实现；
• 可观测性：可观测性主要分为四大类: 监控、告警、日志、追踪；
• 可操作性：支持远程接入、开放服务接口、后台管理UI、CLI、特性参数配置开关；
• 健康管理：健康检查支持、健康报告支持、自动提交故障问题单支持；
• 安全性：安全性是企业级产品必备，数据保护、密码安全、连接检查、LIB库授权协议等；
• 多租户：多租户可以支持多团队、多部门小规模部署，进行业务隔离，也是非常重要的企业级特性；
• 可视化：提供易用的用户UI、CLI;
• 可支持：如何指定进行客户支持规则？如何升级成工程师团队介入提供服务定位问题或者排除问题？

当看到以上类目，脑海里就能闪现出需要怎么去实现这些以及用什么组件可以最佳实践的快速完成交付，而不是停留在概念的阶段，那才算对可服务化有了自己的理解。

无形化有形

无形化有形指的是将无形的软件硬件化或者云化，单单一个软件包是难以让用户买单的，需要把它硬件化，打包到服务器里以有形产品的形态销售出去，或者云化后以服务的无形形态销售出去。

价值竞争

价值竞争指的是“参与到客户的购买周期中，在每个阶段为客户创造价值”[3]，从单纯的销售产品到提供整套生态化的解决方案。单纯的依靠销售产品往往已经难以给客户提供差异化的价值，并且也会面临低利润的同质化竞争，那么这个时候就需要更进一步的提供生态化的解决方案，针对行业需求做端到端的全生态化的解决方案。

生态化的解决方案化能给客户提供差异化的价值关系。比如，一份药品在药店里只能卖30块，而且只是一次销售无法挖掘后续价值。但是到了医院就不一样了，其依据客户的”恐惧“为刚需的基石，提供一整套的类生态化的医疗解决方案，从挂号预约、望闻问切、到各种仪器设备过一遍、再到开出药方、再依据客户的反应效果把这个过程再来几遍，因此在药店里30块钱的药，在医院里就能卖到 300块、3000块，获取十倍、百倍、千倍利润。

可度量化

可度量化指的是质量要可以量化，可预测的业务指标（比如AI训练里的精度、加速比、收敛时间、训练次数等）、性能、可靠性、可用性、可伸缩性、稳定性、容错性、可测试性等，这些很抽象的指标要能量化。在产品功能同质化的场景下，质量是最重要的差异化竞争力。

业务性能、可靠性、可用性、可伸缩性这几者之间页互相制约，质量与成本、时间也互相制约，同时在云化的场景下客户又有SLA要求，不满足SLA要求的服务，除了要赔钱，还严重影响商业信誉，因此质量指标之间也需要合理取舍。

个性标准化

个性标准化指的是将个性化的、“DIY”化的开源项目转成标准化的、可复制的、可量化的，同时依据资源的规格约束进行标准化，比如依据服务器规格、虚机规格，机架规格等进行标准化，例如AI服务器的配置就需要定义CPU、内存、磁盘、带宽以及训练卡的标准的规格，这样才能提供可预测的性能、可预测的加速比等质量指标，再比如云端场景下的服务监控，除了定义指标的名称之外，还需要定义监控指标的类型、故障码、输出的标记以及对应的处理措施等，所有的这些都要能标准化、可操作性化。

复杂简单化

复杂简单化指的是把复杂的体验简单化， 抽象及简化API、量化的安装步骤、高内聚低耦合的设计、易用的UI等，这里又涉及到产品设计哲学、人类的心理学等，也跟人的设计理念相关。

小结

本文以方法论的形式解读了软件开发过程当中经常会遇到的两个问题：”什么是产品以及如何将一个开源的软件项目产品化“，讲的是“无用”的知识。

日拱一卒，功不唐捐，分享是最好的学习，与其跟随不如创新，希望这个知识点对大家有用，另作者能力与认知都有限，”我讲的，可能都是错的“，欢迎大家拍砖留念。

作者简介

常平，中科大硕，某AI独角兽深度学习首席软件工程师，前EMC 大数据资深首席工程师，主要工作背景在深度学习、流式大数据、云计算、分布式中间件以及Linux内核。

参考资料

[1] https://a16z.com/2019/10/04/commercializing-open-source/

[2] https://baike.baidu.com/item/%E4%BA%A7%E5%93%81/105875

[3] 《价值竞争：以客户为中心的销售转型》 - 付遥

版权申明

本文的版权协议为 CC-BY-NC-ND license：https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用（以获利为准）以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

前言

分布式系统是一门讲究实践的软件工程，只有PK过设计方案，从微观处手把手的敲过一行行的代码，才能知道细节在哪里，难点在哪里，痛点、挑战点在哪里。同时，分布式系统也是一门讲究理论的软件工程，从宏观处着眼深刻理解系统设计的理论，将理论与实践相结合，想好、做好、说好才是真的好。因此，宏观处着眼，微观处着手，才能真正掌握分布式系统。自此，本系列文章开始讲诉分布式系统设计里的基础理论，本文为CAP与PACELC理论。

CAP理论与PACELC理论

CAP理论

CAP理论是分布式系统最为基本的指导理论之一，是分布式系统设计时最为基本的取舍依据，CAP理论认为一致性、可用性、分区容忍性不能同时满足，即：

• 一致性(Consistency): 所有的节点在同一时刻看到同样的数据；

• 可用性(Availability): 节点失效不会影响系统的读写；

• 分区容忍性(Partition Tolerance): 系统能支持网络分区，即使分区之间的消息丢失系统也正常工作。

但是，CAP理论也有其自身的局限性。在工程实践中CAP理论的应用可以一分为二：系统整体以及系统内部。比如，系统整体可以选择CA或者CP，但是系统内部微观处有些特性却可以同时满足CAP三要素，因为分区是件极少发生的事，为了追求卓越的设计理念可以尽量同时满足CAP三要素。根据业务场景的不同，不同的分布式系统会根据自身业务的需求在CAP三者中进行取舍， CAP理论的意义是一种在分布式系统设计时取舍的参考因素，而非绝对的三者必舍其一。

此外，在CAP理论中是没有提到系统的时延（Latency）的，而访问时延（Latency）却是很重要的可用性(Availability)因素，因此又延申出了PACELC理论。

PACELC理论

PACELC理论是CAP理论的扩展，PACELC理论在wiki上的定义是:

It states that in case of network partitioning (P) in a distributed computer system, one has to choose between availability (A) and consistency (C) (as per the CAP theorem), but else (E), even when the system is running normally in the absence of partitions, one has to choose between latency (L) and consistency (C).

意思就是：

如果有分区partition (P)，系统就必须在availability 和consistency (A and C)之间取得平衡; 否则else (E) 当系统运行在无分区情况下,系统需要在 latency (L) 和 consistency (C)之间取得平衡

如下图，在PACELC里添加了Latency要素：

当前分布式系统设计指导理论应当采用PACELC理论替代CAP理论，理由如下：

• PACELC更能满足实际操作中分布式系统的工作场景是更好的工程实现策略；

• 当partition (P)存在的场景下，需要在availability 和consistency (A and C)之间取舍，但是实际上分布式系统中绝大多数时间里partition (P)是不存在的，那么就需要在latency (L) 和 consistency (C)之间作取舍；

• Availability在不存在partition (P)的场景下跟 latency关联,在partition (P)时跟”可靠性“指标相关联；

• PACELC 可以在 latency 与 consistency之间获得平衡；

• CAP 理论忽略了 一致性和时延之间的取舍；

PACELC理论是建立在CAP理论之上的，二者都描述了一致性(Consistency)、可用性(Availability)和分区容忍性(Partition Tolerance)之间的约束与取舍。而PACELC理论则更进一步描述了即使在没有Partition的场景下，也存在Latency和Consistency之间的取舍，从而为分布式系统的Consistency模型提供了一个更为完整的理论依据。

理论应用

要保证系统数据的高可用（high availability）那么有个技术方案是采用数据冗余备份的方式，那么就涉及到复制数据，而进行分布式系统的数据复制，就会出现在Consistency和Latency之间做个取舍的要求。举个例子，如下图所示：

在强一致性复制场景下，需要三副本都下盘才能返回OK确认信息给client端，假设Master节点向 Slave 节点复制数据，时延的限制是 20ms，有时候，slave 2 硬盘或网络出现故障，Master 往 Slave 复制数据的时延超过 了20ms，这个时候如果还一直等待 slave 2 返回结果再通知给client就会出现性能和时延抖动，而且这种抖动是经常会发生的长尾效应。

依据PACELC理论，我们可以在 consistency和Latency之间做个取舍，比如 slave 2 节点的时延超过 20ms了，就不等待slave 2 返回，master 和 slave 1 返回结果给client即可，如果 slave 2 出现 超时的 次数超过 5次那么就认为 这个节点可能出现故障，打个故障标签，进行后续的处理。采用这种方式可以消除写时的长尾抖动，获得更优雅的写时性能曲线。

小结

本文遵循理论与实践相结合的指导思想讲述了CAP理论与PACELC理论。日拱一卒，功不唐捐，分享是最好的学习，与其跟随不如创新，希望这个知识点对大家有用。另作者能力与认知都有限，”我讲的，可能都是错的“，欢迎大家拍砖留念。

作者简介

常平，中国科学技术大学硕士研究生，深度学习首席软件主管工程师，前EMC 大数据资深首席工程师，主要从事Linux内核以及分布式产品的架构设计、开发以及交付工作。

参考文献

[1] https://en.wikipedia.org/wiki/PACELC_theorem

[2] CAP理论与分布式系统设计，S先生

版权申明

本文的版权协议为 CC-BY-NC-ND license：https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用（以获利为准）以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

前言

编程是一种创造性解决问题的能力， 其本质上是一种思维体操，可以大大的提升人的逻辑能力、推理能力以及解决问题的能力， 那么什么是分布式系统的编程思维呢？

编程思维模型

具体来看分布式系统的编程思维包含11大内容：

抽象、分层、解耦、拆分、聚合、治理、取舍、模型、演化、质量、边界。

//TODO

小结

本文解读了分布式系统的编程思维模型。日拱一卒，功不唐捐，分享是最好的学习，与其跟随不如创新，希望这个知识点对大家有用。另作者能力与认知都有限，”我讲的，可能都是错的“，欢迎大家拍砖留念。

作者简介

常平，中科大硕，DELL EMC 资深首席工程师，曾就职于Marvell、AMD，主要从事Linux内核以及分布式产品的交付、架构设计以及开发工作。

参考资料

[1]

版权申明

本文的版权协议为 CC-BY-NC-ND license：https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用（以获利为准）以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

前言

懂得很多道理，仍旧过不好这一生。懂得很多分布式系统的概念以及设计方法，依旧做不好分布式系统。分布式系统设计是一门实践软件工程，只有你PK过设计方案，手把手的敲过一行行的代码，才能知道细节在哪里，难点在哪里，痛点、挑战点在哪里，不是看书或者看文章就可以完全掌握的。因此，宏观处着眼，微观处着手，才能完全掌握分布式系统设计的道理。本文抽象出分布式系统的思维模型，当你看到这个模型里的字眼与图画，就可以从脑海里分解出一个个设计方案、一行行代码的时候，那才是真的掌握了分布式系统的精髓。

分布式系统八卦思维模型

这里我提出一个分布式系统八卦思维模型，如下图，其要义如下：

方法论

核心：在前面的文章里讲到可以用一句话来描述分布式系统：

分布式系统是指其组件位于不同的网络计算机上的系统，这些组件通过相互传递消息来进行通信和协调其动作，且彼此相互交互以完成一个共同的任务目标。

并且提到了“系统 = 要素 + 连接 + 目标” ， 这个思维模型的核心即分布式系统的第一性原理， 公式：“分布式系统 = 计算机 + 网络 + 协同”，要素是计算机（新的虚机、容器也算），连接是网络，目标是协同以完成共同任务。

提供：即服务接入的提供，指的是对外提供restful 接口服务：权限、多组合、监控、审计、计费等，对外提供SQL服务接入接口服务、对外提供自然语言接入接口服务等
注册：即服务注册，将集群的工作负载注册到集群注册中心
配置：即配置管理，将集群的配置管理在配置中心；
调用，即服务调用，各种RPC调用，系统内的消息传递
路由：即服务路由，目的是集群的负载均衡与扩伸缩性
观测：指的是集群内部指标的可观测性，即监控、告警、追踪、日志
治理：指的是集群内部的服务治理：熔断、降级、限流、隔离、容错
编排：即服务编排，基于k8s+ docker，完成安装、升级、扩容、运维、调度等；
质量：指的是安装部署运维质量、客户质量、用户质量与开发质量
边界：指的是系统内的约束条件，涵盖 硬件资源、客户约束、用户约束以及团队约束

这10个功能与核心之间是互相联系、互联影响的，因此类似于一个八卦图。

底层思维

1

抽象、分层、解耦、拆分、聚合、治理、取舍、质量、边界、模型、演化

抽象、分层、解耦、拆分、聚合、治理、取舍、质量、边界、模型、演化是分布式系统设计的底层思维，也是软件工程的底层思维，这个主题很难掌握，目前，这里不展开讲。

基石假设

分布式系统有两个隐含的基石假设，即 “资源协同与质量可预测”，资源即计算机、虚拟机、容器以及网络，基于此，分布式系统的第一性原理 即： “分布式系统 = 计算机 + 网络 + 协同 ，以质量为度量”。

小结

本文提出一个分布式系统八卦思维模型。分布式系统不是我首创，用这个类八卦图形来表示思维模型也不是我首创，但是用这个类八卦图形表示分布式系统思维模型应该是我首创，目前不管是书籍还是网络都找不到这样的分布式系统思维模型。日拱一卒，功不唐捐，分享是最好的学习，与其跟随不如创新，希望这个知识点对大家有用。另作者能力与认知都有限，”我讲的，可能都是错的“，欢迎大家拍砖留念。

作者简介

常平，中科大硕，DELL EMC 资深首席工程师，曾就职于Marvell、AMD，主要从事Linux内核以及分布式产品的交付、架构设计以及开发工作。

版权申明

本文的版权协议为 CC-BY-NC-ND license：https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用（以获利为准）以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。