读完《系统架构，复杂系统的产品设计与研发》记住这三个词
读完《系统架构，复杂系统的产品设计与研发》记住这三个词
这篇文章是《系统架构，复杂系统的产品设计与研发》第二部分。
本文主要围绕 概念，需求与目标三个词展开。
之前第一部分主要围绕涌现，形式和功能三个词阐述。原文参照这里
我认为这六个词是这本书的核心之处，值得关注。
概念
什么是概念
概念是我们对产品或系统所形成的图景，理念，想法或意象。
概念把功能映射到形式。
概念虽然不是产品/系统的一项属性，却是形式与功能这两项属性之间的一种观念映射。
翻译过来讲，我们给用户描述系统或者产品时，通过概念可以让用户直观的感受到产品最终的样子。
书中特别强调
概念虽然不是产品/系统 的一项属性，但它却是形式与功能这两项属性之间的一种观念映射。
概念不是产品/系统的属性，而形式和功能是。
在我看来由概念到产品的过程就是讲故事，并且实现故事的过程。
概念是表达想法使用的语言
之前在一篇博文中说到系统复杂性，文中强调
复杂性就是任何使得软件难于理解和修改的因素
我们说到软件开发，随即想到一些词，像高内聚，低耦合。自顶向下，分而治之。模块化，服务化，都是为了降低软件的复杂度。
复杂性
John Ousterhout 教授在《A Philosophy of Software Design》书中提到了一个非常主观的见解：
复杂性就是任何使得软件难于理解和修改的因素
John 教授将它抽象为变更放大（Change amplification）、认知负荷（Cognitive load）与未知的未知（Unknown unknowns）这 3 类
变更放大
看似简单的变更需要在许多不同地方进行代码修改
认知负荷
认知负荷（Cognitive load）是指开发人员需要多少知识才能完成一项任务。
使用功能性框架时，我们希望它操作简单，部署复杂系统时，我们希望它架构清晰，其实都是降低一项任务所需的成本。
盲目的追求高端技术，设计复杂系统，增加学习与理解成本都属于本末倒置的一种。
未知的未知
未知的未知（Unknown unknowns）是指必须修改哪些代码才能完成任务
或者说开发人员必须获得哪些信息才能成功地执行任务
在日常工作中体现在不知道需要修改哪些功能，影响范围在开发之前无法判断。
「复杂性」贯穿整个产品设计与开发周期，降低复杂性是架构师的重要职责之一。
书中有专门一章提到了架构师的角色，减少歧义，制定解决方案，交付结果。
架构师的角色
我一直有一个观点，架构师有两个属性
一个是权力，一个是责任。
架构师绝不仅仅是技术资历更高的工程师而已。
读完这本书，结合最近的经历，这句话描述架构师更合适
架构师是构建产品解决方案，并付诸交付的管理者和执行者。
减少歧义
某个事件或者状态被解读为不同的含义，就会出现模糊现象
事件的结果不明确或者值得怀疑，会出现不确定，模糊的。
不确定的都是有歧义的。比如项目的参与方，需求方，截止日期等。
其实每天工作交流也就是做这些事。
团队管理者的任务可以理解为，减少歧义，更新目标，管理复杂度。
需求与目标
说出你的需求，我们通常说，技术服务于业务。
利益相关者
在我看来设计系统之前，有两项需要知道。一项是系统的利益相关者和受益者有哪些。
第二项是需求方描述的需求是什么样的。
软件系统参与者通过交付软件体现价值。利益相关者理论有一个核心原则，认为利益相关者的价值是从交换中得来的。
这个理念与经济学上的一个观点契合
合理制度下的交易让双方变得更好
目标
目标可以定义为计划完成的事，生产企业想要完成的事
目标是产品系统的一项属性
书中将目标围绕系统问题陈述展开。
通过 To-By-Using 框架（为了-通过-使用）来系统陈述问题。
充分了解了软件系统三个属性，形式，功能，目标之后，
一起看看书中提到的 四步通用产品的开发过程
通用产品的开发过程
产品开发过程分为 4 个活动。分别是 构思，设计，实现和运作。
构思：根据市场需求以及目前可供使用的技术决定构建何种产品。
设计：将要实现的东西表达成信息对象
实现：把设计变为现实
运作：运行产品，体现价值，也就是我们通常所说的运营。
之后就是迭代优化升级。
提出概念，确定形式，整理需求和目标，实现功能，展现价值。这就是复杂产品设计与开发的核心路径。
这是一本高屋建瓴的理论书籍，读完这边书，结合实际工作经验，有一种似曾相识的通透感。
原来可以这样理解软件产品。
理论结合实践，两方面都很重要。
总结
今天学习到一个观点 分享到这里，作为本文的总结。
自己思考，做决策时，需要抽象。 给别人解释事物时，需要具象。
软件设计最讲究抽象能力，软件实现就是具象和落地。
厉害的人只讲人性，不讲逻辑，人性会决定他的逻辑
一个人使用 什么逻辑决定于他是什么思维框架。
先把架构原则搞清楚，再做编码执行。
参考文档