第一届搞管理|志遥 - 如何在小型前端团队的管理中踩坑

前端早早聊大会，前端成长的新起点，与掘金联合举办。加微信 codingdreamer 进大会专属内推群，赢在新的起跑线。

第十四届|前端成长晋升专场，8-29 即将直播，9 位讲师(蚂蚁金服/税友等)，点我上车 (报名地址)：

前端早早聊大会目标成为用得上，听得懂，抄得走的前端大会，计划 2020 年办 12 期，第一期 2020 年 1 月 11 日在杭州梦想小镇举办，报名 450 人，到场 230 人，话题聚焦在「前端转管理」，来探讨大家常遇到的问题：

三五年后我大概率走上管理，之前该做什么准备呢？
老板提拔我带前端小组，我内心慌慌该怎么应对？
真有 35 岁天花板么，我要不要坚持走前端这条路？
技术编码做好多年，现在转型管理是对的选择么？
公司业务发展太快，我怎么才能带好 3 人到 50 人？
我老板懂不懂管理，我想看看别人公司怎么做的？
...

会议的五位讲师工作经验从 5 到 15 年不等，带的团队从 5 到 50 人不等，这些问题他们是如何处理的呢，一路怎么走来的呢？这 5 场干货的分享一定会带给大家完全不同的观察视角：

本文是第二场讲师 - 志遥的讲稿文字版，来看看他是如何讲的，观看视频请扫码文末二维码，回复 “早早聊第一期” 即可获得其他 4 篇文章、录播视频及 PPT 地址。

大家下午好，主持人提到的跳舞只是一个爱好，也不是跳的很好。下面开始我的分享。我是来自丁香园丁香医生业务线的一名前端工程师，今天给大家分享的一个话题叫做如何在小型前端团队的管理中“踩坑”。

我是 15 年本科毕业的，16 年的 3 月份加入了丁香园，17 年的夏天开始正式去负责丁香医生的前端团队。

今天的分享主要是三个部分，第 1 部分是简单的背景介绍，第 2 部分是从正式加入丁香医生业务，逐步开始带团队到目前的踩坑心得，第 3 部分是做一个总结。

背景介绍

关于丁香医生

我们先简单了解一下丁香医生：

toC 方向。丁香医生是一个 toC 方向医疗健康相关的业务。
在线问诊。16 年的夏天丁香医生开始去尝试做在线问诊。可能有些人在线问诊这个词还是比较陌生的。
探索型的业务。在线问诊对于整个互联网医疗行业来说都是一个探索型的业务。在这个行业中，不仅是国内，甚至是整个世界上，都没有一个成熟度像电商一样可以去借鉴的商业模型，要靠一点一滴去探索业务的方向。
互联网医院政策。在线问诊业务是背靠国家互联网医院的政策。

丁香医生前端团队发展历程

这里做了一个比较详细的团队发展历程整理，从 16 年开始业务的试水，到 19 年我们业务模型初步清晰的一个过程中团队的变化。表格中整理了每一个业务阶段，一些具有代表性事件，包括我们产品形态的变化，团队人员的变化，团队技术栈的变化等。

我把它做了进一步精简：

从 16 年到 17 年是业务试水的探索期，初步通过 Web 平台验证了业务是可以进一步去做的，所以公司决定把在线问诊业务用 APP 形态去承载。
17 年，丁香医生技术团队开始快速迭代 APP，这个时候需要更多的同学参与进来，我们的前端团队也开始快速的扩张。
18 年，我们的业务在继续增长的同时，还有一些新的健康领域相关业务想尝试，这个时候我们团队人员会继续的增加。
19 年，我们大概想清楚了一些事情，业务的基本模型已经达到了一个稳定的状态，此时前端团队也达到了一个相对稳定成长的状态。

