从工程师到Leader成长之路

注重沉淀:充实自己

沉淀,是能最直接证明自己有收获的一种方式,可以是文档沉淀、技术沉淀,等等

工作过程中,我们肯定会去做一些技术调研、方案分析与评审,这些东西便可以细细整理成文档,统一汇总到一个地方,比如团队的wiki专栏下,自己能去review,组里其他同学也能查看到。

在一些大项目开展过程中,或多或少会针对某一类问题创造出比较优越的解决方案,可能是一种高性能的实现方式、也可能是一种高效率的调试技巧,这些东西,稍微花点心思,都能将其作为一个类库或工具提供给组内其他同学,以此作为技术点,沉淀下来。

简单来说,可以把握这样一个原则:

  1. 能用文字记录的做事方式方法,就一定不要只靠口口相传!用嘴巴传来传去,慢慢的也就走了形了,俗话说的好,好记性不如烂笔头!

  2. 好用且实用的技术实现方式,能抽取成组件或类库的,就尽量让它最大限度的复用起来,并伴之以尽量详细的使用文档!切莫针对类似的功能,在组内还不停的造轮子!

  3. 多看多写多调研(有时候需要以玩儿的心态去学习);但做技术的,若无实际产出,那只叫瞎折腾,知其然而不知其所以然,效果并不佳

就我个人而言,无论是在百度,还是美丽说,所有我能够去沉淀或者帮助大家一起去沉淀的东西,一定都不会放过。

如文档方面,我们搭建了团队专属了文档平台,有项目设计与实现方案的评审文档、有项目总结的分享文档、有大型项目的排期节奏跟进文档、有技术的调研文档、有团队技术分享的文档、更有团队周报的归档专栏等等。

在技术方面,有符合团队开发规范的集成解决方案、编译工具、开发工具、前后端线上服务监控与报警系统、后端服务性能监控与分析平台等等。

在玩儿技术的这一点,比如Web前端助手(FeHelper)就是在百度做前端的时候,玩儿Chrome扩展,一步步沉淀下来的。记得当时CSDN还举办了一个Chrome浏览器插件开发中国区大赛,这FeHelper也迷迷糊糊拿了个三等奖。

再后来微信公众号兴起,在朋友圈铺天盖地的转发都是只有一个标题,很土;正碰上那一段时间2048小游戏在PC和Wap上特别火,于是我也写了一个放到自己公众号,本着让大家一起能够在微信里玩儿起来的心态,于是搞了一套基于微信公众号分享的SDK,应用到这个小游戏里;这就是大家后来一直在使用的WeixinApi。在微信一直没有推出官方版的js-sdk之前,WeixinApi造福了许多人。

任何形式能让别人看得见摸得着的东西,才叫做沉淀,更是可以用来衡量价值的参考。

做一个项目负责人:历练自己

接受Leader的命令,并能单枪匹马的把产品功能做完上线,这顶多能够算得上能做事,离会做事、懂做事还差得远

如果有一天你觉得自己能够独当一面去负责一个产品功能,不再需要导师和Leader的协助,那么,是时候从更全的维度去历练自己了:主动挑起一个项目,作为项目负责人,将其推行到底!

