我在 UC 的四年管理经验:从 0 到 200 人团队,不同阶段我都用了哪些姿势?

5.7_.1_.1_.jpg

 
 

 
常常有人问,你在 UC 是怎么走上管理这条路的?从自己一个人到带 200 多人的团队,中间是怎么走过来的?能不能分享一下你这 4 年的职业成长经历?
 
今天这篇文章,算是我的一个正式回答。
 
0 – 5 人:需求管理 & 文化雏形
 
2013 年 5 月,我放弃了刚刚到手的晋升机会,从工作了 6 年的爱立信裸辞,以高级工程师的身份加入 UC 。
 
进入 UC 的第一个正式挑战,是团购导航产品。
 
接下来的一个月,我和另外一个小伙伴几乎没有一天是在晚上 11 点前下班的,好几次加班到凌晨 3 点,回家睡 5、6 个小时,早上起来匆匆吃完饭又继续上班。整个人就像打了鸡血一样。
 
可老天爷并没有因为我们不要命的加班,就眷顾我们。
 
项目上线后不到 2 个月,我就收到了「噩耗」:产品下线!连产品经理也静悄悄地离职了,那个时候我还在做着大卖的白日梦。
 

5.7_.1_.2_.jpg

 
 
这个事情对我的打击是巨大的,我不甘心,千方百计询问原因,得到的答案是:产品需求分析没做好,很多地方没想清楚,数据很差所以下线了。
 
项目虽然失败了,但我的反思却没有停下来:我不比别人笨,我也这么拼命了,为什么我们辛辛苦苦做出来的东西就这样被抛弃了?如果下次还是遇到这样的情况,我们是否还会重蹈覆辙?
 
除了祈祷下次碰上个靠谱的产品经理之外,我自己能够做点什么呢?为什么我当初也没发现产品需求的问题呢?
 
作为一名技术至上者,我第一次觉得 「程序员懂业务,懂需求分析 」是多么的重要。
 
自此我开始自学各种需求分析的技能,后来我把自己关于需求分析的经验,整理为 10 个问题,分批给部门的主管和骨干培训。后面会专门用一个系列来讲。
 
这个阶段,团队虽然只有 4 个人,但我做了一件事情,就是开始向组员灌输团队的「做事理念」。为此我还专门在内网 wiki 上写了一篇文章,向新来的组员解释我对「创业文化」的理解 :
 
专注当下:专注当前工作并做到极致
产品意识:做自己产品的天使用户
数据说话:用数据指导评判策略方案
日省三身:在反思和总结中前进
 
这几个理念一直支撑着我在 UC 的工作,并且随着团队的扩大,逐渐演变为最终的团队文化 —— 「产品工程师」的内核。
 
5-12 人:项目 & 时间管理
 
接下来我们团队又有一个业务,因为各种原因被停掉了。
 
这个时候,我负责的业务只剩下一个:抢火车票。
 
在当时,这个业务对公司、对我、对团队而言,都是不能失败的任务。
 
背水一战。
 
一开始我还能参与少量的研发,但随着广州、北京、武汉三地的产品、技术、营销、设计、项目、法务将近 80 人被卷入这个项目,很快整个项目完全失控。
 
大家都很忙,但没人知道做到哪了
项目啥时候上线,什么时候算完
天天加班,但版本经常 delay
会议繁多,且效率极低
前后端测试人员轮番出现瓶颈
横跨三地的沟通,效率极其低下
已修复的问题莫名其妙又出现了
研发改了逻辑,但测试人员不知道
 

5.7_.1_.3_.jpg

 
 
那段时间我整个人极其焦虑,项目经理也在中途离开了团队,产品经理工作的时间也不长,我老大说,要不我来做这个项目经理的角色?
 
经过大量的复盘后,针对上面的问题,我们做了以下的应对措施:
 
进度可视化:甘特图、白板、晨会
风险评估:引入 MiniRisk 风险评估
需求管理:砍掉大量伪需求
版本管理:结合资源精细化管理
会议管理:参考《高效会议》文章
研发自测:冒烟测试用例
 
这半年过得极其漫长和痛苦,印象最深刻的是:有一天我们千辛万苦完成了一个版本准备上线,突然发现:
 
12306 整个网站改版了!
 