表格中最核心的是我把整个团队发展过程中，面临的一些主要的问题拎了出来。比如，最开始为了快速上线，面临的代码质量问题。代码写的怎么样，实际上那个时候对于快点上线这个目标来说，真的不那么重要。到了 17 年，我们面临着团队人员快速的扩张后，团队规范短缺、人才梯度不足等问题。18 年，我们的一些同学会产生技术焦虑，然后我们还经历了项目管理、研发效能提升、技术沉淀等问题。

“踩坑”指南

主要是结合一些实际的工作的经历，分享一下踩过的那些坑。

概述：3 个方面，15 个点

3 个方面：

个人转变
团队建设（人、技术、氛围）
团队协作

1.个人 - 定位管理

当我们从技术开始走向管理的时候，我们会遇到自己的心魔。我在 17 年夏天的时候，就非常真切地遇到这样的困惑。最开始团队由 2 个人变成 3 个人，然后快速地去迭代业务、学习新的技术、把技术应用到业务当中，是一种可以让人非常愉悦的状态，甚至可以说有点享受。因为通过个人的努力，可以又快又好地去把业务需求交付掉，与此同时还学到了新的技术。

但是，当团队从 3 个人到 7 个人，开始正式的去带团队，整个业务部门也在快速地发展的时候，leader 每天的工作当中，会有各种各样的琐事来找你。可能你刚要去做事情 A，然后事情 B 马上就来打断你，接着事情 C 需要你去响应一下。

最开始的时候，我的心态是怎样的呢？面临这样的问题，我也会有一些焦虑。团队伙伴都很努力地学技术、写业务。之前我也在很努力地学技术、写业务，变化是我开始每天被很多事情来打断。我该怎么办呢？

解决方案 1 - 越挫越勇：

我选择第 1 个方案是越挫越勇。不甘心在被经常打断的情况下，个人的业务需求输出减少。这个方案可能出现的情况是什么？每天大家都已经下班了，我一个人开始去做那部分我想做的业务、我感兴趣的东西。但实际上跑了一段时间之后，发现这个方案是不行的。因为无论个人的还是团队的交付能力（交付的质量和效率）都没有明显的一个提升，甚至出现了变糟糕的趋势。

解决方案 2 - 被动分配任务，跟踪任务进度：

因为自己有了管理的职责，可以更加“正大光明”地去分配任务：把一些业务需求让团队的同学一起去做。分配了任务之后，还需要去关注任务的进度，这是项目管理当中很基本的一个点。采用这个方案后，情况会稍微好一点，但还是会有问题。因为虽然任务是从我这里分配出去，但是团队处在一个从 3 人到 7 人的过程中。一个新人到了一个团队的时候，前期会戴一个“面具”。他可能跟其他人去交流的时候，不太能做到完全的敞开心扉。每一个新人的技术能力也是有差距的，这种差距可以细节到每个人的代码风格都不一样。这个时候即使把任务分配出去了，每天花一些精力去关注进度，可能没有达到很好的效果。

这个时候就给我的一个触动是什么呢?

触动/转变：球队的教练不一定是团队当中技术最好，冲在最前面的。在开始正式带团队之前，我属于那种冲锋陷阵型的选手，跑在最前面、努力拿个好的绩效，大概就这样的一个节奏。但是实际上当开始有了管理职责之后，这个方式就不灵了，需要我做一个定位上的转变。

解决方案 3：主动认领任务+整体协调、建立团队规范、定期 Review 问题、加强技术基建、虚拟小组等**

经过 17 年、18 年、19 年做了一些尝试后，现在能以相对能舒服的状态去和团队一起做事情。会让大家主动的去认领自己想做的事情，在大家认领之后，可能会进行一个微调。如果大家已经可以很好地协调好，就不需要再去做后面的调整，只需要去 Review 一下分工是否合理。建立了完善的各方面的团队规范，比如，刚刚提到的代码风格不一致问题，我们就建立了详细的代码规范，并且在具体的前端项目中使用一些辅助性的工具。大家彼此的交流还是没有那么的坦诚，我们就去一点点的推进 Code Review。19 年，业务初步地清晰之后，我们在团队内部成立了虚拟小组，由不同的虚拟小组来负责不同的业务。

