其实,真正的“产品知识”往往不在文档里…

这怎么可能呢？写这些软件的工程师难道不知道它干了什么吗？内部文档里不是应该有记录吗？更进一步说，看看面向最终用户的公开文档不就能轻松找到答案了吗？科技公司里到处都是高薪且能力出众的人，为什么这些人连自己产品做了什么都说不清？

软件本身就很难

大型软件产品复杂到令人望而却步。 简单来说，通过添加复杂功能，你能获取大量的价值。最经典的例子就是那些让核心产品触达更多用户的功能——比如支持私有化部署、提供免费试用、支持大型组织的集中化策略管控、支持多语言本地化、支持在对软件运营有严格法规的国家使用、支持政府这类高度受监管的客户使用，等等。这些功能对大多数用户来说（希望是）无感的，但它们对科技公司自身来说绝不可能无感。

为什么这些功能如此复杂？因为它们影响你后续构建的每一个功能。如果你加了组织管理和策略管控，那你每新增一个功能，就必须为它加上对应的策略控制。如果你做了产品本地化，那每个新功能都必须提供翻译。以此类推。最终你会陷入这样的处境：你试图弄清一个在欧盟部署的私有化企业客户是否有权限访问某个特定功能，结果没人知道——你不得不去翻代码或者实际试一试才能搞明白。

能不能干脆不做这些功能呢？当然可以，但那意味着你把大把的钱留在桌上不赚。事实上，小型科技公司和大型科技公司之间最大的区别，或许就是大公司有能力通过追逐所有这些繁琐、别扭的功能来获取更多价值。

文档为什么救不了你

为什么不能在构建每个新功能时就把这些交互关系一次性记录下来呢？理论上我觉得是可行的，只要投入大量精力并且有自上而下的支持。但在实践中，这真的太难了。

核心问题在于：当你试图记录这个系统时，它正在飞速变化。 哪怕是一个人，只要给够时间，也能把一个复杂但静态的系统文档化——慢慢一点点梳理就行了。但一旦系统开始不断变化，负责文档的人就必须跑得比系统变化的速度还快。如果没有不切实际的人力投入，把它完整记录下来可能根本不可能。

更糟的是，系统的很多行为背后并没有太多刻意的设计意图（甚至完全没有）。它们只是系统架构方式的自然涌现，是一系列”默认”选择交互作用的结果。所以负责写文档的人不只是在记录工程师做出的决策，他们是在第一次发现系统到底是怎么运作的。

那到底谁知道答案？

要可靠地回答这些问题，唯一的办法往往就是去看代码。我认为这实际上才是工程师在大型科技公司拥有组织话语权的结构性原因。工程师当然是写软件的人，但几乎更重要的是，他们是能回答关于软件的问题的人。

事实上，回答关于软件的问题，是工程团队的核心职能之一。 对一个软件最好的理解，通常存在于每天和它打交道的工程师的脑子里。如果一个代码库由一个健康的工程团队来维护，你往往不需要安排人去调查——你只需要问问整个团队，至少有一个工程师能脱口而出答案，因为他们本来就熟悉那部分代码。

当科技公司做团队重组时，这种隐性知识往往会被摧毁。如果没有一个团队对某块软件有经验，问题就只能靠调查来回答：某个工程师必须去把答案找出来。这通常是通过多种方式结合进行的：实际操作产品（也许在一个容易搭建特定场景的开发环境中）、通读代码，甚至进行”探查性手术”——改改代码看看会怎样，或者强制让某些检查始终返回 true，观察会发生什么。这和写代码是不同的技术能力（当然两者高度相关）。

写软件比解释软件容易

以我的经验来看，大多数工程师能写软件，但很少有人能可靠地回答关于软件的问题。我不太清楚为什么会这样——写新软件难道不需要先搞清楚现有软件的问题吗？但事实就是如此。我最好的理论是：这是一个信心问题。 很多工程师宁愿为自己的代码负责（至少在自己机器上能跑），也不愿意为自己的回答负责（因为可能完全错了）。

核心困难在于：你总是在冒险。 你必须接受自己可能完全搞错了的可能性，这和写代码的心态很不一样（写代码时你往往能证明自己的工作是正确的）。而且写代码的时候你想写多啰嗦都行——写测试的时候尤其如此——但回答问题时你必须把事情提炼成摘要。很多软件工程师特别讨厌省略细节。

非技术背景的人——至少是那些没有太多和软件产品打交道经验的人——往往相信软件系统是被构建它的工程师充分理解的。这种想法的逻辑是：系统是一行行代码用（大致）确定性的组件搭建起来的，所以应该是可以理解的。

然而，虽然对于小型软件来说这可能是对的，但对于大型软件系统来说几乎从来不是这样。 大型软件系统即使对最有条件理解它们的人来说，也是非常难以理解的。甚至关于这个软件做了什么的最基本的问题，往往都需要做研究才能回答。而且一旦你有了一个可靠的答案，它也未必能可靠多久——代码库的每次变更都可能引入新的细微差别和例外情况，所以你往往不得不对同一个问题反复去研究。

正因如此，能够准确回答关于大型软件系统的问题，是一项极其宝贵的能力。

#大型软件 #文档困境 #工程知识