在架构师的角色中，沟通是要求有效果的必备技能与工具。换句话说，沟通是架构师指示别人或群体完成特定行动唯一真正有效的手段。

        架构师通常没有对为其项目工作的他人的直接管理权。他们的项目往往是跨部门的，也可能会跨好多个行业单位。由于不能直接管理他人，所以架构师指 示别人或群体完成特定行动的能力就受到限制。他们唯一真正有效的手段就是其影响力。靠技术晋级的人主要关注在技术性的专业知识上。成为技术专家，沟通技术 知识对于他们往上爬来说是非常关键的技能。这种技能通常意味着维护你的职位，明确特定项目的潜在风险和当前问题。在单位等级结构的这一层上，你应该阻止产 生问题、寻找问题并且解决问题。你的上级都在盯着看你的每一步动作。压力往往会非常大。对于靠技术吃饭的人来说，若想迈出跳至管理的第一步（我认为架构师 已经在进行部分管理工作了），阶梯上的下个台阶的特性已经大大变化了。尤其是，首先要求的技能是沟通范围、数量大大地拓宽了。

        架构师必备的关键软技能：沟通

        架构师的沟通首先基于沟通原则，其次是沟通策略，在此之上是与执行官的有效沟通。

        一、沟通原则

        学习有效沟通是一个终身的过程——永远都有改善的余地。要学习的沟通原则包括：先听后说、专心致志（人和心思在一处）、正面思考等，这些原则有助于建立与别人的信任关系，使你成为更高超的沟通者。

        1. 先听后说

        你有没有发现自己在某次谈话中总是想寻求一次讲话的机会，而没有真正在听别人说什么？当你没有听时，你传递给那个对你讲话的人什么信息呢？

        至少表面上，你显得不在乎别人说什么。大部分人会很快厌倦这样的谈话，因为他们说的话白白在空气中传播却没人去听。说话的人也许会想他还有更好 的事要做，而结束此次谈话。如果你只是偶尔这样做，这种行为没什么大不了的。如果这是你的习惯做法，那么你是在自己与别人之间构筑一道墙。

        你听的时候，是不是在找机会纠正对方？即便谈论的话题在往前走，但是你的思路还停留在刚才的某一点上？

        这种情况说明，我们并没有在听别人说什么。讲话的人对你很在乎，从其忙碌的工作中抽出时间，为你提供这些宝贵的信息，所以应该认真去听他说什么。

        当有人与你说话时，要看着他说，并试着理解他想沟通的内容。给对方足够的时间来表达他的观点，然后再向其询问要澄清的问题。向他表达非语言的反馈，例如点头，让他知道你在关注这次谈话。

        我认为罗马人 Epictetus 说得好：“我们有两个耳朵，一个嘴巴，所以我们应该多听少说。”

        2. 专心致志

        不管你在哪里，都应专心致志。生活中有许多事情要分神，例如这个周末你要做什么，几分钟前开会回来如何解决会上的问题，怎样找个办法告诉老板某个负面的消息，小孩今晚的英式足球比赛几点开场……所有这些琐事都很容易让你想入非非。

        一般来说，人在任何时刻最多只能同时处理 7 件±2件那么多的事。如果你的脑袋全是一些无关紧要的琐事，你就无法专心致志地做事。要是有人对你说话，你就会完全听不到他在讲什么。倘若他在问你问题， 你可能要他们再说一遍。这种情况下，你其实是在浪费别人的时间，他们不会高兴的。如果房间里有个执行官，你就会给人家留下一个持久的坏印象：真是个浪费钱 的家伙！

        请你读些时间管理方面的书，列出每天需要关注事情的清单计划。在计划中安排好任务的优先级（当天、本周等），并标识每个任务准备投入的时间。这个办法能够让你通过计划安排好每件事，节省你的精力去记忆周围各种正在发生的事。

        如果某个会议不是真的需要你参加，你就不要去；假如确实需要你参加，就一定要去，而且人和心思都花在那里。

        我发现，坐直、将脚放在座位正下方、做笔记、直视正在讲话的人，能够自然而然地全神贯注于会议正在进行的事情，从说话和肢体语言两方面都给人以积极参与的正面印象。

        不管你做什么，都要专心致志！

        3. 正面思考

        当你表达信息时，总有许多种方法去传递它们。信息需要真实和准确，然而表现出其意义的方式可以多种多样。

        你可以以积极意义或消极意义提供信息。你可以基于所期望的结果选择某种方法。也可以采用不偏不倚的方式，不带情绪地列举事实，尽管这通常很难做到。

        从沟通的观点来看，人们容易注意负面的东西。通常负面消息总会带来恐惧（当我感觉恐惧邻近时，我会把它当做“要求集中精力的行动”的信号）。

        作为架构师，你需要避免不必要的偏见信息，让别人能够选择他们要关注的信息。你可以提供若干种替代方案，但这些方案应当是客观平等的。你需要察觉可能的办法，而不是为别人留下疑惑。

        4. 尽早道歉

        在一天的事务中，你可能注意到对他人做的某个事情不合适或不正确。记住放下自尊去给受影响的对方道一个歉。向别人诚心道歉并不是好玩或者容易之举，但你可以赢得别人的尊敬，展示你在尽力成长，尝试变得更好的意图。

        如果你道歉，对方就有可能重新审视事情，而原谅你带来的任何苦恼伤痛。有些让人尴尬的事情转而有了积极意义。你与那人的关系就有了增进的机会，而不是就此冷淡。

        人的本能倾向就是让冒犯别人后的情势不了了之。遗憾的是，你可能埋下了让它长大成祸患的种子，以致对你造成长期的影响。被得罪的人可能会耿耿于 怀，在很长很长时间内记住这件事。那个人也许会把这件事告诉别人，说你是个什么类型的人。你和此人及周围其他人的交往能力可能大打折扣。最后，或许你已经 忘记做过的事，但是对方却没有忘记。

        道歉时，你要清楚地表达出要道歉的是什么，你说的是什么意思。如果你不是诚心道歉，虚假的说辞可能把事情弄得更糟。如果你不能表达诚意，就不要道歉，但你的目标应当是努力与你所交往的人修缮积极的关系。避免让道歉使你向错误的方向发展，限制你的个人成长。

        5. 不要在缺陷上招致恼羞成怒

        当你在开评审会（例如产品概念评估、需求评审、设计评审、代码评审、测试评审、产品发布评审）时，通常会检查出评审项目的一些缺陷。评审项目的作者对于这些暴露出的缺陷当然会感到不自在。

        出于通常的礼貌，一旦在特定领域发现了三四个问题，就不要再过高、过深地批评了。如果你需要指出再多的条目，可以将其写下来，让被困扰的人随后能仔细看到这些要点。否则这些事情会招致对方恼羞成怒。由于被评审人成了众矢之的，在效率上会极大地影响评审的后续进展。

        对于评审，有下列一些有效的办法：

