开发人员必须了解业务领域，还是该规范足够？

我在一家公司领域工作，因为该领域是电子领域的高科技，因此很难理解，但是它适用于复杂领域中的任何软件开发。

我工作的应用程序显示了很多信息，图表和度量标准，如果没有该领域的经验，这些信息，图表和度量标准将很难理解。开发人员使用规范来描述软件必须执行的操作，例如指定特定的图表必须显示此类指标，并且该指标是以下算术公式。

这样，开发人员并不真正了解业务以及他/为什么要执行此任务。如果规范确实很详细，那么可以这样做，但是当规范不是很详细时，或者当作者忘记了用例时，开发人员很难找到解决方案。

另一方面，对每个开发人员进行所有业务方面的培训可能会非常漫长且困难。

我们应该更加重视详细的规范（但众所周知，不存在完善的规范），还是应该培训所有开发人员以了解业务领域？

编辑：请记住您的回答，即该公司可以使用外部开发人员，并且对所有域的组建大约需要2周的时间

该规范实际上永远是不够的。不具备领域知识的开发人员无法指出规范何时出现错误（大多数情况下经常发生）并做出糟糕的设计选择。

以我的经验，现在已经在3个非常不同的行业中工作，您可能一开始对该域不了解很多，但是最终需要学习它，并且某个人将不得不详细了解它。

根本的问题在于客户与开发人员之间的阻抗：他们想要一些东西，但只有在看到它们后才会知道，而您想解决他们的问题，但不能总是清楚地知道问题是什么。您（开发人员）可以带来他们（客户）行业的领域知识越多，您越容易将模糊的“需求”转化为具体的“问题”并加以解决。

举例来说，我之前的工作是在化学工业中使用工厂管理软件。我从对领域的零知识开始，但是却能够实施解决高级开发人员和客户向我提出的子问题所需的代码。随着时间的流逝，我努力学习该行业，以便可以在客户层面上更轻松地进行交流。当我了解他们的行业时，我开始了解实际的问题是什么。当他们说“我们需要跟踪该模块上的所有数据值”之类的内容时，我可以将其转化为它们的真正含义，即“我们需要保留该传感器生成的每个值的历史记录，并存储X天。保留率，但始终根据该传感器的最新读数进行评估。”

所以是的，有人需要领域知识，最好是开发人员，因为领域问题不是代码问题，并且在两者之间进行转换也不是一件容易的事。最终，任何值得您留在团队中的开发人员都应该选择领域，以便他们可以对代码的细微差别做出更明智的选择。

该项目上的SOMEONE需要具有相当完整的领域知识。该人可能是开发人员，也可能不是。

在敏捷项目中，客户项目所有者就是那个人，他们正在与团队紧密合作。在非敏捷项目中，团队中的某人需要获得该知识，但是通常不需要。这是非敏捷项目如此容易失败的原因之一。

有很多很好的答案。我添加自己的内容是因为在阅读它们并进行搜索之后，我发现没有人提到一个关键问题：bugs。

如果没有为团队提供足够的具有足够权限和领域专业知识的人员，则迟早会出现漏洞，这是不可避免的。在掌握领域知识的情况下，就不可能有或没有意义的价值/结果/关系。有人希望规范能明确指出它们，但实际上，您可以达到的最好是避免出现最明显的问题（如果利率变为负数或类似的情况，请提醒我，这可能是或可能不是错误，但实际上是足以引起注意）。

这与理解选择的原因密切相关，并且在最佳情况下，它还可以带来更好的软件（因为如果实际上知道请求背后的原因，便能够考虑该请求，而不必一定接受一个给定的请求）。 ）。

请记住，爱因斯坦曾说过：“但是思想和思想，而不是公式，是每种物理理论的起点。”也就是说，人们不是以抽象公式的方式而是以思想的方式思考的……

如果您将一个只会说英语的人和一个只会日语的人放在一个房间里，尽管他们是各自语言的专家，但他们无法将日语翻译成英语。出于同样的原因，即使没有领域知识的专家程序员也无能为力，无法弄清他们需要构建的内容，即使他们可以24x7全天候访问既不是软件开发专家又是专家的最佳领域专家。

