今天聊：如何推动与影响中型前端团队的成长

前端早早聊大会，前端成长的新起点，与掘金联合举办。 加 Scott 微信 codingdreamer 进大会周边技术群，前端页面搭建专场，2021-2-27，线上直播。

本次直播关于页面的可视化/自动化/智能化搭建新玩法，讲师来自阿里、腾讯、字节、满帮、蚂蚁、字节等，关键词有：

• 前台/中后台/PC/H5/富媒体(视频、海报、问卷)
• 低代码物料演进
• 组件动态加载/PSD 转 H5
• 渲染容器跨端配置/插件化
• Schema 规则决策/动态注入
• 富媒体支持/视频可视化搭建
• Paas 化高速 API 海报合成
• 自由画布/大型 IDE 架构
• 内核+扩展的编辑器
• UI 智能生成组件代码等

报名戳：www.huodongxing.com/go/tl21

正文如下

今天下午跟大家聊的这个话题 - 如何推动与影响中型前端团队的成长 & 暨最近一年多新团队的管理工作复盘：

○ 前言

本文根据 2020.01.11 日，杭州第一届 “前端早早聊” 的管理专场分享内容整理而来。因为现场设备原因，导致没能提供视频的录播，故以文字版进行沉淀，也能略微弥补现场时间原因一些未能说到的遗憾。

本文的标题是《如何推动与影响中型前端团队的成长》，一是契合大会所有分享都以 “如何” 为切入的要求，另外副标题我增加了 “暨最近一年多新团队的管理工作复盘”，这是因为我本身到政采云，一定意义上属于 “空降”。最近一年多工作上所做的事情，都是将这里的前端进行聚合和打造，帮助团队成长，更好的支撑业务的现在和未来。所以，本次分享也算作是对过去一年多，在团队管理工作方面的实践，和基于实践的阶段性沉淀总结。

另外还是非常感谢@Scott，感谢活动的组织者和参与者，感谢这一期的话题。业界关于技术管理，尤其是前端领域的技术、团队管理的经验沉淀少之又少，希望本次这些个人角度沉淀的文字，能为一些同学带来一些启动，产生一些改变。

○ 介绍

堂主，本名马翀，2006 年开始捣鼓前端。毕业前的 2011 年，先是在淘宝前端团队实习了整一年，2012 年毕业后即加入淘宝（花名@堂主），直到 2016 年加入蘑菇街（蘑菇街时期花名@明淳），在蘑菇街做了 2 年的 TL。2018 年 8 月 ~ 至今，在政采云负责前端团队的工作（花名又改回了@堂主）。

政采云前端团队目前有 50 多人，平均年龄不到 28 岁，妥妥的青年军。团队名字是 ZooTeam，团队站点也是 zoo.team。Z 是政采云拼音首字母，oo 是无穷的符号（♾），结合 Zoo有生物圈的含义，希望后续政采云的前端团队，不论是人才梯队，还是技术体系，都能各面兼备，逐渐成长为一个生态。

○ 一些似曾相识的

首先，我们来看一些日常工作中时常看到的情景（基本上都是从脉脉客户端“职言”匿名社区找到的 Case）

• 同学 A：“… 哎，天天写业务代码，感觉没啥技术含量，也没什么沉淀，成长太慢。架构那边做的东西倒是蛮有趣的，看上去很吊，但参与不进去。再这样下去感觉要废…”
• 同学 B：“ … 天天在公司写内部工具，感觉没啥提升，也没多少时间去学习，前辈们有啥建议吗，这样下去感觉要废了…”
• 同学 C：“ … 独自负责过很复杂的前端项目，一般基础面试题和项目经历没有太大问题。但对一些框架的原理、源码、工具研究较少，技术栈较陈旧，对 React、Vue 了解较少，导致水平一直在阿里 P6 级，无法突破到技术专家的评级（P7）…”
• 同学 D：“ … 每次做项目总是那几个对接合作的人出状况，总不能按时保质给到下游所需。找他吧总是再等等，然后又没下文。反馈吧也不解决问题，下次还是如此，最后还得我们下游加班加点给他们兜底。真 TM 不想干了…”
• 同学 E：“ … 推动个事太难了，就这么点东西，各种拉会沟通。解决个问题谁都不接，各种打太极推诿；出了问题先甩锅。心累…”
• 同学 F：“ …这次绩效考评，主管给了我 3.25，说我层级较高，但产出结果和其他更低层级同学相比，没有明显区别。我也在卖力的干活啊，总说需要多一些想法，结果不够。问题是他也不说啥叫想法、怎么个结果产出才是 OK 的，主管 SB…”

