首页 > 技术文章 > 架构师软技能之协商(上)

UncleCatMySelf 2018-12-02 14:49 原文

在商业活动中,你不是得到你应得的,而是得到你谈判得来的。

 

 

 

对于架构师而言,协商技巧是将项目推向成功,并使之运转顺畅的第一个关键技能。但是社会性是所有技术人员都擅长的领域,初次触及的人都会一头雾水甚至将部门单位搞得鸡犬不宁。

 

架构师的角色在一个单位中可以以多种形式出现,从企业架构师到平台架构师,到应用架构师,到研究架构师。每种架构师角色的职责和所要求的协商领域不同,但有一点是肯定的:协商能力是所有架构师的关键财富。

 

无论你何时从事协商过程,都要遵循一系列的协商原则:

 

不要让人惊讶

 

 

 

在你与人协商时,需要决定结果以一种不让人惊讶的方式给出。否则人们就会质疑所做决定的原因,,而不是考虑随后谈话中基于的事实。要认识到,谣言和捕风捉影的话对于项目的士气、人际关系和进展都很危险。

 

在与潜在伙伴协商时,倘若你不中肯地揭示信息,他们以后就不会信任你,很可能也不愿在关键因素上让步,而项目成功往往需要有人做出让步。为避免出现这种问题,应当以开放、诚实的态度给出技术事实。

如果你的上司不知道正在协商的是重要事宜,应促使他尽快找出需要考虑的决定的其它方面。

 

不要模棱两可

 

 

 

是就“是”,不是就“不是”。

 

做出决定后,要坚持这个决定,对项目决定朝令夕改对单位来说是场噩梦。

 

如果确实改变决定,应当让受影响的各方知道做了哪些修改,以及他们需要做出或考虑哪些调整。坚持错误的决定会对整个项目带来损害,重要的是尽量不要在项目方向上做出改变。

 

一个办法有助于巩固、证明和沟通决定,那就是维护架构的决定日志等。

 

委派权威而不是义务

 

一般情况下,我总是试着在每一组中找出几个需要共事的关键个人,与之建立高度信任的关系。我给这些人在协商中成长的机会,以及做决定的能力。

 

要认识到的一个基本原则是你不能委派责任,不管你所委派权威的人做的决定有什么后果,你仍然要对这些后果负责。

 

在所有情况下,决定及其依据应当与你沟通过,这将使你能够与你告诉别人的话保持一致,有助于强化已经做出的决定。否则,你会削弱你想委派的权威,还不利于对你想培养的人的信任。

 

有困难时寻求帮助

 

 

有些时候,你处于某种境地,即你没有权威、技能或知识来做出某个决定。在这些状况下,需要让别人清楚地知道,这不是你能做主的决定。你需要马上请有权威做出决定的上司介入,或者在做决定时让那些能给你提供帮助的人参与。

 

通过与有权威的人或群体快速地共享信息,确保他们能介入,必要的话能够采取补救措施,当然了,他们也许会继续坚持你的决定。

 

对于已经发生的错误应保持开放的态度,并让真正的决策权威确信你不会再犯第二个错误,你能够与受影响的各方建立信任关系。

 

不要掩盖问题

 

当你做的某个决定以失败告终,应当采取下列补救措施:

 

承担责任、在尽量早的时间内向受影响的各方道歉、让别人知道所发生的事情、让别人知道所发生的事情的原因、不要责备别人,不要把责任转嫁给别人、在别人试图搞清楚发生的事情时,不要保持沉默。

 

即使很难,也要坚持做正确的事

 

 

做正确的事可能在时间、金钱和精力上对你有所耗费,但它对你而言是很重要的,你的伙伴会看到,你是在致力于充分通过协商做出决定之后才会答应或拒绝。

 

协商策略:不管何时你要进行协商过程,都可以用若干策略来达到成功的结果。这里探讨的策略有助于改善你的协商技能。

 

倾听你的内心呼唤

 

内心的想法也许会促使你做出某些调查,在特定地方帮助证实或否决你的想法。在不远的将来,你可能会被要求提供某些事实,来支持这种直觉,即便你的疑虑并未完全明确。必要的话,可以说“我觉得这需要再仔细斟酌,我随后答复你吧”。然后你在将完成调研后,再约个日期。

 

设法同意

 

 

一般来说,真正的决定是要找出如何消除团队或个人面前的障碍,让其能继续前进。基本上,障碍要么是社会或单位障碍,而技术障碍通常是比较容易解决的。

 

请求你做决定的人是否曾有机会自己考虑过该问题?如果这些人还没有学会自己进行关键性的思考,那么你只给他们一个答案并不能帮他们多大忙,将对问题背景做出的总结呈现给他们,能够让他们形成自己的想法。

 

在技术领域里,要被人看做有才能,要有处理不同需要的灵活性,就需要找出问题、技术或设计的细微不同之处,这是一种基本技能。当需要做出技术决策时,探究这些细微差别,才能创作出了不起的软件。

 

感谢阅读。

 


 

推荐阅读