[翻译] 系统工程实践

已徵得原作者同意，以 CC BY-SA 4.0 授权进行本文的翻译。

原文

连结在此。
Hacker News 讨论。

作者

James Munns，Rust 工具 postcard 的作者与维护者。他的专长为嵌入式系统与 Linux，现职为顾问。他的 LinkedIn 于此。

本文翻译开始

---

系统工程实践，或「詹姆斯赖以维生的心法」

译注：原文的 Systems Engineering 本身带有相当的模糊性，译为系统工程实践或有可议之处。译者追求速度之下，探究作者原意应相去不远，所以订定译名如此。

我是一个顾问。我通常参与包含硬体（电子零件或机械元件）的专案，但通常是辅导其中的软体部份：微处理器的程式码、桌面系统的东西、有时也处理些伺服器端的东西。有时候我得负责动手实作特定的项目，如一只驱动程式的概念验证（proof of concept）；有时我参与评估如何导入 Rust；又有时我辅导客户，将原型（prototype）转换为产品。

结果，我的时间通常都花在帮助人们导入系统工程实践。这有点像「如果你只有榔头，什么东西都像钉子」，也可能我自己嗑了太多系统工程实践的药。但无论如何，这招一直都有效且帮得上忙，所以我就继续挥动这榔头吧。

译注：可参照工具定律。

我可能有天会想要以此为题写一本书，而本文即是尚未清晰爬梳过的一堆想法的起点。我现在（还）没有可以卖给你的祕笈，本文也没有任何无敌的通用解答。这里有的，只是一些可能对你手边的专案有帮助的一些思考方向。

我并非流程的忠实信徒，也不是把系统工程实践这一套当神在拜。有时实践一小部份或许就大有助益，有时（尤其如果你的专案与安全相关）你得一次把所有事情做到位。做到你觉得对的程度即可。如果这套没用了，那就找别的方法来尝试。理想上，接下来我要介绍的概念应该会让你像是投资了绩优股，立即开始带来一些红利。

何谓「系统工程实践」？

也许美国太空总署或是哪个机关会有更好的定义吧，不过对我来说，这个实践涵盖以下两个课题：

能够明确地回答，你以及你的团队在打造的是什么东西能够明确地回答，你以及你的团队如何打造它

看起来很简单对吧？嗯，有时候很简单。

在哪里会出事？

当人们参与一个多人专案，其中各人来自不同背景（如：有些做软体、有些做硬体、有些负责管理、有些负责产品等）的情况下，在团队与组织之中，大家往往将上述的「打造什么」与「如何打造」问题抛诸脑后。

也许是，你的专案规模变得比前一个还大；也许是，你打算处理一个你并不熟悉的新领域里的问题。一开始很简单的事情快速变得複杂起来，而且无论你如何努力，终点线都没有因此更接近一些。

就像其他许多的「最佳实践」一样，你几乎总是可以顺风顺水地度过困难，如果你面对的是较小规模的专案，或是仅与较小规模的团队合作。但隐藏的问题可能带有 O(n^2) 甚至指数等级的複杂度，一开始都好好的，直到某天你终于追不上规划的进度了，拖延一个月、一季、甚至以年计算。

为什么人们不着手进行系统工程实践？

每个人的功力可能各有千秋，但我发现一般来说软体工程师们很少受过正规训练以解决上述的问题。他们会拆解问题，希望能够小範围地解决，但他们面对团队规模的问题的时候，往往缺乏好的手段去切分问题。

在传统的工程领域如电子与机械，工程师们比较可能有系统工程实践相关的经验，不过他们未必彻底理解为什么有那些实践的方法。

这表示，如果你的组织中没有系统工程实践的文化，那通常也不会有人能够协助导入了！这也常常是我的切入点。不需要等到火烧屁股，人们就应当可以开始受惠于导入一些系统工程实践。有时候对人们来说，整个专案流程更可预测一些些、更少一些「惊喜」，其实就很不错了。

嘿，你的系统工程实践介绍还有定义还是太模糊了！

好吧，我只是想试着简单扼要。让我们延展一下实质内容...

能够明确地回答，你以及你的团队在打造的是什么东西

译注：原文为 Be explicit about what you are building。译者才疏学浅，不知道 Be explicit 到底该怎么真正在中文对应到一个动词才最通顺？所以翻译时假想了顾问询问「你的团队在打造什么？」而受辅导者必须回答的情境。事实上，结合作者后续的内容展开，明确一词所对应到的动作包含文件纪录、呈现、口语描述、沟通等等。