通过这样的方式，我就逐步地坦然面对最开始的心魔。所以，我分享的第 1 个坑是，我们一直习惯于去扮演业务高手。出现了各种各样的问题，首先告诉团队的人你们不要动、让我来。这对于管理来说，不是一个很好的事情，需要去规避。

总结一句话：要成就他人，就要发挥团队力量。这是我关于个人定位上的一个变化。

2.个人 - 情绪管理

第 2 个变化是关于个人情绪的管理。

前面提到了丁香医生的在线问诊是一个探索型的业务，探索意味着什么？意味着会出现方向迷茫。业务方向不清楚，体现在产品需求层面就是产品的需求，这个月是一个方向，下个月又是一个方向。这样的情况就让我产生了一些急躁、焦虑的情绪。

产生负面情绪的例子还有：觉得团队成员成长速度慢、身边合作的人不专业、团队骨干成员流失等，实际上这些我们工作当中可能会出现各种各样的负面情绪。

当我踩到第 2 个坑时，我当时甚至都没有意识到。大概 17 年年底左右，我把各种原因导致的负面情绪在工作中表现出来了。这不仅会影响到个人的工作状态和工作协作，负面情绪还会传递给团队。

所以说，当我们去开始带领一个团队的时候，一定要把自己的情绪管理好。或急躁，或焦虑，或担心，这些事情我们要尽可能去收敛，不要去把这样的问题轻易地表现给团队的成员。因为这些都会给他们带来一些负面的影响。

在整个转变的过程中，有两个事情给我的触动还是蛮大的。第 1 个是一部电影，这个电影大家有知道的吗？

这是《功夫熊猫》中的一幕。当熊猫遇到了敌人、要去打仗，却内心胆怯、焦虑，觉得自己不行时，他师傅在教导他。这里面有个关键词叫Inner peace，内心的平静。

功夫熊猫听到了这句话之后，他的表现是怎样的，还记得吗？用头不停的撞墙，思考什么叫 Inner peace。

我 17 年的时候大概也经历过这样的状态，只不过我的 Leader 跟我说不是 Inner peace，而是心如止水（第 2 件给我触动的事情）。心如止水怎么做到？不同的人可能有不同的方式，但是作为一个管理者，无论如何都要一点一点地去朝着这样的方向走。哪怕当时做不到，我们也要有这样的意识，去一点点往那边走。经过 18 年、19 年的磨练，到现在我觉得在「心如止水」这件事情上做的会稍微好一点了。

当功夫熊猫做到 Inner peace 的时候，他最终成功的把对手打败了。这就是我第 2 个分享的点，遇事的时候要保持良好的心态，对心如止水。

3.个人 - 信息管理

第 3 个点是关于信息的管理。实际上这件事情我发现在很多人的工作当中，是容易被忽略掉的。不仅仅是有管理权限的人，技术线的软件工程师也有这个问题。他不重视工作当中的一些信息，只关注自己眼中的那一亩三分地。对于 Leader 来说，他获取信息的渠道会比专注于做技术研发的人会多一些，但是他可能做不到把有价值的信息及时传递给团队成员。比如：业务方向调整了，Leader 可能知道原因，但团队成员不清楚。此时团队成员的视角是什么？是需求又变了，我上周辛辛苦苦做了一个需求，这周就把方向变了，我努力的结果轻易就被否定了，此时团队伙伴可能会产生对产品或者其他的合作方的不信任感。

还有什么事例呢？比如：团队遇到了一个技术难题，怎么办？Leader 说兄弟们上，把个问题解决掉。花了一周时间问题终于解决掉了，团队成员很有成就感。但是问题在于，其他的兄弟部门早已经解决过这个难题了，或者说业界已经有更好的解决方案了，身为 Leader 却没有去找这些有价值的信息，也没有去把这样的信息传递给团队的人。