• 确保对评审项目的关注，而评价不是针对生产或创造评审项目的人或单位。换句话说，评审应针对事物、方法，而不是针对人。
• 避免用“你”、“你的”这类个人化的评价。
• 设法表达你要求修改的原因是想达成什么目标：确定修改与市场策略有关，基于一般的架构原则，抑或是公司或部门的目标？
• 评审应关注改善评审项目的方法，不仅仅因为没有遵循某个编码指导原则，而是修改后为什么有用。评审项目的人不仅需要知道怎样把事情做得更好，还要知道为什么这种改进是有用的。
• 找机会说出已做出的工作的积极成分。大多数人被指出暴露的缺陷后，都会非常想要辩解，而找到工作的好的方面能够软化这种态势。所有与会者都应明白，目标是创造优秀的工作成果，每个人都要求用同样的标准—这是集体的努力。
• 确保会上的每个人都参与进来。以局外人的身份参加会议是在浪费公司的时间。
• 模仿你在寻求的行为。拿出当评审你的工作，且结果是“很好，继续干吧”时的行为。目标是创造优秀的工作成果并持续改进它。换句话说，不是关于你的事，而是关于如何奋力争取优秀的事。
• 举止文雅：倘若角色互换，作为被评审人，你希望别人怎样给你反馈意见？
• 任何问题都应记录在案—不只是你感兴趣要追踪的事，还包括其他人提出的记录。如果确有一大串条目需要引起注意，可能随后还要再进行一次评审。

        二、沟通策略

        在我们研究了沟通的核心原则后，现在你可以应用一系列策略来展示恒定、高效的沟通风格。

        1. 多说“是”，少说“不是”

        架构师经常会被咨询问到某个项目的可行性，并提供从战略到战术的多个替代方案，附带若干成本选项，以使商务伙伴能根据特定项目的投资进行判断。 架构师与项目评估团队的角色不是决定要构建什么，而是决定怎样构建。我们试图说出的答案是“对，我们能构建这个项目，这些是相关的信息”。产生的信息需要 包括诸如所考虑的各种替代方案、项目风险（以及可能的规避策略）、基于的假设条件，以及需要指出的突出问题。我们不是在寻找这样的答案：“不行，这个项目 不可行，但我们能构建另一个项目（通过消除原困难项目中的难题，而代之以我们想构建的那些特性）。”

        关键点：作为架构师，我们要寻求说“是”的方法。

        但是，如果一个项目或任务不可行，我们需要立即巧妙地指出评估结果、解释原因，并提供替代方案。这通常归结于法律法规、行规等原因，以致“不” 是正确的回答。当然了，还有其他一些例外情况：提出需求的人是想逃避工作，需求违反了公司的政策，或者你手头有优先级更高的工作，无法让你有足够时间来对 需求做出满意的答复。这些情况下，你要清楚地告诉人家你说“不”的原因。

        如果执行官要求你做某件事，你要确信这个要求的优先级。如果是高优先级要求，你一定要分析不做其他任务的影响，并反馈给执行官。这将让高一级的 经理在确定任务的孰重孰轻时有足够的信息。它也有助于你免于日后陷入两难境地而无法自拔—如果你不得不解释为什么不让另一位经理知道就耽误了其他重要的任 务。学会说“是”可以采用多种替代形式。通常，它涉及为某人或某个项目找到继续前行的办法。没有必要你自己来承担任务或需求。也许你可以提供一套合理的替 代方案，或者引导提出需求的人找到其他人，后者能够解决项目当前面临的问题。对于需要可行性信息的多数项目而言，最值得期望的方法就是提供一个自助餐式的 选项，详细罗列出成本、风险、战略影响以及有效的组合等信息。这种策略让需求者处于决定者的地位，使他可以选取最能产生商业价值的解决方案。提供一组方案 供客户和同事选择，这种做法能让你自然而然地与他们建立友好关系。

        2. 在销售过程中建立起信任关系

        想想你上次购买一辆车、盖房或者购置一个大物件的情形。这次购买的成就感或挫折感很大限度上取决于你所打交道的销售员或签约人。销售员总是仔细倾听你想要什么东西，通过提供下列信息，让你能够以决策者的身份决定你想买的东西：