你至少可以从这几个方面,得到更多的收获,找到更多的成就感:

  • 分析需求,判断该项目需要涉及到的相关角色

  • 组织各角色进行项目需求评审,并分析产品功能上的技术可行性、时间成本等

  • 对需求进行功能模块合理拆分,落实前后端工程师的工作范围

  • 组织前后端工程师进行技术方案评审,并结合需求指定的上线时间判断是否需要分优先级分批次开展

  • 合理分工,产出研发排期,并汇总联调、自测、以及QA的测试工期,统一输出项目的排期

  • 跟进项目进展,结合排期Review项目产出,及时发现风险点,及时调整并通报

  • 较大的项目,更有必要组织定期的站立会,以确保项目整体进展顺利

  • 项目过程中有临时新增需求、或需求变更、或技术实现方案调整,更要能条理清楚的与所有角色进行分析,放眼大局观,结合项目的整体上线要求,输出最终的调整方案,保证项目稳健开展

  • 测试前期,需要和QA明确其中的核心测试点,对于技术实现较复杂的地方,需要明确告知测试的力度,以免测试用例覆盖不全

  • 项目上线前,需要与运维工程师完成一切线上环境部署与配置,确保项目上线毫无障碍;对于涉及到边缘产品较多的项目,更需要考虑到灾备预案情况

  • 项目完成测试后,如果是较大的产品需求,需要和产品同学讨论,是否进行公司内部体验,或者线上小流量(灰度)测试;并提供合理的问题反馈渠道,收集并整理用户反馈,快速优化

  • 项目上线后,需要密切关注服务稳定性,关注用户反馈,稳定后,能进行项目上线通报

  • 组织项目组所有角色进行项目总结,分析各角色在项目配合过程中出现的问题,总结经验教训;同样也记录项目中良好的问题处理方式,最后将项目总结分享到团队;以此结束整个项目!

枪打出头鸟,只要你是带头大哥,项目出现任何问题,Leader必然都会唯你是问,整个项目过程中,必然是会产生压力的!但是,如果你永远都不敢迈出这一步,又怎能知道自己能力究竟有多大呢?胸怀都是用委屈撑大的,大胆承担,没事儿!

所以,大胆去做吧,团队一定都是更喜欢敢于主动挑起责任担子的人的!

四、做一个导师:学会育人

将所有成熟的工作方式,倾囊相授,也从新人身上做自我反省

优秀的做事方式,应该得到传播,让更多的人花更少的时间去变得优秀。工作中,最好的方式,就是在自己成长以后,做一个导师,协助新人一起成长,比如:

  1. 结合新同学的工作能力、业务范围、技术兴趣点,一同分析Ta成长过程中真实存在的阻力(或盲点)

  2. 为新同学量身定制短期、中期、长期的成长规划,定期Review成长得失,及时纠偏

  3. 带着新同学一起去尝试一些大于Ta现阶段工作能力的事情(业务功能、技术Topic等),帮助新同学挑战自己,逐步突破自身的能力极限

  4. 学会放手,做好引导和后备支撑,让新同学完完整整的去搞定一件事;栽了跟斗也不要紧,任何人成长的过程中都应该经历一些坎坷;不经风雨,又怎见彩虹?

  5. 引导并督促新同学进行文档和技术各方面的沉淀,协助新同学在团队里找准自己的定位,站稳脚跟

  6. 引导新同学学会分享、学会与其他角色的沟通技巧、并逐渐学会把控项目的全局观

当然,你也需要从新人成长的过程中,不断的反思自己,新人做的不够好,是我的原因吗?新人做的很好,我有功吗?

  1. 新人某个功能没做好,是不是自己没有提前Review他的项目实现方案?或者自己给他的方案本身就是有问题的?

  2. 新人某个项目Delay很严重,是不是自己没有多去Review他项目的进展?或者自己也没搞明白项目的上线计划是什么?

  3. 新人某个项目Bug太多,是不是自己没有尽到一个导师的指责,为他做好Code Review?或者自己平时的项目就是Bug频出,新人只是效仿而已?

  4. 新人在其他角色面前总是沉默寡言,是不是自己没有告诉他,应当大胆表达自己的想法?或者自己也不敢在人前多说话,自己也怕被拍?

  5. 新人在与其他角色沟通过程中,冲突不断,是不是自己没有教给他更好的沟通方式?或者自己也不会与人沟通,自己也经常与其他角色闹得不愉快?

  6. 新人用一些很巧妙的方法把某件事情完成的很漂亮,得到大家的赞许,是不是自己给了他很好的引导?或者从这件事上面,你发现自己也有不如新同学的地方,你们需要互相学习?

  7. 新同学主动找你一对一沟通,进行成长总结,自我批评,这又是不是你平时的做事方式,让他学会了积极领悟?再或者,你需要思考自己是否具备这样的一个主动性,以及能够批评和自我批评?

  8. 你对你的新同学足够了解吗?你对自己足够了解吗?

