开发不是建筑，而是医学。

我们都听过这样的比喻。有人试图解释软件开发的某些方面，他们不可避免地会把这个过程比作……盖房子。你可能也做过。我也做过无数次了。通过某些例子，这个比喻或许能有所帮助。但总的来说，我确信这种错误的等同是彻头彻尾有害的。为什么？因为软件开发根本不像建筑。它实际上与医疗保健有更多共同之处。

这不仅仅是语义问题。我相信，如果更多人能够将正确的范式应用于软件开发，他们将会从中获得更好的结果。用构建的术语来构建软件项目不仅仅是误导。它很可能会导致你对整个项目管理不善，并激怒那些为项目成功而努力工作的人。

扔掉你的蓝图

人们浪费了太多精力去追逐“完美规范”（蓝图）的狂热梦想。这种（误导性的）想法意味着，只要你能制定出一套完美的需求，然后把蓝图交给开发团队，他们就能像编程机器人一样，完全按照你的计划快速开发出应用程序。但这种理想是破灭的。

一份详细的蓝图意味着利益相关者清楚自己想要什么。一份臃肿的规范，充斥着大量细致的需求，意味着利益相关者绝对清楚自己想要什么，毫无疑问。

在从事代码工作二十五年之后，我可以自信地告诉你，我从未遇到过任何一个利益相关者真正、充分、彻底地知道自己想要什么。一个也没有。

当然，他们对自己想要什么有着清晰的想法。他们可能已经对拟定应用的各个方面做了大量工作。但我可以保证，在我们开始编写代码之前，他们并不能 100%确定自己想要什么。

因为，一旦他们开始看到眼前的屏幕，并开始体验目前为止已经完成的功能，他们必然会意识到，他们最初的设想，往好了说，是不完整的。往坏了说，可能是完全错误的。

你看，可以 100% 量化的软件有个名字，叫做成品。所以，除非你打算完美复制现有系统，否则你不可能预先完全定义好新项目的所有规格。

您的房屋很可能是根据几个月或几年前制定的预制蓝图建造的。这些蓝图也曾被其他类似的房屋使用。建造房屋的过程实际上是一个可重复的循环。他们会打印出同一份蓝图的另一份副本。他们甚至可能雇佣同样的工人。在可预测的时间内，他们就能建造出另一栋与之前建造的房屋一模一样的房子。

但是，当你从头开始构建一个全新的应用时，并不存在完美定义、千篇一律的开发流程。如果你花钱请团队开发定制软件，那是因为在某种程度上，你需要一些真正符合你需求的独特功能。只要情况如此，你就永远无法直接把蓝图交给开发团队，然后确信他们能在几个月内就100%按照规格完成你的应用。

这种“每个项目都略有不同”的特性并不适合应用于建筑行业。但它却是一个描述医疗保健服务流程的可靠方法。

你不能“简化”编程

在医学上，实际上没有所谓的“常规”手术。有些手术成功率极高，并发症发生率也很低；而有些手术成功率却低得多，并发症发生率却高得多。

如果患者有其他并发症，即使是“常规”手术也可能变得相当危险。无论有多少部关于医疗手术的书籍，都无济于事。你永远不可能把一套预先设定好的“规格”交给一名初级脑外科医生，然后就确信他能够在无人监督的情况下成功完成手术。

我注意到美国企业界有很多趋势，他们隐隐希望将应用程序开发变得像某种流水线作业。你把详细的说明塞进前端。最终，你的新应用程序从后端飞速流水。但一旦你意识到它与医疗保健的相似之处，你就需要问问自己：当你接受手术时，你愿意相信说明书吗？还是更愿意相信那些手术医生的培训和经验？

认识你的开发者

把程序员比作外科医生，听起来可能有点傻（或者说傲慢）。在我的职业生涯的大部分时间里，我都不会这么做。后来发生了一件有趣的事：我试图教一个完全的新手编程。就在那时，我开始意识到自己脑子里积攒了多么丰富的高度专业的知识。

我的工作性质或许远不如医生重要。但我确信，我脑子里的技术信息量与外科医生不相上下。

我精通至少五种不同的编程语言。在其他几种语言方面也拥有一定的经验。我对许多其他“支持”技术（例如 HTML、CSS、SQL、REST、SOAP、GraphQL 等）也达到了精通到专家的水平。我可以在移动、Web 或控制台平台上进行开发。我能够轻松地在前端、后端和中间件技术之间切换。