• 可用的选择方案；
• 各选择方案的开销；
• 各选择方案的好处；
• 各选择方案能够如何组合；
• 各选择方案涉及的风险；
• 每种选择方案已知的问题。

        销售员不大可能强行把你往这个或那个方向引导，但会帮助你理清需求，为你寻找以最低花费得到最高价值的解决方案。为做到这一点，他的自身利益只 能退而求其次。通过将你的需求置于第一位，销售员能够建立与你的信任关系。这种信任让你感觉你是在有足够信息的情况下做决定，而他是你的伙伴。当有人问起 你新购置的物件时，你很可能不只对这个物品的方方面面滔滔不绝，还会提到那个了不起的销售员，并推荐他给你周围那些想购买类似物件的人，因而又开启了一个 销售周期。

        作为架构师，你应当成为那个销售员，值得别人信任。

        3. 特殊场合才说“不”

        从架构师的前景来看，只有在若干种情况下你可以简单地说“不”。大多数时候，你必须提供能让事情完成的替代方案（涉及费用、风险和每种方法的好处）。最后的决定取决于项目的主人（即掌握购买权的人）。

        在其他时候，说“不”是合适的（如图 3 所示）。通常这种拒绝需要有足够合理的深度来支撑，以应付所有必要的质疑。争论的领域很可能与任何项目都存在的关键限制因素有关，如效果、成本、时间和范围。

        爱惜你的“不”，而只把它用到礼仪场合——不要轻易用它。

        下面是说“不”和不说“不”的一些考虑因素：

• 对于项目的最后期限，当要求违反“物理法则”，即无法执行项目给定最后期限内的所有步骤（例如：硬件的获取和供应、规划、开发、要求的培训、测 试、修正错误和部署）时，说“不”是可接受的。但不能因为工作看起来困难、你不大喜欢它或者有其他不能同时进行的优先级（也许当前需求会很快成为最高优先 级—值得将此列为一个风险）。中性地陈述各竞争优先级的任务，从而让执行官能根据各自的相对重要性安排它们。

        问自己这些问题：