规范是试图将域要求的“日语”转换为编程要求的“英语”。当您获得与Google翻译相当的翻译质量时，这就是您的幸运日；在大多数情况下，质量是不存在的，因此您无法获得至少一些领域知识。由于具有一定的持久性，它使您在项目结束时成为一个体面的“翻译”，因此您对公司的价值显着增长。在大多数情况下，您在此过程中也会有很多乐趣，所以这是双赢的局面。

没有业务知识的某些方面，您最终会成为不问问题并且不注意编写规范说明的开发人员。我认为，不仅要使能敲击键盘的人，还需要“思考者”来制作好的软件。不仅了解您在做什么，而且了解“为什么”以及它如何适应更大的前景，有助于使开发团队更加满意。

我认为您应该尝试获取领域知识。规格是核对清单，说明最终产品应做什么以及验证产品所需的条件。作为开发人员，您应该始终尝试了解要解决的真正问题是什么。获得领域知识将帮助您理解这一点。

这将帮助您轻松设计和编码，因为您将了解正在更改的部分（例如规则集）并将它们分开放置。您不需要是精通它的大师，但可以使用最终用户的语言与他们交谈。

您可以驾驶有基本知识的汽车；但是如果您想享受这个旅程，则需要详细了解如何正确使用它。与其他行业一样，了解域不是强制性的，但是您一定会很有趣。

我认为一个了解该业务的开发者值得在金子中占一席之地。

在“传统”场景中，业务有一些需求，而一些业务分析师将这些需求转换为技术需求，那么开发人员将无法使用那些需求，而不可避免地会发生两件事：

1. 您有多个故障点。业务分析师可能未将所有业务需求都完美地翻译过，和/或开发人员可能未将其完全翻译成技术规范。“围绕房间秘密”方案的一种变体。只是沟通的迫切需求。

2. 企业所有者，业务分析师或开发人员中的一个或全部对组织来说已经很陌生，他们会错过他们通常不会想到的关键项目。熟悉业务的经验丰富的开发人员可以协助教育其他角色的人们，以使产品更加完善。

在规范中每个功能的价值，必须将规范实现为有价值的程度以及满足规范功能的任意组合的成本之间，几乎总是需要做出权衡。通常，只有在一个人或一个紧密合作的团队（包括实际的软件架构师和/或编码人员）中存在完成上述所有工作的知识时，才能做出良好的权衡。

没有如此极端的本地化知识，甚至可能没有直觉，最终结果很容易成为非常昂贵且几乎无用的产品，非常符合书面规格。

创建不存在上述问题的规范的成本通常可能比培训架构师和/或编码人员具有足够的领域知识以使用不太复杂的详细规范（假设合法性和商业合同允许这样做）要高得多。

是的，开发人员需要一定程度地了解业务。他们不必知道每分钟的细节，但是他们应该对报表X的用途以及在业务流程中的使用方式有基本的了解。您的开发人员对业务的了解越多，他们可以提供的解决方案就越好。

根据我的经验*，比起两个人，一个对问题域有深入了解的人，以及一个对知识领域有较深了解的人，一个对问题域有充分了解并且对软件开发有充分了解的个人更有可能找到问题的最佳解决方案。软件开发，一起工作。

我认为这可以归结为一个简单的事实，即在单个人的大脑中进行的交流比在人与人之间的交流要快很多倍且更好。

*我要回答这个问题的主要经验是开发会计软件包（从开始到“维护模式”）花费了10多年。尽管我对软件开发的知识非常好，但是与同事相比，我常常因对问题域的了解不足而感到受阻。

我想回答一个来自业务方面的人，他与对学习交易基本知识兴趣不大的开发人员一起工作，有时甚至为不用了解那些基本知识而感到自豪：问题是开发人员乍一看将看不到结果中的错误（不合理的结果，错误的符号等），这需要详细的测试用例（直到最近我们才开发），或者对结果进行持续的监督。就我乐于学习软件开发的基础知识以简化沟通的范围，我想敦促开发人员也这样做。

您不必这样做，但是为什么不想要呢？

我会担心任何不情愿，尤其是在某种程度上无法学习该领域的程序员。偶尔离开“象牙代码塔”很重要。

