这是本系列的最后一篇。
前面说了，一个架构师，推荐的时间分配应该是 50% 在内部工作，25% 在内部沟通，25% 在外部沟通。所以讲完内部工作怎么做之后，我们来看看这些沟通工作怎么做。
目录
对内沟通
在管理上有一个「第一团队」和「第二团队」的概念。
「第二团队」主要是指汇报给你的人以及他/她们的下属。 「第一团队」主要是指你的平级和你的汇报对象。
大部分人呆在第二团队里面是比较舒服的，因为说白了，你是这个树状结构的顶点。正是因为这样，能不能和第一团队很好地进行目标对齐和协同作战，是很多人做到一定的职位后，管理上的一道坎。很多人甚至意识不到，自己的平级和自己的汇报对象，才是自己的第一团队。
作为架构师，对内沟通，其实就是第二团队里的沟通，肯定也是比对外沟通要容易的。如果你按照前面说的做好了「内部工作」，就更加容易了：
- 你参与了编码和关键技术框架的搭建；
- 你使用了简洁具体的语言和图例编写了架构文档；
- 你构建了自己在团队里面的影响力和声望；
这里主要再讲两个容易被忽视的技巧。
展示脆弱性，构建安全感
《反脆弱》是一本创业公司的老板们很喜欢分享给员工的书。
在各种不确定性中去做决定，拿结果，的确是需要很理性很坚定的。但是，另一方面，作为团队里拿主意的人，敢于说出「我不懂」或者「我的锅」，敢于展示自己的「脆弱性」，可能是你在对内沟通中要学会说的最重要的话。
这比较反直觉。
因为市面上流行的「领导力」教育，大都是类似《勇敢的心》里面的华莱士，或者在公司里暴走但却力挽狂澜的乔布斯的故事。像马刺的 Buford 那样干得好像个助理般默默无闻实际上却功勋卓越的管理者，好像不太被看作很有「领导力」。
但我听阿里的同学讲过，有一次一个业务负责人挑战马云说，你怎么才过了几个月又变了。马云很平淡地回答说：「你应该高兴啊，你的老板又进步了，之前确实有些地方还没有想清楚」。
如果你有了一定的工作特别是创业的经历，甚至，我觉得如果你有了一定任何关系里的经历，就会明白，关系的构建常常是在「脆弱」的时刻完成的。当你们一起面对一个个自身和团队，业务和系统的弱点或者分歧时，你们是假装强大其实划水还是直面麻烦一起努力；你们是互相学习还是要「赢」下讨论；你们是公开发表自己的见解观点还是在下面三五成群的说来说去……这一切很多时候都看团队的管理者的风格：如果管理者端着，团队就很难打开。
为什么？其实事关安全感。
Google 花过很大的力气研究如何构建一支强大的团队。
如果你仔细阅读他们发布的数据和论文，就会发现，本质上唯一有效的办法，就是构建心理上的安全感。
构建有安全感的团队，有很多技巧，比如好好倾听，一起吃饭，私下批评，公开表扬，夸张地感谢，谨慎地招聘。它是一个系统工程，也不仅仅跟管理者自己有关，这里讲得是架构师作为管理者最核心要做好的事情：敢于认可和拥抱变化，敢于展示自身的脆弱性。
建立目标感和节奏感
团队相处融洽，成员有安全感，并不意味着团队是高效的。在公司里，任何一个团队必须是为了一个明确的目标存在的。
一定程度上来说，架构师和其他的管理者一样，主要任务就是搞清楚目前在哪里，接下来要去哪里，具体怎么去，层级越高的管理者越需要放权给团队。
因为是技术角色，架构师在团队里要建立的目标感主要来自于对业务和技术如何结合的理解。形式上，如果使用 OKR 来保持和团队的对齐，那么架构师的 Objectives 里可以有很多和下面这些内容有关的部分：
- 引导技术决策：注意「引导」两个字。「我决定使用 React 进行前端开发」，和「我会带领大家在 Angular、 Elm、 React、 Vue 几个 web 框架之间做出选择」是两回事；
- 持续分析架构：大多数架构都会经历结构衰退，这种衰退发生在需求变更等不可避免的情况发生时，架构师要关注现有架构的特征，如性能、可用性和可伸缩性，并有计划的降低变更带来的影响；
- 落地最佳实践：架构师需要紧跟最新的技术和行业趋势，并且梳理出适合当前团队和业务的最佳实践，在内部落地。有计划地跟踪并理解趋势，对团队效率，以及做出正确的决策来说非常重要；
节奏感也很重要。架构本质上是一组关于「选择什么妥协什么」的决定，因此你按下跷跷板的一头时，一定会有一头翘起来。要习惯花大量的时间跟大家对齐这些决定的原因，要习惯自己的系统每过一段时间就会重构，也要习惯大家会挑战：架构师做的每一个决定都会受到挑战，产品经理、项目经理和业务涉众将对架构决策提出质疑，那些认为自己的方法更好的开发人员也会挑战。
对外沟通
学习正确的语言
不同的人有不同的语言体系。当你跨入第一团队的沟通，你会很快有不适应的感觉：他们和开发不一样，和你说的不是一样的话。
你可以给团队说「这个模块写得太糟了所有东西都耦合在一起，我们用两个迭代来重构它」。但是对外部沟通，没人理解或者在乎什么是「耦合」以及为了解决它为什么要花两个迭代。要说清楚这件事情不如讲「因为之前的技术债我们的单点登录再不改用户数过一万就会天天崩溃，这个会影响核心流程所以我们必须要花两周时间重写」。
一方面，市场里面还是有很多人把研发当成施工队，和这些人沟通有可能是浪费时间。但另一方面，站在听众的角度调整语言，以对方理解的成本收益去沟通并落实团队关于架构做出的决定，是架构师的基本功，但也是被很多人忽视的：要明白当你沟通不畅的时候，并不是其他人「傻逼」或者「没 sense」，而是你没学会对方的语言，这是你技能上的缺失。
收集并讲述更多的故事
我觉得每个人来到世界上，都有自己要去完成的故事。常常有人问我到一个团队怎么尽快融入，我也会告诉他们去搞清楚大家的故事。
在不同背景下，「故事」的含义大不相同。作为架构师，为什么要讲故事？要讲什么样的故事？
本质上，讲故事是因为故事是具体的。它不像你画的那些抽象的架构图，它有助于沟通。
同时，故事还有更微妙的作用。神经科学表明，故事会触发心理模拟，甚至影响身体的反应：
We can’t imagine events or sequences without evoking the same modules of the brain that are evoked in real physical activity. Brain scans show that when people imagine a flashing light, they activate the visual area of the brain; when they imagine someone tapping on their skin, they activate tactile areas of the brain. The activity of mental simulation is not limited to the insides of our heads. People who imagine words that start with a ‘b’ or ‘p’ can’t resist subtle lip movements, and people who imagine looking at the Eiffel Tower can’t resist moving their eyes upward. Mental simulation can even alter visceral physical responses: When people drink water but imagine that it’s lemon juice, they salivate more. Even more surprisingly, when people drink lemon juise but imagine it’s water, they salivate less.
根据你希望人们关心什么，有不同种类的故事。也许你想讲清楚用户需求？也许你想分享一些知识？也许你想鼓励合作？也许你想引进一项新技术？也许你想强调文化价值观？不同的情况需要不同的故事。有时故事必须是真实的，有时却无关紧要。有时要有足够多的细节，有时不是。
别害怕，作为架构师，你不用是一个讲故事的高手：一个没有娱乐性、没有戏剧性甚至没有任何趣味的故事也能起作用。当然，我观察到，那些能够把故事讲好的架构师，会更有魅力。
说之前先多写
沟通为什么这么难？因为你常常不知道怎么说话，或者说错话。
前面说的，每个技巧，都需要锻炼。怎么练习？我觉得最好的办法是先多写写。
对内沟通？你可以写写管理周报。
对外沟通？你可以多写文档，多写邮件。
黄铮写给股东的信是写给股东的吗？我觉得更多是帮助自己把思路梳理清楚。
所以，我强烈建议想在业务和管理上走得更远的同学，要多思考，多写作。
Summary
架构师有 50% 的时间应该花在沟通上。除开常规的管理技巧之外，本文建议你做好下面几点：
- 对内沟通：展示你的脆弱性，建立团队安全感。建立团队的目标感和节奏感。
- 对外沟通：学习正确的语言，收集和讲述更多的故事，多思考多写作。