“那些遗落在某个角落里的记忆,早已随着时间的流逝消失的无影无踪” 2017年已过半，又到了年中复盘与规划的时间，每天大部分的脑细胞用来开会与反思，大部分的睡眠时间则用来输出PPT，无论这种方法论的疲劳还是兴奋，在这个过程中，我构建起自我反思与展望的能力。

写在前面

其实，复盘相当于总结，规划相当于展望，在强调数据的互联网时代，所有的复盘与规划都需要通过输出物进行表达

在复盘与规划中，表现形式被区分为两个大类：

线上：通过输出物的方式，传递总结的经验、问题、步调及解决
线下：通过’密集话’讨论、脑爆，无论是务虚也好、务实也罢，聊一下经验、问题、步调及解决

在过去的10-20年里，公司内最重要的改变，我想应该是从 ‘英雄主义’ 逐渐转型为 ‘团队主义’，也就是说一个人能力的强弱越来越无法使得团体自如的应对互联网快节奏的变化与不确定性，那么既然是团队，就有一群人，一群人就需要用目标驱动的方式进行疏导，讨论、开会这样的形式就在所难免

架构师，这个技术圈相对处于顶端的岗位，取得架构师抬头，相信是很多程序员的梦想之一

记得在某公司架构师招聘信息中看到，岗位职责中写着 “XXXXXXXX，有较强的系统设计和问题解决能力” ，这句话其实非常聚焦，从词语上看，“问题” 是目标，“解决” 是动词，“能力强” 是形容词，也就是说只要能够对某某技术问题给出解决方案并解决他，你就基本符合这个岗位的要求了，有意思的是，在我接触的架构师中，绝大多数都以此项能力引以为豪、沾沾自喜

为什么沾沾自喜？为什么引以为豪？我觉得应该是如下几点：
优越感 - 只有我可以解决，别人解决不了
被仰慕 - 你好厉害，我好崇拜你
独尊感 - 缺我不可，唯我独尊
满足感 - 这种感受，就好像费了九牛二虎之力后，才将大便逼出体外的感受一致

总结下，架构师比较喜欢技术活，没技术含量的事，多半没啥兴趣，或者比较讨厌

曾经与某架构师面谈，听到过这么一句话 “这是资深开发的事呀，还需要我来搞定吗？”
开会是个技术活吗？
我个人觉得，无论是架构师还是程序员，技术属性大的岗位，应该都不喜欢开会

有时候参加的会议整场下来跟我毛关系都没有，全程神游俩钟头，最后突然有人一拍桌子：“还有问题没？好，散了！”

也有可能有个什么会没叫你，过了俩礼拜突然收到封邮件催开发进度， “当时那个会你没参加，大家都说应该是你们做……你没看会议纪要吗？”

吐槽了这么多，但我还是认为开会是个技术活，对于架构师来说尤其如此

大多数架构师开会并不是那种新闻里的工作汇报或者长者们的会议，他们真的需要通过开会讨论一个具体方案，或者解决什么具体问题；

令人可惜的是，大多数的会议都是在毫无意义的交流中浪费时间：几方人坐在一个屋里互相说一些对方理解不了的话，最后得出一个 “我们会后再捋一捋” 之类的结论

这并不是会议才有的问题，在架构师日常的沟通中，也有很多人并不懂得如何交流，比如偶尔会收到一些写的非常认真的邮件，打开之后是密密麻麻的一屏幕文字，但是从第一句开始就不知道他在说什么，后面的东西连看的动力都没有了

大多数时候，沟通的核心不是你说了什么，而是你想要让对方了解什么、让他做什么。良好的沟通能在工作中显著提升效率，这恰恰是大部分架构师最不喜欢，最瞧不上的；

想要恰到好处的进行沟通是技术较高的工作，但是简单来说有几条原则：
确保各方对背景的理解一致，比如开会之前先简单通过邮件交流一下，对新加入会议的人花个 30 秒钟做个前情提要，或者在讨论过程中让对方说一下他的理解；
去掉对方不能 / 不需要理解的内容，比如跟产品说 “这个队列在高并发下因为锁的实现有问题导致 CPU 性能瓶颈” 不如改成 “我们发现了性能问题，持续 10 分钟了，10 万用户收不到运营发的无节操广告，大概 5 分钟后扩容解决”；
确保在对方失去注意力前尽快说出重点，比如排查问题的总结邮件，如果第一段是这样：“某某框架内部使用的是 xxx 技术，这个技术的架构是这样：xoxo”，那么对方可能完全不知道你在讲什么。可以换成这样：“我发现了某某框架的 bug，需要尽快升级，否则在 xxx 情况下有可能会出现 yyy 问题，具体排查过程如下：xoxo”；

在很多场景中，一场高质量的会议是非常具有技术含量的，但前期的准备、线下的沟通、客户的视角、产品的思考都决定了开会的技术含量

结束语

其实开会质量与你的综合能力有关，这其中悬挂着技术属性，也悬挂着同理心、情商、产品视角及业务能力这样的非技术属性
要学会把开会当作一个程序问题来分析，当作一场挑战赛来模拟，你会慢慢发现开会其实也没那么讨厌，甚至还会有那么一些小小的期待。

本文转载自头哥侃码公众号。

原文链接：https://mp.weixin.qq.com/s/fg-tY8XA6FINSVNBkKb97A

创作场景

对于架构师来说，开会是个技术活吗？