正式来讲，这个提问包含了以下主题：需求、规格、架构、以及验收标準。每一个主题都儘可各自展开成文，但我打算留待之后再论述。非正式的来讲的话，这个提问的意义在于，每一个团队中的成员都应该非常清晰地知道这个专案中该做的事情是什么。

所以，本文中我将会强调这件事情很多次，那就是如果资讯没有被写下来，那么那些资讯就不存在。

你永远不知道两个人是否拥有相同的心智模型，多人的情况自然更糟。你永远不知道你自己的心智模型是否一致；有时候你觉得一切都很合理，但试着写下来之后，就发现其中的矛盾。你无法保证你对事物的理解不会随着时间改变，或是遗忘了部份的心智模型。

解法就是你必须写下你的专案应该做的事情，不管是程式码、硬体或其他什么资讯都是如此。这不需要非常的正式。用 markdown 文件、用 Words、用 Excel、用什么都没差，总之写下来。在各种媒体之中迁移资讯，总是比一开始要一次归档大量资讯容易。

不管你使用什么工具，对于你的整个团队来说，接下来的重点是：唯一真实来源是什么？如何阅览它？如何能够随时存取它？

译注：可参考维基，目前没有权威的译名，但常见的简写为 SSOT 代表 Single Source of Truth）。简单的解释是，所有资料都应该只有一个正本，其他的存取皆为参照。

比方说，如果你把专案规格书以 git repo 的形式存放，而你的专案经理不知道如何存取 git，那么你维护的规格书就没有用。如果你的公司导入了一套华丽的管理工具，你并利用它来存放专案规格书，但公司并未取得所有人都能使用的授权条款，那么这份规格书也同样毫无用处。

设想，人们对一个功能感到疑惑「咦，这个的原理是什么？」之后，可能採取的动作为以下两种情境：

查阅说明文件乱猜（存在部份误会甚至完全错误的理解）
仅仅在第一种动作所需的时间小于第二种动作的时间的时候，说明文件的存在才有意义。

说明或规格之类的参考文件，仅仅在人们可以轻鬆查阅的时候有意义，因为存取文件并查阅的力气理当小于为某些系统行为争辩，当然更应该小于召开会议以使得所有人的资讯同步。

要让这套作法成功，我们需要下一个规则：你的规格文件必须是精确的。详细考究的话会有点怪怪的，精确这个形容在「系统将会这么做」和「系统是这么做的」之间应该怎么确定下来？这是另外一个可以独立成文的主题。无论如何，无论何时，你的规格文件必须是精确的。

译注：原作者交叉混用「需求」与「规格」，但译者认为没有必要加入这个额外的困扰因子，统称规格或是规格文件。

如果规格文件描述「这个系统执行 X 行为」，那么电子工程师就不需要与软体工程师沟通，也能够在心里把这个叙述当作事实；业务部门可以引用这个叙述到行销材料之中，而不会有任何问题。如果两个或更多人对于系统应有的行为产生认知的歧异，那么规格文件应扮演仲裁的角色。

总之，规格文件应该要能够容易阅读、查找、并从中获取资讯。

有些业内人士纪录规格文件的工具是像 JIRA、或是 Github Ticket 系统。那些纪录，前后来讲时间都跨度都很大。人们该怎么知道哪一份是正确的？哪一份是最新的？如果你对于系统有个类似「系统一次可以处理多少个东西」这样的问题，你该怎么找到答案？

基于上述理由，我认为只应该维护一份文件且持续更新它。如果这份规格书不清楚，甚至有明显的错误，那每个人都该知道怎么样去改进它。

需求、规格文件、系统行为文件这些东西应该要像是具有生命一般成长。就算你依照「瀑布式开发」模型行事，你对于系统的了解也会随着时间而改变。人们会需要新功能；人们可能会发现某些规划中的效能指标无法达成。稍后我们会提到规格文件应当如何修改，不过无论使用的媒介是什么，在必要的时候每个人都应该知道怎么修正、改良规格文件。

最后，你需要有能力证明你的系统行为符合规格文件的描述。这可以意味着测试，也可以意味着审查；基本上最重要的是，人们对于规格文件的每个部份都会有「感觉」，让人们知道他们是否足够精确。我会在后面补述这个部份。

简单来说，能够明确地回答，你以及你的团队在打造的是什么东西的精髓是：

你应该将系统应有的行为写下来它应该是一份有生命的文件，持续成长、更新。它应该要尽可能完整（可以慢慢扩充而成）它应该总是精确的每个人都应该知道怎么找到这份文件、阅读它、以及在文件中取得需要的答案。如果文件不完整或不精确，人们应该知道如何修改它。你应该要能够证明你的系统真实行为符合它应该达成的行为。

