码迷,mamicode.com
首页 > 其他好文 > 详细

软件架构师的12项修炼4

时间:2019-06-19 22:05:22      阅读:158      评论:0      收藏:0      [点我收藏+]

标签:资源   流程   身体   遇到   ons   原理   世界   开发   分解   

第4章 领导力

4.1 领导力的原则

4.1.1 建立信任关系

领导力完全是建立在信任关系之上的。

4.1.2 建立共识

领导力是为了建立一种认知, 即每个人都觉得这种认知是对的。 你必须知道项目中每个人如何工作, 了解他们对项目的看法和关心的地方。

作为一名架构师, 你应当考虑使用Philippe Krutchen提出的 "4+1"的架构视角模型。 后者是一种捕捉共识的基本细节的方法。 这种方法运用系统的逻辑、 开发、 过程和物理视角(即 "4+1"中的 "4")将用例作为它们之间的 “胶水”,并描述架构 (即 "4+1"中的 "1")。 每个视角都是统一整体的某个方面。 这种模型有许多变形, 但其方法的本质就是要认识到, 不同的利益相关者对问题的解决方案有不同的需要、 背景、 要求, 甚至技能。 既然如此, 架构师需要不同的视角来容纳他们。 对某种解决方案的特定模型抽象出关键点, 这是支撑该架构的主要技能。

4.1.3 建立战略伙伴关系(通过关系带来安全)

作为架构师, 你要对产品的商业认知有彻底的了解。 你最终负责将其转换为技术现实。 为达到这一目标, 你必须能够将此认知以项目团队可理解的方式传达给他们,并领导他们朝这个方向努力。 通过与商务人员紧密结合, 并与项目的骨干成员密切配合, 架构师能够帮助大家在整个产品开发过程中对产品维持一种共识。

在建立战略合作伙伴关系时, 要关注那些能够从认知到最后产品发布过程中影响你进展能力的人, 这一点很重要。为成功管理这些关系, 你必须了解单位内项目和产品发布的流程。如果做不到这一点, 你就会在错误的时间与错误的人打交道。

你越成功, 你就能建立越强的单位信任关系。这种因素将使你拥有更多的战略合
作伙伴关系, 并对项目的更多方面自由控制。最后, 你会有更强的判断力来转移到先
前认为是打破常规做法的地方, 承担必要的风险来使项目成功。

4.1.4 要身体力行(为你所说的话带来安全)

使你说的话有安全感的若干指导原则:

  • 透明化。
  • 见什么人说什么话。
  • 保持开放、诚实的胸襟。
  • 做事正直。

你得身体力行。你也许会发现你要求别人做的事情并不像当初表现的那样容易。 如果你不想做某件事,就不要要求别人去做这件事。

能屈能伸的意愿使你能被看做患难团队中的一员,而能够与他人建立起信任关系。

4.1.5 感知风险、评估影响、 做出行动(明确风险的清晰度)

可以用来处理混乱、决定你的时间花在哪里的要点就是:如果你不干预,会有什 么风险出现(不仅是此项目的风险,还包括你要承担责任的所有项目的风险)。

当事态平息下来, 开始得到解决,你需要问自己下列问题:

  • 这种情况能否事先避免?
  • 是否缺乏了某些培训?
  • 有人散布了谣言吗?
  • 是不是有些信息没能传达到那些需要它们的人手里?

找到这些问题的根源, 有助于你为下一个项目做出更周全的准备。 从错误和失败中尽可能地学到东西。 不要让负面的经历再次发生。

当事情脱离正轨,请花些时间找出办法,使项目的这部分回归你尝试完成的认知。找出不对任何人构成威胁的办法, 来解释所发生的事, 让每个相关的人都知道事情其实可以用一种不同的办法完成。
准备好回答别人问你发生了什么事的问题。 不要责怪那个人。 以适当的方式处理事实。 对于个人问题, 要私下解决。

4.1.6 适当处理风险:什么是鞭炮,什么是原子弹(明确影响的清晰度)

当你评估特定项目所发生事情的风险时, 要在介入和保持距离上把握一个度,如果影响只是小到中等的程度, 项目团队也许要努力一把, 从中可以学到解决问题的技能, 来自我恢复。 这就是一种鞭炮级的影响:形势应当引起你的注意, 但它是可控的。

如果风险的影响有重大意义,比如,项目会失败或受到极大的影响, 你就应当干预, 以最好的办法解决问题。 这种形势类似于原子弹。

项目的效果通常距其最初的根源原因有多个环节。
好的领导力的一部分就是学会倾听自己的内心。 如果别人告诉你某件事, 这些信 息让你有不舒服的感觉, 你可能想仔细倾听, 井更详细地研究问题所在。 在你花时间收集了所有必要的事实后, 就能决定行动的最佳方针。

4.2 领导策略

  • 应用奥卡姆剃刀法。
  • 展现可视化信息。
  • 领导要确保事情不跑题。
  • 寻找机会利用已有的资源。
  • 基于听众所处的环境推销。
  • 找机会利用已有的资源。
  • 关注执行官于策略, 而非冲突的解决