这些的背后，是一个组织的发展遇到了困难。团队的任何问题，归根到底都是管理问题。

○ 如何理解 “管理”

对 “管理” 的理解

对于如何理解 “管理”，不同的管理者可能会有 N 种不同的回答。我对这个问题的理解是：管理，就是靠别人拿结果。

不论是实线的 TeamLeader，还是虚线的小组长，或者项目 PM、技术小组的 Owner，其工作的内容都不是他一人能搞定的，都需要靠其他人的产出来集体落成结果。

管理，就是靠别人拿结果。在不确定性中寻找确定性，通过成就他人成就自己，基于数据阐明一切改变。管理者是带来改变的人，管理者就是要靠影响他人，带来正向的改变。

那一些同学可能会问：我应该转管理吗？什么时候应该考虑这件事呢？对这个问题，我的理解是：当你要推动改变的事，你一个人搞不定时，就要去追求团队的力量了（管理）。

管理不见得必须是实线的方式（如最常见的 TeamLeader）。日常中的业务接口人、虚线小组的组长、虚拟团队的 Owner，其工作范畴都会涉及定目标、出方案、整合资源、跟过程落地。这个过程本身就是在基于驱动一个群体去拿到结果，自然也是在做“管理”相关的事，在锻炼自身的管理能力。

在进行管理相关实操重点的交流之前，我觉得有必要和大家分享一些宏观的视角。

对内的视角

对内，面向团队，我个人关注的优先级是 **人 → 事 → 文化 → 影响力。**这也是后面关于实操部分的分享顺序。另外还需要抓牢治理结构（即必要的制度、流程）和管理工具。

关于治理结构，我的建议是，团队成员平均意识和能力越是偏向于一般般和强执行的，越需要强化 —— 即越需要明确清晰的制度和流程。反之团队成员越是偏向于自驱和专家的，则越需要强化价值观，文化驱动，尽量降低强硬的流程制度对人的直观约束感。

关于管理工具，制度流程是管理工具，绩效、晋升是管理工具，调薪、股权、奖项也是管理工具。合理的使用管理工具，重视 “找平”，而不是 “一体均衡”。积极的管理工具，需要向团队倡导的方向去倾斜。

对外的视角

作为一个管理者，无欲无私几乎是不存在的，将团队视为自身的 “势力范围” 也是生物的本性。但不论愿不愿意承认，管理者都要直面的现实是：你的团队，同时也是你直属老板的团队，更是公司创始人的团队，亦是大股东、投资人的团队。个人发展，离不开团队的发展，更离不开公司业务的发展、所处行业赛道的发展。与其在存量的盘子里过多的关注 “谁的手是不是伸的太长”，不如推动一起把盘子做大，在增量空间里获得更大的自主权和收益。

处理不好这些层层递进的关系，就很容易出现部门墙，导致团队的内耗，甚至是内斗。看过拥抱变化组织架构调整，上位的同时，也有淡出的背影；也看过那些个人、团队 KPI 完成甚至超额完成，但最后公司的目标完不成，公司裁员甚至是倒闭。背后，都能从上面这张图里找到原因。

正视 求同存异，重视 信任关系。

○ 人

人：选筛

梯队建设，正确的盘人、选人是关键的第一步。

内部选拔

内部选拔，我一般的优先级可见上图。其中，价值观和利他精神是我最看重的 2 个点。来到政采云后，整个团队的梯队搭建过程中，最开始抓的部分就是 TL 储备和抓核心员工成长。其中组长（后续 TL）的选育对象，我没有采用常见的搬来嫡系老部队、社招空降的策略，而是完全的“本土化”培养。

筛选过程中，一方面是创造足够的横、纵建设空间让重点被观察员工去参与，同时也是在过程里观察，哪些同学愿意花更多的个人时间去参与讨论，帮助同学解决问题，主动的多往前走一步多承担。同时结合这些同学的业务熟练度、技术能力等，最后选择出组长一级的培育对象，作为后面 TL 的储备人才。

