如何推动与影响中型前端团队的成长 & 暨最近一年多新团队的管理工作复盘

2020/1/23 11:07:42

本文主要是介绍如何推动与影响中型前端团队的成长 & 暨最近一年多新团队的管理工作复盘,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

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

三五年后我大概率走上管理,之前该做什么准备呢?

老板提拔我带前端小组,我内心慌慌该怎么应对?

真有 35 岁天花板么,我要不要坚持走前端这条路?

技术编码做好多年,现在转型管理是对的选择么?

公司业务发展太快,我怎么才能带好 3 人到 50 人?

我老板懂不懂管理,我想看看别人公司怎么做的?...

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

  • 5 人团队 | 竹隐 - 如何从 7 年技术架构走向业务管理
  • 10 人团队 | 志遥 - 如何在小型前端团队的管理中踩坑
  • 20 人团队 | Scott - 如何在中小前端团队中完成管理转型
  • 40 人团队 | 芋头 - 如何带领前端架构团队突破价值困局
  • 50 人团队 | 堂主 - 如何推动与影响中型前端团队的成长

本文是第五场讲师 - 堂主的讲稿文字版,来看看他是如何讲的

如何推动与影响中型前端团队的成长 & 暨最近一年多新团队的管理工作复盘

○ 前言

本文根据 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



这篇关于如何推动与影响中型前端团队的成长 & 暨最近一年多新团队的管理工作复盘的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程