整体工程师的思想体现了这样一种观点，即工程师需要考虑整个系统，即使产品成功的全部工作。它与整体健康毫无关系，也不是一些新时代的庸医。在软件行业有许多专家的角色-市场营销，产品管理，项目管理，文档，教育，支持等等-但是最好的软件工程师是多面手，他们可以承担每个专业的一部分。此外，有些软件特别适合那些能够将对市场、技术和实现的深刻理解结合起来的多面手。软件产品诞生于许多不同类型的组织中，即使在相似的组织中，角色也可能有不同的名称。下面是一个带有角色名称的通用示例。新产品和新功能从产品经理开始。他们的职责是与客户和销售人员交谈，对自己进行市场教育，并确定正确的产品或配件。向工程部门的移交采用产品需求文档（productrequirements document，PRD）的形式——听起来像行话，但这个术语或多或少是通用的。软件工程师针对PRD执行；QA工程师设计测试，断言符合PRD，而开发人员则按照产品管理的描述，将产品从A点引导到B点。文件编写者和学习服务机构利用PRD和软件生成辅助资料，教客户如何使用它。产品营销是动力点，销售人员将其呈现给客户。这就是婴儿的来源。这不是一个完美的过程，但它产生了许多成功的产品。缺点是它会把工程师埋在过滤器下。工程师们没有了解实际的客户问题，而是听到客户所说的一些经过处理的形式。工程师们听到的不是对新功能的原始批评，而是一种软化和删节的形式。产品和市场的技术含量越高，这些过滤器就越阻碍创新，阻碍产品的发展。整体工程师增加这些专家的工作，参与产品开发的每个阶段。他们参与了早期与客户的对话，并分担了理解市场的责任。他们合作构建需求和设计，然后这些工程师将实施这些需求和设计。在这个过程中，工程师当然会与销售和客户一起验证决策—这是敏捷—但工程师也会参与到外部文档、培训和营销活动中。从开始到结束，这一过程旨在通过向创意工程师提供数据和理解来推动创新。顾客经常告诉你他们想要什么，他们很少告诉你他们需要什么。产品的技术性或破坏性越强，工程师在这些对话中就越有价值，从成见的噪音中提取问题的本质。与客户的关系以及他们问题的全部背景使工程师们在产品规范中不可避免地出现差距时保持着良好的基础。整体工程师也有助于向公司和世界其他地方传授新产品和新功能。解释技术的过程为工程师设计和制造产品提供了建议。当我们很难解释一个功能或展示一个产品时，我们需要修改我们的设计。我们都听到过工程师被指责制造了一种对市场来说过于复杂的产品，或者工程师抱怨产品失败是因为它的营销不好；这两者都是协调性差的症状。赋予工程师全面的责任来防止这个问题——如果产品出了问题，解决问题的责任就在他们身上。不过，最重要的是与全身法相关的所有权和代理感。整体工程师的任务是使产品成功。这并不是说他或她独自一人去做——所有职能部门的专家都扮演着重要的角色——相反，工程师有权将产品推进所有阶段；硬币的另一面是，没有机会将责任推卸为属于别人的责任。在这种模式下，公司中每个角色的每个人都有机会参与产品管理。事实上，明确的产品管理还是有价值的。沟通渠道应该是容易和开放的，让有想法的人与将其提炼成实施方案的人联系起来。仅仅创造一个合适的环境是不够的；招聘过程需要确定广泛的思考者，导师制需要培养和奖励整体执行力。不是每一个工程师都能或想承担这些额外的责任，但最好的工程师在市场和技术意识的推动下茁壮成长，而不受过滤器的阻碍。他们需要责任和权威使他们的想法成功。整体工程师的概念不是理论上的，而是我们在Solaris内核组中偶然遇到的模型，后来在Fishworks中被故意实现了。在那里，一个小团队承担了广泛的责任，为甲骨文开发了一款年收入4亿美元的产品。在德尔菲斯，我们再次灌输和聘用整体思维。在这三个方面，我都见过工程师开发新产品和新功能，以满足客户的需求，否则客户的最初要求就不会出现这些需求。要找到合适的工程师并不容易，但如果一家公司能够以正确的方式授权合适的工程师，并且他们能够履行责任，那么回报就是更好的产品，更高效地构建。