沟通
在架构师的角色中，沟通是要求有效果的必备技能与工具。
架构师通常没有对为其项目工作的他人的直接管理权。他们的项目往往是跨部门的，也可能会跨好多个行业单位。由于不能直接管理他人，所以架构师指示别人或群体完成特定行动的能力就受到限制。他们唯一真正有效的手段就是其影响力。
靠技术晋级的人主要关注在技术性的专业知识上。成为技术专家，沟通技术知识对于他们往上爬来说是非常关键的技能。这种技能通常意味着维护你的职位，明确特定项目的潜在风险和当前问题。在单位等级结构的这一层上，你应该阻止产生问题、寻找问题并且解决问题。
沟通原则
先听后说
你有没有发现自己在某次谈话中总是想寻求一次讲 话的机会，而没有真正在听别人说什么?当你没有听时，你传递给那个对你讲话的人什么信息呢?
当有人与你说话时，要看着他说，并试着理解他想沟通的内容。给对方足够的时间来表达他的观点，然后再向其询问要澄清的问题。向他表达非语言的反馈，例如点头，让他知道你在关注这次谈话。
专心致志
不管你在哪里，都应专心致志。生活中有许多事情要分神，读些时间管理方面的书，列出每天需要关注事情的清单计划。在计划中安排好任务的优先级(当天、本周等),并标识每个任务准备投入的时间。这个办法能够让你通过计划安排好每件事，节省你的精力去记忆周围各种正在发生的事。
正面思考
当你表达信息时，总有许多种方法去传递它们。信息需要真实和准确，然而表现出其意义的方式可以多种多样。
你可以以积极意义或消极意义提供信息。你可以基于所期望的结果选择某种方法。也可以采用不偏不倚的方式，不带情绪地列举事实，尽管这通常很难做到。
从沟通的观点来看，人们容易注意负面的东西。通常负面消息总会带来恐惧(当我感觉恐惧邻近时，我会把它当做“要求集中精力的行动”的信号)。.
作为架构师，你需要避免不必要的偏见信息，让别人能够选择他们要关注的信息。你可以提供若千种替代方案，但这些方案应当是客观平等的。你需要察觉可能的办法,而不是为别人留下疑惑。
尽早道歉
在一天的事务中，你可能注意到对他人做的某个事情不合适或不正确。记住放下自尊去给受影响的对方道一个歉。向别人诚心道歉并不是好玩或者容易之举，但你可以赢得别人的尊敬，展示你在尽力成长，尝试变得更好的意图。
不要在缺陷上招致恼羞成怒
当你在开评审会(例如产品概念评估、需求评审、设计评审、代码评审.测试评审、产品发布评审)时，通常会检查出评审项目的一-些缺陷。评审项目的作者对于这些暴露出的缺陷当然会感到不自在。
沟通策略
多说“是”，少说“不是”
架构师经常会被咨询问到某个项目的可行性，并提供从战略到战术的多个替代方案，附带若千成本选项，以使商务伙伴能根据特定项目的投资进行判断。架构师与项目评估团队的角色不是决定要构建什么，而是决定怎样构建。
我们试图说出的答案是“对，我们能构建这个项目，这些是相关的信息"。产生的信息需要包括诸如所考虑的各种替代方案、项目风险(以及可能的规避策略).基于的假设条件，以及需要指出的突出问题。
特殊场合才说“不”
从架构师的前景来看，只有在若干种情况下你可以简单地说“不”。大多数时候,你必须提供能让事情完成的替代方案(涉及费用、风险和每种方法的好处)。最后的决定取决于项目的主人(即掌握购买权的人)。
在其他时候，说“不”是合适的(如图2-3所示)。通常这种拒绝需要有足够合理的深度来支撑，以应付所有必要的质疑。争论的领域很可能与任何项目都存在的关键限制因素有关，如效果、成本、时间和范围。
倾听建议来改善合作
从软件开发的角度看，批评别人和被批评的情况经常发生。因为有软件评审、设计评审、架构方法评审、单元测试，功能测试、觖陷跟踪，或者只是简单地向别人寻求帮助，与上司一对一地谈话，这个列表不断在进行。在所有情况下，总有机会将别人说的话特定到你身上。
了解别人和自己的沟通需求
在架构师的世界中，你需要例行地与许多人交流。你可能在上- -次会议上与有些人谈过话，也可能没有和这些人谈话。挑战就是快速了解人们在说什么，他们怎么说这些话，来“读懂”本次会议。
观察关键的时刻，即做出决定的时刻是一个要点，以此识别人们提出的问题和关心的地方，来加强核心概念，帮助你关注会议的方向以及把会议引向一个成功的结论。为了认识这些关键时刻，我们需要吸收所有信息，包括提供给我们的语言或非语言信息。
观察别人的举止能够告诉我们如何与每个人最好地沟通。由于每个人都不相同,并且对沟通也有不同的需求，架构师必须让传递信息的方式适应这些需求，以确保有效沟通。
关键点就是我们要基于每个听众成员的沟通需求来匹配交流风格。有些人的反应是能够看出来的，他们的偏好能够用诸如“ 我明白你的意思”之类的话辨别。另外有些人需要倾听，并吸纳语言细节，他们的偏好能够用诸如“ 我在听你说"之类的话辨别。还有一些人在交谈中比较情绪化，他们的偏好能够用诸如“ 我觉得怎样怎样”之类的话辨别。