这是我认为的第 3 个坑。避坑的总结是，要重视信息的价值。首先，我们要能从观念上要重视这件事情，然后我们要想尽办法尽可能的多去获取信息，因为有的时候信息不会主动找上门来。然后，我们要起到连接和过滤的作用。不是说我们收到了什么信息，转身就毫无保留的告诉给团队，有时候这样是不合适的，我们只需要把其中一部分，对团队成员更有帮助的信息告诉他们即可。

4.个人 - 项目管理

第 4 个踩坑的点是项目管理。这个表格是从前面最详细的团队发展历程表格当中提取出来的，业务阶段和团队人数这两列没有变，只是最后面一列变为了「发版周期」。

最开始时，业务试水阶段，产品形态只需要 H5，要求尽快上线、快速迭代。此时随做随发的节奏便于验证一个新的业务方向。

当确定了新的业务方向是 OK 后，业务开始需要 APP 去承载。最开始 APP 团队的迭代习惯是根据需求量去排期。比如说这么多需求，需要一个月之后发一个版本，最早的时候这种节奏也是能被业务方接受的。但是业务逐渐地发展，就会变成业务方不满足，他们需要快，所以发版节奏就变成两周。APP 调整成两周后，已经比之前变快了，但是前端还在随做随发，因为业务方说你们这发版成本低。虽然多次尝试去和业务方解释，我们的发版成本也没像是说一句话那么简单，但是他们可能还是要你更快。

到了 18 年，我们不仅要去探索原有的业务增长，还要去开辟新的业务。这个时候是最痛苦的一个过程，原本是两周发一个版本，业务方说要快，我们尝试做到一周一发，但是业务方还不满意。怎么办？最快的时候，我们甚至做过一天之内发几个小程序的版本。这种节奏，我们已经明确感觉到技术团队不舒服了。所以，还要继续去寻找解决方案。我们会尝试去跟业务方、产品协调，能不能把这个节奏调慢一点，比如调成一周一个版本。调成一周一个版本之后，技术团队果然稍微舒服了一些。一旦舒服了一些，就会想着更舒服，就开始尝试能不能发版周期调整为1.5周、2周，结果业务方又不满意不舒服了。

经历了这样一个不断磨合调整，寻找适合团队的项目管理方案的阶段后，19 年整年技术产品团队配合的还是会相对舒服一些。每周我们能保持一个主版本（包括 APP）的发版。19 年下半年，我们可以达到在主版本之外，如果有额外的必要的需求，也是可以支持再去发一个版本的。

这是关于项目管理的一个坑。最开始带团队的时候，我的主要精力，或者说我的主要视角，都在如何做好需求，如何让团队的产能更大。但实际上随着业务的发展，越来越多地去贴近业务，我们就发现项目管理也是每一个有管理权限的人，他需要去掌握的一个技能。

我们生活当中也有很多项目管理的例子，比如说这次「前端早早聊」活动的举办，它也涉及到了项目管理。

现在回头看，在 18 年，就是在最痛苦的那个时期，我发现自己有个误区：把很多事情都归结到了人的身上。比如：团队出了一个bug，那是团队同学这个人的问题；需求变了，或者说业务方没有把需求想清楚，是产品经理这个人不行。甚至说团队出了一些问题时，我觉得是我这个人不行，做管理不行。

但是现在我更会这样去想：正是因为各种各样的人存在各种各样的不足，我们才需要去制定制度、应用管理手段，更科学的方式在整个团队的团队协作和项目管理中去发挥作用，而不是要把很多问题的点全部归结到人的上面。比如：前面提到的交付质量问题，我们要去思考，能不能去规范研发同学自测、提测的流程来规避，或者说我们能不能去推进自动化测试来规避问题。在日常工作中，我们要用管理的方式，去推进一些规范，一些制度来去弥补前面我们可能会遇到人的问题。