4.2.1 奥卡姆剃刀法

“奥卡姆剃刀法源千中世纪的奥卡姆。哲学家William提出的逻辑原则。该原则指出人们不应做出比实际需要更多的假设……对于任何给定模型,奥卡姆剃刀法帮我们剔除不需要的概念、 变扯或构成。

运用奥卡姆剃刀法能够让你这个领导者知道如何去有效率且有效果地融合概念。作为领导者,会听到形形色色的建议。将所有这些信息吸收,并明智地加入到你正在构思的想法中,需要有能力听清他们说的内容,从中提取相关的方面,重组论据以达到知识的完整性。关键在于,在维持清晰度和简洁性的同时增加分析问题的深度。

在选择哪些修改应该包含在认知的范围内时,看看开销、 品质和时间方面的影响。

4.2.2 展现可视化信息

对于大部分环境和人,传达信息的最好办法通常就是做成图片。这并不是说要详细用文字写出来,而是对千抽象概念、 认知还有其他元素,图片能够给出所构思的必要情景和框架。

架构的可视化
一般来说,当我想展现某个架构念头时,就会集中精力做好图表,来表达关键概念 、 模型 、 数据流 、过程流、假设条件及存在的风险。我会考虑使用 Philippe Kruchten的 "4+1‘‘架构视角模型,作为要展示信息的基础。我在工作中,会将演示内容村简到10张幻灯片, 其中包含了一系列图片和图表, 我会口头地说明它们。 其主旨是要含有思路的关键点, 而去除不必要的细节—换句话说, 就是要令 沟通概要信息, 这正是架构本身的内容。

应当试若把事情化整为零,每次传达的思路最多5-9个。

4.2.3 领导者要确保事情不跑题

 

为了保持人们对事情的专心程度,你要将其注意力引导到项目中需要注意的其他地方。

领导者需要知道何时、 何地、 怎样能站起来战斗。

领导者需要发出恒定的消息。

4.2.4 基于环境推销

作为领导者, 你是在推销概念、 认知或目标。 当你在推销,让别人购买你要求的方向时,你需要依据每个人的具体情况来提供信息。

认知是什么?

他们实现这个需要如何做?

有什么好处?

他们可能面临哪些风险?

他们怎样为未来构建?

团队成员需要有足够信息, 才能回到其本职岗位上,去推销你所设想的方案。

4.2.5 随大流(找机会利用已有的资源)

作为领导者,你要问自己下列问题:

单位以前解决过这样的问题或类似的问题吗?如果是,而且解决的结果还不错, 你可能想采取类似的解决办法。 要留意问题的不同点,否则忽略它们或 它们的影响,将会使问题变得相当糟糕。

单位内部可曾用过或评估过这项技术吗?如果不涉及其他关键因素, 且已经选择了该项技术,你可能考虑运用它。 如果收益并不显著,就不值得采纳新技术。

4.2.6 关注执行官千认知, 而非解决冲突

使执行官参与的最好办法之一,就是从战略方向的角度来寻求他们的参与。 他们的洞察力一关于单位的发展方向、 其他单位在做什么、他们专门的未来计划如何一一可以帮助你塑造、形成自己的认知。

对架构师而言,执行官很可能是最重要的利益相关者。 为他们设 身处地想想,在有其他优先级任务和项目时,认知如何符合他们的观点。这种方法也有助千你决定交付成果的三个维度——花销、品质和时间。它们是相互竞争的关系——要牺牲哪个来改善另外两个。

4.3 领导的时机

领导角色要想成功,一个关键方面在于理解时机的重要性。

利用单位动力。

学会何时介人来拯救项目。

知道何时该卓尔不群。

知道何时请求原谅, 何时请求许可。

4.3.1 利用单位的动量

当其他项目或单位的某些部门在特定架构栈上成功,若这一架构、这些人能够提供某些与你解决方案关系密切的东西,就可以为你所用。

如果你没有现成的或者先前成功运用过的方法可循,就要看看你单位所在行业中较大企业的做法,或者相关行业的做法,看看人家是怎样解决特定问题的,以此决定采用什么架构方式。

4.3.2 知道何时伸出援手

如果你介入后能迅速以最小影响消除问题, 就这么干吧??救行为在这儿是对的。 如果你无法轻易地将势态控制住,就需要快速评估下列问题:

  • 要发生的事情可能有哪些影响?
  • 为避免这些影响还有哪些替代方案可选择?
  • 最好的办法是什么?
  • 我如何去寻求帮助?
  • 哪个人对这个出问题的地方在行?
  • 谁需要被加快培养起来? (透明度很重要。)

4.3.3 允许其他人学习

有时, 马上介入解决问题井不是一件好事。 如果项目的影响是可控的, 最好的选择可能只是让团队自行解决问题, 由其找出摆脱他们自己造成的困境的途径一经验总是个好老师。

倘若他们挣扎一段时间,还是遇到问题,那你就有必要介入,帮助他们克服一些障碍了。

4.3.4 知道何时该卓尔不群

