阅读 1679

我在北京这3年前端团队Leader经历。

看过很多文章,大多数是讲大公司(BAT)如何管理,设置怎样规范。感觉跟我的经历稍有不同。在这里记录我在中小型公司(80-300人)的经历。我的经历不代表就正确。欢迎交流讨论。

背景


2016年初来北京,经历了3周20家公司的面试,有巨坑的公司也有好机会看走眼错过的,确定了现在任职的公司,大约100人左右,办公环境还、待遇也满意,我作为公司第2位前端入职,后端有将近40人。

入职后才知道公司想转型,前端后分离开发使用vue框架,招我就是为了改革引入新技术。咱有之前2年angular1.0 vue1.0 react等研究经验也并不是很抵触。上就上吧于是就开始了我这3年技术管理之路。

刚开始后端是几乎是抵触的,开会讨论中最多的问题就是:"你这个接口安全怎么保证? 开发速度还没不分离快呢,还要联调改bug。遇到这种情况我都是随便笑一笑也不说什么(因为我也不知道说啥)"。3年后会上只有前端在唠叨了:"活太多,你们后端做不分离吧,分点任务?后端偷着笑一笑什么也不说"。

前端团队从2人 一直发展到10多人。从单枪匹马我自己就是规范,QQ传文件发布代码,没有代码管理工具等状态。发展到统一基础框架、eslint、typescript、 jenkins自动发布、git版本控制、前端错误监控、不定期组织交流培训…………等等!好像又跟网上其他文章一样了。我一直在想做为前端Leader真正重要的是什么?真的不断引入新技术就OK了吗?前不久我去美团面试时面试官会问我:"你的管理经验心得是什么?,你既然走管理路线为什么不去考个pmp?",面试回来我就在想,我考个pmp就能当管理了吗?不我这3年经验告诉我肯定不是这样的。下面我就列一列我认为管理应具备的重要能力。

1 No.1 与人交流的能力 做管理 == 做人


喂喂醒一醒,别活在梦里了,天天研究技术,为人处世都不管了?技术人最大的劣势就是沟通能力吧?在公司这3年看过太多其他团队管理失利,他们最大的通性就是不会为人处世。与同事之前关系处理不好,工作积极性降低交付延迟。马爸爸说过:"一个团队成员离职最大原因无非两个,一个是钱另外一个是受委屈了",大家好像都很关注钱这个原因,而忽视另外一个受谁的委屈?我认为受的大多数是直属领导的委屈。

团队Leader如何处理好同事关系呢?

  • 工作上公平公正。任务分配要合理,不要有偏袒,随时关注询问任务量是不是需要他人协助。不要以为别人不知道自己干多少活,干活太多都会委屈的。

  • 争取利益。该为同事争取的时候要争取,核心团队成员的利益一定要把握住,工资、升职、福利等,不然团队会涣散。

  • 大方。不要太计较个人利益,如果公司没有团建你就不自己组织了吗?作为Leader就应该自掏腰包请大伙聚一聚!你要是特抠门谁会真心实意跟着你干?有的时候几顿饭比100次一对一谈心要管用的多!

  • 放下老大架子。升职Leader底下捧你的人一多自我膨胀,不知道自己是谁了。自己说的话就是金言金句,这是最大的忌讳。尤其是人多开会的时候要注意给手下人留面子,一言一行要小心一些。往往当管理后人都会自我膨胀容易排斥他人意见。要放下面子多聆听同事的想法。只有大家捧你你才是老大,没人捧你你什么也不是。

  • 向上沟通。当管理向上沟通很需要技巧,做事要及时汇报,有想法要用数据说话,也要注意聆听领导想法,不要左右领导的关键想法,做好自己的专业范围内工作。这一块我做的也不是很好,需要继续学习。

  • 不要过多询问同事私生活。你当领导是有权利,但同事请个假就不要过分深入原因了。不要觉得自己当领导就应该知道对方所有想法。有的时候你也不一定能打听到真实原因,何必呢还不如放手吧互相信任一些。

  • 充分放权,并随时协助。做技术的就不要管的太细,事无巨细的去管,人家还会觉得你很烦。完全交给他信任他在关键的时候去帮一把就可以了,让工作氛围轻松一些。人家也好有问题的时候可以毫无顾虑向你请教,工作会更顺利一些。就怕有一些管理什么事都要管一下,恨不得就自己上,而且还说一些不好听的,人心涣散就是这么来的。如果不信任对方,当初招聘就不要招进来。

  • 真正做到为大家着想。能一起当同事那是很大的缘分。可能会在一起工作1-3年,也许离职以后不会再有交流了,但比同学在一起合作的时间还要长的多。不要把同事当成过往云烟。要用心对待。这都是人生该走的路,该交的朋友。你一辈子能有几个同事呢?以后没准可以互相帮一把呢。不要为了自己利益,好来好走能帮一把的时候帮一把。

这几年看到过很多不重视处理同事关系的反面例子不在这里叙述。团队就像是自己孩子,你不管它它就不管你,人都是相互的。很多领导就是想不明白,不断坑在这里。

2 No.2 团队招聘 标准要想清