• 我表现正直吗？我在会议上公开说的话与我在门廊中说的话一致吗？如果你真的对需求有疑问，应当将它们摆到台面上，即便对你并没有什么好处。与通常一样，这种行动应当以文雅、令人尊敬的方式做出。
• 有没有替代方案能消除“物理法则”问题？脱开思维框框的束缚。如果这是你的公司，你如何解决问题？（当然了，答案不是解雇你周围的所有人。）如果 你在特定领域中没有专业知识，你能引入有这方面专业知识的外包人员吗？其他人有没有解决过类似问题？你能将他引入项目，或者至少请教他一些问题吗？是否有 一些概念证明能迅速实施来降低项目在某些地方的风险？你需要更多的时间来评估项目吗？
• 有没有其他人可以和你一起进行头脑风暴，以找出解决方案？
• 你能分阶段定义项目，每阶段都有可发布的东西（主要的发布）吗？这个分阶段的办法使你能够分别为每个阶段寻求资金，也能够定位你首先要了解什么内 容。随着你了解情况的深入，你可以评估下一个阶段，倘若发现下一阶段并不可行，或者不能提供足够商业价值来继续推进的话，你可能退出项目。
• 如果你不说“不”，你可能注定是在“死亡行军”（death march）——项目已经有了高度可见性，无休止的加班，客户永远不怎么满意。要求有适当的期望值来避免这种结果。
• 特定的环境有时会影响说“是”或“不”的决定。例如，在停业期（layoff）或外包（outsourcing）期间，可能需要更微妙的方法。每个人在此气氛下都很紧张急躁，项目协商变得很具挑战性。

        只说“不”或仅仅阐述事实很难让人接受。充分准备来解释所做决定的原因，证明所做决定是好的商业决定。通过列举事实，探究事实背后的根本原因，陈述此根本原因如何支持期望的商业目标。

        作为架构师，你就是在推销东西。你需要准备即便出现问题，也要将解决方案推销出去。人们提出问题时，可能看上去与你在作对，而实际上，人们询问 是为了确认此解决方案，或者他们要了解此解决方案。他们提出问题，是因为他们随后也可能要向他们所在的单位推销这些提及的解决方案。

        你要相信所提到的解决方案。如果你并不真正相信你所推销的东西，你的肢体语言和眼睛会说实话的。你的不诚实如同水中的血腥味那样：你很可能被问 及更详细的一些问题，如同鲨鱼在攻击一样。在某种意义上，你是将自己置身于未曾准备好的问题。你需要了解足够多的细节来相信这种解决方案。在你向人们提出 某种解决方案时，你也需要自我提问和回答有关的难题。

        在所有可能情况下，避免真的说“不”。事实上，根据你所交互的人或群体的语境，解释决定所基于的原因。

        4. 抑制想自卫的冲动

        通常在交谈中，当我们听到并不完全对自己有正面意义的事情时，我们可能会找借口，我们可能会找办法转移话题，并责怪他人，以使自己脱离干系。或者我们想强词夺理，以阐述那些语句。应当避免做出此反应的冲动。相反，代之以等待，并接受别人所说的话。

        在上一段描述的反应中，会谈的真正兴趣已经从对别人转移到你身上。听别人说话的行为至少暂时结束了，我们开始与会谈者发出警示信号：“我们把话 题引向另一个方向吧，一个和我没关系的方向。”注意你正在用的肢体语言—胳膊交叉在胸前，或者头转向一边告诉别人“我不想听了”。

        问自己这个问题：我能从这个人说的话中学到什么？”通常，他给出的信息也许并不是你乐意听到的，但其动机是好的，仍是你接受信息并获得个人成长的机会。

        抑制想自卫的冲动的一个例外就是当手头的问题涉及企业政策或你的正直时。如果别人说的话使你真正涉及与公司政策冲突或你出于正直未做某事（假 如，你已经正确做出了行动）时，你需要立即抨击这些说法。你可能想用澄清问题的办法来明确要点，比如“你的意思是我做过某事吗”。如果别人说“是的”，你 就以“这并不准确”来明确回应；倘若人家回答“不是”，要感谢他澄清了此事。

        5. 倾听建议来改善合作

        先寻求理解别人，再寻求被人理解。——作家、演讲家 Stephen Covey

        从软件开发的角度看，批评别人和被批评的情况经常发生。因为有软件评审、设计评审、架构方法评审、单元测试、功能测试、缺陷跟踪，或者只是简单地向别人寻求帮助，与上司一对一地谈话，这个列表不断在进行。在所有情况下，总有机会将别人说的话特定到你身上。

        一旦你把谈话话题转移到自己身上，而不是工作成果或某些事件上，你本能的自卫意识就来了。这时，你听进去任何事情的能力就变得有限，“要么拼 命，要么逃跑”的本能反应开始占据上风，而你的大脑指挥身体开始变得激动，以准备自我保护。所沟通的用于改善工作成果的有价值信息烟消云散。从商业角度 看，将一项工作产品做得尽可能优秀以符合每个人的最大利益，因为我们越能为产品增加价值，公司越有机会从投资中得到回报。

        如果你能避免在谈话中个人化，你听取别人说话的能力就大大提升了。要试着找出他说话的真正用意（即便你不同意他说的话）。以适当的方式取得他想 传递的本意，复述一遍要点。一般情况下，别人只是想被理解，他并不是在寻求你同意他的观点。当你倾听并能理解对方表达的要点时，你就能和他心灵相通。

        关键点：通过倾听并复述所说过的话，来理清自己的理解。

        6. 了解别人和自己的沟通需求

        在架构师的世界中，你需要例行地与许多人交流。你可能在上一次会议上与有些人谈过话，也可能没有和这些人谈话。挑战就是快速了解人们在说什么，他们怎么说这些话，来“读懂”本次会议。

        观察关键的时刻，即做出决定的时刻是一个要点，以此识别人们提出的问题和关心的地方，来加强核心概念，帮助你关注会议的方向以及把会议引向一个成功的结论。为了认识这些关键时刻，我们需要吸收所有信息，包括提供给我们的语言或非语言信息。

        观察别人的举止能够告诉我们如何与每个人最好地沟通。由于每个人都不相同，并且对沟通也有不同的需求，架构师必须让传递信息的方式适应这些需求，以确保有效沟通。

        关键点就是我们要基于每个听众成员的沟通需求来匹配交流风格。有些人的反应是能够看出来的，他们的偏好能够用诸如“我明白你的意思”之类的话辨 别。另外有些人需要倾听，并吸纳语言细节，他们的偏好能够用诸如“我在听你说”之类的话辨别。还有一些人在交谈中比较情绪化，他们的偏好能够用诸如“我觉 得怎样怎样”之类的话辨别。

        除此之外，大部分人的肢体语言（如无精打采、坐姿端正、胳膊交叉、与别人交谈，或者说话时用手势）都能给你关于此人的线索，表明此人在本次会议 或集会上是专心致志还是心不在焉的。事实上，电话会议的一个主要麻烦就是你无法看到电话另一端人们的肢体语言。后果就是你不能取得同样多的反馈信息来帮助 引导会谈。而一般会谈中很容易看出需要谈到或考察的问题、人们关心的地方及思路。如果仔细倾听，你还是能够从与会者的语音、语调及说话的速度等方面观察出 端倪—来自所有这些方面的反馈有助于了解沟通的效果。

        电话会议的另一个挑战就是你可能不了解电话另一端的所有人，也无法琢磨其沟通方式、语境。要克服这类知识的匮乏，应在会议开始时做到下列事情：

