我是程序员程序员互联网科技

前端 Leader 如何做好团队规划?阿里内部培训总结公开

2018-05-16  本文已影响353人  阿里云云栖号

"行成于思,毁于随"——韩愈

在阿里从一线前端工程师到技术 TL(Team Leader) 也三年有余了,最重要最难的就是做规划,你可能会遇到如下几个问题:

业务压力巨大,前端是瓶颈,如何做合适的规划?

如何提高规划的成功率?

规划的雷区是什么?

如何寻找规划的线索?

我的老板不是前端,如何做出被认可的成绩?

今年4月份参加了阿里集团前端委员会组织的 TL 培训(老师都是阿里的前端大牛),为期三天,收获颇丰,特别是关于前端 TL 如何做团队规划方面,整理课堂笔记时,就想结合自己这一年在阿里拍卖业务中的规划实践做下总结。

本文会引用课堂上多位阿里前端大牛老师的观点。

一般技术规划路径如下:

(蓝色部分为本文重点论述部分)

一、先从团队特征说起

做规划,先要定义清晰自己团队的特征与发展的阶段。因为特征不同与发展阶段不同,规划的选择就会截然不同。

1. 识别团队特征

在阿里梓骞老师关于建团队的论述中,有一块团队行为曲线的总结特别好,是团队比较核心的特征。

(上图来自梓骞老师 PPT )

我的团队特征(某财年阿里拍卖业务前端团队):

背景:从淘宝技术部到垂直支撑业务

团队行为:处于潜在团队,共同目标不清晰、协同不够、缺乏长期目标

人员构成:6 人,平均层级偏低

业务发展情况:创业型,高速发展,局部瓶颈

业务重点关键字:DAU、用户体验(业务老大高频强调)

资源富裕度:负,人员严重不足,前端成为业务发展瓶颈

TL 汇报对象:产品经理

当识别完团队特征,最迫切的事往往可以呼之欲出,比如招聘是第一等大事,“废话,给我找个不缺人的前端部门...”,莫急,本篇不讲招聘...

发现上个财年推进的事,印证了团队行为目标:努力将潜在团队引领成真正的团队。

如何做?

寻找团队共同目标

增强团队协同

明确清晰短期目标与长期目标

从团队特征中寻找规划的边界:

清晰的边界与基准、对规划内容优先级判断,对落地成功率有至关重要影响。

二、寻找规划线索

寻找规划线索是最耗时间的阶段,作为 TL 你有可能每天都在观察寻找规划的线索。

寻找线索,除了 TL 本身的思考外,需要具备外交能力,多问,如下图:

可以从四个方向去寻找链接,聊得越多,聊得越透,线索会浮现得越多。

下面针对去年比较有体感的点展开论述。

1. 向上管理

向上管理是拔赤老师比较强调的内容,如果你的老板不是前端,向上管理特别有必要,你需要消除“语言差”、做必要的前端核心概念“科普”。

一般业务/产品老板的关注点是:流量、转化、跳失、体量、用户体验、规模化、模式/产品创新等,要了解清楚现阶段老板的关注点是什么,从自己团队的维度思考试图给出到达路径,这是非常重要的规划线索。

向上管理不是有事没事找老板唠嗑,而是注意沟通的有效与质量,提问题最好带着初步的解决方案,业务/产品老板的时间有限,又存在“语言差”,相对复杂的内容务必准备 PPT。

2. 脑暴共创

脑暴共创是非常好的,自下而上的输入方式,而且你可以观察出下属的关注点,为后面寻找规划项目执行者提供线索。

你可以挑个风和日丽的周末,一整天与团队同学们关在一个咖啡馆或风景不错的会议厅。

因为共创会的成本相对较高,所以需要注意必须是主题式的共创,可以安排上午人员做主题式汇报,下午讨论聚焦。

另外还需要一个控场能力比较强的主持人,防止主题失焦,控制时间,共创需要的是高密度的信息。

除了与下属的脑暴共创,也可以组织与协作方的共创,参加业务方的共创。

3.关注业务痛点

从业务痛点出发寻找的线索,确定规划后一般有充足的时间落地,是很靠谱的线索,但要注意抽象与提取,业务痛点更多是单点的现象,而我们需要做普适性的思考,这样才能充分发挥技术的价值,当然也要避免“过度设计”。

三、价值聚焦

1. 前端规划四问

要解决什么核心业务问题?

创造什么核心价值?

为什么要做这件事?为什么是我们做?

是单点,还是相对通用?

以什么样的模式和方式来解决问题或创造价值?

业务边界,系统边界如何取舍?

问题在集团的大图位置和现状是什么样的?

优势?劣势?

终局思考和实现路径是什么样的?

结合前端,我个人认为有核心四问:

做成了会如何?(核心价值、终局构想)

是我团队最重要的事吗?

有没有更简单的方案?

与业务的链接是什么?