在不知道如何使用代码以及什么目的的情况下编写代码听起来似乎很糟糕。当您可以建造大教堂时，谁愿意打破砖块？

开发人员参与程度越高，业务越高级，拥有至少中级领域知识或该行业中更为细微的领域（可能至关重要）的重要性就变得越发重要，开发团队将无法理解。

但是，对于较低级别的任务，应该有足够的规范。简而言之，最好将您的劳动力培训到较低的水平。他们可能是世界上最好的通晓多种语言的程序员，但是如果他们不能十分深刻地理解问题，那么他们总是注定要失败或走向失败。

总应该有一些规范-您不能期望所有开发人员都成为领域专家。同时，如果开发人员盲目遵循某个规范而又不真正了解它的用途，那么结果可能并不是客户真正想要的。经常发生的情况是，即使开发人员的理解水平还算不错（但不是专家），他们也会发现规范中的错误和遗漏。他们还可以为过程做出贡献并提供反馈，这可以使最终产品变得更好。

可能值得雇用一些领域专家，他们的工作是联络客户和开发人员，以帮助他们更好地了解开发人员并编写规范。

我认为这两种方法都很难给出答案。

很难说一个自由开发者如何理解他们所开发的每个应用程序背后的业务（或科学）。在这种情况下，我认为与真正了解业务本身相比，开发人员知道对规范或业务模型提出正确的问题更为重要。

另一方面，假设企业开发人员从事同一业务已有一段时间，那么他们应该应该在几个月（甚至几年）之后就学会了业务运作。在大型团队中，您可能还拥有一位架构师，他比开发人员更了解业务。

在具有单独开发人员的中小型企业中，重要的是，开发人员必须与所有者/经理进行频繁的讨论，以避免过分执行错误的事情。

因此，有很多可能的思考方式，但是关键在所有情况下都是相同的：沟通。

软件开发是我所知道的唯一一个专业，它要求您不仅精通自己的专业，还需要对所从事的专业有基本的了解。对领域的足够了解以与客户和使用客户端语言的其他开发人员。作为开发人员，您不能总是依靠其他人来培训您。有时，您不得不自己进行个人研究，通常是在正常工作时间之外进行。

我真的很明白您的意思，因为我们作为旅游行业的公司，也面临同样的问题。当我还是一名初级开发人员时，我还在一所大学学习旅游业。因此，您可以猜测我不是来自计算机科学背景，但是我的旅游知识很高。

当时，我们正在与其他软件公司合作开发产品，但是缺乏特定领域的知识。正如您所描述的，如果您要在旅游业中开发产品，那么确实很难做到这一点，因为存在许多跨领域的问题，等等。

因此，从长远来看，这一运动带来了很多不好的结果。然后，我们向前迈出了一大步，我开始只专注于开发而不是项目的业务部分。由于我拥有行业知识和编程知识，因此该项目的效率比以往任何时候都高。更不用说，由于我在硬币的两面都有经验，因此我们可以更快地做出决策。

作为对您问题的具体回答，我个人肯定是肯定的。如果您的团队正在从事的项目是一个长期的项目，那么就走艰难的道路，对您的员工进行领域特定的基础知识和细节方面的培训。

如果开发人员在公司/行业中呆了很长时间，他们会慢慢但必定会学习“业务”。

一些公司承认并提供有关“业务”的培训。金融公司就是一个很好的例子。

您学习的业务越多，与用户交流的机会就越容易。他们会对您有更多的信心。您将更容易理解系统如果无法按照用户的预期去做的地方可能会出问题的怪癖。

为了回答您的问题，根据我的经验，该说明永远是不够的。常见的问题是它们通常不包含足够的信息，并且很快就会过时。

对于某些公司来说，必须具有业务领域的经验。他们在招聘时会寻找具有相关领域经验的开发人员。一些公司甚至把这个比实际的技术技能还高。（没有财务经验，没有采访是很普遍的，当然在英国也是如此）。

从个人经验来看，只要您在团队中与您合作并且确实具有领域知识的人员，该说明就足够了。

我在一个非常专业的行业工作：我们为广播媒体制作软件。我几乎不了解广播，但是我知道代码和数据，而且我的项目管理团队中有很好的人了解广播。在过去的几年中，该公式足以使我提出客户喜欢的良好功能。