架构师应该掌握的协商原则

对于架构师而言,协商技巧是将项目推向成功,并使之运转顺畅的第一个关键技能。架构师的角色在一个单位中可以以多种形式出现,从企业架构 师到平台架构师,到应用架构师,到研究架构师。每种架构师角色的职责和所要求的协商领域不同,但有一点是肯定的:协商能力是所有架构师的关键财富。无论何 时从事协商过程,都要遵循一系列协商原则。资深架构师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