29 架构师领导艺术

Posted 2021-10-01 water___Wang

有一次，笔者以架构师的角色参与某个软件产品的开发，产品经过一年多的发展， 已经发布了 2.0版本，并在一些企业用户中成功实施。项目后期，由于产品整体架构设计 比较合理，各个功能模块的扩展性良好，架构师基本没有什么事情可做，加上一些其他 因素，笔者打算辞职。

但是当跟项目组成员宣布辞职的时候，大家很吃惊，纷纷表示挽留“你怎么可以走 呢，你走了，我们怎么办呢？ ”

我说“其实你们已经不需要我了，2.0版本新的功能架构都是你们自己设计的，最近 两个月技术讨论会上，我甚至都不发言了，你们不是做的一样很好？ ”

但还是有人很失望地说“你在，我们就有了主心骨，你不说话就是表示赞成我们的 设计，我们才敢这样搞，你走了，我们怎么办呢？ ”

架构师是软件开发组织中一个比较特殊的角色，除了架构设计，软件开发等技术类 工作，通常还需要承担一些管理职能：规划产品路线、估算人力资源和时间资源、安排 人员职责分工，确定计划里程碑点、指导工程师工作、过程风险评估与控制等。这些管 理事务需要对产品技术架构、功能模块划分、技术风险都熟悉的架构师参与或直接负责。

在软件开发过程中，架构师除了实现技术架构，完成产品技术实现外，还需要和项目组内外各种角色沟通协调，可以说架构师相当多的时间用在和人打交道上。处理好人 的关系对架构和项目的成功至关重要。

架构师作为项目组最资深的专业技术人员，是项目组开发测试工程师的前辈。从架 构师的身上，工程师可以看到自己的未来，因此架构师在做人做事方面需要严格要求自 己，做好表率。

---

1 关注人而不是产品

一定要坚信：一群优秀的人做一件他们热爱的事，一定能取得成功。不管过程多么 曲折，不管外人看来多么不可思议不靠谱。

所以最好的软件项目管理不是制订计划，组织资源，跟踪修正项目进展，对成员进 行激励和惩罚，而是发掘项目组每个成员的优秀潜能，让大家理解并热爱软件产品最终 的蓝图和愿景。每个人都是为实现自我价值而努力，不是为了领工资而工作。

一旦做到这一点，项目组每个成员都会自我驱动，自觉合作，寻找达成目标的最优 路径并坚韧不拔地持续前进。整个过程中，不需要拙劣的胡萝卜和大棒，最好的奖励就 是最终要达成的目标本身，最大的惩罚就是这个美好的目标没有实现。

这也是领导的真谛：寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度 发挥自我价值的工作氛围。

没有懒惰的员工，只有没被激发岀来的激情。所有强迫员工加班的管理者都应该为 自己的无能而羞愧。

---

2 发掘人的优秀

有些企业喜欢挖优秀的人，而不是去把自己打造成一个培养优秀人才的地方。殊不 知：是事情成就了人，而不是人成就了事。指望优秀的人来帮自己成事，不如做成一件 事让自己和参与的人都变得优秀。

在前面提到的那个项目中，有一位刚毕业不久的同学，分配给他的任务是调查某个 技术功能的实现。事实上这个功能已经有开源的代码实现，只需要将这些代码加入到项 目中直接调用就可以了，但是为了让他有较多的时间熟悉项目和背景技术，我没有跟他 说你去使用某个开源项目实现这个功能，而是说你调查下这个功能如何实现。

后来，这个同学不但找到了这个功能的开源实现，阅读了文档和代码，还针对我们
项目的需求场景对代码做了优化，然后又将这些优化的代码提交给开源项目的作者，最 后被合并到开源项目中。

可以说，他的工作不只是超岀了我的期望，简直就是让我吃惊，这种吃惊在我的职 业生涯中曾多次岀现，很多人在工作中做出的卓越成果以及表现岀来的优秀让我自愧不 如。

大多数人，包括我们自己，都比自己以为的更优秀，有些优秀需要在合适的环境中 才会被激发岀来，比如做一些有挑战的事，和更优秀的人合作，抑或拥有了超越自我的勇气。

发掘人的优秀远比发掘优秀的人更有意义。

---

3 共享美好蓝图

架构师要和项目组全体成员共同描绘一个蓝图，这个蓝图是整个团队能够认同的， 是团队共同奋斗的目标。

蓝图应该是表述清楚的：产品要做什么、不做什么、要达到什么业务目标，都需要 描述清楚。

蓝图应该是形象的：产品能为用户创造什么价值、能实现什么样的市场目标、产品 最终会长什么样，都需要形象地想象出来。

蓝图应该是简单的：不管内部还是外部沟通，都能一句话说明白：我们在做什么。