一个好的导师,永远都不要担心青会出于蓝而胜于蓝,因为这是好事,这是他的能力,更是你的本事!他若真能胜之于蓝,说明他足够优秀;我们要学会与优秀的人在一起,那样才能更快的成长。

五、密切关注行业动态:站得高才能看得远

技术的革新都是非常迅速的,我们绝不能仅靠项目上的产出来充实和提高自己;码农界聪明的人太多,必须把好的技术思想都吸收进来

逐渐的,需要将自己视作一个技术负责人。当然,若条件允许,可作为团队技术负责;若团队各方向划分较细,可作为某业务方向技术负责人。

多分析团队工作上遇到的一些技术难题,总结并归类,互联网行业发展至今,你所在团队遇到的绝大部分问题,在别的公司必然都经历过了。跳出来,想方法从各渠道了解发展较为成熟的公司、较成熟的技术Team都在用过什么样的方式来解决这一类的问题;虽然不能照搬照抄,但最起码能从中得到更多的启发。

新技术更新的很快,尤其在Web前端方面,不过多久就又出来一种新的解决方案。你应该作为一个技术痴迷者,密切关注行业的动态,看看人家都在搞什么,为什么会出现这么多新的框架、类库、工具等。举个例子,搞明白:

  1. 在没有jQuery之前,大家用原生的DOM也能把功能开发的很好,那为什么会出来jQuery?它是为了解决什么样的问题而出现的?用它与不用它,在项目上会有什么不一样的地方?

  2. jQuery已经很好用了,那百度WebFE以前为什么还要在公司内部搞一个Tangram?是单纯的造轮子,还是因为它的确可实现各种Api定制化打包?对于jQuery的老手,如果使用Tangram,会有些什么不一样的地方?

  3. 后来大家又一致吹捧的AngularJS、Backbone.js、Ember.js这些又是什么鬼?都是哪个公司哪个团队基于什么样的问题才造出来的?他们用这些工具只是因为某一个产品功能,还是说这货可作为一类通用的解决方案而存在?倘若要把它们引进到自己的项目组,是否真正适用?你能从中得到什么启发,大家又能学到什么?

  4. Nodejs为什么会出现?io.js为什么又会作为其分支,单独发展?后来为什么又还是merge到了一起?

  5. 再比如跨平台的移动开发工具,PhoneGAP、Titanuim、Xamarin、以后今年火起来的React Native,为什么解决同样问题的东西,会出来如此多,更新如此的快?最后出来的东西,是否都已经具备了先辈的优良品质?它们所针对的用户群体是什么?为何能得到大众的青睐?它们和原生Native有何区别?

  6. PHP 7都发布了,为什么你们先上服务还在使用PHP 5.3.29?升级PHP到最新版,在代码上是否需要做些兼容?开发上是否和以前有变化?带来的性能提升是否可大幅度减少服务器的数量?

  7. 全文的搜索引擎,Sphinx和Solr都是啥?索引的效率、搜索的性能、对中文分词的支持、以及对实时索引的支持,这些维度都有什么不同?如果项目上需要使用,结合实际的需求,选择哪一个更为合适?

  8. 再比如,你的团队需要对线上服务进行多维度监控,市面上已经存在的Zabbix、Nagios、Open TSDB、或者Open Falcon,是否都知道这些东西能监控到那个层级?线上部署与应用的成本如何?后期的水平可扩展性又是如何?假如你要自己写一个,你能否先画出一张清晰的监控布局图?

