反思软件开发：知识流动（下）

欧雷 发表于 1 天之前

0 条评论

标签：软件工程前端开发前端工程效率提升

本文来说说在企业中让知识流动起来的大体思路。

在以互联网或软件及服务为营生的企业中，各个层级、分工的人和处理各类事务的应用软件是办公与业务运作的两大要素；企业中的绝大部分人是员工这很理所当然，但为何不能把工作中所用到的各种应用软件看成整体，也当作一名员工来看待呢？

将这名特殊的「员工」称为「数字员工」，与其他员工不同的是，它是纯虚拟的、数字的，没有物理层面的形态，但与其他员工一样可以处理工作上的事务。

也许一开始啥也不会，但在像训练动物或教导小孩般对其加以训练，某些方面可以做得比人更出色，尤其是机械重复性工作！再加上该「员工」没有七情六欲，不知疲倦，比人更加稳定可靠且经济实惠。

如同人类员工会被按照能力和职责等进行职级划分，数字员工同样也存在等级——

处理各类事务的能力七零八落，像精神分裂般没有整体感，像智障一样没有一点智能；不具备任何知识，即便有，相互间也是割裂的——几乎就是像锤子那样的工具。

部分能力之间相互打通，一些知识可以小范围内流动起来，形成更为有效的系统；减少人类员工间的沟通，提高机械重复性工作的效率——算是简易流水线了。

绝大部分企业中的数字员工都是这两个级别的，相对（十分）低能，需要人类员工手把手操控；人类员工与数字员工之间是从属关系，或者说是主奴关系。若以「人」的标准要求，这两类数字员工就是残疾。

而更高级些的数字员工，与人类员工之间应当是伙伴关系，是强有力的助手，让人类员工可以基本摆脱机械重复性工作，转而将工作重心从事创意性内容——从体力密集型转向脑力密集型。

可以说，智能助手是最高级别的数字员工了，是企业内部的「万金油」，承担这一角色的非智能工作台莫属，其核心为——

在当下这个时代，无论是个人还是企业，知识都是最为重要的资产；但如何有效地沉淀知识，并让它们像活水一样流动起来，这是很多个人与企业都面临的一个难题。

对于企业而言，知识更是推动创新所需要的原料，无法创新的企业只能坐吃山空，进而被时代所淘汰；企业常会以人员的频繁换血来谋生机，但这基本是无效的，自上而下地推行知识管理才是正道。

有效的知识管理必须先以《反思软件开发：知识流动（中）》中阐述的那几个基本原理为基础，打造出企业内专有的、集中式地中心化管理各类知识的庞大知识库。

企业员工脑中与企业有关的知识，不仅是员工个人的，也可以转化为企业的，因而企业知识来源于一个个员工的个人知识；所以，如何让员工心甘情愿并舒服地将他们脑中的隐性知识显性化为企业知识，是每个企业高管该用心考虑的。

企业知识虽来源于个人知识，但并非个人知识直接就成为了企业知识，而是经过一定范围内多人讨论后变换得来，这也算是「共识」；是共识就应当尽可能地固化进工具或流程中，减轻并脱离对人的意志等的依赖。

没做好知识管理的话，企业的成果会高度依赖于员工个人，存在于员工脑中与企业相关的隐性知识将随着员工的离职而丢失；若这部分知识数量较多或（潜在）重要性较高，那企业将会遭受较大损失。

大多企业都有知识管理，但很多是将知识散落在多个应用上，如 Confluence、禅道等；这些应用间本身就是较为割裂的，知识间的关联性弱到几乎没有。

如果知识管理不是基于「唯一可信来源」（下文称「SSOT」）的中心化方式，如同一盘散沙，跟没有也没啥区别；遵从「SSOT」进行中心化管理的知识库就是智能助手的「大脑」，使其具备「记忆」能力，可将知识作为后续行为的原料。

智能助手的其他能力实际是输送知识的管道或变换其形态的转换器，人类员工的最终产物（工作成果）皆由数字化的知识经过各部分能力所连成的管线推导而来。

产研一体化

这里说的「产研一体化」就是将企业的数字产品相关的知识自动推导生成为应用成品的管线，其核心理念依然如《聊聊中后台产研一体化：引子》中所说。

在我所设想的「产研一体化」中，「（业务）应用」是「需求 + UI & UX + 低代码框架」，忽略一些细节后可以形式化表达为 App = Render(Extract(需求, UI & UX))。

其中，「需求」是「某一版本的知识集」，Render 是低代码框架的一部分，而 Extract 则是知识库与在线设计器。

在传统的产研协作模式中，需求管理，或者说业务知识管理很容易混乱——知识以不同的形式散布在不同平台、IM 中，并且知识之间没有关联；经常口头产生或更改需求，没有落实为数据存留下来，导致知识丢失。

