协商和领导技能是很难掌握的。要成为一名有效的软件架构师，需要多年的学习、实践和“经验教训”才能获得必要的技能。要知道这本书不能让架构师一夜之间成为协商和领导方面的专家，本章介绍的技巧为获得这些重要技能提供了一个良好的起点。
协商与促进
在这本书的开头，我们列出了对架构师的核心期望，最后一个是期望软件架构师必须了解企业的政治环境，并能够驾驭政治。这个关键期望的原因是，软件架构师做出的几乎每一个决策都会受到挑战。决策将受到开发人员的挑战，他们认为自己比架构师懂得更多，因此有更好的方法。决策将受到组织内其他架构师的挑战，他们认为自己有更好的想法或解决问题的方法。最后，决策将受到利益相关者的质疑，他们会认为决策成本太高或花费太多时间。
考虑架构师使用数据库集群和联合（使用单独的物理域范围数据库实例）来降低系统内总体可用性风险的决定。虽然这是解决数据库可用性问题的一个合理解决方案，但这也是一个代价高昂的决定。在本例中，架构师必须与关键业务利益相关者（为系统付费的人）协商，以就可用性和成本之间的权衡达成一致。
协商是软件架构师能够拥有的最重要的技能之一。有效的软件架构师了解组织的政治，具有很强的协商和促进技能，并且能够在出现分歧时进行克服，从而创建所有利益相关者都同意的解决方案。
与业务干系人进行协商
考虑以下真实场景（场景1），其中涉及关键业务干系人和首席架构师：
场景1：
项目发起人的高级副总裁坚持认为，新的交易体系必须支持五个9的可用性（99.999%）。然而，首席架构师相信，基于对业务领域和技术的研究、计算和认知，三个9的可用性（99.9%）就足够了。问题是，项目发起人不喜欢犯错或被纠正，而且非常讨厌那些居高临下的人。发起人不是十分了解技术（但自认为很了解），因此往往会参与到项目的非功能性方面。架构师必须通过协商说服项目发起人，三个9的可用性（99.9%）就足够了。
在这种协商中，软件架构师必须小心，不要在分析中过于自负和强硬，但也要确保他们在协商中没有遗漏任何可能证明对方是错误的东西。架构师可以使用几个关键的协商技术来帮助进行与这类干系人的协商。
提示
利用语法和流行语更好地了解情况。
诸如“我们必须零停机时间”和“我昨天就需要这些特性”之类的说法通常是没有意义的，但是却为即将进行协商的架构师提供了有价值的信息。例如，当项目发起人被问及何时需要某个特定的特性并回答“我昨天就需要它”时，这就向软件架构师表明，投入市场时间对该干系人很重要。同样，“这个系统必须闪电般的快”的说法意味着性能是一个大问题。“零停机”意味着可用性在应用中至关重要。一个有效的软件架构师将利用这种无意义的语法来更好地理解真正的关注点，从而在协商中利用语法的使用。
考虑前面描述的场景1。在这里，关键的项目发起人想要五个9的可用性。利用这种技术告诉架构师可用性非常重要。这引出了第二种协商技巧：
提示
在开始协商前尽可能多地收集信息。
短语“五个9”是表示高可用性的语法。然而，可用性的“五个9”到底是什么？提前对此进行研究，并在协商前收集知识，得到表23-1所示的信息。
“五个9”的可用性意味着每年5分钟35秒的停机时间，或者是每天1秒的计划外停机。很有雄心，但也相当昂贵，而且对前面的例子来说是不必要的。把事情使用几小时几分钟（或者在这种情况下，秒）来说明比坚持“几个9”的白话要好得多。
协商场景1将包括验证干系人的关注点（“我理解可用性对该系统非常重要”），然后将协商从几个9的白话引入到计划外停机的一个合理小时和分钟数上。三个9（架构师认为这已经足够好了）平均每天有86秒的计划外停机时间——考虑到场景中描述的全球交易系统的背景，这无疑是一个合理的数字。架构师可以随时使用以下技巧：
提示
当所有其他方法都失败时，用成本和时间来说明问题。
我们建议把这种协商策略留到最后。我们已经看到太多的协商一开始就出师不利是因为使用了比如“那会花很多钱”或者“我们没有时间做那件事”的开场白。金钱和时间（所涉及的努力）当然是任何协商的关键因素，但应作为最后手段以便首先尝试其他更重要的理由和合理化解释。一旦达成协议，如果成本和时间是协商的重要属性，那么就可以考虑它们。
另一个需要时刻记住的重要协商技巧是以下一点，特别是在场景1中描述的情况下：
提示
利用“分而治之”规则来限定需求。
中国古代武士孙子在《孙子兵法》中写道：“兵力合则离之。”同样的分而治之策略也可以由架构师在协商过程中应用。考虑前面描述的场景1。在这种情况下，项目发起人坚持新交易系统的可用性为五个9（99.999%）。然而，是否整个系统都需要五个9的可用性？将需求限定到系统实际上需要五个9可用性的特定区域，这样就减少了困难（和昂贵）需求以及协商的范围。
与其他架构师进行协商
考虑一下同一项目中一位首席架构师和另一位架构师之间的以下实际场景（场景2）：
场景2：
项目的首席架构师认为，异步消息传递将是一组服务之间通信的合适方式，以提高性能和可扩展性。然而，该项目的另一位架构师再次强烈反对并坚持认为REST是一个更好的选择，因为REST总是比消息传递更快，而且还可以进行扩展（“通过Google自己看看吧！”）。这不是两位架构师之间的第一次激烈辩论，也不会是最后一次。首席架构师必须说服其他架构师消息传递是正确的解决方案。
在这种情况下，首席架构师当然可以告诉其他架构师他们的意见无关紧要，并根据首席架构师在项目中的资历来忽略它。然而，这只会导致两个架构师之间的进一步敌对，并创建一种不健康的非合作关系，最终会对开发团队产生负面影响。以下技巧将有助于解决这些情况：
提示
永远记住，演示胜于讨论。
首席架构师应该向其他架构师演示如何在其特定环境中更好地选择消息传递，而不是与其他架构师争论REST与消息传递的使用。每个环境都是不同的，这就是为什么简单的谷歌搜索永远不会得到正确的答案。通过在类生产环境中对两个选项进行比较并向另一个架构师展示结果可以避免争论。
在这些情况下，另一个关键的协商技巧如下：
提示
避免在协商中过于争论或让事情变得过于针对个人的。沉着的领导力加上清晰简洁的推理总是会赢得协商。
这种技巧在处理类似场景2中描述的敌对关系时是一种非常强大的工具。一旦事情变得过于个人化或争论不休，最好的办法就是停止协商，待双方都冷静下来后再重新安排。架构师之间会发生争论；然而，当事情变得过于激烈时，冷静地处理这些情况通常会迫使对方让步。
与开发人员进行协商
有效的软件架构师不会利用他们作为架构师的头衔来告诉开发人员该做什么。相反，他们与开发团队合作以获得尊重，这样当开发团队提出请求时，就不会以争吵或怨恨告终。与开发团队合作有时会很困难。在许多情况下，开发团队感觉与架构（以及架构师）脱节，因此在架构师做出的决策方面感觉被排除在循环之外。这是象牙塔架构反模式的一个经典例子。象牙塔架构师只是从高层发号施令，告诉开发团队该做什么，而不考虑他们的意见或顾虑。这通常会导致对架构师失去尊重，并最终导致团队动力的崩溃。一种有助于解决这种情况的协商技巧是始终提供正当理由：
提示
当说服开发人员采纳架构决策或执行特定任务时，提供一个正当理由，而不是“从高层指挥”。
通过提供需要做某事的原因，开发人员很可能会同意这个请求。例如，考虑架构师和开发人员之间关于在传统的n层架构中进行简单查询的以下对话：
架构师：“你必须通过业务层才能进行调用。”
开发人员：“不，直接调用数据库要快得多。”
这个谈话有几个问题。首先，注意“你必须”这个词的用法。这种命令式的声音不仅缺乏尊重，而且是开始协商或谈话最糟糕的方式之一。还请注意，开发人员回应架构师的需求时有一个理由来反驳需求（通过业务层将更慢，需要更多时间）。现在考虑另一种解决这一需求的方法：
架构师：“因为变更控制对我们来说是最重要的，所以我们形成了一个封闭的分层架构。这意味着对数据库的所有调用都需要来自业务层。”
开发人员：“好的，我明白了，但是在这种情况下，我将如何处理简单查询的性能问题？”
注意，这里架构师为所有请求都需要通过应用的业务层的需求提供了合理的解释。首先提供合理解释或原因总是一个好办法。大多数时候，一旦一个人听到他们不同意的事情，他们就停止倾听。通过先说明原因，架构师确信合理的解释会被倾听到。还请注意，架构师删除了这个需求的个人特性。通过不说“你必须”或“你需要”，架构师有效地将需求转化为一个简单的事实陈述（“这意味着…”）。现在看看开发人员的反应。注意，对话从不同意分层架构的限制转移到了一个关于提高简单调用性能的问题。现在，架构师和开发人员可以进行协作对话，以找到快速进行简单查询的方法，同时保留架构中的封闭层。
与开发人员协商或试图说服他们接受他们不同意的特定设计或架构决策时，另一个有效的协商策略是让开发人员自己达成解决方案。这创造了一个架构师不会输的双赢局面。例如，假设架构师在两个框架中进行选择，框架X和框架Y。架构师认为框架Y不能满足系统的安全需求，因此自然选择框架X。团队中的一位开发人员强烈反对并坚持认为框架Y仍然是更好的选择。架构师没有争论这个问题，而是告诉开发人员，如果开发人员能够展示如何解决使用框架Y时的安全需求，那么团队将使用框架Y。以下其中之一必将发生：
1、开发人员将无法证明框架Y能满足安全性要求，并且将直接理解框架不能被使用。通过让开发人员自己找到解决方案，架构师可以自动地接受并同意使用框架X的决定，因为它本质上是开发人员的决定。这是一场胜利。
2、开发人员找到了一种使用框架Y解决安全需求的方法，并向架构师演示了这一点。这也是一场胜利。在本例中，架构师遗漏了框架Y中的一些内容，并且最终成为比另一个更好的框架。
提示
如果开发人员不同意某个决策，让他们自己来达成解决方案。
实际上，通过与开发团队的协作，架构师能够获得团队的尊重并形成更好的解决方案。开发人员越尊重架构师，架构师就越容易与这些开发人员协商。
作为领导者的软件架构师
软件架构师也是一个领导者，他可以通过架构的实现来指导开发团队。我们坚持认为，具备良好的人际交往能力、促进能力和领导能力占据了对于成为一个有效的软件架构师的条件的一半。在本节中，我们将讨论几个关键的领导技巧，一个有效的软件架构师可以利用这些技巧来领导开发团队。
架构师的四个C
每天的事情似乎越来越复杂，无论是业务流程的复杂性增加，还是系统甚至架构的复杂性增加。复杂性存在于架构和软件开发中，而且永远如此。有些架构非常复杂，例如支持六个9的可用性（99.9999%）——这相当于每天约86毫秒的计划外停机时间，即每年31.5秒的停机时间。这种复杂性被称为本质复杂性，换句话说，“我们有一个难题。”
许多架构师陷入的陷阱之一是给解决方案、图表和文档增加不必要的复杂性。架构师（以及开发人员）似乎喜欢复杂性。引用尼尔的话：
开发人员被复杂的事物所吸引，就像飞蛾被火焰吸引一样，结果往往是一样的。
考虑图23-1中的图表，它说明了一个非常大的全球性银行的后端处理系统的主要信息流。这一定要弄得这么复杂吗？没有人知道这个问题的答案，因为架构师已经把它弄得很复杂。这种复杂性被称为偶然复杂性，换句话说，“我们使一个问题变得困难。” 架构师有时这样做是为了证明他们的价值，因为事情看起来太简单，或者无法保证他们总是保持在与业务或架构相关的讨论和决策中。其他架构师这样做是为了维护自己的工作安全。不管是什么原因，将偶然的复杂性引入到不复杂的事物中，是成为一名无效的架构师领导者的最佳方法之一。
避免意外复杂性的一个有效方法是我们称之为架构的四个C：沟通（Communication）、协作（Collaboration）、清晰（Clarity）和简洁（Conciseness）。这些因素（如图23-2所示）共同作用，在团队中创建一个有效的沟通者和合作者。
作为领导者、促进者和协商者，软件架构师能够以清晰简洁的方式进行有效的沟通是至关重要的。同样重要的是，架构师还能够与开发人员、业务干系人和其他架构师协作，共同讨论和形成解决方案。专注于架构的四个C有助于架构师赢得团队的尊重，成为项目的万事通，每个人过来不仅是为了提问，也是为了获得建议、指导、培训和领导。
务实而富有远见
一个有效的软件架构师必须是务实且富有远见的。做到这一点并不像听起来那么容易，需要相当高的成熟度和丰富的实践来完成。为了更好地理解这句话，请考虑一下远见的定义：
远见
用想象力或智慧思考或规划未来。
作为一个有远见的人意味着将战略思维应用到一个问题上，这正是架构师应该做的。架构是对未来的规划，并确保架构的生命力（一个架构的有效性）在很长一段时间内保持不变。然而，很多时候，架构师在他们的规划和设计中变得过于理论化，创造出的解决方案变得难以理解甚至难以实现。现在考虑一下务实的定义：
务实
以一种基于实际而非理论性考虑的方式理智而现实地处理事情。
虽然架构师需要成为有远见的人，但他们也需要应用实际和现实的解决方案。务实是在创建架构解决方案时考虑到以下所有因素和限制：
- 预算限制和其他基于成本的因素
- 时间限制和其他基于时间的因素
- 开发团队的技能集和技能水平
- 与架构决策相关的权衡和影响
- 建议的架构设计或解决方案的技术限制
一个好的软件架构师应该努力在务实和运用想象力和智慧来解决问题之间找到一个适当的平衡（见图23-3）。例如，考虑这样一种情况：架构师面临处理弹性的难题（并发用户负载的突然和显著增加是未知的）。一个有远见的人可能会想出一个复杂的方法来处理这个问题，通过使用一个复杂的数据网格，它是一个分布式的、基于领域的数据库的集合。理论上，这可能是一种很好的方法，但务实意味着将理性和实用性应用于解决方案。例如，该公司以前是否使用过数据网格？使用数据网格的利弊是什么？这真的能解决问题吗？
在务实但富有远见之间保持良好平衡是架构师获得尊重的一个极好方法。业务干系人会欣赏适合于一系列约束的有远见的解决方案，开发人员将乐于获得一个实用（而不是理论）解决方案来实现。
一个务实的架构师首先要看看当需要高弹性时的限制因素是什么。数据库是瓶颈吗？对于调用的某些服务或所需的其他外部资源来说，这可能是一个瓶颈。找到并隔离瓶颈将是解决这个问题的第一个实际方法。事实上，即使是数据库，是否可以缓存一些需要的数据，以便根本不需要访问数据库？
以身作则领导团队
糟糕的软件架构师利用他们的头衔让人们去做他们想做的事情。有效的软件架构师不利用他们作为架构师的头衔，而是通过以身作则来引导人们去做事情。这完全是为了赢得开发团队、业务干系人和整个组织的其他人（如运营主管、开发经理和产品负责人）的尊重。
经典的“以身作则，不以头衔为首”的故事涉及到一个上尉和一个中士在一场军事战斗中。这位很大程度上在军队以外的高级队长指挥全军在战斗中向前推进，占领一个特别困难的山丘。然而，士兵们并没有听上尉的话，而是满腹狐疑地向下级军士打量他们是否该上山。中士看了看形势，微微点了点头，士兵们立刻信心十足地向前走去并占领山丘。
这个故事的寓意是，当涉及到领导人们时，级别和头衔意义不大。计算机科学家杰拉尔德·温伯格（Gerald Weinberg）有句名言：“不管问题是什么，都是人的问题。”大多数人认为解决技术问题与交际能力无关，而与技术知识有关。虽然拥有技术知识对于解决一个问题是必要的，但它只是解决任何问题的整体方程式的一部分。例如，假设一个架构师正在与一个开发团队开会，以解决生产环境中出现的问题。其中一位开发人员提出了建议，架构师回答说：“好吧，这是个愚蠢的想法。”不仅开发人员不会再提建议，其他开发人员也不敢说任何话。在这种情况下，架构师已经实际上关闭了整个团队在解决方案上的协作。
获得尊重和领导团队是关于基本的人际交往能力。考虑架构师与用户、客户或开发团队之间关于应用中性能问题的对话：
开发人员：“那么我们要如何解决这个性能问题呢？”
架构师：“您需要做的是使用缓存。这将解决这个问题。”
开发人员：“不要告诉我该怎么办。”
架构师：“我要告诉你的是，它可以解决问题。”
通过使用“你需要做的是…”或“你必须”这两个词，架构师将他们的观点强加给开发人员，并基本上关闭了协作。这是一个使用交流而不是协作的好例子。现在看一下修改后的对话：
开发人员：“那么我们要如何解决这个性能问题呢？”
架构师：“你考虑过使用缓存吗？这可能会解决问题。”
开发人员：“嗯，不，我们没想过。你的想法是什么？”
架构师：“好吧，如果我们在这里放置一个缓存……”
注意对话中“你考虑过……”或“关于……”的用法。通过提出问题，它将控制权放回到开发人员或客户身上，创建一个协作对话，架构师和开发人员一起工作以形成一个解决方案。在尝试建立协作环境时，语法的使用至关重要。作为架构师的领导者，不仅能够与其他人协作创建架构，还可以作为促进者帮助促进团队之间的协作。作为一个架构师，试着观察团队的动态，并注意像第一次对话这样的情况何时发生。通过将团队成员叫到一边，指导他们使用语法作为协作的手段，这不仅可以创造更好的团队活力，而且有助于在团队成员之间建立尊重。
另一个可以帮助架构师和开发团队建立相互尊重和健康关系的基本人际技能是，在谈话或协商过程中总是尝试称呼人的名字。人们不仅喜欢在谈话中听到自己的名字，而且有助于培养熟悉感。练习记住别人的名字，并经常使用。在名字有时发音困难的情况下，请确保发音正确，然后练习直到发音完美为止。每当我们问某人的名字时，我们都会重复给他听，问他这是不是正确的发音方式。如果不正确，我们就重复这个过程，直到正确为止。
如果架构师是第一次或只是偶尔与某人见面，一定要和他握手并眼神交流。握手是一种重要的人际交往技巧，可以追溯到中世纪。在简单握手过程中发生的物理联系让两个人都知道他们是朋友，而不是敌人，并形成了他们之间的联系。然而，有时候很难正确地完成一个简单的握手。
当和某人握手时，要坚定地（但不是压倒性地）握手，同时看着对方的眼睛。握手时把目光移开是不尊重的表现，大多数人都会注意到这一点。另外，握手不要握得太久。简单的两到三秒的坚定握手是开始谈话或问候某人所需要的。还有一个问题是，握手过分热情让对方感到不舒服，从而不想与你交流或合作。例如，想象一个软件架构师每天早上都来和每个人握手。这不仅有点奇怪，还造成了一种不舒服的局面。然而，想象一下一个软件架构师，他必须每月与运营主管会面。这是一个绝佳机会，站起来说“你好露丝，很高兴再次见到你”，并迅速、坚定地握手。知道什么时候握手，什么时候不握手是人际交往技巧复杂艺术的一部分。
作为领导者、促进者和协商者的软件架构师应该小心地维护所有级别的人之间存在的界限。如前所述，握手是一种有效且专业的技巧，可以与你正在交流或合作的人建立物理联系。然而，虽然握手是好事，但在专业场合拥抱，不管任何环境下都不是好事。架构师可能会认为它体现了更多的物理联系和纽带，但它所做的只是有时会让工作中的另一个人更不舒服，更重要的是，可能会导致工作场所内潜在的骚扰问题。不管职业环境如何，不要互相拥抱，而要坚持握手（当然，除非公司里的每个人都互相拥抱，这会……很奇怪）。
有时候，最好把一个请求变成一个帮助，以此让某人做一些他们不想做的事情。一般来说，人们不喜欢别人告诉他们该做什么，但在很大程度上，人们希望帮助别人。这是基本的人的本性。考虑一下架构师和开发人员之间关于繁忙迭代期间架构重构工作的以下对话：
架构师：“我需要您将支付服务分为五种不同的服务，每种服务都包含我们接受的每种支付类型的功能，例如商店信用卡、信用卡、贝宝、礼品卡和奖励积分，以便在网站中提供更好的容错性和可扩展性。这应该不会花太多时间。”
开发人员：“不行，伙计。这个迭代太忙了。对不起，我做不到。”
架构师：“听着，这很重要，需要在这个迭代中完成。”
开发人员：“对不起，不行。也许其他的开发团队也能做到。我实在太忙了。”
注意开发人员的答复。这是对任务的立即拒绝，尽管架构师通过更好的容错性和可伸缩性来证明它的合理性。在这种情况下，请注意，架构师是在告诉开发人员做一些他们实在太忙而不能做的事情。还要注意的是，请求中甚至没有包含人的名字！现在考虑一下将请求转化为帮助的技巧：
架构师：“嗨，斯里达尔。听着，我处于一个真正的困境。我真的需要将支付服务分成不同的服务，以获得更好的容错性和可扩展性，我等了太久去做这个事情了。你有什么方法可以将其压缩到这个迭代中吗？这真的会帮了我一个大忙。”
开发人员：“（暂停）…我真的很忙，但我想是的。我看看我能做什么。”
架构师：“谢谢，斯里达尔，我真的很感谢你的帮助。我欠你一个人情。”
开发人员：“不用担心，我会在这个迭代中完成的。”
首先，注意在整个谈话过程中反复使用对方的名字。使用这个人的名字使谈话更像是一种个人的、熟悉的性质，而不是一种客观的职业需求。第二，请注意，架构师承认他们处于“真正的困境”，拆分服务将真正“帮助他们解决很多问题”。这种技巧并不总是有效的，但在第一次谈话中，发挥互相帮助的基本人性会有更好的成功几率。下次面对这种情况时，尝试一下这种方法去看看结果。在大多数情况下，结果会比告诉别人做什么更积极。
为了领导一个团队并成为一个有效的领导者，软件架构师应该努力成为团队中的万事通，开发人员会为他们的问题和困难而寻求帮助。一个有效的软件架构师将抓住机会，主动领导团队，而不管他们在团队中的头衔或角色是什么。当软件架构师观察到有人在技术问题上挣扎时，他们应该介入并提供帮助或指导。对于非技术性的情况也是如此。假设一个架构师观察到一个进入工作的团队成员看起来有点沮丧和烦恼，很明显出了什么问题。在这种情况下，一个有效的软件架构师会注意到这种情况，并提出这样的建议：“嘿，安东尼奥，我要去喝杯咖啡。我们为什么不一起去呢？“然后在散步的时候询问是否一切都好。这至少为更多的个人讨论提供了一个机会；而且最好是提供一个在更个人层面上指导和教导的机会。然而，一个有效的领导者也会意识到有时不能太死缠硬磨，会通过阅读各种语言符号和面部表情进行避让。
作为一个领导者，要想赢得尊重并成为团队中的万事通，另一个技巧是定期举办自带午餐来讨论特定的技巧或技术。每一个读这本书的人都有其他人没有的特殊技能或知识。通过举办定期的午餐会，架构师不仅可以展示他们的技术能力，还可以练习演讲和指导技巧。例如，主持一个午餐会来讨论设计模式或编程语言版本的最新特性。这不仅为开发人员提供了有价值的信息，而且还开始将你确定为团队中的领导者和导师。
与开发团队融合
架构师的日历通常都是充满会议，其中大多数会议与其他会议重叠，如图23-4所示的日历。如果这是软件架构师的日历，那么架构师何时有时间与开发团队在一起来帮助指导和指导他们，并在出现问题或忧虑时有空呢？不幸的是，在信息技术世界里，会议是一种必要的邪恶。它们经常发生，而且永远都会发生。
成为一个有效的软件架构师的关键是为开发团队留出更多的时间，这意味着控制会议。架构师可以参与两种类型的会议：强加的（架构师被邀请参加会议）和强推的（架构师召集会议）。这些会议类型如图23-5所示。
强加的会议是最难控制的。由于软件架构师必须与多个干系人进行沟通和协作，所以架构师几乎被邀请参加每一次预定的会议。当被邀请参加会议时，一个有效的软件架构师应该总是询问会议组织者为什么需要他们参加会议。很多时候，架构师被邀请参加会议只是为了让他们了解正在讨论的信息。这就是会议纪要的用途。通过询问原因，架构师可以开始确定他们应该参加哪些会议，哪些会议可以跳过。帮助减少架构师参与的会议次数的另一个相关技术是在接受会议邀请之前询问会议议程。会议组织者可能觉得架构师是必要的，但是通过查看议程，架构师可以确定他们是否真的需要参加会议。而且，很多时候不必出席整个会议。通过审查议程，架构师可以通过在讨论相关信息时出现或在相关讨论结束后离开来优化他们的时间。如果你可以和开发团队一起工作的话，不要浪费时间在会议上。
提示
请提前询问会议议程来帮助确定是否需要参加会议。
另一种让开发团队保持在正轨上并赢得他们尊重的有效方法是，当开发人员也被邀请参加会议时只邀请一个人来代表团队。与其让技术负责人参加会议，不如代替他们，特别是当技术负责人和架构师都被邀请参加会议时。这使得开发团队专注于手头的任务，而不是连续地参加会议。虽然将有用的团队成员从会议上离开会增加架构师参加会议的时间，但它确实提高了开发团队的生产力。
架构师强加给其他人的会议（架构师召集的会议）有时也是必要的，但应保持在绝对最低限度。这些都是架构师可以控制的会议类型。一个有效的软件架构师总是会问，他们召集的会议是否比他们让团队成员离开工作更重要。很多时候，只需要一封电子邮件就可以传达一些重要的信息，这样可以为每个人节省大量浪费掉的时间。当以架构师的身份召开会议时，一定要制定议程并附上去。很多时候，架构师召集的会议由于其他问题而脱轨，而其他问题可能与会议中的其他人无关。另外，作为一个架构师，要密切关注开发人员的工作流程，并且确保不要因为召开会议而破坏它。流是开发人员经常进入的一种思维状态，大脑100%地投入到一个特定的问题中，给予充分的注意力和最大的创造力。例如，一个开发人员可能正在处理一个特别困难的算法或一段代码，实际上几个小时过去了但感觉似乎只有几分钟。当召开会议时，架构师应该总是尽量安排会议要么是在上午的第一件事，午饭后，要么是在一天快结束的时候，而不是在大多数开发人员一天中经历流状态的时候。
除了管理会议之外，一个有效的软件架构师可以做的另一件事就是和开发团队坐在一起。坐在远离团队的隔间里传达出这样一个信息：架构师是特殊的，而围绕在隔间周围的那些物理墙则是一个明确的信息：架构师不会被麻烦或打扰到。与开发团队坐在一起传递这样一个信息：架构师是团队的一个组成部分，当问题或关注点出现时，架构师可以随时回答。通过实际展示他们是开发团队的一部分，架构师获得了更多的尊重，并且能够更好地帮助指引和辅导团队。
有时，架构师不可能与开发团队坐在一起。在这种情况下，架构师能做的最好的事情就是不断地走来走去并让团队看到。喜欢在不同楼层或总是在办公室或小隔间里、从未出现过的架构师不可能帮助指导开发团队完成架构的实现。在上午、午餐后或一天的晚些时候留出时间与开发团队交谈，帮助解决问题，回答问题，并进行基本的指导。开发团队非常感谢这种沟通类型，并尊重你在一天里为他们留出时间。对其他干系人来说也是如此。在去喝咖啡的路上，顺便向运营总监问好，这是保持与企业和其他关键干系人沟通畅通的绝佳方式。
总结
本章介绍和讨论的协商和领导技巧旨在帮助软件架构师与开发团队和其他干系人形成更好的协作关系。这些是成为一个有效的软件架构师必须具备的必要技能。虽然我们在本章中介绍的技巧是开始成为更有效领导者的好技巧，但也许最好的技巧来自美国第26任总统西奥多·罗斯福（Theodore Roosevelt）的一句话：
成功公式中最重要的一个因素是知道如何与人相处。
- 西奥多·罗斯福