列了一些对我来说，看过之后很有帮助的学习资料：

研发效能提升和敏捷实施 36 计
《精益产品开发原则、方法与实践》
《敏捷革命》
《学习敏捷构建高效团队》

5.个人 - 价值管理

第 5 坑是关于价值管理，我把它笼统地总结为：不去关注技术和业务的结合，不去关注技术的投入产出比。

实际上，我是从 18 年初开始思考这个问题的。那个时候业务部门的老大问我：在过去一年，你对业务的贡献是什么？

我们可以从技术视角回答，我做了很多业务需求，并且这些需求也带来了业务价值，同时自己所支持的业务需求具有一定的社会意义，这可以是我们的一个答案。大家有自己的答案吗？

这个问题让当时的我产生了一系列的思考。我会开始去思考技术的价值在哪里？因为我是用技术的人，所以我还会思考我（技术人）的价值在哪里？技术的价值和业务价值，它们的关系又是怎么样的？最开始的一个问题，触动我去做这些进一步的思考。

还有一个关于价值的例子：产品经理急冲冲地过来说，我这有一个紧急需求，能不能支持一下？实际上在过去的工作中我被问到了这个问题好多次。我发现每当我反问“你这个需求为什么紧急？它给业务带来怎样的价值？”这种问题的时候，产品就容易先跑回去做进一步的思考。所以说，这也是关于价值管理的一个延伸。总体来说，我们工作中要去思考需求的价值。所以，这个地方的一个避坑建议是，我们要尽可能去想清楚这样的一些价值问题。

技术的价值定位在哪里

关于技术价值的定位，19 年下半年开始，我自己得出了一些答案。在此会尝试着分享一下：

公司/集团为「用户价值」负责：我们公司或者任何一家公司，最关注的是用户价值。我们做各种各样的服务、各种各样的产品，最终都是去为用户价值服务，从用户那里产生价值。
事业部/事业群为「业务价值」负责：我们需要用实际的业务去承载用户价值业务价值通常怎样是由公司的各个事业部、各个级各个业务部门去承担的。
市场/运营/产品等为「业务创新」负责：对于我们技术来讲，我们要为全部的业务价值负责吗？不是的。在业务价值之下，距离最近的有一个业务创新层。业务创新主要是由市场团队、运营团队、产品团队等来负责的。业务创新是指我们为什么要去做这样的需求、这样的需求解决用户怎样的问题、可以通过哪些方式更好的创造业务价值。
技术/产品为「持续交付」负责：在业务创新价值层之下，才是技术团队、技术人需要去重点关注的价值，叫做持续交付层。这是我们技术人要去负责买单的事情。

技术持续交付价值分层

前面提到：技术的价值在于持续交付。持续交付，是一个很大的话题。我把它去做了进一步的分层。

基本价值：技术最基本的价值是交付。就是把需求做掉，能上线就好了。会使用交付需求需要的技术，这是对于技术人最基本的价值。
技术增值：在实现了技术的基础价值后，我们会去追求能优质高效地把需求交付，这个时候我们关注点会变成质量和效率。这个时候，不仅仅要求技术人会使用技术，而是开始要求能用好技术、更深入的掌握技术，能够用一些辅助的系统、工具或者用技术去创造一些工具出来，利用这些系统、工具来不断提升交付质量和效率。这一层我会把它定义为技术的增值。
软件资产：在技术增值基础上，我们会进一步的去追求能持续顺畅的交付。这一层会开始关注项目管理，关注我们的交付流程。对于技术同学，会要求系统性的去思考、要求技术人的工程化能力。此时单点的软件系统、工具已经无法满足价值诉求了，而是要求技术进行体系化的建设，去沉淀优质的软件资产。技术团队能够给公司不断的沉淀优质软件资产，已经是一件不容易的事情了。在这个价值层之上，还会有进一步的技术价值吗？
技术附加值：最高的技术价值层，我把它定义为技术附加值。此时技术人开始能关注、把握有效的用户价值。日常工作中，并不是技术人交付每一个需求都是有效的。所以说我们要有能力去关注到真正有效的价值，要做到这一点，其实是对技术提出了更高的要求：理解业务、驱动业务，这需要我们技术人可以跨越技术的边界。

