技术人攻略

引言"外向的人不适宜做分享"，仿佛有这么一个想法根植在所有人的心底。特地对于程序员这个群体，外向的人更加多了。毕竟，不外向谁当程序员呢。我过后抉择程序员这个职业，就是因为不太喜爱和人打交道。 然而通过这些年的实际, 我逐步发现，外向的人如果能充分利用好本人的劣势，也是能够做出相当好的分享的。 本文将从三个局部介绍外向者如何做分享： 我作为外向程序员的三年技术分享经验外向者的劣势与劣势外向者的分享筹备技巧心愿本文能帮忙所有外向者发现本身的劣势，实现由内而外的成长。 外向程序员的三年技术分享经验我的初始数值: 外向 + 小白玩游戏时都心愿有一个好的初始数值，这样打怪练级的时候快一些，然而我偏偏领到一个最差的。 我从小性格内向，相比去冷落的团聚，我更喜爱一个读书学习，因而抉择了程序员的工作。 工作后这仍旧是我的一大故障，和人当面沟通会缓和，因而更加偏向于应用 IM 和文档。也有人说我沟通时不走心，只会说 "嗯"，其实这是因为我嘴巧，长期想不到词。也常被吐槽不清，的确从小没有重视过沟通的造就，始终在应试教育，也没当过学生干部。 除了性情 "缺点" 外，教训方面也是十足的小白。 2020 年校招入职，入职前也没有什么技术分享教训。入职后也始终在做平平无奇的业务需要开发。怎么看都和技术分享毫无相干。 三年技术分享成绩这么一个充斥 "缺点" 的我，保持了 3 年的技术分享，也意外播种了一些后果。 从 2020 年开始，我在 ATA 上的影响力就始终是 BG 第一名：z 然而，其实每年的难度是不一样的。20 年的时候，钉钉简直没有人公布文章， 只有轻易公布几篇 (哪怕品质没多好)，就能成为第一。然而前面开始卷起来了，有数大佬开始发力了，每周仿佛都有人上头条，导致我上半年落后了很多，不过下半年还是追回来了。当初要想在钉钉取得 BG 影响第一，则须要在全阿里排名前十了。从阿里的影响力排名中更能看出我这几年的变动： 可能在卷的时候还放弃第一，倒不是因为我有什么特地的天才，只是因为我早开始两年，比拟有教训而已。现代人往往比拟塌实，给一件事件就心愿做得比他人好，然而作为一个普通人，也没有什么过人之处，凭什么就能做得比他人好呢？在无人问津的时候就提前埋伏在一个畛域，急躁期待机会，或者才是普通人的胜利之道。 原本因为外向的起因，相比讲, 我更善于写，起初我发现了演讲和写作是有密切联系的(下文中会阐释这个密切联系)。进行了一些现场的分享，也取得很好的后果，去年有幸取得了奇点学堂极课大赛亚军。 到明天，我反而庆幸本人是一个 "外向" 的人。正因为施展了 "外向者" 的劣势，才让我造成了独特的格调，看起来和其余内向分享者不那么一样。 外向者的劣势和劣势在很久以前读过一本畅销书，名字叫做 《宁静: 外向性情的竞争力》。书中提到大概有 三分之一 到 二分之一 的人认为本人外向，作者 苏珊 凯恩 动摇地认为，尽管内向的人在社会上更受到欢送，然而外向者也有本人的劣势。尽管当初看来书里的内容偏鸡汤，然而的确给人带来了信念。 作为外向者，对本人的劣势始终是恨得恨之入骨。外向者和人沟通时会十分缓和，当众讲话更是缓和得不得了。而且咱们不善于现场施展，是谈话和演讲中的 "冷场王"，时常艳羡那些内向的人，对于任何话题都能滔滔不绝谈上良久。现场反应力也不太行，大脑时常转不过弯，他人问了一个问题，须要想良久才晓得他在问什么。 外向者的劣势就是想的比做得多，相比没有急躁的内向者，咱们更加三思而行，善于对事件提前准备。 所以提前准备对外向分享者很重要，然而筹备也是有技巧的。我就走了不少弯路，心愿下文的教训可能帮忙到读者。 外向者的分享筹备技巧提前的提前: 工作与生存中的积攒从一张白纸或者空白的屏幕开始写作, 是一个彻头彻尾的误会 --阿明.娜塞生存中多读书与思考，工作中多积攒文档，这置信是大多阿里人都在做的事件，就不多说了。 结构化纲要分享筹备过程中，最重要的一步就是画出整个分享的纲要。 ...

