Dave Hendricksen谈软件架构师的沟通原则

   <div id="news_body">     <p> 对于一名合格的软件架构师来说，沟通能力是不可或缺的。来自汤姆森路透的资深架构师 Dave Hendricksen 在《<a href="/misc/goto?guid=4958348018489315308" target="_blank">软件架构师的 12 项修炼</a>》中提供了比较细致的分析和建议，其中对于沟通原则和策略给出了具体的建议。</p>     <p> 对于架构师的沟通原则，主要建议包括：</p>     <p> <strong>多说“是”，少说“不是”</strong></p>     <p> 架构师经常会被咨询问到某个项目的可行性，并提供从战略到战术的多个替代方案，附带若干成本选项，以使商务伙伴能根据特定项目的投资进行判断。架构师与项目评估团队的角色不是决定要构建什么，而是决定怎样构建。我们试图说出的答案是“对，我们能构建这个项目，这些是相关的信息”。产生的信息需要包括诸如所考虑的各种替代方案、项目风险（以及可能的规避策略）、基于的假设条件，以及需要指出的突出问题。我们不是在寻找这样的答案：“不行，这个项目不可行，但我们能构建另一个项目（通过消除原困难项目中的难题，而代之以我们想构建的那些特性）。”</p>     <p> 但是，如果一个项目或任务不可行，我们需要立即巧妙地指出评估结果、解释原因，并提供替代方案。这通常归结于法律法规、行规等原因，以致“不” 是正确的回答。当然了，还有其他一些例外情况：提出需求的人是想逃避工作，需求违反了公司的政策，或者你手头有优先级更高的工作，无法让你有足够时间来对需求做出满意的答复。这些情况下，你要清楚地告诉人家你说“不”的原因。</p>     <p> <strong>特殊场合才说“不”</strong></p>     <p> 从架构师的前景来看，只有在若干种情况下你可以简单地说“不”。大多数时候，你必须提供能让事情完成的替代方案（涉及费用、风险和每种方法的好处）。最后的决定取决于项目的主人（即掌握购买权的人）。</p>     <p> 只说“不”或仅仅阐述事实很难让人接受。充分准备来解释所做决定的原因，证明所做决定是好的商业决定。通过列举事实，探究事实背后的根本原因，陈述此根本原因如何支持期望的商业目标。</p>     <p> 你要相信所提到的解决方案。如果你并不真正相信你所推销的东西，你的肢体语言和眼睛会说实话的。你的不诚实如同水中的血腥味那样：你很可能被问及更详细的一些问题，如同鲨鱼在攻击一样。在某种意义上，你是将自己置身于未曾准备好的问题。你需要了解足够多的细节来相信这种解决方案。在你向人们提出某种解决方案时，你也需要自我提问和回答有关的难题。</p>     <p> 在所有可能情况下，避免真的说“不”。事实上，根据你所交互的人或群体的语境，解释决定所基于的原因。</p>     <p> <strong>抑制想自卫的冲动</strong></p>     <p> 通常在交谈中，当我们听到并不完全对自己有正面意义的事情时，我们可能会找借口，我们可能会找办法转移话题，并责怪他人，以使自己脱离干系。或者我们想强词夺理，以阐述那些语句。应当避免做出此反应的冲动。相反，代之以等待，并接受别人所说的话。</p>     <p> 抑制想自卫的冲动的一个例外就是当手头的问题涉及企业政策或你的正直时。如果别人说的话使你真正涉及与公司政策冲突或你出于正直未做某事（假如，你已经正确做出了行动）时，你需要立即抨击这些说法。你可能想用澄清问题的办法来明确要点，比如“你的意思是我做过某事吗”。如果别人说“是的”，你就以“这并不准确”来明确回应；倘若人家回答“不是”，要感谢他澄清了此事。</p>     <p> <strong>倾听建议来改善合作</strong></p>     <p> 从软件开发的角度看，批评别人和被批评的情况经常发生。因为有软件评审、设计评审、架构方法评审、单元测试、功能测试、缺陷跟踪，或者只是简单地向别人寻求帮助，与上司一对一地谈话，这个列表不断在进行。在所有情况下，总有机会将别人说的话特定到你身上。</p>     <p> 如果你能避免在谈话中个人化，你听取别人说话的能力就大大提升了。要试着找出他说话的真正用意（即便你不同意他说的话）。以适当的方式取得他想传递的本意，复述一遍要点。一般情况下，别人只是想被理解，他并不是在寻求你同意他的观点。当你倾听并能理解对方表达的要点时，你就能和他心灵相通。</p>     <p> <strong>了解别人和自己的沟通需求</strong></p>     <p> 在架构师的世界中，你需要例行地与许多人交流。你可能在上一次会议上与有些人谈过话，也可能没有和这些人谈话。挑战就是快速了解人们在说什么，他们怎么说这些话，来“读懂”本次会议。</p>     <p> 观察关键的时刻，即做出决定的时刻是一个要点，以此识别人们提出的问题和关心的地方，来加强核心概念，帮助你关注会议的方向以及把会议引向一个成功的结论。为了认识这些关键时刻，我们需要吸收所有信息，包括提供给我们的语言或非语言信息。</p>     <p> 观察别人的举止能够告诉我们如何与每个人最好地沟通。由于每个人都不相同，并且对沟通也有不同的需求，架构师必须让传递信息的方式适应这些需求，以确保有效沟通。</p>     <p> 关键点就是我们要基于每个听众成员的沟通需求来匹配交流风格。有些人的反应是能够看出来的，他们的偏好能够用诸如“我明白你的意思”之类的话辨别。另外有些人需要倾听，并吸纳语言细节，他们的偏好能够用诸如“我在听你说”之类的话辨别。还有一些人在交谈中比较情绪化，他们的偏好能够用诸如“我觉得怎样怎样”之类的话辨别。</p>     <p> <strong>才思敏捷</strong></p>     <p> 随时准备好回答别人的提问。当人们提问时，不大可能先给出预告。也就是说，你不会有任何时间去准备理由充分的答案。</p>     <p> 作为架构师，你需要对迅速切换语境游刃有余，即记住头脑中每个活跃的事情，将其压入要记忆的栈中，然后集中全部注意力来快速处理面前的语境。这种活动称作“才思敏捷”。</p>     <p> 在这种情况发生时，试用下列模式来处理此形势：</p>     <ul>      <li>关注是谁在问此问题。这个人的背景如何？他需要知道什么信息来理解你的反应？倘若你对他的问题有所反应，这是否合适？</li>      <li>想出三点解释，如果可能的话，包含一条支持这些解释的商业根本原因。在你有限的时间里，试着对你要沟通的答案构想出一幅场景。</li>      <li>如果对方要求你做出某个决定，暂停并思考你要说的话对单位的影响。因为这项决定将在单位中贯彻，别的群体将如何反应？</li>      <li>有意思的是，在这个所有人都不太高兴的时刻，每个人都变得更通情达理，想出更多的可替代方案来使问题以更简单、更快速、更省钱的方式解决。当答案浮出水面时—可能是真正革新型的解决方案，就准备说“是”吧。</li>      <li>如果你的答案有消极影响，要展示别的答案也是“有问题”的。陈词滥调过后，大家同病相怜—一起共享不快，滋味总比吞咽药丸感觉好一些。</li>     </ul>     <p> 这些原则在架构师的日程工作中都值得借鉴，欢迎大家对此发表自己的看法和见解。</p>     <div id="come_from">     来自:      <a id="link_source2" href="/misc/goto?guid=4958348019293057212" target="_blank">InfoQ</a>     </div>    </div>