The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
我已经解释了我对软件架构师角色和责任的理解。但仍有一个问题没有答案，并且在我们的项目中经常成为一个问题：当项目发起人不喜欢软件架构师的技术决策时，软件架构师应该怎么办？架构师以某种方式实现了某些功能，而发起人（或其代表）却说这不是正确的工作方式。接下来该怎么办？
在我们的项目中，产品负责人（PO）通常是项目发起人（付费客户）的代表。由于我们所有的项目都是相当复杂的Java软件包，PO们是非常技术性的人员。他们是程序员，或者曾经是程序员。他们理解我们编写的代码，并希望他们的意见被考虑和尊重。
我不是指那些愚蠢的产品负责人，这些人是另外一个故事。我指的是一个相当理性的PO，他有自己的技术观点需要被听取。
这里有一个实际的例子。上周，我开始了一个项目。我是架构师。这是一个Java服务器端模块。我决定使用Maven作为构建自动化系统。
我创建了一些初始文件，配置了pom.xml，在README.md中简要解释了项目结构，并提交了一个拉取请求。产品负责人Chris审查了它，并问道：“为什么不用Gradle呢？”
这是一个合理的问题，对吧？Gradle是另一个我本可以使用的流行构建自动化系统，但我没有选择它。问题是为什么。这是一个相当无害的问题，我在拉取请求的评论中解释了答案。我说Maven在这个项目中更合适，因为…等等。
但Chris提出了反对意见。他仍然认为Gradle是更好的选择。他有他的理由。与此同时，我试图说服他接受我的意见。我尝试了几次，然后意识到我做错了。不应该这样工作。
软件架构师不应该说服产品负责人、客户或其他人。相反，架构师必须做出自己的决策，并对产品的整个成功或失败负责，就像我之前解释的那样。
这样做有一个简单的原因。任何试图说服他人的尝试都会导致“责任泄漏”的可能性。如果我未能说服，我将不得不改变我的计划并使用Gradle，对吧？如果产品因为那个决策而出现问题怎么办？我会试图责怪Chris，对吧？我无法完全对产品负责，因为我被“迫”做出了至少一个决策。
别误会，一个好的架构师在做出自己的决策之前必须收集不同的意见。但收集Chris的意见会有所不同。我会先问他对Maven和Gradle的看法。他会告诉我他不喜欢Maven，因为这个和那个的原因。我会考虑这些意见。或者也可能不考虑。但我的决定仍将是我的，是我自己做出的，没有任何人强迫我。Chris仍然可以因为该决策的任何负面后果而责怪我。
但是，如果Chris真的不喜欢我的决定，他该怎么办？这是他的钱和他的产品，对吧？他关心这个问题。他不想在他的产品中使用Maven。他该怎么做？他如何影响我的决策过程？
很简单。每个软件项目中都有两个文档。第一个是需求，第二个是架构。Chris应该同时使用这两个文档来纠正我并指导我正确的方向。具体方法如下。
首先，如果他真的不想使用Maven，他应该在需求文档中进行更改。他应该添加类似于“构建系统必须使用Gradle，因为…”的内容。或者甚至不需要“因为”。这由他决定。在这种情况下，我将不得不考虑这一点，我也会这样做。我知道我的设计决策是由需求所决定的。不是因为Chris说服了我或者我未能说服他，而是因为文件上写着那么做。
其次，如果他对选择Gradle是否正确并不完全确定，只是希望我对自己的决策更加认真，他应该通过提交一个缺陷（bug）来抱怨我的架构文档的质量。他应该说：选择使用Maven的解释不够充分。然后，我会重新考虑我的决定，要么更改它，要么更好地解释它。但再次强调，我这样做不是为了取悦Chris，而是为了修复一个被报告的缺陷。
总而言之，一个架构师在项目中必须是绝对的技术独裁者，并且不必说服任何人。如果不是这种情况，整个项目将面临巨大的风险，仅仅因为责任将会“泄漏”。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-22 at 10:13
