工作思考：降低工作对 knowhow 的需求

在开发软件的时候，我们常常遇到这样的现象：同样的一个功能开发，为什么有的人（老法师）可以做的又快又好，而另一个人（新员工）却总是磕磕绊绊，反反复复。

然而，铁打的项目，流水的小兵。作为小兵的我们，常常就突然收到领导的一个消息，和从未接触过的客户打交道，然后独自完成一个从来没有做过的项目软件。

但不会有人会因为你是新人就降低项目的需求，更何况这些需求对于一个小兵来说可能它之前从未听说过。可是，如何才能让一个新员工能够快速地上手工作呢？其实解决之道无非是以下两种：

让员工变得更强

把工作变得简单

那有没有什么办法，能在短时间内提高新人的能力，快速地成长呢？很遗憾，这个并没有。因为能力可以提高，但绝对无法速成。

那我们换一条路试试，有没有办法能让工作变得更为容易上手呢？如果这条路行得通的话，那也算是帮了大忙了。

要解决这个问题，我们需要引入两个基本概念：工作中所需要的“最小knowhow”与“工作knowhow”。工作中所需的“最小knowhow”是完成任务的基础门槛，而“工作knowhow”是把任务做好的关键密码。

前者回答“怎么做”（What/How），后者回答“为什么这样做”（Why/Best Way）。

前者的减少意味着工作变得更为简单容易，而后者的增长意味着员工的工作能力变得更强。

举个具体的例子：对于一项安装螺栓的任务，工作所需的“最小knowhow”就是使用扭矩扳手把这个螺栓装上去，用100nm的扳手，把5号螺丝顺时针拧5下装上去。而“工作knowhow”则需理解为什么要选用扭矩扳手，为什么设置100nm，为什么用的是5号螺丝，为什么是拧5下而不是4下或者6下。只有真正了解其中的各项工作原理的“老法师”，才能将其真正的描述出来。

因此，“最小knowhow”是“完成任务的入场券”，确保我们能“开始做”且“不犯低级错误”。而“工作konwhow”通常指难以用文档或语言明确表达的经验、技巧、直觉的隐性知识。例如对复杂系统的深层理解、故障排查的“灵感”、特定方法论的优化经验，或团队协作的默契。而我们所说的降低工作对knowhow的需求就是就是基于最小knowhow去考量的。其核心思想就是通过显性化、标准化、自动化，将隐性知识（复杂的知识原理）转化为可传承、可复用的资产。

最终目标是让团队从“依赖少数核心成员的经验”转向“依赖可传承的资产和标准化的流程”，从而提升项目的可维护性、降低人员变动风险。

1️⃣ 隐性知识显性化

隐性知识特点是“难以言传”，这大大限制了它掌握程度与传播广度。但我们可以将隐性知识进行结构化的记录和沉淀，将其转化为可记录的资产。

例如编写功能开发报告，软件编写规范，DFMEA，软件集成指导书等。除此之外，我们还需要加速这些知识在团队内的传播。例如组建公司论坛，搭建知识AI系统，构建团队分享文化等。

2️⃣ 显性知识标准化

从我入职起，领导就反复强调：“一定要遵守流程标准，流程是我们的保护伞”。实际上，公司的隐性财富，其实就是由这么多的指导书，工作手册，流程方法等累积形成的。

通过标准化工作流程，不同人员在执行相同任务时能遵循一致的方法，降低因人员差异导致的实现偏差和质量波动。

而这些标准化，其实就是我们在工作过程中所需的“最小knowhow”。留心的你肯定会观察到，公司里的那些“标准规范”，几乎全部都来自于那些“老法师”之手。

3️⃣ 标准流程自动化

当我们把重复性高、逻辑清晰的工作流程固化后，就可以进一步利用技术手段将其转化为自动化任务，从而减少人为干预，提升效率与准确性。

AI大模型的普及，让普通员工也能轻松编写代码和脚本，这大大降低了流程自动化的门槛。

4️⃣ 减少“隐性知识”的产生

长期来看，我们不仅要将隐性知识显性化、标准化、自动化，更要从源头上减少隐性知识的产生，推动知识在诞生之初就走向显性化、共享化。

例如，在开发流程中嵌入知识沉淀环节：代码审核（Code Review）时要求说明实现逻辑；利用工具自动生成文档、规范提交信息；建立“退出检查单”（Exit Checklist），确保人员变动时的关键知识传递。同时，通过强化团队分享文化，鼓励主动表达和质疑，把那些“藏在脑子里”的思路和经验自然转化为可传播的内容。如定期举办“吐槽大会”“经验复盘会”等。

本质上，这些都是把知识管理前置的过程。让“知识显性化”不再依赖于事后的补救，而是自然而然地成为工作过程中的一环。

当知识真正成为可传承的集体资产而不再是个体的秘密时，团队协作将会变得更加高效。