很多时候, 领导力要求有远见的人卓尔不群。 当要追求新的行业方向、 引入新的 要求(至少是对本单位是新的)或者审视二次设计肘, 会需要这么做。

如果你只是扩充先前做过的事情, 可以考虑如何提高做事效率。 对比而言, 仅仅因为这是项花哨的新技术或方法就想引人变更, 则很少是个正当理由。

心理学家已经勾勒出一种度量, 这里我们称为 "选择与过程" (options and procedures) 。

如果真的感觉所做的事情是 “错误的",就应当换用不同的办法, 要准备好证明要做的投入是正当的, 并能够给出纠正 ”错误” 的投入可带来的收入增长或开支节省信息。

4.3.5 请求原谅还是征求允许

谈到领导力时, 关键的决策点通常强迫你决定, 是你要日后为你所做的决定请求原谅, 还是征求允许并承担对方可能拒绝的风险。

如果选择采取 "请求原谅"的办法, 你需要充分认识到所承担的风险和成功的可能性。在这些情况下, 单位意愿可能不会支持、 赞成你最初的努力, 但当它感觉有成功希望时,就会充分肯定新方法。确保你知道自己做的是什么, 准备应对问题,井发展应对失败的计划。缺点就是, 你会将你的上司置千一种难以招架的境地,需要解释你为什么能做出无端决定,你的行为已经损失了信任关系

如果你选择采取 "征求允许” 的办法, 你的上司会以为你想把做出艰难决定的责任推卸给别人。 这显得是你埋下了这场糟糕游戏的祸根。你也为以后做出决定开创了先例。

4.4 领导别人

领导力潜在的一个关键概念就在于 “别人” 一要有跟随者存在。你能有效激励别人的领导力的关键, 就是让你的跟随者能成功地为所追求的目标贡献力量。

4.4.1 允许别人奉献(不要命令)

认知本质上是模糊不清的, 更多的情况下它是一种方向上而不是具体的固定的东西。 从某种意义上说, 认知是行进的目的地。

对于一名架构师, 关键任务是分清项目的哪些部分是根本的不容协商的。 领导者井非那种能够灌输思想给别人的宗教式的领导者, 而更多扮演着在一起前行时的向导角色。

为了帮你分清认知中哪些是可通融的地方, 请考虑下列问题:

认知中哪些关键性质不能妥协?

你事先做了哪些假设条件?它们真的有必要吗?

这些假设条件写成了书面形式吗? (人们不喜欢吃惊。)

你相信该认知吗?如果不相信你要努力去的地方, 别人为什么要相信?

为了达到预定的认知, 有没有其他办法或途径能够得到同样的期望结果?

你有哪些资源或你预计需要哪些资源?

在评估项目费用时, 你是否已经考察了至少一种实现路径吗?

所预想的商业投入产出比现实吗?

单位对此认知做过有价值的判断吗?

该项目能否分解成按阶段实施的过程?

该项目需要何时完成?

其他项目完成了哪些工作?

技术或商务前景是否已经有所改变, 需要比当前把握的假设条件更有挑战性?

你知道自己的认知与先前失败的那些有什么不同之处吗?

关联和基数的哪些方面很重要?

公司或其他类似公司中有人做过类似的事情吗?

你过去有过成功的项目吗?

在确立认知和战略方向时, 所有这些因素都要经过深思熟虑。 你要能够在合适的边界内激励别人, 允许他们消化吸收这个认知, 鼓励他们为其增加深度。 对于那些已经确定边界的领域, 确保你已经书面告诉他们, 并指出了这些边界的位置。

4.4.2 通过影响力激励别人

领导者的基本品质在于能够激励别人的愿望,让后者希望朝一个认知迈进。

领导力的要点不在于等级角色, 而是分享真理的认知——对于特定项目解决方案的正确方向。因此, 项目执行所采取的办法需 要更多地基于影响,你能够激励别人朝你试图建立的目标和认知努力。

4.4.3 确保别人能做主

通过逐渐将决策背后的知识、 依据和原理转变为现实世界的工作,将使项目团队完全沉浸于他们要完成的事项中。

他们拥有自主权, 也便千你作为一个领导者在团队执行项目期间去做其他事情。

针对你的认知写下清晰的文档, 这能够加大按照认知执行的可能性。

4.4.4 处理冲突

领导者要会处理冲突。 通常, 表面上看起来的冲突其实只是观点的不一致。 如果是这样, 就认识到它而继续前行,如果的确是冲突, 就要考虑下列做法:

励所有有关人员(必要的话, 私下或公开均可)。

倾听各方的说法。

找出问题的根源所在。

用你自己的话来阐述你的理解一尽可能简洁。

用清楚的语言说明这个问题, 表示你已经了解了情况。

寻求合乎人意的解决方法。

至于你试图达到的认知, 仍维持它的完整性。

倾听并理解冲突各方的观点, 是有效调解的关键所在。真正有能力的领导者, 其特质之一就是能调解和解决冲突。



软件架构师的12项修炼4

标签:资源   流程   身体   遇到   ons   原理   世界   开发   分解   

原文地址:https://www.cnblogs.com/edithfinch/p/11055047.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!