作为一个技术出身的人，必须要在无限的资源下最大化架构流动所带来的商业价值。 我的职责为架构师，所以明天我以架构的视角切入，对于任何一个架构流动而言，架构师的可用资源，包含商业老本、研发老本、工夫老本、迁徙老本等等，都是十分无限的。 但架构流动就是要在这些限度条件之下，将商业价值最大化。 在职业生涯的初期，不太关注商业价值，不晓得咱们的工作最终能为公司带来什么样的商业支出。我刚工作时，也素来没想过我的工资是从哪里来的；公司凭什么会在今天、明年甚至十年后还会给我发工资；更别说思考我为社会发明的价值了。 但随着在职业上的一直成长，我越来越粗浅地意识到，必须要为本人所在的企业发明出可度量的商业价值，这是咱们取得有品质的长期支出的重要前提。 什么是商业模式？什么是商业价值？商业模式（Business model) 就是讲一个企业是以什么样的形式赚钱的，比方电商行业，有自营和平台两种不同的商业模式。 商业价值 (Business value) 呢，就是从现金支出的视角看价值发明的过程。 你每天繁忙的工作，从企业的支出上来说，能够为公司带来什么样的短期和长期现金和其余支出，那么对这部分支出的量化，就是你发明的商业价值。 简略来说，商业价值就是帮忙公司获取商业支出。 那么作为一个技术人员，原本是写代码做架构设计的，那你是怎么为公司发明商业价值的呢？从发明商业价值视角来看，你的代码和设计有三个作用： 实现一个商业模式；晋升一个商业模式的效率；减速一个商业模式的收敛速度。 也就是说，你作为一个程序员，次要通过下面这三个门路为公司赚钱。 举个例子来说，你写代码实现一个电商平台的一部分性能，最终电商平台能够获取交易支出。或者是你实现一个算法，晋升了买家转换率，从而晋升了电商平台这个商业模式的效率。你也能够通过 A/B 试验的平台、数据仿真的性能等等，减速一个公司的商业模式收敛速度。这些都是为公司增加收入的方法，所以公司多赚的这部分钱就能够归因到你，也就是你为公司发明了商业价值。我之前是在一家企业里做软件基础设施的，比如说写云平台、自动化测试平台、财务零碎和数据平台。那么当你通过企业外部用户来间接发明商业价值，通过晋升用户的日常工作效率、产品质量、经营效率、决策品质和商业洞察的品质，这个时候，你同样也为企业发明了商业价值。不过这样的工作更难以量化。 这就是须要咱们破局去思考的中央，我把它分为五个局部来： 了解你所在的企业或团队的商业模式；了解你在本人所处环境中发明的商业价值；保障架构流动的长期商业价值；在架构布局中寻找扩充支出的机会；在架构布局中寻找缩小老本的机会 了解一个企业或团队的商业模式我发现，在一个畛域做了很多年的研发人员、架构师，甚至是团队主管，都不太分明本人开发的模块和所在畛域的商业模式是什么。 这很危险，不晓得商业模式，就没法被动发明商业价值，你的日常工作很可能只是一直被动实现需求。 这时候，你的成长也会是缓而慢的。 一家企业必须要有支出，尽管这个支出不肯定来自当下，但它必定会有一个可继续的商业模式。 也就是从长期来看，有稳固且衰弱的支出，以及可控的老本，并且最终要做到盈利。 这个商业模式，就是咱们被动发明商业价值的突破口。 哪怕大家是在为同一家公司工作，但如果各自所在的畛域不同，那么为公司发明商业价值的办法也有所不同。 对于一个技术人而言，你必须深刻了解本人所在公司和团队的商业模式，并且想尽一切办法去最大化这个商业模式的胜利概率。这样你能力通过工作为公司发明商业价值，同时也为你本人发明长期的商业价值。 还是那个简略的情理，咱们的工资和各种支出，都来自于公司的商业支出和融资。 当然，并非每一家公司的商业模式都是相对清晰和稳固的。大多数公司往往处在商业模式的探索期，有的团队连本人的 KPI 是什么都不晓得。但无论如何，至多要了解你的团队为什么存在，你的工资收入从哪里来。 有句话叫做“良禽择木而栖”，就是说你要抉择可能最大化本身成长的工作环境。 那么接下来，我就通过一个例子教你怎么从发明商业价值的视角看一个部门， 帮你“择木”。 了解本人所处的工作环境在一个企业里，从 CEO 到一线员工，大多数人的行为和决策都是基于资金的流转逻辑而来的。 对此，咱们的老祖宗有一句精辟的总结：“有钱能使鬼推磨”。 一位敌人曾给我讲过这么一个有意思的景象。在一家大企业里，只有是公司鼎力推动的我的项目，没有一个存活的。反倒是不怎么受公司高层待见的，由具备守业心态的员工本人发动的我的项目，最初都很胜利。 在我认真思考，也近距离察看了这个过程后，我认为本人了解了这种景象的实质。咱们还是通过一个实在的案例来阐明。 一个大企业的独立核算部门，之前始终放弃着高增长，也做到了盈利。 但公司高层不称心当初的下滑增速，认为团队的人才形成、营销办法、经营能力有问题。 而且认为部门的管理层自以为是，给的倡议也不怎么听。于是公司高层就更换了部门的管理层。 新管理层到岗后，依照高层的指导，把之前的精细化经营形式，换成了高举高打的靠营销和大量模式摸索投入来获取高增长的模式。 很快，该部门的营销和经营老本一飞冲天，增速却变慢了。尽管业绩一塌糊涂，不过团队高低反倒天天颂扬公司高层的英明决策。好像本人受领导器重了，日子也就越来越有盼头了。 尝试了两年下来，统计指标越来越玄虚，越来越难看懂，增速也一泻千里。 增速为什么会这样呢？新管理层是高层指派的，按理说单方有相对的信赖，应该是有一说一啊。然而认真想一想，在新的环境下，公司高层的任何发言都变成了圣旨，别说是抗旨不遵，哪怕稍稍让领导感觉你不足信念和激情的表情都不会有。 比照之下，反倒是部门前治理团队始终保持“客户第一”的准则和市场规律，对公司高层的不合理倡议会据理力争。 为什么会有这种截然不同的行为呢？答案很简略：部门的资金来源逆向抉择了人才及其行为。 部门重组后，老本一下子收缩了很多倍，齐全没有方法养活本人。这时整个部门都要靠公司高层调拨的估算来求生存。公司高层抉择了我行我素的乖乖虎，那么这个乖乖虎就会以他最善于的形式来获取部门赖以生存的支出，也就是公司的拨款。所以他们只有一条路，就是无时无刻索取高层的欢心。 然而一个以客户为导向的团队，他们的首要目标不是服从下属的声音，而是去聆听客户的声音，从客户的需要中寻找本人可能发明商业价值的中央。所以这样的团队，绝不会靠公司的拨款过日子，他们的支出必须源自为客户发明的实在的商业价值。 这就是为什么越是受公司鼎力资助的我的项目就越难存活的情理。 咱们钻研一家公司的商业模式，就是心愿你认真了解本人所处的工作环境. 如果你活在一个靠公司拨款而生存的部门，那么你学习到的能力是无限的，因为你们部门从上到下都不是在求生，也不是为客户发明价值，所以你也学不到真正的生存技能。 或者短期内，你作为一个一线技术人员能够不用担心。然而你越资深，待的工夫越长，你对公司的依赖性就越大，那么你的危险也会越大。因为公司遇到困难必然会膨胀资金，公司真的到了生死存亡的时刻，就只能依附自力更生的部门了。想想看，这种靠拨款能力生存的部门，还会有保留价值吗？ 总结来说，对于一个业务部门而言，存在不肯定正当，只有提供稳固商业价值的存在才是正当的。 每个人都要有本人的商业模式咱们方才讲了，你应该对本人所处环境的商业模式有一个粗浅的了解，而且你最好能在一个可继续的商业模式下工作。 当初我还要给你讲另一个理念，就是每个人都要有本人的商业模式。意思是说，你必须在工作环境中找到发明价值的形式，这样能力保障本人始终被须要，也能保障将来的支出。 具体怎么做呢？那就是你要为公司、部门或团队提供可量化的增量价值。 这外面有两个要害元素。第一是增量价值，就是你通过工作所发明的价值，是在社会提供的均匀价值之上的。 举个例子。2010 年之前，如果你是一个做微服务框架的高手，那你的增量价值就十分大，一个人能顶十个甚至一百个研发。因为那时候开源的微服务框架还不够成熟。但到了明天，如果你还是单兵作战，善于写微服务框架，那跟开源的 Spring Framework 相比，你提供的增量价值可能就是一个正数了。因为团队剩下的同学还要花工夫来学习、应用和保护你写的框架，公司也要为这些同学付出工资老本。 ...