所有的接口和参数都变了,还新增了验证码。几十号人、几个月的工作全都白费了。当时想死的心都有了!但也只能从头开始。
 
幸亏我们最终撑过去了。随着春节的临近,产品日活一路飙升,UC 品牌得到持续曝光。公司年会前一天,我收到了通知:
 
团队拿了最佳团队奖,而我则拿到了个人奖项的最高奖:UC 特别战功奖。此时我入职 UC 还不到一年,幸福来得如此突然!

5.7_.1_.4_.jpg

 
回想起这段经历,我觉得自己最大的收获,是通过这 6 个月地狱式的项目,培养起了几个能力:
 
项目管理能力:作为技术负责人要如何统筹好各方的工作,目标如何拉通?项目关键路径要如何识别?资源要如何调配规划?进度要如何体现和同步?风险如何管理和跟踪?
时间管理能力:每天各种大量的事务和打断,你要如何处理?经常面对各种突发问题,你如何应对?
快速学习能力:整个项目过程中,我除了研发,还客串了测试人员、项目经理、客服人员、用研人员、数据分析人员等等角色。团队缺什么角色我就顶上去。每次遇到新的任务,都需要在很短的时间内了解情况,这个能力对于我接手新业务、新团队都发挥了巨大的作用。
 
12 – 70 人:效率 & 质量管理
 
年会过后没多久,就接到一项任命:整合部门内其他几支团队,统一管理。
 
这几支团队加起来有差不多 50 人,而且这些人都不是我招进来的,每个人是什么情况?有什么优点和缺点?发展诉求和性格脾气一无所知。
 
更糟糕的是,我发现了两个巨大的问题:多数人都是短时间招聘进来的,没有经过统一的培训,做事方式都不一样,技术栈也是五花八门。往往一个开发人员借调到其他组,得花一周的时间才能上手,刚刚上手就又得回去了,帮不上忙不说,还增加用人方的培训成本。
 
我在 UC 的四年管理经验:从 0 到 200 人团队,不同阶段我都用了哪些姿势?
 
第二个巨大的问题是:质量监控。因为 UC 浏览器大多数业务都是和 「网址导航」和「内容聚合相关的,极度依赖于原始网站的有效性。当时我们压根就没有统一的业务监控,时不时发生原网站改版了,而我们不知道,等用户反馈产品不能用了,才急急忙忙修复的情况。
 
熟悉移动互联网发展历史的人都知道, 2013 ~ 2015 可以算是 H5 的一个小高潮。公司高层对于快速探索新业务有强烈的诉求。
 
团队不成熟,技术不统一,质量不稳定。怎么支撑业务的快速发展?
 
苦苦思索之后,在向总经理室汇报年度工作目标中,我只写了一句话:
 
如何快速、低成本地上线新业务?
 
我在 UC 的四年管理经验:从 0 到 200 人团队,不同阶段我都用了哪些姿势?
围绕这个目标,我做了很多事情,核心有下面四件:
 
组建团队的核心班子:矩阵式的分工,确保纵线上业务有人管,横线上各种跨团队事务有人牵头。
把监控作为头等大事亲自抓:从指标定义、采集、汇总、加工、计算、展示、告警一整条链路打通,缩短发现问题的时间。
好钢用在刀刃上:在人力极其紧张的情况下,依然调出最好的前、后端员工,开发了供部门内统一使用的前端框架 Scrat 和 后端 BaaS 平台 NAPI。统一解决前端工程化、后端存储和性能的问题。
做好新人指引项目:牵头在内网上建立一个「新人一周上手课程」,利用一个模拟项目指导新人在一周内搭建起开发环境,了解内部框架,跑通整个发布流程。并通过一些任务驱动新人主动认识团队的其他成员。更快融入团队。
 
经过差不多半年的救火,团队开始走上正轨。
 
在 2014 年底统计各个业务的迭代周期时,我惊喜地发现各条业务线的迭代速度明显快起来了,而且开发新业务所需的资源:逐步降低到最少只需要:一个前端 + 一个测试。到年底的时候,我又整合了另外两支团队,此时团队规模达到 70 多人。
这个阶段,「产品工程师」的文化理念在我脑海中慢慢成熟,通过一次又一次不断的以身作则和宣传,核心班子成员都很自然地接受了这种定位。很快团队形成了独特的气质和技能树。
 