6.个人 - 思维管理

第 6 个点是思维管理，说的是要求团队 leader 能够系统性、全局性地去思考。可以在工作当中经常问问自己，我的老板他在想什么，或者说公司做了一个决策，其背后到底为什么去做了这样的决策？

7.个人 - 健康管理

第7点是关于我们的个人健康管理。实际上这是一个工作中非常容易被大家忽略掉的点。我们技术人总是关注技术的成长，忽略了健康。

如果大家三年前见到我，那你会见到一个 180 斤的胖子，胖使我有了种种的健康的问题，通过对个人健康的重视，现在减肥到 135 斤了，每年体检各项指标也是健康的。还有比如说生病的时候疼到深夜无法入睡，那个时候真的会觉得：我还没有看过 Node.js 源码这件事已经没那么重要了。但是人的欲望是一个有趣的事情，当我生病好了以后，就会开始考虑：Node.js 源码还没学习过，找个时间得盘它。此外，生活工作中我们可以见到的健康问题还是很多的，无论如何我们都需要重视个人的健康。身体不健康、生命不存在了，谈其他的事情就没有什么意义了。

上面 7 条是关于个人转变的一些坑，后面的 8 条是关于团队的一些坑。谈到团队，最开始的直面的话题就是人。

8.团队建设 - 人才招聘

我的 2019 Q4 OKR 中有这样一个 KR：招聘一名资深及以上级别的前端工程师。KR 的背景是 2019 年一直在做这个事情，但始终没有成功。是因为不努力吗？似乎也不是。招聘系统上的记录，可以看到关于招聘是做了不少事情的，但始终就是没有成功。

到了 Q4 的时候我就开始了不断的思考，逼着自己去想问题到底出在哪里？然后去思考解决方案，更多的思考以及行动这里地方就不展开说，在一个前端招聘者的内心独白和杭州丁香园丁香医生招聘资深前端工程师中有详细的记录。幸运的是，最终结果是我们招到了适合我们团队的人。

所以关于招聘的这个坑，我把它概述为：关于招聘思考的不透彻。如何避坑我把它总结成了三个点：

（招聘前）想的明：业务现状、团队人才现状、岗位现状、招聘标准 (JD) 、招聘的优先级、需要HR资源情况。
（面试中）面的准：能力因素(能不能做) 、动力因素(愿不愿意做) 、人格因素(合不合适做)。
（面试后）决策稳：匹配专业能力、匹配价值观、匹配个人意愿。

在适合团队的人招进来之后，接下来要做的一件事情就是人才的培养了。

9.团队建设 - 人才培养

第 9 点的坑，也是一个思维上的转变，就是我们要对团队的成员发展去负责。

10.团队建设 - 人才培养 - 目标管理

在人才培养这一点，有一件很重要的事情是目标管理。在团队目标管理上，我曾经犯过的一些失误，比如给团队定了远超出团队能力范围的一些目标，会导致团队会很疲惫；比如团队目标分散，在一个季度我们想做成三个方向的事情，人的精力是有限的，目标分散导致精力分散，最终就会导致目标达成效果不好；再比如，Q1 我们目标是想做 A 事情，Q2 目标完全 180 度转弯，要做与 A 毫不相干的 B 事情。

关于目标管理的避坑方式，我个人的解决方案是要去系统性的去学习目标管理。给我最大的感触是 OKR 学习与应用。同样的这里提供了一个学习参考资料。

11.团队建设 - 人才培养 - 绩效沟通

关于人才培养的，另外一件很重要的事情是绩效沟通，或者概述总结为「沟通」。