皮实、要性也很重要，选育过程中要求的维度和压力都是逐渐增加的，也会有苛刻的时候。本身这也是一种双向的考察，一是对象能否逐渐适应我的节奏和管理风格，同时也是看选育对象能否担得起来，是能冲出去，还是老样子被动的待命。

外部招聘

外部招聘，我的策略是面向本地中短期内长不出的 “物种” 、或能长出来但数量不满足团队未来那个时期的需求去招聘。如果某种特质、某个方向的人才，我们团队未来半年到一年是能长出来的，那我会优先本地培养。所以，能看到现阶段社招的侧重点是 2 年内经验的优质高潜，和具备经验的技术专家。

外部招聘尽量避免缺人时急躁胡乱招，能干活就行。记得我们前面提到的吧，管理就是靠别人拿结果。你团队同学的能力，决定了你的管理结果。招聘，应优先面向能为团队带来积极改变的候选对象。

人：育用

用人长，补人短。关注团队成员的输入与输出。

育人

育人，是为员工提供 “输入” 的渠道，通过做事用人帮助员工在认知、能力维度上得以成长。我个人的经验，是要在过程中能为员工提供认知的升级，在负责的维度，和事的复杂度上要逐渐的比之前更上一个台阶，叫有潜力的员工承担他能力 120% 的事情，反推员工突破自己。每一年都根据员工的特点，思考其后续的阶梯式成长计划。具体粒度看组织的梯队层级和你所处的位置。比如我会重点侧重 TL 长这一层，兼顾组长和团队核心；TL 这一层重点在团队内组长和核心，兼顾高潜；以此类推。

很多同学在刚开始承担管理工作时，会担心自己务虚的占比增加，编码参与减少，专业能力下降。这都是因为增加了输出，但他能认知到的有效输入不足的体现。

用人

在用人这一块，是为员工提供 “输出” 空间。把他个人的优势长处，通过做事、推动事，辐射到更大的范围，影响其他人，帮助业务拿到更多结果。这部分管理者要帮助团队同学撑起必要的空间，优秀的管理者是扩大增量空间，一般管理者是争取存量空间。一般的策略，都是为同学争取能够主导的方向，如承担业务的前端 PM，做跨职能的建设，在过程中软化、优化、强化合作关系和信任关系，并通过影响力建设为员工提供结果放大器，叫更多的人了解并认同其过程和产出。

不论是育人，还是用人，都要考虑对象的诉求，和输入、输出空间的匹配度。

人：换血

换血是团队成长的必经之路，不论是主动的淘汰不合适人员，还是被动的接受优秀员工的流失，其本质都是双向的匹配问题。

主动淘汰

关于主动汰劣，首先要和大家分享的一点，是要求前置，过程跟足。也就是说绩效的重点是在平时的绩效管理，而非最后的绩效考核。绩效考核是在最后的结果，绩效管理的重点是在平时的过程。在考核周期的开始，就将要求摆明，目标和考核标准尽量都公开透明，阳谋至上。过程中做好阶段性 Review，我的方式是一般每隔 1 个半月左右（看考核周期，我们公司是半年一个考核周期），会和我直接的下属进行一次过程的阶段性 Review，对称 Aciton 是否是沿着既定目标在前进，进度是否有问题，过程中是否有方向偏差和其他问题。尽量避免过程中缺少沟通，最后来个一次定生死，给员工个 Surprise。

绩效结果，只要不是系统自动打分，由人来评判，成员绩效结果就一定会受到管理者个人主观意愿因素的影响，无非是多和少的区别。管理者人正的，这个因素会少一些；管理者人不正的，这个因素就会大一些。我个人的建议是，立场要站稳，对公不对私。标准前置化，绩效看产出结果，尤其是对应的业务结果。合适的前置目标和过程跟进，合适的考评标准宣导，会让绝大部分的团队成员，对自己和团队内他人绩效结果的预测，八九不离十。

如果决定要淘汰，一定要站稳立场：淘汰一个人不是他对你无用，而是他不再是业务、团队后续发展希望匹配的对象。心要慈，刀要快。强留、老好人心态泛滥，对各方都不见得是好的。如业务未来的发展，需要 80 分的团队匹配，他可能很努力，但确实能力和潜力的问题，再使劲最后也只能 70 分（且中长期来看没有突破性成长的可能），面向团队基本水平，他再努力也不够。最后他对接的业务受到阻力，团队成长变慢，他自己的职业自信心也会受损。