能够明确地回答，你以及你的团队如何打造那个东西

正式来讲，这包含的主题是系统开发计画、验证计画、设计/程式标準、审核标準、以及文件管理。非正式来讲，每个团队成员都应该清晰无偏差地了解他们该怎么做事。

而这...与流程大有关係。如何设计并验证一个系统、如何捕捉需求、细至如何设定程式的格式标準；新手必须要精熟这一大堆事情才能够在你的团队中有效率地产出。

所以我再强调一次，如果资讯没有被写下来，那么那些资讯就不存在。理想上，以下情境对于你的团队来说应该是可达成的：某个新人报到的第一天，在他开始一切之前你们就都知道他（译注：女性与其他跨性别者都是人，所以译者继续以他作为中性第三人称应属合理）需要哪些资源；你们能够指引他去阅读一份文件（这文件可以内建连结到其他必要的文件去）；该文件是可阅读的；他接着就大致上能了解如何开始加入你的团队协作。

你可以以任何方式去呈现这些资讯。Markdown 格式文件实务上运作良好。内部的维基系统也还可以。这些文件最后都会有点像是「流程的必要条件」。也就是说，

这些文件应该要是一份有生命的文件，持续成长、更新。每个人都应该知道怎么找到这份文件。如果出现了任何歧见，「流程的必要条件」都应该有答案可以解决分歧；或者，就算没办法，你的团队也应该能够找出一个方法来决定如何将之写下来到文件中。不完整不是问题，总之持续改进就可以，但是...不準确绝对是不能接受的。

没有必要把所有流程都订得非常严谨。大部分的团队流程都不需要严格到符合安全需求标準。但如果有些事情必须天天做（像是合併请求的生成方式、审核程式码、设计电路等等），也许把那些「流程指引」準备好，对于新人训练会更有帮助。

如果团队中有两个人对于「如何完成 X 工作」有歧见，坐下来讨论、做出决议、然后将之纪录下来吧。然后就别再争执该议题了，除非未来有个改动的好理由。

总之，有一份书面的流程指引能够帮助你的团队行动一致。一致性让人们困惑该怎么把事情做对的时间更短，也因此可以花更多时间在解决真正的问题上面。

TL;DR：总之，把东西写下来。

在未来的某个时间点，我会写一些你可能会想要引用作为「合理的预设工作模式」的做事情的方法。但说老实话，总之做些对你的团队有用的事情，然后写下他们，好让每个人都能够达成一致的理解。

总结

系统工程实践在解决「解决问题」的问题上能够派上用场。如果你有个大型团队或是大型问题，「定义与解决某个问题」本身就是值得大家坐下来一起处理的问题。

如果状况允许，在你开始工作之前花点时间确定每个人都已经準备好要解决同一个专案里的问题，以及每个人都知道自己应当做些什么。如果你已经开始了，这么做也不会太迟，因为比起完全不做，你仍然可能提早抓到一些问题。

你不需要正规的训练（译注：但如果你需要帮助的话，可以寄一封信给作者），总之把东西写下来，确保每个人都有一致的认知。

「在胡搞一通与科学之间唯一的差别是，有没有把它写下来。」
-- Adam Savage （流言终结者主持人）

---

译者后记

如果资讯没有被写下来，那么那些资讯就不存在

这个说法相当极端，且否定了部落知识与隐式知识的意义。实务上以译者的经验，组织内总是有些口耳相传、仅有部份人最清楚的业务。虽不至于出现他们挟知识以自重的状况，但没有脆弱到可能会有单点故障的程度的话，（尽量）将所有知识建立一套流程文件的作法缺乏动机。

但反过来讲，如果管理层愿意推动这种实践、这种文化，那么执行面（可怜如你我般的基层主管）又要怎么开始？不同组别亦敌亦友的同侪又该怎么摆平呢？万事起头难，但会不会头洗下去更有一堆没想过的问题？可是如果一直做行前评估，会不会又像牧羊少年的奇幻旅程当中那一位一辈子都没有起身朝圣的富有穆斯林一样，天天看着麦加的方向，总觉得自己还没準备好？

译者目前也在技术组织之中面临类似的管理问题，总觉得许多事情都不够精确，但同时人们也欠缺动机去完成这样一个体系。这的确需要文化、工具、惯例的形成，但这样的协作模式不太可能自然涌现。译者这次的翻译只是捡现成的小小劳动，期望后续能够换得一些 IT 领域前辈赐教的机会。

至少，丢出一些问题，试着让答案慢慢成型。

感谢！