著作权归作者所有。商业转载请联系 Scott 获得授权,非商业转载请注明出处[务必保留全文,勿做删减]。
Scott 近两年无论是面试还是线下线上的技术分享,遇到许许多多前端同学,由于团队原因,个人原因,职业成长,技术方向,甚至家庭等等原因,在理想国与现实之间,在放弃与坚守之间,摇摆不停,心酸硬扛,大家可以找我聊聊南聊聊北,对工程师的宿命有更多的了解,有更多的看见与听见,Scott 微信: codingdream。
本系列共 15+ 篇,此为第四篇务虚篇,篇幅可以缩短了一下,大家看完后点下关注,再转发下朋友圈我就心满意足了。
正文开始
小菜前端团队经历多次的新人进入。比如校招过来的实习生,社招过来的有经验的工程师,包括我自己作为 8 年老司机,刚进小菜时也是新人,小菜近 1 年半大概进入了 6 位新人,还有正在招聘要进来的 8 位新人。本文基于新同学自身经验所表述的观点(行文风格因人而异,请大家理解),我把这些观点进行了聚合和整理,转述到这里,同时也会加上作为老司机的思考。
步入社会之后,工作开始成为生活的一大部分,与我们所相处时间最多的往往是身边的同事。在这样的环境下,如何与身边的同事融洽相处、如何在一个新的环境下快速成长以及融入团队,成为了每个人工作中必经的阶段。
小菜前端技术骨干的典型特征
一个技术强的团队,一定是靠技术骨干撑起来的,先来看下小菜技术骨干身上所具备的特征,这也是小菜对前端工程师提出的更高的要求:
- 较强的学习能力:前端这些年飞速发展,不断有新的解决方案涌现,无论是 Node.js 社区中丰富成熟的框架库,还是 ReactNative 跨系统开发 App 的能力,提高前端数据接入效率的 GraphQL,包括新的产品形态下的端场景,比如微信小程序/公众号,凡是提高效率的手段,在 ToB 的业务场景下都需要积极研究,谨慎落地,这就需要工程师有快速适应的能力,以开放的心态拥抱社区的优秀方案。
- 较强的项目合作能力:生鲜 B2B 的流通路径及链路非常长,每个节点上都能长出产品,这些产品背后也有着全新的业务概念。而这 7 款 App,不同的前端工程师都可能参与,参与时候所合作的业务方/产品/设计/服务端也都不同,需要工程师跟合作方有效率的沟通,快速消化理解产品的交互形态和背后的业务路径,才能在项目中有效的发现和解决出现的问题。
- 跨端编程和体验优化能力:不同的端意味着不同的物理设备和使用场景,也意味着不同的用户人群。比如 PC 端跟 App 不同,iOS/Android App 跟微信小程序又不同。它们背后的技术栈也有差异,比如宿主环境、布局原理、系统规范、接口能力都不同,这就需要工程师对不同的端都有理解。不仅在编程技巧、工程健壮性、跨端组件复用上面有较好的实践,同时对于用户真实的端交互方式和使用体验也有更加准确的判断。前端是在用户体验上最接近用户的群体,因为前端的工作就是用代码来输出体验。
- 创造性的工程基建能力:尽管在工程保障和线上运行稳定性上面,社区工具也不断推陈出新,但新轮子叠旧轮子,并没有一个系统化的方案。尤其是小菜的主技术栈是 2015 年才面世的 ReactNative,甚至是小程序,在这方面更为匮乏,这就需要前端工程师利用 Node.js 这个顺手工具来在团队内外,业务流上下,快速研发贴合 ToB 工程场景的工具系统,保障前端的研发效率和线上产品体验。
怎么融入这样的一个团队呢,我们听听大家的看法。
标准融入的 SOP 流程
针对这个命题,有童鞋根据自己的过往经验,总结了如下几点:
- 了解团队
- 适应团队
- 融入团队
与之并行的是:
- 了解技术
- 熟悉业务
- 进入项目
前者是人,后者是事,就像是标准操作流程,以上的几个环节折腾完,基本就算是融入一个团队了。比如了解团队,是可以像销售一样去调查大家的爱好的,然后来做整理输出给大家,这个过程可以快速了解所有人的兴趣和方向,比如小菜在非常早期做过这样的一个小调查:
基本上很快就知道了所有人当前预期的职业方向,这可以为之后跟不同人聊他的话题打下很好的基础。我们再回到新入职的时候,可以更具象的来脑补这样的一个融入画面:
一般新入职都会有一份入职指南,一个老司机和你大概讲一下就说:“你先自己看一下,有什么不了解的再问我”,那我们究竟要看什么呢?
- 首先要了解的就是团队的一个大的宏观的战略方向,这一般是一个长期的稳定的,所有团队成员的奋斗目标;
- 其次要知道团队平时都要承担哪些任务,又有哪些压力,项目的节奏,这会让你更快的适应团队;
- 然后就要了解和技术相关的内容了,都使用哪些技术栈,有哪些业务场景,eg:PC, h5, RN, 小程序, node...
可能有一些是你有过实践的,有一些是不熟悉的,这很正常,不要盲目的去看去学,要和 Leader 稍微沟通一下,了解可能接下来需要你接手的项目与你比较擅长的地方相结合考量一下,知道了你将要做什么就可对症下药了。你接手第一个项目的过程就是一个很好的融入团队的开端,在这期间不忙的时候你就可以看一下之前的项目中的一些代码,一些 UI 组件库,工具库都是怎么实现的,有哪些常见的业务场景试着去探索一下,也可以和同事相互讨论一下。
接下来我们继续深入探讨本文的核心命题:如何快速融入技术强的团队?重点是技术强。
充分挖掘自己的优势与强项
如果你进了一个技术强的团队,每个人身上都有那么多优点,都有那么厉害的技能,这会给自己带来很多惊喜,但反过来也会带来不少压力。毕竟单点比较的话,总是感觉比别人落下一大段距离,这时候需要正确调整自己的心态:如果你能经过一道道面试被选择进入这个团队,说明你一定也比较厉害,至少你也是个好苗子,而一定不是一名平庸至极的选手。如果是那样的话,就算能进来,你依然过不了试用期,最终一定会被整个团队刷掉。
以上是基于能力的正确认识。但它不是全部,我们要知道,融入更多是指人的融入,而技术则只是技术。既然是人的融入,我们就要把眼光放大到整个团队和人的上面,特别是自己身上。因为往往一个工程师最后入职团队,抛开能力一定是他/她的其他特质可能也能弥补这个团队所欠缺的,比如你:
- 是一个幽默气质的逗比小话痨,可以在茶余饭后工作缝隙调动团队气氛,发动话题,营造更轻松愉快的氛围
- 是一个酒桌上的老英雄兼游戏达人,会喝会玩,可以利用聚餐团建和喝酒的同学玩翻天玩嗨皮
- 是一个对业务和产品非常敏感的人,可以主动出击去撩产品和业务童鞋,输出更多思考给到团队
- 是一个工具效率黑科技折腾侠,可以分享更多有趣有用的知识和方案,帮整个团队提效闪亮双眼
- 是一个协调和攻略达人,可以在 outing/小型活动 扮演主持人和当导游,带团队各种游戏与轰趴
- 是一个电子竞技游戏达人,可以把更多游戏世界的有趣新闻/攻略/背后的研发故事分享给团队
- ...
举一个 Scott 2010 年刚参加工作的小例子:我进公司没多久,作为团队新人,其实归属感和荣誉感是比较弱的。看到公司有人在组织上山清扫垃圾的公益活动,我就主动加入后从志愿者慢慢成为领队,连续组织了近三年的活动,甚至还组织了我所在的大部门去往徽杭古道包括环西湖等大型的公益活动。不仅我所在的部门甚至其他部门也都有很多人来参加,结果是结识了更多不同岗位的人,也很好的锻炼了自己的社交能力。在团队内的影响力也自然有很大提升,与此同时我还组建了公司的足球队,作为队长组织球队踢了二三十场的球赛,队友之间有了非常铁的革命感情,同样通过比赛个人的社会人脉也有了很大的扩展。
还有很多很多套路大家可以继续发散,在团队融入这块,外向型人格的同学会更有优势,这也是很多技术团队所欠缺的。因为通常程序员会更朴素冷静沉稳,热情满满风风火火随时嗨翻天的童鞋比较缺少,而这些特质其实很多同学身上都具备,只是自己没有把它可以放大而已。
对于内向型人格的童鞋呢,优势和机会也有很多,大家发现我上面没有把纯技术能力的优势放进来,对于内向型人格的同学,技术讨论/技术分享/技术影响力/技术的行业趋势/技术的应用场景等等都是可以尝试的方向了,只要自己擅长或者只要自己有兴趣潜心研究,都有无数的方法,可以给团队注入不可或缺的新想法和活力。
简而言之,每个人身上都有无数的特质和优势。只要你具备的这些特质是团队刚好欠缺的,那么就缺什么补什么,不要保留不要畏惧,即便结果不那么尽如人意,你在团队老大的眼中已经迈出了重要的一步,起码在认同感融入这个层面就已经成功了。
通过执行力来输出自己的责任感
在没有了解足够多的团队工程技术栈之前,以及在没有理解足够的产品和业务之前,往往对于新人最大的挑战就是任务的及时完成。这个任务可能是独立承担,也可能是有一个小组长分配给自己,或者是与别人共同完成,头几个月的完成度和完成率非常关键,在这个过程中的责任感的传达是关键中的关键。
而责任感传达的最好方式,就是你的执行力和主动性。执行力就是说到做到,无论是要通宵还是要周末无休,拿到结果就是底线。同样主动的沟通进度和上报风险则是一项软技能,不能因为好面子或者怕失去信任而强行大包大揽。这样造成无法完成的结果,对自己对团队都是不够负责任的表现,所以在拼死完成和必要的风险上抛求助之间是要有一个度自己反复拿捏的。
把赞美体现在代码上
工程师是喜欢被别人夸代码的一群人,无论他的技术多厉害都不会拒绝这样的赞美,除了口头的美誉还有很多可以尝试的方式,比如到团队的代码仓库里,多花时间把不同同学的代码都看看,一个是可以帮助自己更了解这个团队的代码风格和质量,更重要的是这是一个极佳的了解别人技术深度的机会,在翻阅别人的代码的时候,看到不懂的地方可以做个笔记,凑合适的机会可以当面请教下,还有一个更有意思的动作就是对写的让自己眼前一亮的代码,进行在线评论,赤果果的表达自己的崇拜之情,比如 “这个去重函数还可以这样封装啊,真是开眼界了!” 等等这样的崇拜脸,有了这样的尝试,可以让所有技术好的同学对你产生好感,进而更愿意接受你的求助。
同样,当自己在项目中参考别人的代码,也可以把引用信息备注到注释里,标明是受到了谁的启发诸如此类,如果再 open 一些,可以把这段参考别人实现的地方截图发技术大群,向别人炫耀自己遇到了一个很好的代码实现,用这种方式来为原作者博得更多的成就感。
往往打动别人才是迈出的第一步,而打扰别人往往成为你走出去的最后一步,两者的区别大家可以仔细品味下。
将代码仓库视为藏宝地
每一个团队的每一个仓库,背后都有它神秘的故事,所有的故事细节都埋藏在 commit 记录里,如果想让自己快速融入整个团队的技术栈里,必要的代码 review 是必须走的一步,这一步可以用寻宝的心态走。既然是寻宝,就一定是先粗筛选找出最有价值最有技术含量的仓库和组件,甚至是框架或者通用方案,定位这个仓库后,让自己一边看源码咀嚼里面的设计思想,一边用文字记录这个过程,也就是为这个仓库编写一篇技术实现分析的文章,通过这种方式,不仅让自己对原来团队的宝贝仓库代码更有理解,更重要的是,这个文章的团队内部发表,可以快速的激起大家的兴趣,任何一个点都可以拿来跟仓库的维护者进行一些形而上的讨论,从整个过程里可以进一步获得到他们原本深思熟虑的精髓思想,而这些思想,如果你没有经过自己的整理和理解,完全靠他们主动灌输也是很难消化的,但经历了这样的整理过程,你不仅会收获别人更多的输入更容易理解原理,也会获得更高的人气,更多的仓库的作者都希望被你 Review,这种事情当你做过后,你会发现自己可能比团队更了解团队,至于技术的提升,更不是问题了。
浏览代码宝库的另外的一个好处是,可以更快的在大脑中建立当前团队缺失的地带,形成一些方向性的建议,比如我对小菜前端早期的代码仓库盘点后,列出了很粗的可以做的大事情的大时间轴,其实就是缺什么补什么,也就是当时最原始的大计划:
大计划
第一阶段 - 2017.7~2017.8
- 至少 2 个项目全部代码规范化
- 仓库分支协作规范落地
- App 发布流程锁定权限规范化
- 组件化服务器与组件化框架方向落地
- 仓库协作周报系统上线
第二阶段 - 2017.9-2017.10
- RN 打点 SDK 集成
- RN 项目单元测试录入
第三阶段 - 2017.11 -2017.12
- issue 工作流落地
- 资源轮转实现补位练习
- 打包发布系统优化及对接
- 发布及热更新系统重构
基于这个大计划,我们一边尝试一边摸索,过程中又启发大家抓住更多机会点,结合不同同学的思考和建议,就很快形成了我们自己的套路版图:
又比如这里面的堂哥 - 一个自动生成周报的系统,我们的一个同学 review 代码后,通过代码梳理了它的流程:
这个流程又被他反复优化,最后服务于整个团队,带来了很多便携性,所有这些事情,或者说是机会,其实都是从历史代码仓库,与大家沟通以及讨论共创后收到的惊喜,而它的起点就在于代码仓库这里。
适当的制造一些惊喜
惊喜总是能让人眼前一亮,耳目一新,而适当的制造一些惊喜,对于融入团队有很大的帮助。比如你接手一个项目,又快又好的完成了项目并且还跟进了项目的后期效果,最终让合作方对你乃至整个前端团队都建立了新的好感和认知,那么这就是对于团队的惊喜,再往小一点,从家乡带一些特产来跟大家伙分享,也算是一种惊喜。
所以惊喜不一定拘泥于工作,也不拘泥形式,只要团队因为你的到来,而大幅度的或者小幅度的发生一些更好的变化。无论是整体研发能力还是气氛的营造都变得更好,那么你的到来注定是被所有人拥抱欢迎的,融入过程中的障碍也就更小了。
小结
我们简单探讨了新人融入团队的几个常规路径,以及快速融入可以尝试的三个办法:第一是让自己的优势弥补团队的短板;第二是让自己的执行力和责任感给团队成员注入一针信任剂;第三是制造一些惊喜让团队因你而变得更有趣。那么无论你的技术在团队内是强还是弱,你会更容易融入这样一个技术强的团队。
最最后,本文作为预热篇,旨在针对如下话题为大家输出:
把团队蛮荒到自动化运维的从 0 到 1
成长历程总结输出给社区,帮助更多的小团队少走弯路
以一种可被量化的方式汇聚小菜前端的困惑、沉淀与方法路径,给团队带来更多创作成就感
从更多视角侧切进入团队管理/技术演进/个人成长的过程中,探讨工程师团队的价值最大化
如果大家感兴趣,我们小菜前端团队,会集体智慧共同凝聚,一起撰写并推出一本偏前端职业生涯、技术成长和团队成长的小册,回馈给大家,大家在文后记得留言评论和提需求哦,还有别忘了加 Scott 微信哈: codingdream。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。