主动淘汰，刀要快，心也要慈。这个圈子很小的，经常的我们会看到有管理者被投诉在绩效结果中夹私报复，或者任人唯亲，或者借绩效之名职场骚扰等拿自己职业信誉开玩笑的“新闻”。只想说，做人留一线，日后好相见，这个圈子比我们的主观认知要小得多。

被动流失

团队核心离职，可惜性流失，是大家都不希望看到的事情。但，人和企业的合作，是双向匹配的，这种情况在所难免，这里只提几点重要的。

关键岗位必须有 Backup，团队 TL，业务接口人，技术建设 Owner，都是关键岗位。如我团队的 TL 、组长们，自这个团队的组建、分线、分梯队开始，就第一时间和大家明确过他们都有自己的 Backup，且会要求各组内同步建立下面的 Backup 机制。

系统性坍塌，是指一个人的离职会导致一批人的离职，比较常见的是某 Leader 离职后带走大批核心，导致对应业务支撑能力系统性受损。能力性坍塌，是指离开了某个人，某项能力就玩不转了，如团队某关键建设基于 A 技术，结果负责的同学离职后，团队剩下的人谁也不会 A，导致这块变成无人能维护，出了问题也无人能解决。每年的人才盘点中，除了要盘点团队梯队、核心的阶段性潜力，更要考虑在岗的可替代成本和流失成本。

熟人场，很重要，也最容易被忽视。离职从想法变成行动，有相当一部分原因，是因为离职同学之前关系很好的同事（有些也是其生活中的朋友）都已经离职了，他周围不再是他最熟悉的人。这背后体现的，是熟人场带来的团队融入度和主观认同感。团队的组织架构调整，TL 调整，和关键核心的离职，都需要考虑对应的影响面。

人：结果

绩效与晋升，都需要对结果负责。

绩效

正如前面所说，我们要尽量做 “绩效管理” 而非仅仅 “绩效考评”。绩效的工作，90% 在日常中的过程跟进，不要本末倒置放在最后的结果沟通时。因为前面内容这部分已有涉及，我只重点分享我对绩效结果认定的一些原则。绩效结果我沿用了阿里系的 3.xx 数字，有些公司是 ABCD 等... 这个不重要，大家能找到参考点就行：

• 3.25（不满足期望）：代表的是无年终、无加薪、无晋升。有些公司还会针对这部分员工纳入 Pro 改进流程，改进不到位就淘汰；有些公司是连续两次 3.25 解除合同。针对业绩不满足期望，一定是其工作有重大人为过失（如因个人疏忽直接导致线上 P0/P1/P2 等重大故障），或是明确不满足团队现阶段的用人标准。
• 3.5-（部分不满足）：这部分我的标准是，有 80 分的能力，却只拿到了 70 分的结果。可能是因为合作态度问题，可能是因为自己跟进不力，总之未能发挥该有的水平，浪费了天赋。
• 3.5（满足期望）：良好完成自己分内工作，属于得努力踮踮脚甚至跳一跳才 OK 的结果，但也没明确的亮点，只是做到了分内事。
• 3.5+（部分超出）：有亮点，除了完成分内事，还带来积极正向的改变，有明确的对外的影响和推动结果。
• 3.75（超出期望）：不止是亮点，更有惊喜。通过个人努力和推动，带来了突破性的变化。

晋升

晋升是一个结果而非目标。简单说，晋升的前提，是能像下一个层级那样思考问题，并在做下一个层级做的事并拿到结果。

绩效好不等于能晋升，前者是拿到了突破性结果，但不代表一定能胜任下一层级的综合要求。管理者也不应该将晋升等同于排队，晋升需要对结果及直接显著的贡献负责。

对于晋升提名通过者，管理者需要进行必要的晋升辅导，如演示稿、陈述内容结构优化的辅导等，必要时还可以组织几场模拟面试，帮助参加晋升面试的同学找找感觉。程序员很多人都是会做不会说，必要的辅导还是需要的。

这里特别强调一下晋升后新的目标的设定。部分流失是出现在晋升后，晋升成功就提离职不是玩笑，是确实存在的局部现象。晋升后，前期的持续努力得到了阶段性满足，新的目标感缺失（有些是晋升后待遇变化低于预期），会加大诱发离职的风险。

层级&要求

