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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

崔康 热情的技术探索者,资深软件工程师,InfoQ编辑,从事企业级Web应用的相关工作,关注性能优化、Web技术、浏览器等领域。

This entry was posted in Achitecture, Best Practices. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s