• 收集电话另一端所有人的名字。
• 重视每个人的响应。
• 注意所有与会者的交流方式、开会的方法（如态度、言辞、语调）及角色。
• 在将来的电话会议上使用这些知识来引导交互过程。

        诸如 WebEx 之类的在线开会，比电话会议效果好，至少你能够看到他人当前如何反应。这些可视性也有助于主导会谈。

        在视频会议中，每个人都能看到自己，这是对电话会议或在线会议的重大改进。我们能够看到活生生的对方，或者说是某个人的图像，使得交互更具人性化，能够大大改善与其他参会者的沟通能力。

        要记住这种交谈的一个关键方面就是，在交谈中别人不仅以多种方式将他们的所思所想告诉你，你也在给他们传递类似的信息。在会议中，你需要本能地意识到你的身体正在给别人传递信息。

        你的肢体语言会“大声说话”—所以要谨慎你“说”的内容

        在会议中记住这些事项：

• 你在微笑吗？
• 你坐姿端正吗？
• 你赞成时点头吗？
• 你的眼神对着正在讲话的人吗？
• 你的声音或者说语调是抑扬顿挫的吗？
• 你参加会议时的装束风格和别人类似吗？
• 你真的在倾听并理解别人说的话吗？
• 你做笔记吗？
• 你主张对抗吗？

        所有这些条目组合在一起，可以让别人知道或确认你要发出的消息的一致性。你是在笑着讲述一个伤心的故事吗？如果是这样，这种不一致性就会剥夺你所试图发出消息的完整性。

        对于同样的一个消息，要努力发展自己说什么、怎么说的技巧。这种持之以恒的表现会增强你有效沟通的能力。

        7. 才思敏捷

        随时准备好回答别人的提问。当人们提问时，不大可能先给出预告。也就是说，你不会有任何时间去准备理由充分的答案。问题可能来自任何方面（单位中职务比你高的、和你平级的或者低于你的）。

        作为架构师，你需要对迅速切换语境游刃有余，即记住头脑中每个活跃的事情，将其压入要记忆的栈中，然后集中全部注意力来快速处理面前的语境。这种活动称作“才思敏捷”。

        在这种情况发生时，试用下列模式来处理此形势：

