如何理解形式和功能？复杂系统的产品设计与开发
有一天我在逛知识星球的时候，看有人推荐《系统架构 复杂系统的设计与开发》，于是买了实体书，读完后感觉很有价值。
抽象，复杂，难以理解的同时，呈现出来的是一套高屋建瓴的方法论。
有软件开发经验的同学，肯定可以从中读到日常工作的细节和影子。
本文主要分享功能和形式
软件系统定义
书中结合涌现首先对系统进行了定义
系统 是由一组实体及实体之间关系构成的集合，其功能要大于这些实体各自的功能之和。
实体之间的关联建立起来，各个模块完成之后，整个系统就会出现一些意想不到的功能。
可以是正向的，也可以是反向的，整体大于各部分之和。
这也可以解释，事情做到一定程度之后，会有新的想法，新的问题出现。
因为「实体之间的关系」需要在系统运行的过程中体现。
涌现
系统架构这本书又一次重点讲述了「涌现」，涌现伴随着软件系统生命周期。
最先接触到 「涌现」 这个词是 在《失控》这本书，当时的理解是我们脑海中出现的一些想法。
现在想来，当时的理解比较肤浅。可以参考我之前的一篇分享 读完《失控》，我总结了这三点与你分享：分布式，去中心化和不均衡态的加速交付
系统思维的主要目标，就是努力了解并预测涌现物以及涌现物带给系统的强大能力。
我们经常说，想做一件事的时候，先启动，先完成，再完善。
结合涌现的思考，当我们在做一件事的过程中，事物呈现出来的状态，能够涌现出更多相关的关联因素。
包括我们的想法，与预期的差异等等。做的做的过程中，就有了新想法了，也是这个道理。
系统思维
确定系统中实体及其形式和功能
一般来说，系统中的每个实体都有其形式和功能。
那如何理解形式和功能？
形式和功能是系统的两个属性
书中把软件系统分解为形式和功能两个大的方面。
形式
系统有两个属性，一个是形式，一个是功能。形式说明系统是什么，功能说明系统能做什么。
或者说，形式是名词，而功能是动词。
在产品设想，原型设计，系统架构的时候，首先我们想到的是产品要满足什么样的功能需求。
其次以什么样形式展现给用户，再者就是这样的形式存在什么样的关系和结构。
像小程序，网站，H5 界面这些都是系统形式，在线和购物，居家团购就是系统功能。
形式强调存在性
每个系统都可以作为形式来出售，形式通过表现出来的功能而体现价值。
要执行某项功能，需要一个工具来承载，形式就是通过操作来体现系统功能的「实物」
商品是有形的产品，可以认为是形式。
服务是无形的，可以认为是功能。
所有由人类构建而成的系统，其本身都同时存在于物理领域和信息领域中。
这也是后边所说的二元原则。
功能
对特定的系统，分析对外体现的，与价值相关的主要功能是什么？
系统的功能需要对外展示，也就是说，系统的一条重要原则：功能与价值总是体现在系统边界处。
翻译过来，只有在跨界输出时，才能体现出最大价值。像 设计团队，只有在交付设计方案时，才能体现出价值。
而这些功能和价值就是我们构建系统时的目标。
二元原则
所有人类构建而成的系统，其本身都同时存在于物理领域和信息领域。
做软件的过程中这两个领域都需要思考。
翻译过来，计算机软件系统是对现实事物的抽象。
之前我就听说过一个观点，计算机系统中大多数专有名字都来源于现实世界，比如说，防火墙，安全区，账户，密码等等。
信息歧义与复杂度
公司有一个 PMO 小组，什么是 PMO 小组，就是项目管理委员会。PMO 们主要职责是跟踪落实项目的开发上线进度，协调相应的资源，降低项目延期风险。
有一天我再跟进一个新进排期会的项目， 一个需求，包含有四个子需求。我之前又没接触过这块的业务，各个参与方一概不知。就一脸懵。
然后这时候产品同事还需要各个需求的大概时间节点，用于 回复业务方。
那么问题来了，之前没接触过的业务线，涉及方比较多，如何破解？
这种情况是作为 PMO 最困难的地方。
如果不了解需求背景，和常规的上下文，遇到问题时就很难控制和做判断。
书中关于架构师职责中有这么一段话,正好引导了我的工作。一点点的对齐信息歧义
某个事件或者状态被解读为不同的含义，就会出现模糊现象
事件的结果不明确或者值得怀疑，会出现不确定
模糊的，不确定的都是有歧义的。比如项目的参与方，需求方，截止日期等。
结合工作场景，其实我们每天工作交流的主要任务就是做这些事，避免信息分歧。
而团队管理者的任务可以理解为
减少歧义，更新目标，管理复杂度。
总结
1 系统是由一组实体和这些实体之间的关系所构成的集合，其功能大于这些实际各自功能之和，系统架构是对系统的抽象的描述；
2 形式和功能是系统的两大特征，形式表达的是系统是什么，而功能体现的是系统能够做什么，它们是我们分析系统的重要角度；
这篇文章分享的关键词是 系统，功能，形式，涌现和复杂度信息歧义。
这本书中的呈现的系统架构原则有几十种，后续我将结合工作案例和个人感悟继续分享。