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

对于一名合格的软件架构师来说，沟通能力是不可或缺的。来自汤姆森路透的资深架构师Dave 在《软件架构师的12项修炼》中提供了比较细致的分析和建议，其中对于沟通原则和策略给出了具体的建议。
对于架构师的沟通原则，主要建议包括：
多说“是”，少说“不是”
架构师经常会被咨询问到某个项目的可行性，并提供从战略到战术的多个替代方案，附带若干成本选项，以使商务伙伴能根据特定项目的投资进行判断。架构师与项目评估团队的角色不是决定要构建什么，而是决定怎样构建。我们试图说出的答案是“对，我们能构建这个项目，这些是相关的信息” 。产生的信息需要包括诸如所考虑的各种替代方案、项目风险（以及可能的规避策略）、基于的假设条件，以及需要指出的突出问题。我们不是在寻找这样的答案：“不行，这个项目不可行，但我们能构建另一个项目（通过消除原困难项目中的难题，而代之以我们想构建的那些特性）。”
但是，如果一个项目或任务不可行，我们需要立即巧妙地指出评估结果、解释原因，并提供替代方案。这通常归结于法律法规、行规等原因，以致“不”是正确的回答。当然了，还有其他一些例外情况：提出需求的人是想逃避工作，需求违反了公司的政策，或者你手头有优先级更高的工作，无法让你有足够时间来对需求做出满意的答复。这些情况下，你要清楚地告诉人家你说“不”的原因。
特殊场合才说“不”
从架构师的前景来看，只有在若干种情况下你可以简单地说“不” 。大多数时候，你必须提供能让事情完成的替代方案（涉及费用、风险和每种方法的好处）。最后的决定取决于项目的主人（即掌握购买权的人）。
只说“不”或仅仅阐述事实很难让人接受。充分准备来解释所做决定的原因，证明所做决定是好的商业决定。通过列举事实，探究事实背后的根本原因，陈述此根本原因如何支持期望的商业目标。

文章插图
你要相信所提到的解决方案。如果你并不真正相信你所推销的东西，你的肢体语言和眼睛会说实话的。你的不诚实如同水中的血腥味那样：你很可能被问及更详细的一些问题，如同鲨鱼在攻击一样。在某种意义上，你是将自己置身于未曾准备好的问题。你需要了解足够多的细节来相信这种解决方案。在你向人们提出某种解决方案时，你也需要自我提问和回答有关的难题。
在所有可能情况下，避免真的说“不” 。事实上，根据你所交互的人或群体的语境，解释决定所基于的原因。
【Dave Hendricksen谈软件架构师的沟通原则】抑制想自卫的冲动
通常在交谈中，当我们听到并不完全对自己有正面意义的事情时，我们可能会找借口，我们可能会找办法转移话题，并责怪他人，以使自己脱离干系。或者我们想强词夺理，以阐述那些语句。应当避免做出此反应的冲动。相反，代之以等待，并接受别人所说的话。
抑制想自卫的冲动的一个例外就是当手头的问题涉及企业政策或你的正直时。如果别人说的话使你真正涉及与公司政策冲突或你出于正直未做某事（假如，你已经正确做出了行动）时，你需要立即抨击这些说法。你可能想用澄清问题的办法来明确要点，比如“你的意思是我做过某事吗” 。如果别人说“是的”，你就以“这并不准确”来明确回应；倘若人家回答“不是”，要感谢他澄清了此事。
倾听建议来改善合作
从软件开发的角度看，批评别人和被批评的情况经常发生。因为有软件评审、设计评审、架构方法评审、单元测试、功能测试、缺陷跟踪，或者只是简单地向别人寻求帮助，与上司一对一地谈话，这个列表不断在进行。在所有情况下，总有机会将别人说的话特定到你身上。