软件架构师应该具备哪些协商策略

协商策略是软件架构师的必备技巧之一，也是常见的短板，除了精深的技术储备和高层的大局观，架构师应该具备哪些协商方法呢？资深架构师 Dave Hendricken分享了自己的经验。

Dave 认为，在协商时，不要找分歧。在技术领域，要被人看做有才能，要有处理不同需要的灵活性，就需要找出问题、技术或设计的细微不同之处，这是一种基本技能。当需要做出技术决策时，探究这些细微差别，才能创造出了不起的软件。然而对于更高层次的决策，找出不同点的需要就开始退化了。目标变成找到一种可行的解决方案。该解决方案可能在技术上并非“最优的”，但在技术上“足够好”，能够满足项目中其他方面的需要。花销、时间和品质都是要折衷考虑的因素。为满足其中任何两个指标，第三个就只好有所变通，不得不在那个方面做些牺牲。

如果无法达成一致，Dave 认为那就让所有人稍微不满了：

我们的首个目标就是让每个人对某个方法满意。但我们必须认识到，这样的结果往往不可能做到。经常需要做出折衷平衡。生活中有个出乎意料的事实：要让不同的团队一起有效地工作，有时团队中的每个人需要稍微不高兴。这种不满之所以存在，是因为所有人都必须将其成见置于协商桌上，并舍弃某些东西。这种妥协让其他团队能够以合理的花销来成功完成任务。

最后，决策是一个生态系统，要求所有成员都为了共同的利益，舍弃个人前嫌而共同努力。这种“先舍而得”的结果是所有各方都相信他们都宽宏大量，因为他们会对结果感到满意。显然，倘若每个人都拥护一种方法而无反对意见，那就是共赢的局面。有些情况下，当告知别人决定时，并非所有人都一致同意。这就需要每个团体不得不做出一些妥协，以便让大家都能接受这一决定。相反，如果每个团队总想比别人受优待，就会在组织内引发怨恨，在未来导致不必要的隔阂。

除此之外，Dave 指出，寻找共同点也是必要的。当不同单位聚在一起要解决某个特定的问题时，他们都是携带着自己预先制订的方案与他们进行讨论的。他们带来的方案都是其认为最好的、最容易做到的，也是其最擅长的领域，对于框架问题明确有哪些范例是可用的，哪些范例是不可用的，诸如此类。

当不同团队凑到一起，第一个议题就应当寻找共同目标。共同的目标就是所有人都赞成的目标（换句话说，就是找出需求是什么）。下一步，大家找出“成功”是如何定义的。也就是说他们如何评判问题已圆满得解决了呢？最后，他们开始着手工作，找出解决问题的办法。为了成功地完成任务，桌面的所有人都撇开偏见，需求方法解决问题。该方法能够达到成功的衡量标准，并且不是只照顾某个团队的好处。要是哪个团队总是要求凡是都按他们的办法来办，两个团队就要花时间检查手头的如下这些问题：

• 找出他们立场的根源所在（必要的话，私下做这件事）。
• 找出他们最关心的是什么（你也许能让他们在不太重要的地方做出让步）。
• 找出他们是否有决策的权利（如果没有，你可能需要将有真正决定权的人请到协商桌旁）。

成功解决分歧意味着做出让步，做出牺牲。在处理问题时，最好的做法是试着站在对方的角度，从他那边看问题。如果你理解了对方的观点和需求，找出共同点就容易多了。

Dave 希望架构师将协商作为一种改进措施：

假如每个人都将其主意拿上台面的话，协商过程能极大地完善某个主意或解决方案。这有点像磨光一块石头：大家齐心协力地磨边角，从而得到一个圆通的结果。有效协商还可以将一些想法和项目扼杀在早期阶段——在没有花费客观的资源之前，这样实实在在地位公司避免了损失。投资血本无归时间非常糟糕的事情，它会迫使其他项目来弥补糟糕生意造成的亏空。早早地明确一些注定要失败的项目是很有好处的事情，可能这样并不好玩，可能会导致你心爱的项目下马，也应这么做。在“让创新点子开花结果”与“将其扼杀在摇篮中而不施加投资”之间有个很好的折衷，那就是通过大家共同协商来做决定。

Dave 指出，作为一名架构师，在每一天的工作当中，都会受到需要快速响应的困难决定所“轰炸”。一般来说，真正的决定是要找出如何消除团体或个人面前的障碍，让其能继续前进。障碍可以有多种形式：

• 工具的选择
• 建模问题
• 团队中有个顽固不化的家伙，他总是坚持自己的做法，而不与别人合作
• 管理层需要关键的状态信息
• 两个团队无法就“该谁做什么”达成一致

基本上，障碍要么是社会或单位障碍，要么是技术障碍。而技术障碍通常是比较容易解决的。

对于社会或单位障碍造成的局面，你的目标往往是让别人说“好，我理解了，得到了我需要的东西，我能继续前进了”。通常，要达到这个目标，需要仔细倾听别人的需求，寻找表面之下潜藏的真正问题。注意对方的肢体语言，后者作为线索，能够反映是否有事被隐藏，或者是否要关注某些地方。不要想着马上解决问题。要让别人尽可能地多说话，从而获取尽可能多的语境信息。必要的话，召集相关人员开个现场会，来得到有关此问题的更广泛语境。会谈过程中，应复述对方表达的信息，以确保你理解了别人所说的话。

一旦你能够准确地评判问题，并真正理解了别人的背景，就可以由倾听和理解转而寻求解决方案。这时，有必要总结你的理解并写出来，这样可被共享和确认。请求你做决定的人是否曾有机会自己考虑过该问题？如果这些人还没有学会自己进行关键性的思考，那么你只给他们一个答案并不能帮他们多大忙。将对问题背景做出的总结呈现给他们，能够让他们形成自己的想法。

你可以这么考虑，让那个想让你做出决定的人回去一段时间，仔细考虑一下这个问题，然后带着三个办法和一个建议再来找你。如果你不这样做，你就只是把自己当成他的拐杖，他的同伴将错失一次潜在的有价值的学习机会。当然，为避免对项目有负面影响，你可能需要不时地给予一些思路上的启发。