团队招聘绝对要重视起来,这个可能影响着你当前公司整个职业生涯的走向。重视不意味着严格。好多公司面试造火箭入职拧螺丝的现象太多了。你要想清楚你到底要招什么样的人?你是否有决定权?我认为这个现象的其中一个原因可能是直接招聘领导不亲自面试让手下去初选,大多数面试官面的人太多以后都懒的面了吧?另外一个是总拿自己当标准。自己成长高了以后标准也越来越高。

团队Leader怎样做好招聘?

  • 看清楚面试者的为人。我认为性格最重要,如果不是什么高科技的项目,只是增删改查的话,你还是多看看对方人品吧?比如你是否能hold住?对方是不是听话?性格是不是沉稳能抗事?爱不爱学习?这个都要从面试中一点一滴的去考察去判断。不要一股脑的认为对方技术好什么性格都可以。入职后你会受罪的。

  • 不要用自身水平标准去面试。尤其是当自己研究方向越来越偏离一线业务时,就不要拿自己的标准去面试别人。自己一定要形成一套固定的标准面试题来去考察候选人。很多面试官今天看了篇文章学了个什么知识点,或者自己做了个东西框架、库,明天就用在面试上这是最不合适的做法。如果你实在没办法改变,那就叫一个稳重的同事去面试好了,也多给人家点锻炼机会。

  • 想清楚我到底要什么样的人? 有的面试官问问题很随意,想到哪说到哪。也不看看对方简历上人家会不会这个问题?这样很突兀啊。简历上最近没怎么用node。 你就非问人家node都有那些api ? node底层原理? 要不就是你给我写一个Promise实现吧?要不你给我写个这个吧那个吧?各种靠背的理论题,你到底要什么样的人?好好想一想,在本上写一写定一个绝对标准。基本从简历中就能看出个七七八八了,不要等面试的时候才挑三拣四。简历要看清楚,节约大家时间,对方大热天/大冷天的跑过来面试一趟也不容易。

招聘不要墨迹,不要过分仔细,不要用自身水平做标杆,高于自己就高级,低于自己就不合格。想清楚自己要什么样的人,能维持团队稳定的挺好,能带来新技术的也罢。最终都是服务公司的业务。

3 No.3 团队交付力


技术再高大上,交付不了也完蛋吧?技术服务于业务,不是卡业务脖子。满足业务的前提下尽量提高团队技术能力。这个不同公司业务要求应该不一样。作为Leader要想清楚这个尺度在哪里。听说朋友一家公司因为某某某review 有几个空格标点符号没过延迟上线推迟1-2天,天天为了多个空格少个空格在哪争论。又有的为了绩效的封装了一套前端UI层框架大家严格按照这个去做。实在感觉没有必要。

  • 技术选型要根据实际情况。 使用新技术都是有成本的,选型要根据公司实际情况来,要考虑:是否能提高团队整体能力?团队成员能力是否达标能够快速使用这种技术?能为团队带来什么好处?不要为了自己绩效就胡乱上技术。我认为比较好的做法是,遇到了问题现有技术无法很好解决且很大程度上增强团队能力的时候就上新技术。我简单列一列我们公司在1-10人发展历程中团队的变化。

1-3人 : 团队成员较少,技术不成熟,现阶段偏向使用。

3-6人 : 团队初步形成规模,有一定技术积累,现阶段偏向交付与多人合作。

10+人 : 团队已成规模,技术积累较多,现阶段偏向提高整体能力和开发规范化。

这里讲到的都是我团队中比较常用的,还有一些深入到开发细节(性能、技术、组织、编码、测试、UI审查等)的规范可以参考其他文章。我这里就不提了。主要还是要评估当前团队的规模、水平、公司的要求、或其他各种因素来综合考虑是否需要改进。不同时期不同团队都会有所变化不能一味的去套其他团队做法 。

4 No.4 Leader个人技术能力


身边一些人升职做管理本身一线开发就少,在不加强学习,慢慢的越来越边缘,只会指挥。如果你有技术傍身的话还是有很多好处的。 比如技术厉害,团队更易管理,团队成员更依赖你的技术输出。如果你技术水平跟团队成员差距较大,不服众谁会真心实意听你的呢?比较常见的话是:"看那个领导又在哪吹,什么都不懂。瞎指挥"

Leader增强技术方向

  • 一线业务接触少了,可以多做基础服务服务团队公司,监控平台、通用组件、基础库 等等,锻炼自己架构能力又增强代码能力。
  • 提前实验性研究一些现在公司还没用到的技术,例如 ssr nuxt、网站首屏加载优化、单元测试、集成测试、typescript等等。提前预研用到时可以很快的投入生产。
  • 写技术文章博客,巩固积累知识。分享给团队成员或组织培训效果更好。
  • 看书,看各种书籍。
  • 参加交流会,尤其是带团队一起去参加,一起讨论。

总之就是一句话:"你丫技术好一点吧,别太菜。"

最后


还有好多内容没写,会跟其他文章趋同暂时就写这些。做个好管理不易,既考验技术又考验与人沟通的能力。希望所有Leader能放下浮躁,一点一点的把事情做好,这样整个大环境也会越来越好。能开心的应对每一天的工作不是一件很棒的事吗?

关注下面的标签,发现更多相似文章
评论