• 关注是谁在问此问题。这个人的背景如何？他需要知道什么信息来理解你的反应？倘若你对他的问题有所反应，这是否合适？
• 想出三点解释，如果可能的话，包含一条支持这些解释的商业根本原因。在你有限的时间里，试着对你要沟通的答案构想出一幅场景。
• 如果对方要求你做出某个决定，暂停并思考你要说的话对单位的影响。因为这项决定将在单位中贯彻，别的群体将如何反应？
• 如果你已经安抚寻求决定的人，也清楚地知道其他群体将对决定的影响有所反应，你应当认识到不久后的日程上将有一系列不令人愉快的会谈。
• 你也许在考虑做出一项决定，这一决定会导致涉及的每个组都不太高兴。通常，如果你能做到这一点，你就是协商的高手。当每个人在这场游戏中都有利益 关系时，所有参与方会在未来更好地合作。如果没有相关的利益，他们会认为自己并未被挑选出来，现在可以集中精力解决手头的现实问题。
• 有意思的是，在这个所有人都不太高兴的时刻，每个人都变得更通情达理，想出更多的可替代方案来使问题以更简单、更快速、更省钱的方式解决。当答案浮出水面时—可能是真正革新型的解决方案，就准备说“是”吧。
• 如果你的答案有消极影响，要展示别的答案也是“有问题”的。陈词滥调过后，大家同病相怜—一起共享不快，滋味总比吞咽药丸感觉好一些。

        当然了，能让每个利益相关者高兴的决定有时可能存在的，也总是最可取的。

        三、与执行官沟通

        执行官在任何公司都是独特的个人。他们的职责很广。执行官的沟通能力、领导才能和关系技能都经过刻苦磨炼。学习与执行官沟通需要花费时间和经过实践，但你只有一次机会来取得第一印象，所以务必准备好。

        1. 执行官需要信任、忠诚和连贯性

        执行官对信任、忠诚和连贯性有着热切的渴望。

        当你在与执行官沟通时（特别是那些对你工作领域不甚了解的执行官），你需要注重与之建立信任和忠诚关系。在你继续与之工作的过程中，你给出的信 息应当具备一致性：你不能某天告诉高级经理一个故事，而第二天却是个完全不同的故事。不要对呈交的信息有偏见，以显得你是对的，而别人不好。关心的事实应 尽可能简洁且开门见山，要知道执行官都是一些大忙人。

        当你会见执行官时，不要嘲笑那些不在场的人。这样的行为只能证明你不值得信任，也不够忠诚。

        当你呈交信息时，提供事实，而不是关于人们的观点。事实是能够理性处理的东西，即便是不在场的人也能够理性处理事实。要确保你适当地传递了信息，这样当执行官向有关人员索要事实信息时，即便原先不在场的人也不会措手不及。

        我曾经有过一些这样的参加会议的经历，执行官召集其他的人一起进入房间讨论，来验证我所给出的所有信息。要确保你讲的故事是想在别人面前重复的，因为你可能有机会立即这么做。

        2. 清晰性甚于完整性

        作为一般性的经验方法，给人提供细节信息的数量应当反比于此人在单位中的级别。换句话说，开发者可能需要海量的信息来构建某个东西，而执行官在 项目定期更新状态时，只需要有关项目的高度概括性信息。但信息需要清晰、简明扼要。你需要给执行官提供正确的信息，并提供适当的背景，多些商务信息的成 分，少些技术信息的成分。

        执行官不大可能会顾及所有技术信息。他们想知道你精通技术，但他们没有时间关心所有的项目细节。这样过滤的一个主要原因就是执行官受时间限制， 必须工作于信任的基础上。他们寻求将所有权、执行权和照看项目的责任委派给你。他们希望你处理问题、做好规划，以及照顾项目的其他方方面面。

        执行官想知道的就是如下这些东西：