对于人，核心重点是明确层级标准和产出结构，结合不同的策略提升组织的整体能力。这其中要求组织上下都能明确不同层级的定位，明确考评标准，面向梯队的分层，制定对应的阶梯式成长计划，提供足够的输入和输出空间，对结果的评定也当是站得住的（有业务落地并带来明确变化）。

我个人对研发 P8 以下的关键性要求及定位见上图。因为大部分团队的构成，都是工程师 ~ 技术专家这个范畴（P4~P7），所以上图也是面向这个范围，高级技术专家以上的部分暂未列入。

工程师到高级工程师的阶段，在做好分内事，从独立执行到能做出亮点。资深工程师到技术专家，是要能由对内转变为对外，能影响到其他人，从影响团队到成就团队，从影响业务到成就业务。高级专家、总监等再往上，是维度的升级，影响到部门之间、业务之间，乃至影响到事业部之间、企业之间、行业之间，以此类推。你看，马总这些年考虑的，都变成全人类的事了。

考评维度的单一，是管理者的大忌。考评什么，就会得到什么。维度单一会导致团队能力单一，核心人员的输入、输出空间不足，诱发流失。考评维度单一，也会客观上造成面向 “履约率” 的“计件式”结果核定，面向层级分配工作量（层级高的多分配几个业务模块），造成团队寒心、失心，严重的会导致团队核心离散。

上图是我在蘑菇街时期，同时也是在政采云时期的一套通用的团队能力建设结构。政采云时期的现阶段，比较蘑菇街时期，在内容上会增益一些。基本的四纵五横九线结构，每一条内又有不同的专项化成长突破方向。每一条线内的点，和每一个不同线之间的交叉点，线本身，线构成的面，都是不同维度、不同 Level 的空间和结果，也都是不同的考核点。每一个考核点，也都分能力成长，和业务收益等不同结果。最后在正常的业务支撑考评之外，再结合这些围绕业务、为业务带来更多可能性的成长建设方向，看同学是在做点的事，还是推动线、面的事，看结果是做了能力的建设，还是建设已经能给业务带来直接的积极变化。

更丰富的维度，更深层的要求，增加维度和复杂度，创造足够的 120% 空间，管理者可以有更多推动改变的事情去做。

岗位能力模型也是一项需要花点心思去做的事。不同业务阶段、不同团队构成，岗位能力模型也不会尽然相同。花点时间思考团队现阶段需要的能力，按照团队实际情况设置不同的段位及要求标准，做做团队的能力摸底，大方向上是能掌握团队现阶段的长处和短板的。基于此可制定下一阶段的内部培训计划、招聘计划等。上图是我团队一个岗位能力模型，内部有个小系统可供团队同学每个季度自我评测一次，并提供主管角度的评测。一是为同学明确能力结构要求和定位长短板，同时也为对称上下级之间能力认识上的偏差。

人的方面，管理者需要基于以上的标准，区分出团队的梯队构成，并对梯队现状有一个了解。上图是一年半前和现在的对比。政采云前端团队的梯队结构，能看到由之前较为明显的金字塔式，转变为现在的纺锤式。相比前者，后者的结构更为健康。

○ 事

事：建设

业务支撑、技术基建，都是建设。

业务支撑

优质高效的支撑业务，是活在当下。做完既定的业务工作，帮助业务达成既定的业绩目标，是拿工资该做到的最基本的事。但做完绝不意味着结果 OK。好的业务支撑，在做完的基础上，还要能做好。深入业务，对业务预期的把握和影响，面向业务支撑的流程、协作等优化，驱动业务乃至正向的影响到业务的产品架构，技术的方式优化支撑业务的基础模式，用更具效率、更优体验的方式为业务带来更多可能性，都是需要考量和衡量的点。

技术建设

必要的技术建设，是为了帮助业务和团队活好未来。尤其是对于前端职能来说，太多的前端团队仅是面向最上层的 “用户界面层” 进行开发，基建也仅是一套三方的开源组件库 + 一套本地脚手架环境，技术范畴很薄，业务影响不深。这也导致普遍的在研发体系的对话中，前端的话语权偏低，处于堆人力的资源型工种，经常被 “资源瓶颈” 的问题怼。

出蛮力的堆人、加班，顶多能带来 40% 的人效提升（看你是 996 还是 997）。希望于数倍的人效提升，需要在业务支撑结构，和面向业务的技术基础建设上找答案。