「To Cure Sometimes, To Relieve Often, To Comfort Always.」是在医学界广为熟知的一句话，翻译成中文是：有时去治愈，时常去帮助，总是去安慰。

生活中我们接触到的大多数人看上去都很健康，但是一个客观事实是世界上 80% 的疾病是不能被治愈的。医生做的更多事情是提供帮助，他在医院、在诊所给你提供帮助，比如告知我们该去做怎样的检查、根据他的经验给到我们治疗方案、去给患者做手术，这些都是实际行为的帮助。但是帮助实际上也是有限的，对吧？医生做的最多的一件事情是去安慰你，有的时候我们去医院拍一些片子，最终结果是怎样？医生说没什么事你回去多休息多喝水就好了，此时他在安慰你，不仅是提供了实际行为上的帮助，更多的通过他的话是让我们对自己的健康放心，给了我们心灵上一颗“安心丸”。

其实，在我们团队做绩效沟通的时候，甚至说在平常去跟别的团队同学相处的时候，我们也要去像医生这样做。为什么？提到治愈的时候，通常是某一个结构性的一个质变，意味着要去改变一个同学，比如改变他的一个做事情的方式或者一个认知，这是很难的事情，我们很难去“治愈”一个人。作为 Leader，我们更能做的事情是给团队伙伴提供帮助，然后总是去安慰。团队成员每天的工作当中，他们也有各种各样的情绪，这些是需要我们去做安慰的。

12.团队建设 - 人才离开

踩坑的第 12 点是人才的离开。在今天来活动现场的路上，我跟车上的一个小伙伴在交流，实际上我们都会遇到这样的问题。团队总会有人离开的时候，核心骨干的离职会难过；让不太适合团队的人离开可能会不忍心，他也不是不努力，挺努力的，但是结果可能就跟你的标准差了一些。

这个地方的建议是面对人才离开要果断。我现在会这样跟自己说，大家分开是因为彼此的不合适，分开之后实际上是为了彼此更好。

13.团队建设 - 技术沉淀

第 13 点是关于团队建设的技术沉淀。

从 16 年开始，团队从两个人到现在的这样一个稳定的状态，我们实际上是做了很多的关于技术沉淀的探索，尤其是在 19 年业务比较稳定之后，我们会更有精力来做这样的事情。最终的效果是，如果我们踏踏实实认认真真的去做了技术沉淀，它真的会去反哺到业务的优质高效交付上，同时团队伙伴也获得了技术的成长。
**

这里展示了一些丁香医生前端团队的技术沉淀：

小程序研发体系
持续集成服务
小程序组件库

14.团的建设 - 团队氛围

第14点关于团队建设的坑就是不重视团队的氛围。这里我把它定义成了坑，因为我见到过一些氛围比较差的团队。但是不谦虚的说，自认为在这一点上做的还可以。

在这里想和大家分享一下丁香医生前端团队文化的关键词：快乐、优质、高效、成长和自由。我把快乐放在第1位，因为我认为一个人如果在工作当中快不快乐、在这个团队当中快不快乐，这是最核心的问题。这个时候都不要去谈工作，我们先把这样的问题解决掉，要能保持心情愉悦地去面对工作。然后，我们会关注我们团队交付的质量和效率。在能做好交付的同时，我们要去追求每一个技术同学的成长，希望今天的事情会比昨天的事情是有进步的。最后我会认为自由对技术团队的同学来说是很重要的一件事情。

15.团队协作

关于整个踩坑分享的最后一个部分就是团队协作。这是今年某个 Q 我做的一个 OKR，其中一个 KR：在 APP 热更新机制上，使用 A 系统替换 B 系统。这是一个前端团队负责人确定的一个关键结果。这个 KR 会有怎样的问题？我没有去跟移动端的同学提前沟通好。因为这件事是要跟他们配合的，没有提前做好充分沟通的结果就是 KR 的延期落地，因为移动端团队也有他们的目标。当我们想推进一个技术升级，移动端团队、服务端团队也有他们自己的一些考量，所以说关于团队协作方面，最核心的还是要去共赢，不仅我好，你也要好。