作为一名程序员，每当跟新的朋友介绍我的职业的时候，别人都会问：『你们程序员是不是一个个都是情商低的钢铁直男啊？』，每次回答这种问题的时候我都很无奈啊！ 因为本身是一名IT从业者，所以身边的朋友同事也确实大部分都是搞IT的，但如果说搞IT的都是死宅臭屌丝，那我是玩玩不敢认同的。就我身边的朋友同事来说，都还是热爱生活，亲近大自然的那种，至少你是没办法将社会对程序员的固有映像用到他们身上的。 那像外接人士认为的那种程序员是否真的存在呢？当然存在！最明显的就是体现在情商低这一点，对于情商低这个问题我其实认为是跟我们从事的工作有关的。在程序的世界里，是没有情感的，任何东西都是以数据来表示，黑就是黑，白就是白，不会存在灰这种概念。任何事情过程都是存在因果关系的，必然是先有因后面才会有果(即if...else...),所以当女孩子问这种程序员"你为什么喜欢我？"的时候，他久久没有回复你的原因并不是因为他不喜欢你了，而是他可能正在认真的思考这个逻辑问题，寻求一个最优解回答你！ 但即使如此，我认为情商低也是氛围两类的，一类绿色无公害，一类有害不自知。 绿色无公害的这种多半是可爱的。他们往往是在自己的领域独领风骚，挥斥方遒；但是一到生活中，跟人打起交道来，就变成了一个懵懵懂懂，不知所措的老实人，特别是在女孩子面前。这种给人的感觉是不坏的，往往还存在一种反差萌，本质是好的。 有害不自知的这种便是我接下来要讲的。 上图是我加入的一个前端交流群的日常小白向所谓大神请教的聊天记录； 相信种种事情在技术圈子里面是普遍存在的，刚入门的小白向他们心中的大神(可能也就是比别人先入门而已)请教一些遇到的问题，由于是刚入门，对于编码规范啊，以及一些提问的技巧都是有欠缺的。这时候所谓的大神上来就是一顿灵魂质问，关键是问的问题还对人家的问题毫无半点帮助；往往这些质问中体现出来的潜台词都是"垃圾代码！就你这样还写什么代码哦？你看我多牛逼，一眼就看出你这么多问题！"，然后这时候与这种大神类似的大神就过来一阵帮腔，直到折辱凌辱到小白无话可说，不敢发言，他们才像是打了胜仗的将军一样偃旗息鼓。 对于此类大神，在下着实不敢苟同！ 俗话说"满罐水不荡，半罐水起波浪"，进入技术圈也有三四年的时间，记得刚开始遇到问题去向别人请教的时候，也是喜欢去各种技术群里面问，慢慢发现多半是自取其辱或者无人回应的情况(当然偶尔也会遇见一些好心人细心直到，甚至私聊指导，再次感谢这些帮助过我的人)，后来到网上，各种技术论坛，各种正真的大神的论坛或者博客寻求帮助(要讲究提问技巧，人家愿意帮你最好，尽量给别人添麻烦)，往往这种方式更能解决问题，并且人家要么耐心指导你，要么直接不回你，但至少不会凌辱你一番只收把你晾在那儿。 以上，在下义愤填膺所言； 本来大家一起建立一个社群，相互交流技术，本着是互相尊重，共取互赢的态度；即使是技术新手，提出来一些不是神入眼的问题，作为技术上的长辈，我们是不是可以用更加温和善良的方式来指正他们呢？即使最终你也没有帮助人家解决问题，但至少你没有打击人家，你还是个好人；即使你不是一个乐于助人的人，你便是不回答，不掺和，你也不是一个坏人；可是你偏偏要跳出来，一顿言语秀优越，秀你懂的多，秀完你还啥也不告诉人家，如此将自己的优越建立在摧毁别人的自尊心之上，可以说你是个渣子！ 标题是如何让自己成为不被讨厌的程序员，但说到这里，其实应该是如何让自己成为一个不被讨厌的人，各行各样，各国各地想来都是如此。 最后，对这些人说，你可以不爱我，但请你不要伤害，生而为人，万请善良！

工作了四五年，感觉技术上依旧长进不大摘要： 技术成长需要系统化地积累。原文：工作了四五年，感觉技术上依旧长进不大公众号：歪脖贰点零Fundebug经授权转载，版权归原作者所有。技术精进是一个持续增长的过程，而非一朝一夕，即便你在最短时间的掌握了大量的技术点，如何不及时应用到实际问题中，也很容易被遗忘。有朋友会说，我平时也挺努力的，一直不间断的学习，并持续将近 3、4、5 年的时间，依旧精进不大，这是为什么？现在数一数掌握的技术有哪些？一个简单的方式就是把自己的简历找出来，技能掌握那一栏，都填了些什么就是自认掌握的技术点。学习是一个慢性的温水煮青蛙的过程，你认为自己很努力了，其实都是零零散散的、跨度很大、不成体系的知识点，还有串联成一条线，更不能称之为一个技术面。从另外一个角度看，学习其实可以像蚂蚁搬家一样，一点一滴去啃，日积月累，功不唐捐。技术书还是有必要阅读的，网络上散落的碎片资料，解决一两个技术难题还可以，但并不能替代书籍中成体系的章节。比如你要专攻一个技术体系，将涉及到的技术点一一列举出来，然后再针对某一个点就延伸下去，拉个思维脑图。当下比较常用的技术点，其实就那么多，比如分布式开发、缓存、消队列、多线程、高可用、非结构化存储等等，每周、每月、每季度做好计划，慢慢的去消化学习。最后把这些技术由点成线再成面系统整理出来，几年下来，相信常用的一些技术点都能掌握，精进之路就蕴藏在平常的有计划有目的学习中。可结合《什么时机学习一项技术最高效》《学习新技术时你应当掌握的『最少必要知识』》两篇文章阅读。日子是忙碌的，也有时候看似很忙碌，确实并没有掌握到实质性的东西，左晃右摆，来来回回。一晃一个月、半年、一年过去了回头再仔细看，确实是没有掌握住技术，都是些老技术点在业务中反复应用而已，这是技术能力与业务能力相互精进循环往复的过程。磕瓜子之所有爽，是因为能及时的得到反馈：一秒磕完，下秒吃到嘴里，瞬间感知到那个香啊！但学习不会，长期的学习后，甚至看不到什么明显的效果。这是因为学习的反馈闭环比较长，要想卓有成效，就要缩短反馈闭环。一定的输入后一定要跟随一定的输出，如写文章，或者将自己掌握的东西讲解给另外的人听，形成自反馈，在写或讲解的过程中加深理解。长期坚持下来，就能看到一个显性的增长。如果只有输入，没有输出，就无法检验输入的效果如何。做完一个项目之后去回顾这个项目，除个别角色外，如架构师、设计师外，很少有人能全局参与，大部分是只参与了其中某一些功能。想对项目有个全面深刻的掌握，就要直观的描述整个项目的全貌，整体业务全貌和技术应用全貌，即便自己没有参与，可以自学或求教同事慢慢去梳理整个项目的全貌，后期再遇到类似项目就可以提供一些比较直接的解决方案。别成天忙碌的忘记了自己的成长，有句话是这么说的：成天忙着工作的人，哪有功夫赚钱。2019 年 04 月 08 日 21:17往期推荐一线人员忙着学习技术，二线人员忙着技术变现团队管理到底在管什么？软技能：代码之外的生存指南与年龄相匹配的经验与阅历突破自己的技术思维我只想安心的搞技术，不想做管理程序员之间的距离是怎么拉开的学习新技术时你应当掌握的『最少必要知识』代码、功能、系统、产品、生态30 多岁挨踢人要转行的焦虑，是真的吗关于FundebugFundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了10亿+错误事件，付费客户有Google、360、金山软件、百姓网等众多品牌企业。欢迎大家免费试用！