体系结构

管理者需要带动团队，推动业务方、协作方，优化队伍支撑业务的基本结构，变出蛮力的做事方式，为更聪明高效的方式。相比较一线大厂已经在 Serverless、FaaS、微前端、 AI 机器学习 UI 自动转 Code 的方向上发力，一般的中小型企业的前端团队很难具备这样的基础。面向一般中小企业的前端团队，在大厂新一代解决方案还未成熟产品化之前的现阶段，因地制宜的优化团队的支撑结构，是更接地气的。下图是我团队过去一年形成的现阶段基本策略，仅供参考：

过去一年面向业务迭代的生命周期，政采云前端团队所做的基建相关（点击查看大图）：

业务支撑结构，和技术体系的搭建，管理者要能站在未来看今天。从现阶段的业务情况出发，推演半年、一年、两年后的业务发展趋势，从趋势推演未来，站在未来看今天。假设现在你的团队支撑的是 500 亿的业务，一年半后业务体量变成 2000 亿，那时候你的团队应该以什么方式去支撑？需要什么样的人才结构和底层系统？多推演，想明白这些，优先面向解决高频业务问题的方向去推动建设。

事：视角

前端在研发体系中话语权偏低的现状，从前端这个职能出现那一刻就存在了。不排除个别研发团队，因其业务模式的原因，对前端的依赖较深，前端的话语权相对偏高。绝大部分的研发团队中，前端的工作，在其他研发眼中，往往是 “技术含量低”、“很薄的一层” 等情况。这个现状的背后，看看下图就知道了：

横、纵，2 个维度。先说右边的 “纵”，参考网络应用系统的分层体系，前端的传统工作范畴，都是集中在 “用户界面层”，很少能往下深入，深入到网关 ~ 基础设施层。后端则不同。从这个角度看，前端确实很 “薄”。现在良性的一面是，Node 能力为前端提供了向下渗透的服务端能力。一些团队也基于 Node 横向扩展自身的工程化能力，和向业务纵深去拓展前端的系统化能力。

我们再看左边的 “横”。只有很少的前端团队，能较完善的去建设和发展技术体系。对于有了较完善体系的前端团队而言，其技术体系也更多是局限于前端自身的职能范畴，没能较好的互动渗透到业务侧，更多是在自嗨，业务的感知力是很弱的。将技术带来的工程收益，转变为业务收益；将部门内的技术影响，转变为业务影响；将技术场景，升级到业务场景；将团队的基础能力，变为业务能力。跳出前端，围绕并深入业务，这是每一个正在推动团队体系建设的 Leader 要更多想想的事。

○ 文化

一家公司，最重要的资产和产品，是不断成长的人，和不断成长的团队。而文化，是组织发展的核心引擎。

团队共识

团队共识，有助于帮助团队找到做事的态度和节奏。我的个人经验是，先从团队不希望拥抱的那些问题出发。我们团队的核心成员，曾经聚在一起用了很多时间，罗列出日常中那些反感的行为，并归类总结，反推出团队集体认同的方向、观点，和希望拥抱的行为，落实为我们的团队共识。

价值观

价值观是公司级别的文化要求，价值观必须要落地到考评中，且重点在标准的解读。如下标准供参考：

组织发展维度

下列是政采云前端团队最近 1 年多时间，在组织发展维度进行的建设项，供参考：

○ 影响力

影响力是放大器。对于团队管理者，不能忽视影响力的塑造。塑造影响力，核心抓手是利他性输出。对内的业务支撑优质高效，共建性推动（帮别人拿结果，做大盘子），跨部门的裸心会、吐槽会（增进理解，扩大共识），沉淀分享、定向培训、内部论坛输出等都是有利的方式。对外需要重视品牌化运营，把团队影响力按照做产品的方式去打磨，制定好输出的策略、路径、节奏，找准可相互共利的 “借风” 渠道。

○ 数据指标

一般的团队数据指标，可以参考如下结构：

数据指标的设计，需要在某专项建设的前期即设计好并进行采集，并在整个推动周期和落地后持续收集，这样可以得到一个相对完整的变化曲线，用以作证工作的成效。数据不见得一定是精准的，但数据一定要能说明趋势，直观化结构，准确反馈。

○ 最后，一些建议