• 有哪些风险会导致项目无法如期完成或者按预算完成？风险是否已得到控制？
• 能创造什么战略资产来支持当前或未来项目的需要？
• 单位中谁是“升起的新星”？

        执行官要求你提供的是准确的信息。他们希望你保持一致性。一旦你给出一个答案，就应坚持它，所以要谨慎选择你的答案。有的执行官可能会深入项目 的特定方面。你至少应该准备探索这方面。执行官可能借此找出你知识的边界及疏忽在哪里。开会时，倘若你处于你不知道或不确信某些信息的境地，要明确表达自 己不知道，但声明自己随后会关注被问及的这些信息。永远记住：如果你不这样做，你可能会将自己辛苦挣得的信任关系付诸东流。

        你和执行官最好的交互过程就是把你的扑克牌都放在桌面上。也就是说，让他们能看清你所有的东西（好的、坏的、丑的）。你可能因为彻底袒露、容易被人挑刺而感觉不踏实。但这样的行为能让你在信任和忠诚方面—这是执行官最看重的——增加好感。

        当你真正需要执行官来介入处理事情时，你已经建立了与之关键的关系，这使你能够与高级经理一起处理这些事情。执行官不想知道的就是项目中存在的 争执。部门A与部门B之间的分歧完全是“你的”问题，你应该去解决它。如果你请执行官来介入“解决”某个争端，你和所涉及的团队都不会对后果感到高兴。执 行官似乎有第六感，他会选择争端中最痛苦的解决方案。既然如此，建议你简明扼要，并坚持在符合执行官而非 IT 人员需要的层次上解释相关的事实。

        3. 不要让执行官感到惊讶

        谈到不断积累的问题时，执行官不喜欢惊讶，尤其是那种惊讶：他们必须在很短时间做出行动、剩下的选择少之又少，而结果是他们必须将坏消息通知给单位的其他部门。

        执行官不喜欢惊讶。如果你有坏消息，就早些告诉他们。

        绝大多数项目的风险是逐渐累积的。从事或接近项目的参与者知道这些风险。如果仔细倾听，你会知道到处都在反映这些信息。遗憾的是，风险发出的隆 隆声并不总能让需要听到的人听见。当人们与高层的管理人员和执行官说话时，他们在本能上会报喜不报忧。结果就是，他们不太想把一些看起来不妙的事情呈递上 去。

        中层经理不会在来不及处理风险的情况下，乐意被人将风险暴露给他们的上司或其上司的上司—那就是，围绕风险的推销问题。如果风险会随时间而膨 胀，应尽早暴露出来。通常要有个判断过程来确定何时告诉别人这个生长着的麻烦。没有捷径知道确切的时间。作为一个经验规则，早些暴露远比问题发生为时已晚 要好得多，因为后者要迫使高级经理人员和执行官去处理善后事宜。

        如果你发现你的上司或管理人员没有将所需的信息沟通给执行官，你可能需要自己呈递这些信息（倘若你决定采取行动，必须极度小心，也许有些你未意 识到的因素导致别人那样做）。当你真的呈送消息时，确信所有中层管理人员都意识到了风险。他们需要有机会拟定行为计划来处理这些风险。这仍然是关于信任和 忠诚的问题。

        当执行官越早知道存在的风险，他们就越能够成功应付它们，并最大限度地降低负面影响。如果执行官被搞得惊讶，他们不会高兴的。假如你还没有破坏 他们对你的信任（你工作非常努力才换来的信任），你可能已经在朝这个方向做了。当晋升机会到来时，你可能不会得到执行官的多少支持，因为你曾经引起他的不 快。

        本文节选自《软件架构师的 12 项修炼》一书，Dave Hendricksen 著，张菲译，由机械工业出版社出版。