终局构想特别重要,决定了规划内容的价值天花板,圆心老师给我们讲了案例,Pandora.js 做规划时,就要求是开源的,要服务外部应用,这个定位改变了 Pandora.js 从 0 到 1 的结构,如果一开始只是定位于为集团 node 应用服务,那么日后开源必然面临大量改造成本。

在前端团队多年,体感比较深刻有二点,前端容易将问题复杂化,喜欢用大的平台去解决小的问题,前端容易为了技术而技术,与业务“失联”。

2.来自大牛灵魂的拷问

要让评审者学到点什么

在前端技术的横向影响

对业务中其他角色或业务的影响

对未来的判断

是否是重复造轮子

是否是“技术投机”,缺乏业务场景适用性思考

解决问题与痛点,远比构思复杂技术方案更重要,避免无差异重复造轮子或“技术投机”,着重预判规划落地后的影响力与价值论证。

3. 规划推导

规划推导分正推:从线索->本质痛点或问题->解决方案->目标,反推:从目标->解决方案->本质痛点或问题->线索。

二个过程都需要,你需要通过反推,去论证推导与路径的正确性,比如你的目标是提高 50 张页面 50% 的性能,推到解决方案,发现只能提高 10 张页面 10 % 的性能,就会发现解决方案是不靠谱的,需要再思考。

所有的线索都是现象,你需要去剖析现象背后本质,思考:

什么问题导致了出现这些现象?

痛点够不够痛?

解决方案的设计要思考:

调研是否充分,集团是否有现成方案?

是自己做,还是引进?还是引进后二次定制?

预计投入资源,投入产出比如何?

目标的设计要思考:

能够体现规划价值

可量化,可衡量,有影响

可达到

一般写规划时候,我们是先写目标,再写解决方案,而在实际推导规划时,一般是有个大概的解决方案,然后预判可能达到的目标。

举个简单的推导例子(过程做了简化):

线索大部分单点的,如果依照单一线索,做出来的规划也是单一价值,就会发现价值不够大,比如上图,如果只是为了解决设计师的痛点,只做品牌的优化,就会发现价值点很小,而只是解决前端研发效率的问题,又如何深化前端的价值。

所以最后决定打包在一块,项目名是业务有体感的体验升级,目标是业务有体感的跳失率,将前端技术体系的建设包在了里面,同时也解决其他协作方的痛点。

4. 控制力

如果一件事件你也能做,别人也能做,且比你做的好,那么就要想想要不要做这件事。

控制力还体现在边界梳理,能跟其他岗位或其他前端团队合作是非常好的,但一定要理清楚边界,权责清晰才能有效促进规划成功。

四、规划落锤

价值聚焦完后,已经识别出最有价值的事,但未必是团队当下最重要的事,所以有规划落锤阶段,有如下几件事:

规划内容按照重要性排序

产出规划 PPT

产出关键里程牌时间点

排兵布阵、资源调度

李牧老师说,“TL的核心素质是判断力与前瞻性”,这个阶段就很考验着二个能力。

1. 长期规划

价值聚焦完发现可做的事很多,如何办呢?这是好事,就可以试图做下长期规划,可以是三年规划、二年规划,并不是说非得一年建设完所有体系,罗马不是一天建成的,画张三年大图,给自己以指引。

明确团队技术体系的演进方向,穷尽所有高价值的事,每个季度复盘调整这张大图,让团队有共同的目标。

拔赤老师建议 “技术规划以一年为最小单位,每季度做详细复盘,跟的勤,就不怕跟丢”。

2. 勇气与吸引力法则

有时你认为最有价值也是团队最重要的事会受到其他人的挑战,比如有人坚持认为现在资源紧张,不应该额外投入资源去做这件事。

这时就是很考验人的勇气的时候,选择接受,那么这件事就从你的规划移除,人员轻松了,产品满意了,但技术体系、体验没发生变化;选择坚持,那么人员工作强度变很大,协作方说不定会投诉。

你肯定也有面临这种选择的时候,无关对错,但我们需要有勇气面对挑战,做对的事,不要怂。

吸引力法则(你关注什么,就会将什么吸引进你的生活)告诉我们,有勇气去要求,笃定你的判断,有策略的执行,周围自然会发生你所希望的变化。所以关注于对的事,别被困难吓倒。

还有个策略,跟你的老板或上游来个“对赌”吧?

一定要发声营销

技术团队的 PR 意识相对淡簿,而前端团队在业务的影响力又相对较弱,所以特别需要 PR。

发战报是最有效的营销方式,但需要注意个注意点,如果战报对象是业务方、协作方,不懂前端技术,战报需要包装,让他们能看的懂。

别写做了什么技术方案之类,别人看不懂,也没时间看。

技术产品宣传:

技术产品宣传分社区与公司内,办法很多,发放宣传礼品是个讨喜的办法。

去年自费做的二个宣传品:

本文作者:剑平

原文链接

本文为云栖社区原创内容,未经允许不得转载。

上一篇 下一篇

猜你喜欢

热点阅读