在产品经理出了 PRD、原型之后，UI & UX 设计师出设计图，后端建表、写业务代码，前端再根据产品经理、UI & UX 设计师及后端的产物去编写页面代码——他们的工作是相对割裂的，各环节产物之间没有实际的关联关系，改个需求要分别更改。

但在我所设想的产研协作模式中，将「需求」抽象为「知识」，一切需求变动都要先更新知识数据，然后自动将变更反应到「应用」这个最终产物上——这便是以「知识」作为「SSOT」的「产研一体化」。

产品经理整理各类需求，抽象并沉淀/更新与自身业务相关的业务概念，明确它们之间的关系和作用规则，这些会留存在知识库中，能够以文章、流程图、知识图谱等形式查看；挑选几个固定版本的知识创建一个集合，这就是一个「需求」，可以认为是「PRD」。

产品经理在做这些事情时实际上就是在本体建模或领域建模，其产物可以转化为供低代码框架消费的元数据，用于后端处理业务数据和前端对数据进行校验等处理。

产品经理再在在线设计器上通过可视化的方式从领域模型中选取字段，从已有的交互模式库中选取合适的 UI 组件，经过一系列拖拉拽操作后就产生了「原型」，与传统模式不同的是，这个「原型」发布后就是页面的最终效果。

如果 UI & UX 设计师对「原型」的某部分视觉效果不太满意，也可以在在线设计器上进行微调。

以下为大概的示意图（一年前画的，但整体思想差不多）：

示意图

总结下新的模式与传统模式的不同点：

1. 「知识」驱动，以「知识」作为「SSOT」，强制使知识保持最新，不会出现知识分散与丢失的状况；
2. 「代码」与「需求」间建立了关联关系，根据由「知识」衍生的元数据自动化生成/更新业务应用（的功能）；
3. 「代码」与「设计」间建立了关联关系，UI & UX 设计师在平台上微调产生的配置数据会生成前端页面的样式代码。

「产研一体化」这条自动推导管线的关键点是要抽象出数量最少、可组合性最高、可解释性最强的几个原子化概念，就像物理中的「粒子」、「力」等一样，它们之间的相互组合与作用可演化出万物。

作为区别于其他更低级别数字员工的关键，智能助手必须搭载 AI 以让它拥有「智力」，从而具备自主学习的能力，能够了解企业并理解人类员工的需求，进而在被动接受指令执行任务之外还能主动进行提醒与建议等。

遵从「SSOT」进行中心化管理的知识库为 AI 提供了海量优质的学习材料，可在此基础上训练出最懂企业的专属模型，如此一来——

人类员工在新增或编辑知识时，会自动拉取关联度很高的其他知识进行提示；人类员工输入的知识及与智能助手之间的交互同时也能使它变得更加「聪明」，更懂那个人类员工的习惯。

团队中某个人有事要请假，领导在审批时智能助手会根据任务的排期与状态以及备选人员情况等信息进行建议，看是否予以通过或想些替代方案。

需要接手他人工作的人类员工，智能助手会收集整理好一份较为全面且详细的交接文档供其阅读理解，并根据人类员工的能力等提供能够快速上手的建议。

当监测到企业业务所关联的政策、行业等的重要动态时，智能助手会通知相关人员，并提醒有哪些知识需要进行更新以紧跟时事，及时应对变化。

除了以上列举的场景，还能做到很多令人感到「贴心」的事情！

一家企业内不仅有人类员工，还有可将工作中各种数字化手段整体看待的数字员工；其中，最高级别的是智能助手，智能工作台承担了这一角色。

智能助手能够卓有成效地帮助人类员工解决机械重复性工作，使人们可以专注于创意性内容，真正地从体力密集型变为脑力密集型；它就像是个「贴心」的小秘书，因而不能把它看作奴仆，而是伙伴。

由于智能助手的特性，一个需求的出现，一个想法的诞生，它们是否靠谱在输入进去之后的那一刻就能得到初步验证；经过大家共同讨论与修改，敲定后的结论就作为知识在智能助手中留证，并直接看到数字产品的最终成品。

ChatGPT 的横空出世，带来了一些影响——

既标志着 AI 对人类自然语言的理解能力已经达到可落地推广应用的程度，同时表明自然语言用户界面（LUI）在某些场景下可以取代图形用户界面（GUI）——通过输入文字或说话告诉智能助手把页面背景色从白色变成红色。

倒逼着那些自己逻辑不清晰，表达能力差，不会描述问题的人乖乖承认是自己不行，而无法甩锅给别人；让某些老板意识到智能助手及伴随的组织架构与协作模式的变革是企业在未来得以生存的关键，晚一步就会被时代所淘汰！

此外，企业知识来源于员工的个人知识，那么员工个人的智能助手与企业的智能助手之间无缝对接的话，会产生什么效应？