70 – 200 人:组织 & 业务管理
 
2015 年,国际化成为 UC 发力的重点,同年 3 月份我和同事一起去印度调研了 17 天,给了我无比巨大的冲击。
天天跑校园、街头,近距离接触访谈用户。作为用户融入到这个环境中,亲身感受自家产品的使用体验。这种现场调研,比起坐在办公室里等前方同事发回调研报告,好太多了。
 
我在 UC 的四年管理经验:从 0 到 200 人团队,不同阶段我都用了哪些姿势?
 
年底,我接受了国际业务总经理的邀请,将自己亲手组建的国内研发团队交出去,带着几位核心骨干,从头开始组建新的研发部门。
 
这个期间我又面临了一个新的挑战:
 
国际业务部门是由 6 个业务部门组成的。各条业务线都有自己的研发,但都归属不同的研发主管,且平时几乎没怎么往来。如何把这 6 支团队『捏』成一支团队?
 
这个阶段的早期,我犯下了很多错误,后来我把这些错误整理下来,在 UC 内部的主管训练营中进行了分享,后面会再分多个主题来讲。
 
其中最大的一个错误就是:
 
带着救世主的心态去融合团队。认为我过往的经验已经被印证成功了,照搬过往的做法,却不知道管理难就难在「没有绝对」—— 结果自然是遭到了强烈的抵触。
 
好在后来在 HR 的协助下,加上自己的反思,迅速调整了姿态和做法,稳住了局面。
 
2015 ~ 2016 年,海外业务发展非常迅速,我们打了几场大的漂亮硬仗。
 
团队也迅速膨胀到 150 多人,这个阶段,之前的小团队管理做法已经显得很吃力,于是我做了几个管理升级:
 
更重视中长期的规划
从团队管理过渡到组织管理
提炼部门文化和团队价值定位
关注组织架构的灵活性和升级
将招聘 – 面试 – 转正标准化
学习阿里的人才盘点方法
搭建常规性人才流动制度
倡导推动业务技术创新
沉淀分享自己的管理体系认知
 
我在 UC 的四年管理经验:从 0 到 200 人团队,不同阶段我都用了哪些姿势?
由于业务发展变化实在太快,2016 一整年整个国际研发部几乎都是在摸着石头过河,人员的调整和团队的合并时有进行。唯一不变的就是在打仗中学习带队伍。
 
这个阶段,对我来说,最大的挑战是:商业意识和能力的建立。
 
面对同在总经理室的几位成员,我发现大家讨论的都是商业策略、市场销售、渠道推广、品牌营销、成本预算等商业性的话题。这个时候,快速学习的能力再次派上用场。但坦白说,这些方面依然是我目前的软肋。
 
2016 年,UC 浏览器在印度、印尼两个国家的市场占有率均达到第一。
2017 年中,国际研发部人数达到 200 多人。
 
后记
 
在 UC 的这四年,就像是一场超浓缩的职场成长史,我以每半年甚至三个月一次的调整,经历各种挑战,也在挑战中成长学习。
 
我记得最清楚的一句话,是一位老领导对我说:蓬蓬,你坐在这个位置,就不要指望什么事情都有人教你了,你要学会自己去找问题,找答案。
 
另外最大的一点感受就是:职场上,面对新的挑战,你永远不会有准备好的那一天。保持快速学习能力,不给自己设边界很重要。
 
我曾经很纠结别人怎么看我,到底是技术,还是产品,还是管理?现在我完全不在乎了 —— 我就是一个解决问题的人。
 
虽然我离开了 UC ,但我至今依然非常感谢 UC,怀念 UC 的「大五文化」,怀念「同学相称」的氛围。
 
感谢把我带进 UC 大门的 如冰老大;感谢我四年来的四任领导;感谢小鹏 Boss 给我的机会,从你们身上我学到了太多太多。
 
感谢一同奋斗过的兄弟姐妹,我们一起经历和成就了很多美好和骄傲的时刻。
 

作者:林篷蓬

原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/industrynews/257937.html

(0)
上一篇 2022年5月19日 23:32
下一篇 2022年5月19日 23:35

相关推荐

发表回复

登录后才能评论