管理者是推动改变的人，从最初的执行，到开始承担对改变负责，到逐渐适应，一路上的心路历程和风景各不相同。管理者是火车头，肩上负担着业务、团队方向，及身后一群人未来一个阶段的得失。套用一篇讲企业发展文章的话，“朝哪个方向走，判断的核心是深刻理解市场、业务的趋势。这其中，要对技术的未来做判断，对产品的未来做判断，相对而言，大部分人都能看到技术的发展趋势，困难的是判断未来的产品形态”。运作一个团队，和运营一家企业，异曲同工。管理者，其自身也是创业者。

管理者同时也要面对结构性挑战与周期性挑战，只有活得久才能迎接更大的空间挑战。结构性挑战，是在不同的业务及团队阶段，团队需要发展和落实的结构性能力、体系性能力。人才体系、文化体系、组织架构、技术体系、业务体系，管理者首先要尽量成长为体系性选手，具备搭建体系的能力，否则会压低团队的天花板。周期性挑战，亦是在不同的业务及团队阶段，管理者需要侧重面对的核心问题也是在变化中。草莽期解决无到有，资源压力；快速发展期要快速搭建技术体系和优化梯队；技术体系相对完备时要跳出前端的事业，横向推动和打通，和业务产生更多互动；平台期需要帮助业务和团队在新的曲线破局... 每个管理者必须要务实、要花足够的精力提高自己推动改变的能力。

最后，分享一些在之前的团队管理过程中，看到、思考过的点，作为这次交流结束前的引申参考，和大家交流：

管理者是第一 HR

TeamLeader 的工作范畴，绝不仅仅是分析需求、拆解需求、下派需求、跟进执行过程。团队的组织建设、文化养成、环境塑造、人员培养、招聘策略等等... 都是管理者的职责范畴，HR 是辅助你更好的完成这些工作的。

视人为人

说起来容易做起来难，视人为人，真的能做到吗？有多少企业和团队，还是在拿人当资源，当工具。相当多的管理问题甚至是管理事故，都是出在视人不为人上。

灰度思维

灰度思维的对立面，是 “二元论” 思维。二元论的认知，会让他对很多事情、人际关系的理解，局限在非好即坏、非敌即友、非 A 派即 B 派、要么是帮我要么是整我的角度。实际工作中的人际关系，绝非是二元论这般简单，都是动态的灰度。是放大共同利益，求同存异，做大盘子，还是局限于自己部门内树墙，列位自己品味。

输入与输出

在输出中得到自我认同感与成就感，往往是源于你的能力超出团队和业务一大截。但如果在岗位上，一惯性的在做输出的推动，缺乏有效输入（成长），你可能要考虑下是不是离业务太远了，或者认知维度上局限性过低了，丧失了对更多输入维度的感知。

60 分与 80 分

一般情况下，一个平均分是 80 分的团队，来了一个 60 分的人，大家都会认同这个 60 分的人是个问题。但我这里需要指出企业中常见的另一个场景，为了提升企业或者团队的能力，优化结构，在平均分 60 多分下，招来一个 80 分的人，这个 80 分的人是不是个问题？表明上看，招聘到更牛逼的人对团队发展是好的，但如果落地辅导做的不到位，会导致这个 80 分的人看谁都不顺眼，看谁都觉得垃圾，导致信任关系危机，带来更多问题。

场景与方案

《庄子·列寇传》有一则寓言，“朱评漫学屠龙于支离益，单千金之家，三年技成而无所用其巧”。 讲的是一个人散尽家资学习屠龙之技，学成却发现世界上本没有龙。对于研发同学，同样会存在从方案出发找场景的问题，如想学习 Node 不知道如何学习，照着书中的例子学，最后发现都忘了效果很不好。没有一个作家是看小说看成的，也没有一个语言学家是看字典看成的，同理技术专家也不会是通过看技术书籍养成的。我的建议是，管理者要在不同的维度组织空间，从问题场景出发组织同学产出技术方案，并在落地过程中学习掌握新技术，更有成效。

信任关系

重视信任关系，无论是对下，还是平级，还是向上管理。信任关系会影响事倍功半还是事半功倍，也会影响资源和机会的配比。

Backup

最后再强调一次，任何关键岗位，一定要有 Backup 储备，避免系统性或能力性坍塌。

○ 招聘信息

简历自荐推荐，请发送至 ZooTeam@cai-inc.com