总之,闲暇的时候,把技术眼界放宽些,多逛逛Github,或者一些国内外牛人的Blog,看看别人都遇到了什么问题,都在解决什么样的问题,多做一些假设:如果这个问题是你遇到了,你会怎么做?

六、多思考多做事:多一些证明自我能力的机会

公司不是养老院,发你工资,你就必须创造价值。任何一份工作(一个产品功能、一个技术系统、一套开发规范、抑或一套工作流程)都必然有它的问题所在,多思考多分析,发现问题并解决问题,这样才能创造价值,我们也才能成长!

也许你所在的团队就好比一坨浆糊,一团糟,同事们都已懒得抱怨,只在乎工作能干完上线就成。也许你所在的团队一切都顺风顺水,同事们一团和气,工作之余有说有笑,开心的不得了,甚是满足。

但是,世上没有100分的人,必然也没有100分的团队;凡人皆有缺点,团队亦然。不要被乱七八糟的团队吓到,也不要觉得团队看起来太好了,便无从下手!

大家平时的开发方式是什么样的,是否都在重复的做一些体力劳动?如果是,是否可通过开发一些工具来自动化完成?

如果每位同学都自成一套开发体系,这样的代码必然是很难维护的,团队里旧人去新人来,看着各式各样的代码,哪有不抱怨的理?在开发流程和规范上必须要有统一的标准,推动并协助切实执行!

一个线上的技术系统,是不是都因为它是一个庞然大物,不敢轻易调整,所以对于新功能都是不断的打补丁?久而久之,团队里的每位同学必然都只知道补丁,而不知道它真正的功能,真正的工作原理!所以必须要迈出第一步牵头去重新梳理、归置,将核心的部分独立出来,展现它应有的功能!并伴之以详尽的文档说明!

对于一个臃肿的业务系统,是不是大家都因为已经习惯了现在的开发、测试、部署等方式,所以不愿意去做纵向拆分?如果这样的一个系统已经拖慢了工作效率,那就必须动手梳理整治,让它变成多个功能独立的子系统,小而美,业务分明,项目之间更不易产生冲突,可维护性也能大大提高!同时推动团队给每个子系统安排不同的owner!

如果以上技术团队本身的问题不存在,则可以从产品功能的线上服务稳定性着手考虑。线上是否有频繁的报警?各业务日志是否都正常?用户是否对某些常用功能有频繁的反馈或吐槽?总之,能用工具自动监控报警的,就一定不要用体力解决。能够通过工具平台让运营或产品同学自助查询问题原因的,就一定不要再让研发手工去操作。

只要愿意静下心来,从细小的点着手开始分析,发现问题,并利用一切可利用的资源,推动去解决它,不怕事小,只要一件件逐渐积累下来,定能体现出自己的价值,老板们要的就是:因为有你,所以团队变得更好!然而,你这样的收获,是无法简简单单只用金钱就可衡量的,更是别人拿不去的财富。

七、带一个团队:规范化流程化

当然,这也不是每个人都有这样的机会能被提升为Team Leader;工作上可没有裙带关系,哥儿俩感情好就把团队也交给你;必须是你平时的工作已经能充分证明,你具备了带领这个Team一起发展的能力!

当然,在我看来,更重要的是做事,而不是在行政位置上的那个Title;只要你现在正在做的事情,就是带一个团队,至于是否是经理职称,根本不重要。有时候一个小公司的技术总监,到了大公司,也得老老实实的做一线研发,不是吗。你若真牛逼,公司又亏待你了,你走了,那只能是公司的损失。所以,还是老老实实的做事吧,该来的自然会来。