技术布道师的日常对于程序员来说，摆在面前的职业道路选择很多，不仅限于向管理岗位或技术专家的方向发展。近年来，技术布道师也成为了开发者们的新选择，很多经验老道的程序员都或多或少地承担起了布道师的工作。技术布道师主要指既拥有丰富项目经验，同时也有极强沟通技巧的人。他们可能是：大厂技术专家、知名博主/大 V、技术会议组织者甚至是艺术家，不同背景的人都能在这个职位上取得成功。技术布道师在国内是一个新兴职位，本文通过与 15 位国外技术布道师的访谈，介绍他们的工作日常，揭开技术布道师这一职位的神秘面纱。Microsoft Azure 技术布道师虚拟形象（小浣熊干脆面）对技术布道师最主要的误解@Alex Lakatos就职于Nexmo，JavaScript 布道师人们总是觉得我们唯一的工作就是到世界各地参加会议+吃喝玩乐。但是很少有人能理解对于我们来说，不同的城市仅仅意味着不同的机场、酒店和会场而已。台上一分钟，台下十年功，每次演讲都需要花大量的时间来进行准备，而且经常出差还需要适应在飞机、火车这类交通工具上工作——我到现在都还没学会在汽车上办公: )@Don Goodman-Wilson就职于 GitHub 的 EMEA 布道师就布道师这个职业来说，其实对技术水平的要求没有那么苛刻，相对的，与人沟通的技巧才是最重要的。我认为，只要你的技术水平足以让你应对各类可能会被问到的问题就行了。大家总认为成为一个布道师，意味着要在技术圈作为摇滚巨星出道才行，我觉得这完全是误解。我最喜欢招有教师经验的人来做这份工作。在我看来，一个有高中教师经验的人会比一个资深的程序员更适合，因为我就是教师出身，不过同时还有超过 20 年的编程经验而已。布道师的日常工作@Ihor DvoretskyiCloud Native Computing Foundation (CNCF)，技术布道师CNCF 是一个非盈利、以开源社区为中心的组织，拥有现在世界上增长速度最快的开源项目，比如：Kubernetes, Prometheus, Envoy, Helm 等。在这样的背景下，我的主要工作是为社区管理项目和进行技术布道。布道师方面，我主要是通过演讲和博客的形式帮助宣传 CNCF 的项目（主要为 Kubernetes 和 Helm）同时也会为 CNCF 生态中的其他项目站台。在这之外，CNCF 有很多社区自发组织的技术小馆、技术大使等项目，再者 CNCF 也是 Google 的 Summer of Code 项目的合作伙伴，我也会协助执行这些项目。对于我这种对开源项目有极大热情的人来说，能在一个以开源社区为中心的组织当一名技术布道师，是很幸福的一份工作。@Amara Grahan就职于 IBM 的技术布道师我会写很多技术相关的内容（教程、博客、经验分享等），同时也会牵头一些 workshop 和讲座。个别情况下我还会参加一些售前会议，跟研发团队一起为客户展示如何最高效地使用 IBM Cloud/ Watson API 的服务。这些工作的目的是收集外部各个社区的声音，然后归纳整理反馈给我们的研发团队，来确保现在的研发方向是正确的。@David Needham就职于 Pantheon 的技术布道师对于我来说，我的大部分精力是放在培训和教育上的，同时我也是 Drupal 和 WordPress 社区的贡献者。我觉得我们推出的项目，比如 Pantheon for Trainers（免费的教育培训）和 Getting Started with Drupal 8（线上和线下结合的课程），对于关注这个领域的工程师来说都非常有意义。Pantheon 对开发者关系的要求就是要能真正理解社区的需求，为了做到这点，我们秉持着从群众中来到群众中去的原则，会志愿参加各式编程夏令营和会议，除了做命题演讲之外，有时我们也会做一般性的支持工作，比如会场清理等等。对我来说，技术布道师是一份完美的工作。我能分享我学到的东西，力所能及地为社区做出贡献，然后还能在第一时间感受到这些努力带来的变化。什么样的人能做好这份工作呢？@Jlsh DzielakDeveloperMode 联合创始人，前 Algolia 开发者关系负责人一个享受同时使用左脑和右脑的人。技术布道师其实是代码和写代码的人之间的桥梁，所以对于他们来说必须要能很好地理解桥的两头。我见过的优秀布道师都具有一种与生俱来的、乐于助人的意识，即使很多时候解决的问题与自家公司的产品无关；而且很多布道师其实都在凭一己之力开拓新的领域，所以我认为拥有企业家精神和无限的求知欲是成为优秀布道师的两个重要品质。@Zan Markan就职于 Pusher，技术布道师拥有主观能动性的工程师，同时还要能热爱社区这种形式和与人打交道。我觉得技术布道师一般都是喜欢分享知识，帮助其他人进阶的人。当然不同公司、组织甚至团队对于技术布道师的角色和职责都有不同的定义，提前确保个人对职位的理解和发展方向是否契合公司的需要，也是成功的关键。@Nicolas Grenié就职于 Typeform，技术布道师在技术布道师这个职位刚刚出现的时候，很多公司主要是在找一个什么都能做的人。随着近两年的发展，这个职位逐渐有了不同的细分模块，有的人可能更专注于社区方向，有的人可能在内容产出方面更加专业，也有人专注于写代码。在我看来作为技术布道师最重要的是要有好奇心，要能聆听用户的故事，乐于认识新朋友同时还要喜欢尝试新事物。谦虚也是布道师应有的品质，还要能站在其他人的角度考虑问题。并不是说外向的人才能成为好的技术布道师，喜欢安静产出内容的人同样能把这件事做好，甚至我觉得我们中的大部分人都是内向型的。你是如何成为一名布道师的，对正在观望这个职位的朋友的建议？@David G. Simmons就职于 InfluxData，资深技术布道师大概 25 年前我就成为了一名技术布道师，主要是因为做一名全职的工程师比较无聊，所以我想出去多跟人交流。对于那些希望成为布道师的人来说，我觉得要多多练习与人沟通的技巧，用“说人话”的方式让对方理解你做的事情。不要因为麻烦就回避交流，应该去尝试用更有趣的方式来解释问题，同时要学会聆听，花时间去了解其他工程师们在说什么。@Lorna Mitchell就职于 Nexmo，资深技术布道师作为一名软件工程师，我很喜欢没事儿写写博客，同时我还会去各种大会做演讲，还写了几本书。成为一名布道师仅仅是因为这个职位能支持我做这些我喜欢做的事情！对于所有工程师来说，能够走出去，融入社区都是很重要的，而且也是有回报的。@Tim Falls就职于 DigitalOcean，开发者关系负责人我当布道师的经历还是挺意外的。最开始我在 SendGrid 当工程师，当时我在 Twilio 的朋友 John Sheehan 刚好准备推出布道师项目，跟他聊天的过程中我意识到我们两家公司的商业目标是一致的，都是用更好的服务来吸引开发者群体，于是一拍即合，我们开始合作发展双方的布道师项目，直到取得了如今的成果。建议：如果你对布道师或者开发者关系感兴趣，那么最简单的方式就是立刻开始尝试。千里之行始于足下，从现在开始主动为公司的产品代言，去参与到那些你感兴趣的技术社区中，产出有价值的内容，逐步开始在开发者群体中塑造个人品牌。如果现在你所在的不是技术性公司，没有产品去布道，你也可以在市面上选一款感兴趣的产品，然后融入相关的技术社区，和社区中的成员互动，写写博客，做相关的主题演讲。一分耕耘一分收获，你终会获得相应的回报。@Shawn swyx Wang就职于 Netlify，技术布道师/用户体验工程师2017 年我定下了一个新年目标，全力专注于前端开发并逐步尝试对社区做出贡献。我把之前所用到的编程技巧和知识都重新打包成了一系列博客文章、cheatsheets 和一些主题演讲，这些内容帮我在前端技术圈建立了一些影响力，也渐渐开始接触到更多圈内人。对于我来说，这些工作让我能在大厂里拧螺丝钉之余，增长见识，搭建人脉和塑造个人品牌，同时还能回馈社区。成为布道师本来只是我的一个职业发展经历，结果当我开始之后，发现原来很多老板也很需要有人说”人话“，给他们展示 demo 和站在用户的角度理解问题。@Chloe Condon就职于微软，技术布道师我是表演系毕业的，最开始白天在一家科技公司做行政，晚上和周末偶尔会接一些音乐剧的角色，后来慢慢开始接触代码。机缘巧合下参加了一个女性程序员专属的训练营活动叫 Hackbright，成为布道师的契机发生在活动最后，在面对潜在雇主展示成果时，虽然参加活动的很多女性都有很强的技术背景，但她们大多都不善于做主题演讲。当我发现技术布道师也可以作为职业的时候，就觉得这应该是我的菜。你可能不太相信，但是真的只有部分人可以玩转技术圈的内容创作/演讲/教学/没事儿写写微博/理解开发者等等事务。我的舞台经验成为我的秘密武器，让我在会议、市场活动和人际交往中能游刃有余。我把布道师的每一项工作都当作是一次演出。我觉得有时大家会忘记程序员也是人，也有感情需求，也喜欢幽默、喜欢笑，我能给出的建议就是要 think out of the box。对于我来说，我会组织带有主题的活动，在活动上提供有趣的食物、带大家唱歌并穿上巨大的松鼠布偶服。对比传统的大家都严肃的坐在一起，吃着冷掉的披萨的活动，这种推陈出新的活动可能更容易让人接受。所以要活用你的背景和经验去思考如何更好的布道。结语在国内，技术布道师才刚刚起步，但无疑会成为技术型公司的重要职位之一，来帮助社区的搭建和活跃，完善公司的品牌形象。同时成为一名布道师的过程也是个人品牌搭建的过程，无论对于公司还是个人来说，都能增加重要的无形资产。期待国内能涌现出越来越多的优秀技术布道师！原文链接：https://www.keyvalues.com/blog/what-exactly-do-developer-advocates-do ...