蓝图应该写在软件架构设计文档的扉页、写在邮件的签名档、写在内部即时通信群的公告上。

在项目过程中，架构师要保持对目标蓝图的关注，对任何偏离蓝图的设计和决定保持警惕，错误的偏离要及时修正，必要的变更要经过大家讨论，并且需要重新获得大家 的认同。

也许有人会说“你是在忽悠我吧，只是想让我努力工作而已”。青春总会逝 去，人总是会死的，当有一天你白发苍苍回首往事，你会为无所事事而遗憾， 但不会为被人忽悠而羞愧。批评马云忽悠的人，一定为马云在创建阿里巴巴的 时候没有忽悠他成为创始人而遗憾。

---

4 共同参与架构

架构师需要对系统架构负责，但并不是说一定要架构师自己完成架构设计，并要项目团队严格遵守架构决策。

把架构和架构师凌驾于项目和项目组之上，只会让架构师变成孤家寡人，让架构曲高和寡。

1. 不要只有架构师一个人拥有架构

架构师不要把架构当做自己的私有财产，为了维护架构的纯洁和架构师的威信而不 让他人染指架构。让项目参与者对架构充分争论，大家越是觉得自己是项目架构的重要 贡献者，就越是愿意对开发过程承担责任，越是愿意共同维护架构和改善软件。

2. 让其他人维护框架与架构文档

框架是架构的重要组成部分，许多重要的架构设计通过框架实现来体现。但是在软 件开发过程中，架构也需要根据需求不断发展演化，框架和架构文档也会随之调整。除 非是重大的重构，否则架构师应该让项目组成员维护框架和架构文档，给项目组成员成 长的机会也让自己有更多的时间去寻找更大的挑战。

---

5 学会妥协

不要企图在项目中证明自己是正确的，一定要记住，你是来做软件的，不是来当老 大的。所以不要企图去证明自己了不起，永远也别干这种浪费时间、伤害感情的事。

有个小故事：猎人进山里打猎，反而被一头黑熊抓住了，黑熊说“如果你给我XX我就放你走”，猎人无奈只好给黑熊XXo回去后苦练打猎本领，再次进山，结果又被黑熊 抓住，再次要求给了 XX。第三次他又来了，黑熊看到他就乐了 “你是来打猎的还是来给 我XX的？"。

每次我在做项目迷失方向，五迷三道的时候，就会想起这个故事，提醒自己是来做 软件的，来实现客户价值的，不是来证明谁对谁错的，不是来给黑熊XX的。

很多时候，对架构和技术方案的反对意见，其实意味着架构和技术方案被关注、被 试图理解和接受。架构师不应该对意见过于敏感，这时架构师应该做的是坦率地分享自 己的设计思路，让别人理解自己的想法并努力理解别人的想法，求同存异。

对于技术细节的争论应该立即验证而不是继续讨论，当讨论深入到技术细节的时候 也意味着问题已经收敛，对于整体架构设计，各方意见正趋于一致。

而当大家不再讨论架构的时候，表明架构已经融入到项目、系统和开发者中了，架 构师越早被项目组遗忘，越表示架构非常成功；项目组越离不开架构师，越表示架构还 有很多缺陷。

---

6 成就他人

我们活着不是为了工作，不是为了做设计、写程序，这些不是我们生活的目的。我 们活着是为了成就我们自己，而要想成就自己，就必须首先成就他人。

每个人都有自己成就的目标，而工作是达成自我成就的一种手段：通过工作的挑战, 发掘自我的潜能，重新认知自我和世界。

软件开发过程是人的智力活动过程，软件开发不仅是制造软件的过程，也是开发人员完善自我、超越自我的过程。所以我们工作不只是生产产品，还要成就人，并最终成 就我们自己。

做成一个项目不但要给客户创造价值，为公司盈利，还要让项目成员获得成长。要 让他们觉得通过这个项目，自己的知识技能和业务水平都得到了提高。项目结束时，大 家会觉得不可思议：“如此完美的产品，如此有挑战的开发居然都是我们完成的”。而且 每个人都觉得自己在项目中至关重要不可或缺。

架构师作为团队的技术领导者，在项目过程中不要去试图控制什么，带着一个弹性 的计划和蓝图推进，团队会管好他们自己。你越是强加禁令，队伍就越是没有纪律；你 越是强制，团队就越是不能独立自主；你越是从外面寻找帮助，大家就越是没有信心。

而一旦打造出一个优秀的团队，在以后的合作中，面临更大的挑战时，架构师就可 以从容应对，因为你不是一个人在战斗。同时一个优秀的团队内部也会发生化学反应， 创造出超出工作本身的机会，开启更美好的明天。