作为一个业务&技术团队的管理者,至少需要做这些事情:

  1. 按照团队所负责的各业务进行清晰地规划,切莫吃大锅饭,还是小团队作业的好;一支精锐的部队,责任感会更强,每个人会更清楚自己要做什么。

  2. 每条业务线,需求范围明确,跨部门的需求,必定要有清晰的界限,保证组内各Team的工作能更顺利开展

  3. 组内各小Team必须有统一的开发规范,攘外必先安内,如果自己Team内部的开发规范都一团糟,提供给第三方部门的接口还如何统一?

  4. 组内各小Team必须有统一的项目全流程,在每个环节都应该注重实实在在的产出(沉淀)

  5. 组内需要沉淀公共的组件库、类库、公共服务层,它必将形成一个团队的主心骨,绝大部分的开发工作都能围绕着它转。如果有一个需求,团队里任何人不需要思考,直接就能完成,那就够了。

八、团队培养与发展:健康并可持续发展

一个大于10人的团队,必须考虑有效的梯队建设,各方向的业务&技术负责人培养

在各业务方向上培养小组负责人,并让该负责人培养自己的Backup

在团队内培养技术方向负责人,源源不断在团队内输出更多可供选择的技术方案

团队内形成良好的导师制度,Leader带方向负责人,方向负责人带一线研发;同时也需要将梯队扁平化,打造一个无障碍的沟通和汇报机制

有团队周例会制度,每周至少保证有一次机会,能让大家聚集在一起,知晓团队过去一周的项目整体状况,以及下周的工作节奏

团队内部必须形成良好的技术分享机制,至少每周一次,可以是大型项目的技术实现方案分享与评审、可以是大型项目的项目总结分享、可以是项目上某技术点的深入分析与应用介绍、可以是某工具平台的构建思路或工作原理分析、可以是工作中必备小技能(奇淫技巧)的发散讨论、也可以是行业前沿技术的调研报告分析、也可以是一些新技术的尝后感、更可以是跨团队甚至跨公司的技术交流。总之,需要让大家切实感受到:在这个团队,有东西可做,有东西可学!

与同学们进行不定期的一对一沟通,助其排忧解难,有问题也要直接指出来,并授之以渔!帮助同学们成长,这是做导师做Leader的职责!

明确合理的奖惩原则,公司不养闲人,也不养不长进的人;与优秀的人一起,团队才能健康可持续的发展

不定期进行团队建设(Team Building),可大可小,需要创造一些条件,能够让大家能够聚在一起,讨论一些工作之外的东西。身心愉悦了,哪还怕代码写不好?

做Leader的,无论哪个Level,就应该想着:你何时才能把自己现在正在做的这些事情,都交给自己的Backup?

只有你自己能完全从团队现在的事情上抽离出来了,你才有机会去考虑对团队来说,更多更重要的事情,这是给Backup的机会,也是给自己的机会。

九、学习一些其他的技术:跨界、全栈

俗话说,技多不压身,用更多的技术知识来武装自己,真有一天要上一个陌生的战场,那也完全不在怕的。

当然,技术工程师成长过程中,全栈并不是必须要走的一条路,不过在深入掌握其中一门技术以后,眼界看得更开些,总是好事。

假设你是做前端的,一个前端Team能完全Hold住了,可以逐渐涉入后端,服务端、客户端,做事的方式其实都一样。不用花心思再去把每一门技术都重新学一遍,只要把该领域内的核心技术摸熟了、其中的工作原理掌握了、与其他领域的区别搞明白了,就够了。

如果自身能力有限,领域,精一门儿足以,用同样的做事方式,融会贯通,其他的技术领域必定不会太难。

回想自己工作的这么几年,先做Java,再做VB.Net、在做C#.NET、接着再做Web前端,一做就是三年;后来又学iOS、再转Android;回过头来又继续带Web前端Team、再带PHP后端Team;说实在的,方法对了,事情也就好办了。

十、关注业务发展

很多行业大佬可都是技术出身啊!

技术改变世界,但没有好的产品意识、没有清晰的产品思路、没有明锐的产品洞察力,不能将技术变现,总觉得自己技术很牛逼,又有多大用?感动了自己,感动不了别人。

展开阅读全文

没有更多推荐了,返回首页