摘要： 不要沉迷于技术。原文：突破自己的技术思维公众号：歪脖贰点零Fundebug经授权转载，版权归原作者所有。想了很久，迟迟没形成文章，但又总感觉少点什么，经过跟朋友交流、阅读、小范围讨论等等，思路开阔不少，这才把这两年来心得体会写下分享出来。什么是技术思维，我个人的理解是行事大多从技术出发看问题或是仅专注技术提升，忽视其它事物的发展的比较固定的思考问题的方式。举几个最平易近人的例子：在需求评审会上，有多少人在讨论技术实现细节问题？在对外合作交流会上，有多少人在说一些对方听起来比较晦涩的技术名词？有些场景技术实现相当繁琐，ROI不成比例，很多人陷入其中。但可以通过简单的制度约束，达成目标。将所有的精力花在技术语言、框架学习上，以为掌握了这些就可以独步天下，赢得未来，反而跟人打交道上火候不足？可以花很多时间来解决一个难题，但被追求心仪的姑娘拒绝过一次后反而不能越挫越勇？跟自己收入差不多的朋友，已经源源不断的被动收入，自己还在月光？一个很简单的技术，有人能将其应用在生活中获得不错的收益，而放在自己里只能等到合适的项目才能用的上，拿一份工资？……长期受技术思维影响的人在往上走的过程中，很容易碰到天花板，遇到职业发展的瓶颈，只能在技术圈子里打转，跳不出来。技术思维就像往一个瓶子里装水，提升技能只是为了将这个瓶子装的更满，忽略了瓶子外还有更广阔的空间。将一个瓶子丢到湖中，如何才能更快的装满水呢？不是将瓶口朝上，一副死撑到底的样子，而是适当倾斜瓶口，融入到湖水中才能更快的装进去水。湖水就是外面的世界，瓶子就是我们自己，瓶中空间就是自己的容量。手里拿着锤子，看什么都像钉子。就像自己只掌握了Java一种语言，不管做什么产品都只考虑Java，很明显不是明智之举。这是技术语言的局限性，将适合的技术应用到的合适的项目场景中解决具体的问题才能发挥最大的优势，也能降低成本，加快研发速度。技术思维更多的体现在对技术的专注，但对其他的事物缺乏关注。在创业这件事上，不少技术人表现的比较突出，因为创业要求个人方方面面的技能，如营销、招聘、管理、财务、市场、融资等等，虽然合伙人制度可以弥补一部分欠缺，但如果自身能掌握更多的技能，再结合技术，才能发挥更大的作用，不然就会对合伙人形成依赖，缺失自已对事情的预判。不幸的是不少小伙伴醉心于产品研发，一心要提供完美的软件给用户，结果也显而易见：推向市场，却反馈平平（对市场痛点把握不足）；在市场反馈不佳时，不能及时调转方向，有时候坚守初心也很危险；等要推向市场时，发现研研发经费耗尽了公司储备，没钱做营销（过分专注技术而忽视产品的推广）。不是人人都可以学Jobs来创造需求。我们也会经常看到懂技术商业思维又比较活跃的朋友，能轻松的将技术变现，姑且不论变现程度有多高。比如做付费社群、软件开源高级服务付费、提供职业规划指导、写专栏、做收费视频课程、带徒弟等等，这已经将技术自身的价值提高了一个台阶，提高了反脆弱性。参考之前的一篇文章《技术人要懂商业》。在工作中技术依附于业务、又反哺于业务来产生价值，同时事物管理又将组织、流程很好的协作起来保证价值的产出。技术在不同的阶段具有的价值也是不一样的，所以就要求我们适当的评判技术价值，跳出技术思维局限，将眼光着眼于整个产品的生命周期中，提高技术外的技能才能将产品做的更好。对于个人，技术迭代无穷尽，在追逐技术升级的道路上肯定是要落伍的，只有一小部分人能潜心修炼成为技术专家，作为大部分人可以将技术作为工具应用到实际的生活场景中，解决身边实际的问题，不能落地，再牛的技术都是空中楼阁。人的成长，无非还是认知、心智的成长，眼界提高了，关注的东西自然会发生变化，正确对待技术，同时扩展技术外的视野，警惕技术陷阱，才能更好的利用技术。我刚上路，转变势在必行。关于FundebugFundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了6亿+错误事件，得到了Google、360、金山软件等众多知名用户的认可。欢迎免费试用！

