- 推荐序一:架构师真正要学会的事情
- 推荐序二
- 译者序 2.0
- 序
- 关于本书
- Part Ⅰ 什么是软件架构
- 第 1 章 什么是架构
- 第 2 章 架构的种类
- 第 3 章 软件架构是什么
- 第 4 章 敏捷软件架构是什么
- 第 5 章 架构对上设计
- 第 6 章 软件架构重要吗
- 第 7 章 问题
- Part Ⅱ 软件架构的角色
- 第 8 章 软件架构的角色
- 第 9 章 软件架构师应该编码吗
- 第 10 章 软件架构师应该是建造大师
- 第 11 章 从开发者到架构师
- 第 12 章 拓展 T
- 第 13 章 软技能
- 第 14 章 软件架构不是接力运动
- 第 15 章 软件架构要引入控制吗
- 第 16 章 小心鸿沟
- 第 17 章 未来的软件架构师在哪里
- 第 18 章 每个人都是架构师,除非他们有其他身份
- 第 19 章 软件架构咨询师
- 第 20 章 问题
- Part Ⅲ 设计软件
- 第 21 章 架构驱动力
- 第 22 章 质量属性(非功能需求)
- 第 23 章 处理非功能需求
- 第 24 章 约束
- 第 25 章 原则
- 第 26 章 技术不是实现细节
- 第 27 章 更多分层等于更高复杂度
- 第 28 章 协同设计是一把双刃剑
- 第 29 章 软件架构是对话的平台
- 第 30 章 SharePoint 项目也需要软件架构
- 第 31 章 问题
- Part Ⅳ 可视化软件
- 第 32 章 沟通障碍
- 第 33 章 对草图的需要
- 第 34 章 无效的草图
- 第 35 章 C4:语境、容器、组件和类
- 第 36 章 语境图
- 第 37 章 容器图
- 第 38 章 组件图
- 第 39 章 是否包含技术选择
- 第 40 章 你会那样编码吗
- 第 41 章 软件架构和编码
- 第 42 章 你不需要 UML 工具
- 第 43 章 有效的草图
- 第 44 章 C4 的常见问题
- 第 45 章 问题
- Part Ⅴ 为软件生成文档
- 第 46 章 代码不会讲述完整的故事
- 第 47 章 软件文档即指南
- 第 48 章 语境
- 第 49 章 功能性概览
- 第 50 章 质量属性
- 第 51 章 约束
- 第 52 章 原则
- 第 53 章 软件架构
- 第 54 章 外部接口
- 第 55 章 代码
- 第 56 章 数据
- 第 57 章 基础设施架构
- 第 58 章 部署
- 第 59 章 运营和支持
- 第 60 章 决策日志
- 第 61 章 问题
- Part Ⅵ 开发生命周期中的软件架构
- 第 62 章 敏捷和架构的冲突:神话还是现实
- 第 63 章 量化风险
- 第 64 章 风险风暴
- 第 65 章 恰如其分的预先设计
- 第 66 章 初识软件架构
- 第 67 章 问题
- Part Ⅶ 金融风险系统
- 第 68 章 金融风险系统
- Part Ⅷ 附录:技术部落 的软件指南
第 13 章 软技能
本书主要讨论软件架构角色跟技术深度和广度有关的部分。但这只是一部分,我们本质上谈论的是领导的角色,“软技能”或“交际能力”也极其重要。
领导力:简单来说,领导力就是创造共有的愿景,并带领人们向着共同目标前行的能力。
沟通:你有世界上最好的想法和愿景,但如果不能有效地传达给其他人,也是死路一条。这包括了软件开发团队内外的人,要使用适合受众的语言和细节水平。
影响力:这是重要的领导技能,从毫不掩饰的劝说到神经语言编程1或绝地控心术2,它能够以多种途径实现。通过妥协和谈判也可以达到这样的目的。每个人都有自己的想法和计划,你在处理时还得让他们都不反感,并主动地去追求你需要的结果。好的影响力也要求好的倾听和探索能力。
信心:信心很重要,是有效的领导力、影响力和沟通的基础。但信心不代表傲慢。
合作:软件架构角色不应该被孤立,(与其他人)合作想出更好的方案是一项值得实践的技能。这意味着倾听、谦虚和响应反馈。
指导:不是每个人都对你正尝试做的事情有经验,你需要对他们进行角色、技术等方面的指导。
辅导:辅导是对人进行学习方面的指引,而非告诉他们怎么做一件事。作为领导,你可能会被要求去辅导团队中的其他人。
动力:这说的是保持团队愉快、开朗和积极。团队要有积极性,才会跟随你这个软件架构师所创建的任何愿景。你还要面对团队中一些人不买账的局面。
润滑剂:你经常需要退后一步,促进讨论,特别是团队内有不同意见时。这需要探索、客观,帮助团队达成共识。
政治:每个组织都少不了政治。我的咒语是,离得越远越好,但你至少应该明白周围发生了什么,这样才能做出更可靠的决策。
责任感:你不能因为失败就责备软件开发团队中的其他人,有责任感对你而言很重要。如果软件架构不能满足业务目标,无法交付非功能性需求或技术品质很差,那都是你的问题。
授权:授权对任何领导角色来说都是一个重要部分,作壁上观和事必躬亲之间有一条模糊的界线。你应该学会在适当的时候授权,但请记住,你授权的可不是责任。
1http://en.wikipedia.org/wiki/Neuro-linguistic_programming
2电影《星球大战》中绝地武士(Jedi Knights)的技能。——译者注
保持积极
不管你怎么看,软件架构师都是一个领导的角色,对开发团队中不少人来说,作为软件架构师的你都可能会是重要的榜样。原因是什么?团队中的一些人可能就是有抱负的软件架构师。这种处境让人飘飘然吧?然而如果你把视线移开,还是能看到一些负面的东西。
不管你是否意识到了,你都在一个非常有影响力的位置上,你的一举一动都被整个开发团队看在眼里。不管愿不愿意,单是这一个原因,你就有改变整个团队的能量。如果你很主动,开发团队也很可能变得主动。如果你对工作充满热情,团队其他人也会很可能充满热情。如果你对每件事都很乐观,开发团队也会这样。
你几乎可以把这看作是正能量的回路,你的热情带动了团队,他们的热情也带动你。这无比梦幻,但也不难看到由于你不恰当的行为而造成的损害。任何程度的懒散、冷漠或悲观传染到团队的速度,都会比你说“但我们会没事”更快,然后你就会陷入消极的恶性循环。
我们不常谈论软件架构师的软技能,但软技能有时候比过硬的技术更重要。交付产品的团队才是愉快的团队。作为领导,让团队保持积极是你的责任,你的角色在整个团队中不应被低估。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论