总结

小型技术团队管理指南

以上是关于整个踩坑指南部分的分享，我把它做了一个总结，一共 15 条：

实际上我还是想把它进一步的精简了一下。去总结出影响我这几年做团队管理的一些内核理念。

支撑我做团队管理的内核理念

健康、快乐是最重要的事情。第一个核心点就是健康快乐是最重要的，刚刚前面由于时间关系，我没有展开说，这真的非常重要，每一个人都要重视自己的健康和快乐。
关注价值与价值流动。第二点是前面提到技术价值定位和价值分层，我们要去关注价值，关注价值的流动，这件事情无论是在团队内部、在团队协作上，在自己个人的成长上都是很重要的一件事情。
互相成就 / 共赢。我很喜欢的一个词叫做互相成就，不仅是说作为一个团队负责人要去成就团队的成员，我跟我的 Leader 也是一个互相成就的过程，甚至说一个团队跟公司的关系也是互相成就的。
明者因时而变, 知者随事而制。

明者因时而变, 知者随事而制

我们去做管理，不是单纯的去看管理方法，当今这个时代也不是说缺什么样的管理方法，而是当我们遇到问题了想清楚是什么样的问题，我们可以采取怎样的方案去解决掉问题。比如今天做分享的嘉宾会提供很多管理方法、管理理论，当把这些理论方法拿到其他团队去应用、放在实际的问题场景下去看，它可能也不是最合适的。这个时候需要直接面对问题的人，要能去定义问题，找到解决路径，然后带着团队走过去。

告诫自己的三句话

当我的职业发展走到了当下一个节点后，我会去反思，会想给自己一些提醒：

个人技术深度要深耕（根本）。告诫自己，个人的技术还是要去深耕，这是我们技术同学安身立命的根本，我还不想死的那么快。
不要急（风物长宜放眼量)。深耕归深耕，努力归努力，在这样的过程中告诉自己不要急，风物长宜放眼量。比如我们会有自己的榜样、有个人目标，还是要尽可能保持自己心情愉快的去朝着既定的方向去努力，不要急躁，也不要担心。
健康、快乐才是最重要的。再一次的告诫我自己，这件事情真的很重要。

关于「个人技术深耕」想做一个展开：光说不练假把式，告诫自己要深耕也不能说只嘴上说说，要落地到实际的事情上。基于这样的思路，19 年我用 TypeScript 做了一个小程序的 Sentry SDK：sentry-miniapp，遵守官方统一的 API 设计文档，使用方式和官方保持一致。感兴趣或者有需要的伙伴可以了解一下。

最后跟大家分享的是这样的一张图片，这是在公司我们部门内部在一个大屏幕上每天都会看到的，它是一个中国的地图，每一个点代表的是国内每个省份有多少用户在使用我们的在线问诊等健康服务。每次看到这个大屏幕，我都会去觉得：我们做了这样的健康服务，它真真切切地能去帮助到一些用户，是一件有情义的事情。

回过头，今天是关于管理的一个话题。如果我用一句话来去总结我们的管理是怎样的一件事情，我想用这句话：聚一群有情有义的人，做一件有情有义的事。

以上分享，谢谢大家观看。

近两年 Scott 观察到前端行业已经完全进入竞争的深水区，各大小公司的前端 TL 刚刚上任，初带团队，针对前端工程师这个群体，应该怎么管人理事，搭台拿结果，帮带有成长，就成立了这个全国的前端技术主管学习交流群，在人的选用育留上互相学习成长，入群的门坎是你有实线或者虚线在带团队，请加 Scott 微信: codingdreamer 邀请入群，同时，未来的前端早早聊大会行程动态、资料下载请扫码下方的公众号：