背景工程师主要面对的是技术挑战，更关注技术层面的目标。研发团队的管理者则会把实现项目成果和业务需求作为核心目标。实际项目中，研发团队所需资源（比如物理机器、内存、硬盘、网络带宽等）的成本，很容易被忽略，或者在很晚才考虑。在一般情况下，如果要满足更多的技术指标如并发量和复杂度等，或者满足峰值业务的压力，最直接有效的方法就是投入更多的资源。然而，从全局来看，如果资源成本缺乏优化，最终会出现如下图所示的“边际效用递减”现象——技术能力的提升和资源的增幅并不匹配，甚至资源的膨胀速度会超过技术能力的提升，从而使技术项目本身的ROI大打折扣。从笔者十余年的工作经验来看，资源成本优化宜早不宜迟。很多管理者在业务发展的较前期阶段，可能并没有意识到资源成本膨胀所带来的压力。等到业务到了一定规模，拿到机器账单的时候，惊呼“机器怎么这么费钱”，再想立即降低成本，可能已经错过了最佳时机，因为技术本身是一个相对长期的改造过程。所以，正在阅读此文的读者，假如你已经感觉到了成本膨胀的压力，或者正在做成本控制相关的工作，恭喜，这是幸福的烦恼，贵公司的业务体量应该已经达到一定规模，同时也说明你的管理意识可能已经超前于业务发展了（握手）。本文我们将分享美团到餐研发团队的资源成本优化实践。实践像美团这种体量的公司，资源的提供方包括多个团队，除了到店餐饮研发团队自用的资源外，还有多个兄弟团队也提供了资源支持或者联合共建，比如SRE、大数据团队、风控团队、广告团队等等。在每个月拿到成本账单之后，我们都需要抽丝剥茧，对每一项进行拆解，才能制定对应的解决策略，具体流程如下图所示。1. 确定方法论“凡事预则立，不预则废”。在做一件事之前，要充分评估整个工作完整生命周期的要素，并进行整体工作框架的设计，一个科学的方法论是十分有必要的。成本优化遵循的是一个行业内成熟的P（Plan）D（Do）C（Check）A（Act）方法论，在每个阶段都又有对应的二次迭代和微循环。具体方法论如下：在Plan或Standard阶段要做的事：建立意识->确定目标->分析现状->确定评价指标。在Do执行阶段要做的事：分解原子项目->确定方案->落实到人->优化原子指标。在Check检查阶段要做的事：规定动作检查->行动结果评估->系统问题定位->修正标准动作。在Act优化处理阶段要做的事：定期复盘->形成报告->迭代认知->升级方法论->下阶段目标。2. 计划规划阶段（Plan&Standard）在这个阶段的核心目标是：用2-3个指标来衡量自己的工作。很多工作之所以最后失败，很多时候是相关人员根本没有办法用具体可衡量的指标来衡量自己的工作，这样对于工作结果，只能有一个“定性”的认识（比如很好，很不错，不好，较差），而无法做到“定量”。对于研发人员来讲，不能定量的结果是不够科学的，具体如何确定指标，或者确定哪些指标作为工作目标，其实也是一门学问（有机会另外发文章讨论）。这个阶段的几个建议步骤为：建立意识。这个是团队Leader的首要责任，要让团队成员明白自己在资源上花了多少钱，成本控制是不是一件真正有意义和价值的事，要做到大家认知一致。虽然见到过一些团队在提倡成本控制，但是落实到具体行动时，却流于形式或者无从下手，最后只能停留在口头上，并没有产生实际的效果。确定目标。这个过程相对宏观，也可以认为是“定性”的阶段。在这个阶段要明确的就是，在成本控制这件事上，后续动作要解决的问题是什么？比如有些团队是总体成本偏高，但有些团队总成本并不高，而是应该增加成本，有些团队是非核心服务消耗的成本偏高，这些目标都需要经过团队成员讨论后得到一致的结果。在后续阶段的迭代中，也可以进行不断地修正。就像“客户永远不知道自己的需求”一样，很多人是不清楚自己的目标的，可以使用SMART原则来明确目标。分析现状。对成本这件事，罗列相关的数据，尽可能多地帮助自己做判断。自己团队在成本优化这件事上，处在哪一个阶段，哪些工作有可能被进一步优化，在此阶段要明确出来。确定评价指标。对于不同的专业序列，甚至对于同一专业序列的不同人员，大家对于成本的评价指标都不一样。这个阶段要做到最终的收敛，把团队未来成本优化的结果，用明确的数据表示出来。具体在到餐研发团队，我们确认了2个优化的核心指标：总成本、总订单成本。后续大家所有努力的目标，如果跟这两个指标没有关系或者弱相关，都可以忽略。本阶段最大的经验是“知易行难”，虽然拍脑袋想出来一两个方向和目标很容易，但是最后用数据论证现状时，如何判断自己这个指标是“优秀”、“良好”还是“不及格”？对标的团队是谁？为什么对标的对象是TA？都是需要从人员规模、业务阶段、业务量、行业特点等方面考虑仔细，也需要想清楚，其工作量甚至不比实际干活阶段小。3. 执行阶段（Do）3.1 建立思考流程在执行阶段的流程是：分解原子项目->确定方案->落实到人->优化原子指标。在这里包括两个核心要素：1）把核心指标相关的工作向下一层分解；2）在下一层，找到具体的人来执行，这个人要具备将自己负责的指标继续分解到更细的能力，类似于我们说的树状结构。这样层层地分解下去，每一层的叶子节点都可以找到对应的负责人。这种“总分”结构，在一本经典教程《金字塔原理》中也有详细的阐述。分解原子项目。在本阶段要建立一个完全细化的分级结构，用金字塔原理中的"MECE不重不漏"原则，将工作内容分解到最细的可控粒度。至于按哪个维度进行拆分，不同的团队或者业务可能会有不同的原则，比如有些团队直接按子团队进行拆分，有些团队按业务进行拆分，有些团队按流程进行拆分。从较多团队通用的角度，成本控制这件事，可以简单的将指标分解到二级指标，包括“自身使用的成本”和“被分摊的成本”。其中，“自身使用的成本”是指，为了满足自己业务的需要，由本技术团队申请或者使用资源产生的成本；“被分摊的成本”是指，由于根据某种计算逻辑，间接使用了其他团队的资源，为其他技术团队承担一部分成本费用，比如常见的资源包括公司其他团队开发的广告、投放、风控、安全等系统。如果可以分拆到具体的系统，则每个系统又可以继续向下拆分到更细粒度的构成项目，每个节点都是一个小的“总分”结构，按这个逻辑继续向下分解，可以分为“可落地的最细粒度的成本”和“可落地的最细粒度的分摊成本”。再根据开篇描述的方法，确定每个原子的评价指标，无法量化的项目都是“耍流氓”。这样就形成了一个更完整的金字塔结构，如下图所示：确定方案。根据上面的金字塔结构，每个原子指标，都需要专业的同学来评价分析，确定如何进行优化。比如，系统主机的成本，主要集中在虚拟机+存储这样的资源上，衡量的指标可以确定为“资源利用率”和“单订单成本”，为了解决“资源利用率”这个原子指标，就需要考虑目前的空闲机器是否可以下线，在线的服务是否可以优化或者合并；为了解决“单订单成本”这个指标，可以考虑分析下系统架构，跟核心流程处理有关的服务是否可以更加高效或者抽象出来成为服务中台，这样就可以释放一些"烟囱式"的建设资源，使得核心处理能力更加集中、高效。类似这样将所有的解决方案整合起来，就形成了最后的解决方案。落实到人。有了方案之后，一定要确定唯一的Owner（主R），根据经验，主R只有一个会比较好，否则会造成“责”、“权”、“利”分割不清。在这个过程中，也是培养团队技术能力和架构能力的好机会。优化指标。不同的方案，实施的周期和代价不同，各个主R深入到不同专业后，会对目前的资源指标有分析和反馈，有可能理论上所有的指标都需要优化，也有可能一些指标已经很好了，这时候要甄别出来哪些资源指标的实施“杠杆率”比较高，建议应用80/20原则进行分析，即某些指标投入20%的资源和精力可以解决最后80%的核心问题，保证投入适合的工作量带来较高的产出。对于没有解决方案的资源或者实施难度过大的资源，建议果断放弃或者搁置。3.2 实践分析框架在具体实践中，我们可以把以上的过程，再次用一个金字塔结构来表述，如下图所示：建立了以上的结构，就可以根据各个专业的不同，对各自的指标进行优化了，如果最细一级的指标被成功优化之后，最上层的指标一定会有下降。因为上述指标都有其各自深层次的业务、技术，甚至是财务上的逻辑，故在此把一些需要关注的概念再赘述一下.很多公司每个技术团队的机器成本，在财务上叫做“网站运维成本”（网站？听起来还像PC时代的概念对不对），从顶层可以分为两类构成因素，就是“自己产生的成本”（自己用的）和“被分摊的成本”（别人替你用的）两大类。跟自己有关的继续向下钻取，可以分为交易相关的资源成本（跟业务流程相关的）以及跟分析有关的大数据成本（分析、算法、决策相关）。3.2.1 业务主机成本大部分业务系统的团队，使用的资源成本都包含在这个部分，比如商户研发团队、订单系统研发团队、前端研发团队、供应链研发团队、营销系统研发团队、CRM研发团队等。这些资源典型的物理载体就是物理机、虚拟机、容器资源以及对应的机器连接的存储（DB、缓存、K-V数据库等）资源，还会包含由于交换、存储以上资源之间的数据产生的带宽、云资源、CDN等。这部分资源，我们从控制成本的角度，最浅的层次，建议关注服务组（OWT）所消耗主机的资源利用率，如果资源利用率较低的主机数量较多，建议及时下线。同时，从技术方案本身来说，任何一个服务承载的业务能力和消耗资源之间，会有相对的一个“比例”或者权重。某些高利用率的服务从架构上是否可以重构、解耦或者改造，也非常有利于节省资源。这块内容到餐技术部在过去一年的工作中，对于核心、非核心的服务都进行了梳理，对于其中可以优化的服务也进行了部分重构。相比年初，很好的降低了资源的成本，业务主机成本的两个主要指标的变化情况如下（备注，后续由于新增其他业务导致成本略有上升）：3.2.2 大数据成本数据行业在互联网的应用目前已经较为成熟，行业主流的数据处理架构都是Yarn 2.0或者类似框架，核心的资源消耗主要基于Container（Vcore+Mem）的计算资源+基于HDFS的存储资源消耗这两部分：第一部分，是存储资源的消耗，行业通用的模型是基于物理HDFS或自研的类似存储引擎，这部分主要是指离线ETL用来按分区（一般是按时间戳）进行存储的资源，由于数据仓库的核心理念之一是保存“所有”的数据，并在此基础上按照维度建模理论对数据进行预汇总、加和。但是，由于对于模型建设本身的理解深度不同，故在基础数据之上的数据冗余，在很多数据研发人员看来是理所应当的，进而导致存储资源的快速膨胀，这是每个数据团队在管理过程中面临的难题。在此，到餐研发团队主要采取了两种手段：对于数据模型的热度进行了分级，把数据分为冷、温、热数据，对于需要保留的数据才保存在生产环境的HDD、SSD中，对于不重要的冷数据，通过异构的方式存入其他介质中。对于数据模型本身，需要重新思考数据的价值和存储，在数据的中间层（汇聚层），对数据模型进行重构，这也是很多数据团队忽略的基本功部分。到餐数据团队对于数据仓库进行了二次迭代，每次都基于新的业务模式，重新构建中间层以及之上的集市、宽表层，有效节省了空间。还有一种技术手段是压缩，比如流量的数据往往是存储大户，但是流量数据相对的格式比较固定，所以很多流量数据可以进行压缩或者改变其存储格式（如map型），根据实测可以节省20%以上的流量数据空间。另外需要补充的，还有一部分OLAP存储资源，也会消耗大量资源，比如Kylin、Elasticsearch、Druid、MySQL等，这些数据库主要用来将基于HDFS上的文件，同步到前端可以直接访问的介质上，供系统访问。这部分资源有些也是基于HDFS的（如Kylin、HBase），有些需要单独的存储介质，也需要关注其膨胀速度以及存储周期。第二部分，是计算资源的消耗，主要满足基于复杂规则的分析或者机器学习算法中的计算，也就是实时ETL计算和离线ETL计算的场景（代表性的引擎如Storm、Flink的计算还有MapReduce的计算）。这部分计算消耗的资源类似于业务系统，可以参照业务系统的“资源利用率”确定几个指标，进行机器优化或者算法逻辑优化。3.2.3 分摊成本（一）风控及反爬在某些公司里，某个技术团队开发的内容，有可能为了服务其他团队业务，比如前文中提到的风控、反爬、广告等，会为各种业务提供基础的技术能力。这时候就涉及到一个重要的概念“分摊”。分摊有两种规则，一种是按“实际用量进行”，另外一种是按照“使用比例”进行，这两种模式之上，可能还有混合计费模式，即“按照实际发生的比例进行整体费用的分摊”，做成本控制时，就要清楚地知道这部分成本是按哪种逻辑来进行计算的。在风控及反爬的实践中，美团的风控及反爬按照整体风控技术团队的总体成本，按比例分摊给业务团队。所以作为业务团队，如果试图降低这部分成本，也要关注两个组成项：一是自己使用的风控及反爬的原子业务数量的绝对值，对每天风控及反爬的总体请求次数是否合理需要进行判断，以保证自己的业务请求量不增加；二是自己业务使用的比例。需要跟相关技术团队一起进行分析，以防止某些场景下，自身业务使用的绝对值下降了，但是因为其他业务绝对值下降的更快，导致自己比例反而上升，进而导致成本上升。3.2.4 分摊成本（二）安全数仓成本为了保证各个业务团队之间的离线数据交换，美团集团层面建设了安全数据仓库，用来满足跨团队之间的数据交换。这部分的费用也按照实际发生的资源占比进行统计，所以同理，为了降低成本，需要关注两个组成项目：一是自己使用的数量，从架构设计上能否将相关数据模型的效率提升、降低空间是关键因素；二是自己的使用资源在整体资源的占比，这时候也需要跟相关团队一起努力降低总成本。很多公司的技术团队，也有类似的数据共享仓库或者共建仓库的概念。3.2.5 分摊成本（三）广告成本很多互联网公司都有做广告业务的技术团队，广告的形式主要有按点击收费CPC，按时长收费CPT等等，这部分分摊的逻辑同上述两者，也是按最终的总费用中的占比进行分摊。但是这块有一个需要关注的点是，由于广告的业务逻辑并不在到餐自己的业务方，也就是说归到餐研发团队可以控制的部分较小，故在这个过程中需要建立有效的评价体系，来衡量广告分摊的费用，在此采用的指标是“千次曝光成本”和“千元广告收入成本”，这里仅供大家参考。3.2.6 其他成本除了以上梳理的项目之外，每月还会有一些新增的成本项目加入进来，团队要保持足够的关注。在实践中会发现某项成本在个别月份突然升高，这时候就要找到是新增加了项目，还是某个指标在业务或者算法上有所调整。4. 检查（Check）在这个阶段，建议关注以下结果：规定动作检查。规定的方案是否执行？相关的同学是否按照规定的动作进行了相对应的行动？这个阶段只关注过程不关注结果，而且更多的是关注执行人、配合方、时间点，用项目管理的思路来运营。结果评估。之前梳理出来的指标是否得到了优化？这个过程是在验证结果，各项指标中得到优化和未优化的都要整理出详细的List，有些指标如“资源利用率”是立即可以查看结果的，有些结果是需要周期性的时间才能获得。在这个基础上可以继续深入反向思考，按“指标定义是否有问题->方案制定是否有问题->执行人是否有问题->配合方是否有问题”这个流程来进行评估。系统问题定位。在这个过程中，可以做到小范围闭环，建议针对某个指标的优化方案可以设计多套，方案A不行马上迭代成方案B，快速试错，找到合理的方案。修正标准动作。在执行的过程中，很多方案和动作，都是在一线现场发现和修正的，不需要等待大规模复盘的时候再提出问题和总结，主R要具备这样的意识，在执行过程中多说多问，找到关键要素，相信每个同学都有过这样的经历。经历过某个完整项目生命周期的同学，往往也是团队内成长最快的骨干。在到餐研发团队的实践中，业务系统的指标定义上也有类似的经验可以分享。开始进行优化工作的时候，定义了非常多的的项目和指标，比如业务主机分为云存储、带宽、CDN、Tair、Redis等等，关注到每一项对于RD投入的时间和精力都是巨大的损耗，后来经过反复跟相关兄弟团队确认，向上抽象了一层“服务组的资源利用率”，这时候就不需要关注太多细碎的项目，而只关注与这些服务有关机器的使用情况，因为机器会自然的消耗CPU、内存、带宽、CDN等，这样可以有效节省运营的时间成本，把精力集中在优化机器和优化服务架构设计层面。5. 复盘总结，继续迭代(Act)定期复盘。复盘是一个非常重要的能力，个人以为，复盘总结的能力在某种程度上也代表了自己的“抽象能力+思考能力+管理能力”，关于复盘的方法论书籍很多，这里不再进行赘述。在这个阶段，个人建议关注的点在于两个“知道”：“知道自己不知道”，通过复盘掌握了成本优化的方法、框架、方案、团队素质、结果；“不知道自己原来知道”，通过一些结果，知道了自己原来一直是在正确的道路上还是在错误的道路上前进，把带有“运气”成分的成功，升华成为一种未来的“习惯性成功”。形成报告。让第一次看到这个报告的人，也能通过1-2次实践，学会成本优化这件事。迭代认知。将之前的过程开始深化和迭代，也是再次进行PDCA的过程，反复打磨自己的抽象能力、思考能力、管理能力，使自己工作深度、广度的ROI继续提升。在迭代过程中，总会有一些惊喜和收获。从个人来说，原来以为成本项目仅仅是个管理项目，在不断通过技术手段取得成本优化的过程中，收获了对架构、技术的理解，并且很多时候需要用创新的手段来解决前人未曾突破的问题，另外还收获了7项跟架构升级、数据压缩、技术处理有关技术专利，也是技术能力提升的一个佐证。总结成本优化这件事，有可能被阶段性忽略，但是重要性一直存在。到餐研发团队通过将近一年时间的运营，帮助公司节省了几千万的成本。这个过程有时候枯燥，有时候让人兴奋，有时候又让人懊恼和沮丧，某些时候其实是在拷问自己一个问题：“保证业务不停的前提下，敢砍掉多余的机器吗？”在管理越来越精细化的今天，相信更多的有识之士也有一些需求或者进行了一些实践。期待跟行业同侪一起，在保证技术能力和满足业务的前提下，更加合理使用资源，节约公司成本，不断提升研发团队的效率，希望本文能给大家带来一些启发。作者简介刘强，美团到店餐饮研发中心数据方向负责人，美团数据技术通道委员，2017年入职美团点评，就职于到店餐饮研发中心，负责到餐数据仓库、数据产品、数据系统的研发工作。之前曾任多家公司的数据方向负责人。建钟、小英、杨轩、云杰、方旭、鹏文，均为美团到餐研发团队工程师，对本文均有贡献。特别感谢在本文及成本优化过程中，得到了美团技术团队李伟、登君、李闻、语宸、洪丹、普存、树熠、士涵等人的支持和帮助，在此表示感谢！