50人左右软件团队技术管理
一、背景
最近团队人数涨到了接近50，自己也逐渐感觉吃力，也借此机会好好的总结了一下，50人左右的团建团队如何做好技术管理。
自己本身也不太算manager，只不过因为跟领导分工，我更多是在技术或者技术管理上，而我领导本身帮我屏蔽了很多非技术无关的会议、任务、扯皮、需求拉齐、验收等，所以我领导给我俩定义的方式叫做“搭班子双人管理的方式”。所以整体来说，我几乎从事的都是技术相关的，但是本身人数已经接近50，所以管理本身无论如何也绕不过的去点，因为这篇文章也会从技术、管理以及个人三个层次来分析，如何做好50人软件团队技术管理。
本身还是需要介绍一下自己的背景：
自己本身在蔚来大概有10人左右的团队管理经验，从结果看，虽然只有大半年的时间，但是效果还是很好的。小团队中软件开发管理 - 汽车与it技术学习与分享（https://jinbaotang.cn/2022/06/28/mini-team-softwaredev-manage/），而自己在新公司也是将上述提到的经验复刻了一次，基本上算是效果无敌。
新公司属于造车新势力的一种，团队主要是做中间件平台的开发，包含mcu和soc
自己负责范围包含：s2s,comm(someip/dds/zmq/iceoryx),tsn,diagnostic(doip/uds/otx/ota/flash/rvdc)以及soa开发。
团队成员背景基本上来自很多行业：互联网、游戏、物联网、汽车行业、手机以及其他桌面软件开发等
开发内容几乎全是从0到1的过程
老板和领导均是技术出身（很重要！！）
在这个团队，自己原本算是普通工程师吧，然后慢慢在开发过程中，任务越来越多，在入职没几个月后开始带着小伙伴一起干活，在23年下半年开始慢慢逐渐对团队整个技术负责。整体来说，算是团队搭建过程中的主要人物之一吧。
目前从结果来，我觉得团队做的还是非常不错的，从过去的23年成果来看，在组织横向对比来看，基本算是比较顶尖的团队了。
所谓技术管理，首先想到的是技术。
二、技术
整体来说，车载中间件不算是天顶星级别的科技，在我看来难度并没有高到不可逾越的程度，否则作为一个工作年限不长的95后，也不可能驾驭的住。因为本身要做好技术管理，本身需要对团队的工作内容和方向有一个很好的认知，至少需要了解到整个团队在未来1-2年内产品应用场景和落地方案。
1-2年较长期的技术规划能力、保障质量
以车载中间件为例，尤其通信相关的组件，本身是平台属性，首先想到的就是易用性、性能、稳定性以及深度，相对需求开发团队来说，开发内容相对固定，长期规划相对来说好做。以我在极氪的第一个从0到1的项目--s2s来说。
s2s（signal 2 service）本身是软件定义汽车--SOA的关键过渡组件，不管如何变化，从功能安全、历史包袱来看，can/lin信号依然是整车最为关键的通信方式，从面向信号开发到面向服务开发，信号转服务就变成了很关键的组件。正因为如此，s2s贯穿了整个SOA流程，如果了解了s2s的原理和开发过程，不仅了解SOA的开发方式，而且还会了解到基于信号的开发以及如何将两者粘合到一起。所以在我开发完成s2s组件并且在实车落地后，我基本上对我们整个大团队2-300人开发内容以及上游电气架构工作流程、下游集成测试工作比较熟悉了。从具体内容来看：
基本上非常熟悉cp对can/lin信号如何打包以及打包策略，了解了ub位的使用，对于不同信号优先级的处理方式
信号到服务转换关系涉及到“兼容性”问题
所谓SOA开发需要包含的组件：comm组件、serviceframework、service代码生成原理以及序列化的具体实现，原子服务划分的原则，
基于SOA开发方式的测试流程
在s2s的开发过程中，虽然是从0到1的过程，但是本身又做了长远规划。在开发过程中，意识到的信号超多、并且超多高频一样数值的信号，所以提出了两大方向：
零拷贝、零手工代码
全链路、端到端的自测试
从结果看，正是因为有了上述两者大方向，在经过23年一整年的迭代过程中，我们的速度变成了“能考100分，是因为卷面只有100分”，而且我们的质量远超出预期。
s2s是我自己从0到1开发，但是在进入23年之后，我几乎没有参与到开发，但是整年的技术路线、代码结构都没有按照22年定义的走。
所以如果做好技术管理，首先本身对技术必须要有1-2年的规划能力，尤其作为基础组件来说，架构、方向必须定下来的，在实现本身不断突破自己的边界，充分了解自己组件在整个系统的作用以及相关模块的功能、实现细节，这样自己在后续迭代中不需要投入很多精力调整方向等。
抓住主要矛盾、项目管理能力、重视测试
在23年4月中旬，临危受命需要对comm重构的整个技术负责，在接到这个任务的时候，整体来说，原有的小伙伴做了不少事情。下面是我使用STAR模型对整个事情的过程总结。
当时遇到的问题就是，feature特别多，人员严重不足，并且新入职大量的同事，按照《人月神话》的理论：在项目有延期风险时，大量进人是会拖慢进度的，在这个重构项目，算是亲身感受了一把。
所以在我了解清楚到整个事情背景后，快速了定义目标：6月必须发版、达到重构前功能以及完成适配。在我梳理清楚目标后，我开始梳理具体需要的事项，除了上述目标外，还有一个潜在目标，我们必须完成相关技术方案验证（重构肯定为了拓展），当时发现在技术方案验证上，花了太多的时间。因此我自己亲自去参与的非必须功能的方案验证，完成验证后立马放弃开发法，节省有限的人力开发最主要的功能。剩下就是比较老套了，涉及项目管理的一些知识：
拆解任务，
拆分小组
并行开发
而我自己为了快速熟悉所有的代码，选了一个贯穿始终的组件--listener开发，这个选择让我几乎掌握了项目的所有细节。在掌握了较多技术细节后，我就具备了对外沟通的能力，作为技术负责人，沟通能力是必可不少的，但是很多开发恰恰相反，技术很行，沟通拉胯。因此保证技术强、沟通能力弱同事安心开发是必不可少的，我承担了不少对外的沟通，包括：方案确认、适配时遇到的问题、合作开发遇到的情绪问题等。在后续交付迭代的过程中，基本参与到了好几个对外重难问题的解决，这个过程保障了，我进一步熟悉了关于性能相关的代码细节以及架构。
并且还有一点，在重构的过程中，我将几乎最优秀的工程投入到开发测试代码，全面的保证质量。因为我必须在快的过程中保证质量，这样才是真正的快，否则反工则是最严重的效率低下。
所以在技术管理，尤其任务紧、人数多时，抓住最主要的问题点，做好项目管理和质量保障是及其重要的。
交流中快速获取关键信息以及给出结论
在所需要管理的人员达到30人以上时，即使你不去找别人，也会遇到各种各样的同事因为各种事情找到你，如果每天平均5个人来找你讨论技术，每个人半小时，看起来是2-3时没了，实际上是4-5个小时没有了都不止，因为包括你必须从已有工作中恢复上下文。因此在与小伙伴沟通过程中，快速抓住重点，了解到他们的困难到底是什么，就变的很重要了，否则自己就没时间搞其他的了。当然，每个人遇到的困难都是不一样的，是方向？还是方法？还是技术积累不够？我自己抽象了一个模型，以物理中求当前的速度为例：
我们都知道：速度v = 初速度v0 + at（加速度*时间）。
如果小伙伴找你讨论时：
首先要问他是否知道自己的目标是求出当前的速度v，
如果不知道，先明确自己的目标是什么？或者给小伙伴说清楚你要求的目标是什么！
在明确了目标之后，我们需要明确，初速度v0是否知道？加速a是否知道？t又是否知道？
如果不知道，我们需要跟小伙伴讨论为什么不知道？是因为没法知道？还是什么？目标就是帮小伙伴把所有需要的条件都找到。
所有条件都满足，至于at（加速度*时间）是需要积分、拟合亦或者a是常量，这些都是小伙伴自己去考虑的。当然如果时间充足的话，也可以帮他一起分析，但是想说的是，需要控制时间以及给小伙伴的时间。
在明确目标、确定条件后，在讨论的过程中，作为技术负责人一定要给一个明确的结论，并跟小伙伴明确清楚是否还有其他困惑，同时自己的内心需要有一个工作量的评估，这个可以小伙伴也可不和他说，只是自己作为技术管理、项目管理的一个参考指标。
我自己用这个模型后，从过去1年的效果来看，给自己节省了不少时间，在这个过程也培养到了小伙伴的思维。所以作为技术负责人，明确目标、找到必备条件以及给出结论是不可少，同时还得有难度、工作量的评估。
参与、甚至亲自实现初版代码+并且保持技术在整个团队的中上水平
作为技术管理者，自己水平是必须保持在中上的，如果团队成员是小于15个人的，我认为还得是top级别的；如果是多于15人后，也必须保持在整个团队的中上水平。因为只有这样，你才能做到其那面提到的各种要求：规划能力、项目中的主要矛盾、个人困惑中的解答以及工作量的评估。并且作为技术管理者来说，本身的技术水平决定了团队成员对你话的信服是成正比的，在团队成员中建立了技术影响力之后，你的很多结论、方向和方法可以得到推广，这样又能一定程度降低沟通成本。
如果从0到1的项目（并没有这么多从0到1的项目），我的建议是初版代码必须自己去写，甚至可以通过代码来替代软件架构文档，对于组件来说，如果满足技术水平中上时，前期做好构想，写初版代码和写详细的软件架构文档时间不会相差很多的。这样做至少有两个好处：
软件架构和初版实现都是按照自己的想法去写的，在后续迭代过程中、review代码时，可以极大的降低心智负担，并且如果小伙伴开发时没有按照既定要求开发时，也能很敏感的感知到。
交付（架构）代码，然后软件架构文档交给小伙伴去写，这样有助于小伙伴从设计角度去审视组件，也有助于小伙伴的能力提升
我自己还是上述工作模式中受益很多，比如s2s、sox、comm、service template都是从0开始搞起来，作为一个合格以上的组件架构就在心中很明确了。实际中，s2s我接近1年都没有做过开发，但是需要遇到新需求、有bug时，我基本都能快速反应过来应该在哪里；平常技术时，小伙伴沟通，我也是无障碍可以get到他们想表达的意思。
没有银弹，快速原型很重要
“没有最好的技术，只有正确的技术，选择一个方向先把困难点找出来，再做优化。”这是我对小伙伴说的最多的话。当然这句话本身是有一点片面性，所以我更想说的是，作为技术负责人在做决定以及技术探索时，一定不要疯狂内耗，东一榔头、西一棒槌的。针对一个任务、项目尤其是一个全新的任务，路上会遇到很多困难，当我们遇到困难时，我们首先想到的就是是不是当前路线有问题，此时就会考虑换一种方式，但是大多数时候，换一种方式也会遇到另一种困难。如果一个人的时候还好，浪费的是自己的时间，当需要对整个团队负责的时候，如此反复横跳，带来的后果是灾难性的：失去信任、以及浪费时间。
《人月神话》中没有银弹的论点，问题不会消失，只会转移，所以我们作为技术负责人，千万不要想着或者追求一个完美无缺的方案，在我过去的经验看来，这是不可能的，如果有这个错觉，那一定是因为我们考虑不够，有很大的概率我们是把一些技术难点转移到的其他地方了。按照之前我之前做法，作为团队负责人，针对有难度的项目或者任务:
在前期充分调研，可以把时间拉长一点。
比如我在做mcu自研时，我们其实在10月份才真正的开始，但是我在7月份就已经开始着手调研、实操，把未来可能遇到的问题、困难点，都列出来，然后找到对应的资料定性、定量的分析。
当我的一个想法提出来或者要让团队开始做时，基本我已经把所有任务的难点都评估到70%以上了，所以在后续小伙伴提出质疑时或者畏难时，我基本可以把他们说服。
定好基调（做或者不做、方案、时间点）后，不要再改变
基于第1点，大概率是不会出错了，这个时候千万不要瞻前顾后的，我们应该一往无前的把一个大致目标完成，把所有困难点再进一步细化解决方案或者反向。
优化、迭代
没有最好的方案，但是有更好的方案，在小细节中，我们为了快速达成目标，多多少少都会用一些workaroud或者stub的地方，这个时候，我们一定不要忘了这些点，我应该通过多次优化、迭代甚至重构来达到整体更好的方案
我们做的大多事情，都不是天顶星科技的，所以不管如何最终都能完成，但是在时间、资源都有限的情况下，我们只能通过合理的安排我们的计划，才能达到“最优解”。很多时候，我都认为，技术在对一个项目中不是最难的，尤其对于技术责任来说，更多的是在于：项目管理能力、随机应变能力、做事思路、以及坚持。
三、管理
如果技术方面是让团队方向不会错、目标不会错，那么管理我想谈的是，如何让团队所有人一起参与，从而真正的达到目标。从个人感情来说，我是一个不太会做管理的人，个人比较推崇所谓的“发挥个人自主性”，所以真实来说，我不太会push，算是一个“重过程”的人，所以考虑更多的是共情。从另一方面来说，我的职业生涯从18年开始，一直也是比较自由的，而且自己也算一个比较懒的人，因此我的管理是有重大缺陷的，幸好在我现有团队中，我领导帮我弥补了很大一部分。就管理来说，我想从四方面来谈：团队文化、团队成员培养、目标制定和回顾、奖励与惩罚。
团队文化
在23年团队快速扩张过程中，我给领导，我们要有自己的文化了。文化整体是一个很虚的东西，但是在实际过程中，又是一个很实际的东西：当年你要完成任务时的思想一致！当你提出质量要求时的响应！当你面对困难时的信心！以及当面对压力的支持。
在我看来的文化，始于招聘。招聘到最优秀的人，其实很难，但是找到服务我们气场的人，相对来说简单一些。所以我面试时（过去1年面试了100多人），我很少关注候选人当前完成的一些成果，我更多的会关注候选人在完成任务时的一些思路、心理变化以及扎实的计算机基础，在我看来，这个优秀的人，即使不是这个行业的，相信即使转变也是很快的。扎实基础的人，往往会对技术有敬畏之心，在后续交流中可以较少出现激进、蛮横的行为。
招到合适的人之后，我们要真正让文化体现在工作中，比如老带新，提升大家对文档、jira流程、测试以及编码规范、思路一致性。同时也应该培养大家的沟通方式，比如应尽量的说重点，说关键矛盾，比如我们前面提到的“速度的案例”。还有就是培养大家在遇到困难时的态度，这首当其冲的就是技术负责人，应该作为榜样，千万不要让人觉得“你行你上”，而是要让大家知道，“他都在，肯定没问题”。
关于高效不加班，我也是很推崇的，但是但是不细说了。
写到这，突然卡壳了。只能说，文化这个东西，是体现在日常工作中的一点一滴，很难评判一个好的文化是什么样的。但是如果在合作过程中，经常出现在非技术问题上看法不一致时，那文化一定是有问题的。
团队成员培养
团队培养，我自己喜欢分为三个阶段：融入，成长，独挡一面。
在人数很少的时候，成员的融入，我基本都会从当前项目中，抽出很独立且核心部分，然后提供函数级的实现，这样在他完成函数级编写，并且完成联调之后，，他基本上了解项目的内容、目标以及现状了。后面在人数变多时，我做的其实并不够好，因为自己忙的晕头转向了，但是我后面又想了解决办法：在融入的过程中，应该尽早识别后续有可能成为别人入职导师的人，并告诉他，以后有新人进来时，要把这个做法重复一遍，并且把自己融入过程中的困难，让后续新人避免过去。这个在团队从小到大的过程中特别重要，算是团队文化的一部分。我自己从恒润出来的，深受其益。对于大部分人来说，这个时间不会太长，基本1-2个月就过来了。但是，但是，这个过程，你会发现有些人难以融入，这个时候，我的做法是，即使人数很多的情况下，也需要花时间，帮小伙伴分析融入困难的原因，是因为背景？还是喜好？甚至还是个人问题（人品、技术、动机），如果前两者的话，我们需要站在团队的角度、并且结合个人背景合理的安排；如果是后者的话，我建议根据大团队通俗做法、该劝退、劝退；这样对大家都好，避免内耗。但是，即使分手，我建议还是和平一点、人性一点，能够帮小伙伴争取到的，尽量争取。
成长的过程，每个人的时间长短不一样，这也是一个人是否能够成为独当一面的的关键，对于很多优秀的小伙伴，即使跨行也是能很快的上手的。在小伙伴成长的过程中，我觉得保持客观极其重要的，没有十全十美的人，一定要发现小伙伴的长处，并且利用其长处，团队都4-50人，一定会有人家合适位置的。比如有些人技术牛逼，但是不爱说话，那应该给他有挑战、需要埋头干活的位置；有些人默默不闻，但是对于琐碎、需要耐心的活，无怨无悔，那应该给让小伙伴指定具体的任务给到他；有些人完全具备端到端的能力，测试、开发、bug修复一条龙全部完成，如果遇到这种人，就应该往独当一面的反向培养；而有些人技术整体平均水平，但是很会吆喝、甚至很爱表现，那就应该配置一些默默干活、且没有规划的人跟他一起干活，把这些攒在一起共同完成任务；在人数有点多的时候，不管是奇葩的、优秀的、中庸的人都会遇到，在这个过程中，处理作为技术负责人必须尽早的识别出来，然后给到合适的位置以及工作内容。在我看来，这个过程其实不仅考虑负责人的识人、用人的水平，而且也是经验负责人是否达到了一定技术水平的关键。只有在自己技术水平中上以上，才有能力评估，有些人是真不行，还是只是不爱说话；有些人是真的牛逼，还是会汇报。有一个事实不得不承认，大部分在很长的职业生涯都会在成长过程中，很难成长为独当一面的人，而对于我们这种4-50人团队来说，技术负责人更应该关注的应该是有特点的人：长短明显或者各方面都很不错的人。
在经历过成长后，我们应该选出能够独当一面的人或者在某方面有特长的人，我们后续的关注重点也基本上都是在这些人身上。针对到了这个地步的人，我比较喜欢或者我自己认为正确的做法时，给予足够的空间，帮其背足够多的锅。很多时候，有些人都是遇难则强，在这个时候难免会做的不好，那作为技术负责人，必须有足够的担当的，在我看来，让其没有后顾之忧是最大的支持。我也经常在他们遇到困难时，会说，别怕，决定是我做的，尽管做，我会经常check，做烂了，我也会担着。能够走到这一步的人，多少还是很要强的，他几乎不会让你失望，即使真的做烂了，背锅又如何。但是如果小伙伴做出成果了，一定要在各种场合明确的说，这是哪个小伙伴做的，没必要含糊不清，更不要说自己做的功劳，作为负责人，成果本身就就是你自己共享的。
目标制定和回顾
目标制定尤其考验技术负责人能力，必须意识到，很多底层执行者是没有办法制定自己的中长期目标的，这不是他们能力的问题，而是负责人不能很好的制定清晰、工作量可评估的目标，甚至团队目标也是多变的，那对于底层执行者来说，太难了，自己心中的目标变成了大海中漂浮的灯塔，所以这时候千万不要对小伙伴说，你们先制定，我来整合！整合个毛！
在前面技术章节，我提到了目标制定，负责必须能够清晰的知道：
产品最终要达到的目标以及需要的时间和工作量
为了达到最终目标过程中的小目标，
下一代产品或者新业务需要的事情
团队大部分成员应该关注的前两者，而负责需要着重考虑第三个。坦白来说，目标制定，是一个很虚的事情，但是有一个综合素质的体现，技术、项目管理、人员能力识别，缺一不可。让合适的人、使用正确的技术在合理的时间内完成任务。
与目标制定同样重要的，还有回顾。回顾分两部分来说：个人回顾和团队回顾。
作为负责人首先需要自己回顾，自己定的目标是否达成了，总结做的好，尤其还需要总结做的不好，是否有因为决策失误导致加无用的班。我自己在回顾2023 q2时，就发现了，对原来的目标没有牢记心中，到时团队在一个短期不需要交付的事情长，让自己、团队加了很多没用的班，导致自己灰色q2产生了。在后面的过程中，我基本上都会反复检查自己的目标。而回顾是避免自己作为领航人做出有较大的偏差。
团队回顾，我自己更多的是以正面为主，当然这个可能跟我们本身做的还不错有关系，不过我依然认为即使做的不够好，依然应该以正面回顾为主，因为所有人都希望得到肯定，如果把回顾作为复盘会，那么回顾会已经失去了很多人的兴趣了。团队回顾中也应该做检讨自己做的不足，然后在指出其他小伙伴做还有进步的地方。在面对全员暴露自己的弱点也是拉近距离的方式。
目标制定需要根据组织的方式按季度、按年来规划，以前我在比较轻松氛围的公司时，更多的是按照自己喜好（关键节点、成果以及失误）来展开，在现在公司基本上是按季度制定。而内心其实季度、1年度、2年度都有自己的目标。
奖励和惩罚
绩效是所有人最关心的问题，关于这部分，我的做法是，开诚布公说清楚，团队绩效规则：丑话当先，no surprise。
总的来说，能争取的利益一定帮小伙伴争取，但是很多时候，作为组织一员，能够的金钱激励还是很有限的。所以需要让个人实现个人价值也是对其的一种奖励。
而惩罚的话，其实是我不想谈的，年底有一个小伙伴拿低绩效，我自己是不愿意的和愧疚的，因为我觉我没给到最好的，好在是我领导去聊的。所以我想表达的，当小伙伴做的不够好时，自己是否有责任呢？如果小伙伴真的做的不好，只能走PIP（貌似现在这个词很负面了！！）。
坦白来说，我对管理中的人员管理并不是很擅长的，包括我的管理经验基本都是靠技术影响力在支撑，所以主打的是共情力，共情力在有重大缺陷，那就是对目标认可多不够高，会为团队的不及预期找各种借口。另外，其实底层管理者很难做，两面为难，所以不管对任何人来说，打工人何必为难打工人。
四、个人
本来不想写这个块的，说到个人这块，那肯定就是认为自己做的好，然后从自己身上总结经验，这多少有点吹嘘的成份，但是后面想了下，我自己其实做的也不够好，对个人这块的总结，也算是对自己的鞭策吧。所以谈到个人，除了前面谈到的技术，我想从以下方面来说：情绪以及演讲能力、总结能力以及持续学习方面，三个方面来谈
情绪以及演讲能力
适当做过管理甚至有一定这样角色人（负责一块技术也算）都很能体会到，有管理属性后，情绪是波动最大的一块了。而我自己最近脾气明显变差了，甚至针对应届生，我本应该无条件包容的人，我都会明显的表现出来不耐烦；在讨论技术问题时，我在遇到自认为“傻逼的人”，特别容易情绪化。
上周五的时候，看到我们大领导面对有人“开口既错”时，依然很有耐心的听别人说完了，着实震撼到我了，而我们领导真正的技术大佬。而最近在风马牛年终会上，程前的翻车，感觉看到一样傻逼的自己。所以在上周末时，又狠狠地看了一遍全过程，对着主角之一的周鸿祎三小时公开课又看了一遍，自认为在这块有点进步了。我跟很多人是，我是一个自卑的人，到现在我依然这么认为：自卑的人渴望得到的别人认可，在得不到认可时，总会发疯了想证明自己；但是看了前面的视频，我又觉得自己是一个自卑又有点自大的人。
为什么我讲情绪跟演讲能力放到一起？因为在我看来，管理者很多情绪波动都是由谈话引起的，而谈话的目标又大部分是为了输出某个观点，因此我认为要管理好情绪，就需要很好的演讲技巧来推销自己的观点和理念。因为自己毕竟比较年轻，所以针对情绪控制，我自己也没有很好的办法，所以就侧重演讲绩效了，结合周鸿祎的演讲，我自己总结三点：
不装不端有点2（stay hungry stay foolish）
保持谦卑，我自己很多情绪变化是在应该得到被认可时，却遭受正确、不正确的质疑。这也是人性的弱点，但是后面我学聪明了：我上来就躺地上，我就是一个傻子，别人说的话，或多或少对我会有启发。包着学习的心态，好像情绪一下好转了，就像当初老师质疑学生时，你首先怀疑的是自己。
why? what? how？
很多时候，我都喜欢讲，是怎么做的，再讲这是一个什么，最后再讲为什么。发现效果奇差，大家都是有自己看法的，我为啥要知道你怎么做的？这个时候，大家心里估计就是想着挑刺！！所以我后面换了，先讲为什么，让观众带入我的思考方向，如果不对的，立马反思；然后再将这是一个什么，告诉大家产品形态；最后基于原因和目标，讲为什么是这么做！发现效果奇好。
总结、确认
基于大家的反馈，给出总结，是让参与者感受到参与感，同时也是对大家的结论再做最后确认，提高沟通效率和准确性。
总结能力
第一次意识到总结能力的重要性，是在我们大领导伯牙的交谈中，我发现他总是能够将一大堆话，高度总结成一句话的观点，当时给我的感觉是震撼和反思欲。其实之前自己也会经常总结，但是很少刻意在别人输出观点之后，再进行提炼。
但是在这份工作中，自从被震撼过之后，我基本上担当上了，我们团队各个交流时的“翻译官”，我会把小伙伴互相听不懂的“语言”翻译成大家都能听懂的话，尤其在周会上各个负责人在一起时，有这么一个角色可以让大家都参与进来。同时在这个过程中，我自己也能掌握所有的技术细节或者大致内容，如果没有掌握这些，是没法做出翻译的。对于技术负责人来说，优秀的总结能力，不仅仅是可以将团队成团拉到一起沟通，而且这个过程，不知不觉就掌握了很多技术细节，进一步的降低了团队管理负担，在后面写文档时，也能写出大家都能看懂的文档。
关键，总结能力是可以快速学习的，只要在平时刻意练习，不需要很长时间就能有很显著的变化；而作为技术负责人天生就提供了这样发挥的土壤。
持续学习
这个其实没啥好说的，只有持续学习才能保持技术敏感度，才不会胡说八道，对技术保持敬畏之心。
但是持续学习是有技巧的，按照我的经验，后面学习起来会越来越轻松，直接知识迁移就好了，但是这个的前提是扎实的计算机基础。
五、总结：大部分都是草台班子、
有时候，总是会很恍惚的觉得：我居然在负责车载这么底层、关键的模块，而且还决定着很多技术方向和细节。总是会在这个时候会怀疑，凭啥我可以？？
本来没有信心写这么一篇文章的，但是后面看到团队中，在学生时代、各个工作经历中，都是独挡一面的存在，转而会发现这个世界大部分团队就是草台班子，无非就是我们这些人因为机缘巧合凑到了一起，又有除了赚钱之外的相同目标。因此完成了一个又一个在行业内领先的设计、模块和性能，想到这里又释然了，写一篇文章当做工作笔记了。
最后不得不感慨一下，团队的优秀总是会在每次打绩效中深刻的意识到。