这里的重点不是吹嘘我的简历。重点是，当你开始量化我所掌握的所有技术细节，涵盖我能够操作的所有平台时，它们构成了海量的知识。而且我说的可不只是我自己。

深入研究一下几乎任何一位在这个领域工作了十年或更长时间的开发者，你很可能会发现他们拥有相当（甚至更高）的知识水平。在这个行业工作足够长的时间，你将积累一个惊人的关键数据库。

说许多开发人员在各自领域拥有堪比外科医生的高超技能，这并非傲慢或自夸。然而，我常常感觉“行业”总是想方设法把程序员贬低为流水线工人。

诊断

如果我有一份详细的规格说明书，能准确说明我想要如何制作一个橱柜，我就可以拿着这份说明书去找一个技艺精湛的木匠，以合适的价格在合理的时间内拿到一个完整的橱柜。许多公司在进行应用程序开发时就是这样做的。他们只想把规格说明书塞到你面前，然后说：“给你，动手做吧。”

现在想象一下，我预约了一位医生的初诊。当我走进办公室时，他询问预约的原因。我递给他一大堆医疗文件，上面解释了如何进行一项特定的医疗程序。

我问他多久能给我做这个手术。我还告诉他，我需要一个详细的费用估算。

他想知道我为什么要做这个特殊的手术。他想知道我出现了哪些症状。他想知道我病史里各种令人头疼的细节。

但我把这些都抛诸脑后，只是不停地指着我给他的医疗“规格”。我告诉他，他只要按照规格上说的去做就行了。你觉得这次预约会怎么样？

医生的存在并非为了像你点菜单一样提供医疗服务。医生的存在是为了解决问题。任何一位技术娴熟的医生首先是一位问题解决者，其次才是一位执业医师。

即使我们假设我那些荒谬的要求是正确的，任何医生在未了解问题的情况下就进行手术都是不负责任的。但很多时候，我们把规格说明书交给开发人员，期望他们交付产品，却没有充分理解产品设计要解决的问题。

你觉得我有点夸张吗？想想最近我遇到的一个客户，他不停地修改我的规格。他们在项目进行到最后一刻还不断提出一些随意的要求，这些要求确实带来了技术上的影响。每当我提出新的要求，我都会问：“我们想通过这些修改来解决什么问题？ ”但他们其实并不想跟我讨论解决问题的方法。他们只想跟我讨论具体的要求。

如果我理解了问题，我就能妥善地咨询解决问题的最佳方案。但如果我经常被“蒙在鼓里”，就会削弱我成为一个合格问题解决者的能力。

紧急技术人员

医生不会因为想让你不舒服而盘问你。他们会尽力收集所有相关数据，因为这能大大降低紧急情况发生的可能性，并帮助他们在紧急情况发生时做出更好的应对。经验丰富的开发人员也同样如此。

无论你的规格多么光鲜亮丽，一个简单的事实是，一旦我全身心投入到项目中，我就会遇到……一些意想不到的事情。一些会改变项目最初目标的事情。一些会改变时间表的事情。一些与丑陋的遗留代码有关的事情。或者一些与不合作的供应商有关的事情。不管这个“事情”是什么。在任何规模庞大的项目中，总会有……一些事情。

当组织试图将程序员从应用​​程序构建过程中隔离出来时，他们自己就无法应对这些紧急情况。他们束缚了开发人员的手脚，迫使他们通过委员会和评审来进行分类处理——最终项目会因此受到影响。

我在项目中遇到过很多意料之外的障碍。通常情况下，我能快速评估出问题所在，并且通常清楚地知道应该对项目进行哪些修改来解决这些意外问题。但我却无法真正解决它。因为，即使我已经在这个领域工作了四分之一个世纪，我仍然常常发现自己没有权力做出这样的决定。

于是我联系了我的项目经理，解释了这个问题。项目经理召集了我们客户负责人（POC）的会议。客户负责人又召集了所有项目利益相关者开会。有时甚至需要再开一次会议，专门让客户的“领导”参与进来。我经常被拉去参加每一次这样的会议，反复向最新的参与者解释这个问题。

经过数周（有时甚至数月）的反复讨论，客户最终会就如何处理该问题做出正式决定。通常情况下，该决定与我最初的建议完全相同，甚至极其相似。一旦所有人都同意变更，我就可以重新开始项目了。

如果该项目是一名病人，那么该病人早就去世了。