如何在中小型创业公司做前端TL

3,347

一、前端到底关注什么

毕业至今已满三年,机缘巧合,在一个相对比较早的阶段便担任了前端团队TL这样的角色。近三年来遇到了很多人很多事,也自己尝试去做了很多事情,过程中也是有对有错,有成有败。今天回头再来看,事实上都是在试图探索、看清一件事,或是试图搞明白一个问题,那就是:前端到底关注什么?或者说:前端到底为何物?前端输出的核心价值是什么?是什么让前端变得不可替代?

这事实上问的都是同一个问题。针对这个问题,直至今天为止,我能够给出的答案就是:解决用户问题。

二、你的用户是谁

那么,前端的用户是谁,我们要去解决谁的问题?我认为,前端的用户分两类,一类是对内的,其实就是前端团队内部和合作方团队中的每一个人,无论是开发、测试、还是产品运营,他们都是第一批用户,需要帮助他们解决工作效率和产出质量的问题;另一类是外部的,是使用我们输出的产品的用户们,需要解决他们的效率、性能、体验这类问题。

下文中我会分享一些自身的经历,其中包括这三年做的事情、遇到的问题、总结的一些经验,告诉大家我是如何一步步的探索出上面这个答案的。

三、心路历程的几个阶段

1、懵懂期

作为初入社会的小白,一切都是陌生的,一切都是新鲜的。没有体系化思考,也不知道何为体系化思考;方法论的积累为零,也不知何为方法论。

2、发现问题、深入问题、解决问题

工作近三年,对自身影响最大的一句话就是:“发现问题、深入问题、解决问题”,这真的是一句很牛逼的话,完全可以作为一个职场小白前n年的一个核心指导思想,围绕这个思路去做事、去成长。

这个思路对于技术能力上的学习也非常适用,可以从一个问题中去发现一个技术点,然后在这个点上不断深入,不断下沉下去,可以深入到源码层,深入到问题本质。然后由点及面,不断扩充广度,将这些零散的知识连接起来,随着时间的打磨积淀,最终就能形成一个属于自己的知识体系网络。

3、将技术与业务相结合

技术的核心价值是解决问题,没有所谓的“纯技术”,每一项新技术的诞生和演进,都与现实世界中的一个具体问题的发现与解决是相对照映的,只有能够解决真实的场景中问题的技术,才是真正有用的、有价值的技术。

很大一部分技术人存在的一个通病就是容易陷入对技术的盲目崇拜,而脱离了与真实业务场景的结合。解决这个问题的办法就是:一切从业务场景出发,识别核心问题的痛点所在,探索解决这些问题最高效可行的技术方案,而不是拿着技术去找场景,本末倒置。

4、发现业务问题,用技术去赋能业务

工作时间越久,越发会觉得“发现问题”其实是更重要,同时也是更难的一环。我们日常工作涉及最多的领域中,可能并没那么多的困难到技术无法解决的情况,最起码也会有一些折衷的、临时的方案可以解决。我们面临的问题是,无法透过现象看到本质,找到那些藏匿在深处真正的痛点所在。

这种当局者迷的状态很多时候会影响到我们去发现问题、优化用户效率和体验,可行性比较高的解决方案就是:跳出来,把自己当做小白。从旁观者的角度,置身事外去观察,去做自己团队研发出来产品的深度用户,去体验合作团队的日常工作流,用这样的方式去发现问题可能会更容易、也更深刻一些。

当真正的问题被识别出来后,我们开始思考如何用我们擅长的技术能力去优化、解决这些问题,可能是提高了效率,减少了成本,优化了性能等等。

5、发现技术本身的局限性

当你做的事情足够多了以后,你可能还会发现另一个惨痛的事实,技术不是万能的,很多时候技术的好坏,对一条业务、对一个公司发展的贡献事实上并没有你想象的那么大。换句话说,商业模式的成功与否,事实上与技术能力的高低关系不大。

听起来是不是很惨痛,很消极?但这是否就意味着技术无用?那肯定不是的,我认为这个现实给我们更多的启示是,当技术人成长到一定程度后,要开始跳出技术这个圈子的局限性,不要给自己设限,而应该主动去拥抱更多未知的领域,也就是所谓的跳出舒适区。如果仅仅将自己局限在技术这个领域里,甚至前端技术的领域里,那肯定是将自己的路走窄了,你从这条路上获取成就感、认同感的难度会越来越大,并且时间越久困难和焦虑会越大。

技术的能力是有限的,那我们技术团队里要做的就是集中团队力量,解决关键问题,将有限的技术资源利益最大化,做到对业务的赋能,让技术的价值在我们的现实场景中去充分体现。

四、技术上做过的几件事

1、前端基础设施和工作流的完善

我刚加入前端团队时,公司也正处于初创阶段,技术上一切基础设施都近乎为零,工程化、自动化能力也几乎没有,大多数工作都要靠纯手工、人肉操作的方式去完成,工作流方面也基本是没有任何规范的约束。但这种状况就意味着这是个糟糕的团队,十恶不赦吗?其实不然,我反倒认为这种极致简单、灵活的工作方式事实上很适用于当时还是处于初创阶段的公司状况。一切都需要从简,用最快速、最直接的方式投入到业务试错中,说不定这个月还在做的项目下个月方向就会发生大转变,还用讲什么基础设施和工程化?这时简单的复制粘贴、快速出活才最有效最靠谱!

后面随着公司的业务快速壮大,我们面对的场景也变得日益丰富,前端技术团队基础设施缺失和工作流不完善带来的负面影响开始逐渐显露出来,技术上的瓶颈开始出现。此时,我们针对面临的实际问题,通过搭体系、理流程,定规范,完善各项基础设施,丰富工程化能力和自动化建设,并对前端应用做了大量的性能优化,在监控方面也略有涉足。至今为止,团队的各类基建已经相对比较完善,足以应付现阶段的业务压力和复杂度,并为了下一步的发展也做了一定的储备。

2、前端规范体系的建立

团队如果缺乏规范,每个人就会按照自己的行为习惯和自我意愿去自由行事。当团队中人员较少、彼此之间工作相对独立、相互协作较少时,这并不会带来太多问题。但当团队内人数越来越多,项目开发需要多人同时协作时,这个问题就会被无限放大,成为阻碍团队进步的绊脚石,并且会拉低工作效率,严重情况下还会带来线上环境隐患。

首当其冲要解决的问题就是,多人协作的代码提交、Git工作流规范问题,当时最先考虑的是直接照搬大厂流行使用的一些成熟方案,但稍一尝试便发现这些十分成熟的规范对于我们而言其实有些过于繁琐、不灵活,并不适合当前的团队现状。因此我们还是基于当前团队的情况和问题,定制了我们自己的代码提交、合并和发布规范,从流程上避免了多人协作时出错的隐患,并利用一些自动化脚本工具,拦截一些分支合并错误、代码冲突未处理等这类低级失误的出现。

另一块比较重要的内容就是编码的规范,我们通过在团队内部经过半年多的打磨和多次讨论review,制定出来了一整套的前端研发编码规范,包括Eslint、Stylelint、Prettier等等,并封装成方便引入的npm包的形式,将公共规范继承到项目的配置文件中,最终覆盖到前端团队的所有工程代码,保证了团队内部代码风格的一致,让开发同学可以更多的去关注代码质量与业务实现,而无需太多关注最基本的风格、命名等琐事。

两年多以来,我们逐步搭建了前端团队的整套研发规范体系,从评审、设计到研发、联调、验收、测试、发布,打通了整套产品研发流程的各个环节,保证团队成员在每个环节中都“有法可依”,保证了日常工作的稳定运行,团队也无需再为规范流程不完善导致的错误去踩坑埋单。

3、前端工程化的推进

团队初创时,前端工程师部署项目代码使用了一种非常简单粗暴的方式,就是代码写好之后在自己本地机器上完成构建编译,生成dist文件之后,在git上提交代码,通过web hook即可完成发布。我们也因此尝到了苦果,犯了很多错、加了很多无谓的班,各种因为环境差异、代码冲突、代码回滚、操作失误所导致的问题越来越多。最终,我们与公司的运维团队协商之后,快速搭建了前端项目的自动化发布平台,将代码置于远程构建,屏蔽环境差异,支持了一键发布与回滚,并对构建速度进行了多次优化。后来,还针对微信小程序应用特殊的上传及送审操作,个性化定制了该领域的自动化能力,最终也支持到了微信小程序的自动化打包、预览和送审功能。

在提高研发效率上,H5、微信小程序、PC后台这三端的UI组件库也随着技术和业务的发展逐步沉淀了下来,至今已有几十个组件可以支持到业务开发中去使用,很大程度上提高了前端团队的研发效率。基于丰富的组件库,我们还在上层搭建自己的CMS管理系统,支持快速产出运营活动H5页面,进一步做到了对业务的赋能。

除此之外,我们还抽象出了符合公司业务诉求的前端项目工程脚手架,集成了上述的所有规范体系和工程化、自动化能力,帮助快速生成和搭建各端的项目,也在一定程度上提高了团队的工作效率。

4、前端性能优化的逐步落地

产品研发初期,我们并未在其性能、用户体验上投入过多精力,而是尽全力保证业务的快速迭代和试错,而当业务实现稳定增长、用户量达到一定规模时,各类性能问题也被暴露出来,成为我们关注的重点。微信小程序的黑屏白屏、长列表卡顿、闪退等大量问题开始集中爆发,一时间让人无所适从。因此在去年一整年中,团队成立了专门负责性能优化的项目组,解决此类性能体验问题。关于如何解决小程序性能问题,我们大致的思路分下面三步:

1、因为微信小程序框架技术实现的黑盒特性,我们无法得知一些底层性能瓶颈产生的细节原因。因此,我们先试图去深入了解小程序底层的技术实现,想办法寻找可以去做性能优化的切入点。我们安排了团队中两名技术能力很强的同学,通过对编译混淆之后的小程序框架源码进行深层逐行剖析,结合官方文档中给出来的一些零散信息,最终提炼出一些易导致性能瓶颈的问题隐患点,总结出我们如何去规避和优化的编码方式和避坑指南。

2、我们以业内一线优秀电商产品诸如某狗、某多作为参照学习对象,分析了它们在性能、体验上做出的一些工作,在各类运行环境、网络情况下进行测试,观察他们面对这些问题时做出的措施,作为我们对标的参照。

3、结合上面收集的底层技术资料和业界相关参照信息,我们针对自己的小程序当前存在的问题,制定了多项性能指标,拟定了我们自己的优化目标,分多期逐步迭代,从视图渲染、图片加载、接口聚合、渲染层和逻辑层通信、代码分包等多个维度逐一进行优化。

最终我们在小程序性能优化这件事上取得了一定的成果,尤其在首屏渲染速度、内存告警率、低端机降级这三项关键指标的数据上效果显著,实现了用户使用的基本性能和体验保障。

5、通过优化架构提升整体效能

业务蓬勃发展,历史包袱同时也变的越来越重,旧的项目变得越来越庞大、越来越难以维护;新的孵化项目又如雨后春笋般地快速长出,开发资源难以协调,依赖现有的技术架构已经很难满足当前的业务诉求,技术的瓶颈重新出现。因此,我们又开始致力于对前端技术架构体系进行优化,并抽象出一个个中台业务模块,通过这种方式来实现进一步提效,解决当前阶段的痛点问题。

针对C端小程序应用,我们一方面沉淀出自己的业务研发框架,将登陆授权、分享、路由、请求、存储、监控等基本能力置于底层,让开发人员投入更多的精力关注业务代码;另一方面还将一些复用性高的业务流程抽离出若干个页面级应用出来,以npm插件生成H5页面的形式,嵌入到小程序或者App中,支持新业务用配置化的方式快速接入,例如电商系统中的订单、物流、售后、客服等业务模块,都是一些不错的使用场景。

在中后台业务中,我们面临的最大的痛点就是“巨石应用”的问题,微前端/微应用的技术架构成为一个很好的技术方案,我们对已经线上运行超过两年的一个运营后台系统,根据业务模块去划分,将其拆分10个左右的微前端应用,完美解决了“巨石应用”难维护、易出错、效率低的问题。同时,我们还沉淀出一套JSON配置化的组件框架,解决过去HTML模版难以维护的问题,通过JSON配置化的方式,自动生成HTML页面的表单和列表内容。

近期我们还在新的微应用架构体系与技术基建之上,对各个业务进行了中台化重构,将通用逻辑进行封装,业务差异化部分对外暴露自定义配置,实现了老业务易扩展、新业务可以快速接入的目标。

五、如何快速落地拿结果

在以结果为导向的大前提下,作为团队TL,需要特别关注的一点就是,如何帮助团队以及团队中的同学在项目开发上完美落地,拿到应拿的结果。在这件事情上,我个人总结了三条经验:

1、小步快跑,快速落地

我们经常在业务繁忙的同时需要做一些技术上基建设施,以提高我们的研发效能。这些技术基建工作一般可能会需要大量的时间和人力成本。例如,我们需要开发一个完整的前端异常监控系统,就可能需要多个开发人力的连续工作投入,这对于大多数快速发展中的团队而言,是很难具备这种条件的。那么我们就会采用一种小步快跑的方式,不做过大、过早、过度的设计,先用最少资源成本投入,去换取一个简单可用的版本,然后立即投入业务场景中去使用。接下来要做的就是在上面提到的“发现问题-深入问题-解决问题”这个理论上不断去打磨迭代这个产品,最终达到一个比较满意的状态。这样做还有一个好处,就是你的方向不会跑偏,很多技术驱动的项目很容易在深入的过程中脱离实际场景,导致最终的结果出现偏差,我们只有通过不断的去做阶段性复盘、总结,在实战中去验证,才能保证工作产出的准确与有效。

总结一下就是,给技术产出先找好业务的阵地,看看有没有可以借力的地方,不要重复造轮子。快速验证这个方向的正确性后,再逐渐多加投入、丰满技术设计。不要自己YY、默默地做完,这样做出来的东西没有业务场景埋单。

另外还需要特殊提醒的一点就是,并非所有问题都得通过技术手段去解决,技术能力只是我们的一个优势、长板,但并不意味着技术是我们的全部,有些时候有效的沟通、协调,同样能够帮助我们解决很多问题。代码很棒,但代码并不是全部!

2、做好向上管理

其实无论是大团队的TL还是项目研发的小组长,我们都在做管理的事情,要做好管理很重要的一条就是对上解决问题,对下拿结果,向下管理可能是大多数人很快就能想到的,但如何做好向上管理呢?你是否知道你的上级也是需要你去“管理”的?

这里举一个真实的例子,可能会比较有体感。同学A和同学B各自在做一个很有价值的前端技术驱动项目,两个人的做事方式和拿到的结果却是大相径庭:

同学A:团队研发的C端小程序在性能体验上遇到较大瓶颈,常有用户反馈白屏、卡顿等问题,严重地影响了用户的体验,于是安排同学A组织一起深度的性能体验优化项目。在做之前先在组内大致分析了这次要做的东西要解决哪些问题、要用哪些方法、需要协调哪些资源、拟定哪些量化指标、预计能达成怎样的效果等等,然后在执行的过程中,每周都会将项目的进度、投入的资源、遇到的问题、潜在的风险都以项目周报的形式详细的同步出来,等项目上线之后还会持续跟进,继续将上线后的各类指标数据进行收集统计,新老数据在各个维度进行对比,验证上线效果,并收集各方意见,准备下一期的迭代内容。

同学B:前端团队在异常监控这块比较有欠缺,生产环境常有一些bug排查定位起来效率很低,于是交给技术能力比较强同学B来解决这个问题。B同学做了一些调研之后,便决定开发一套纯自研的监控体系,大致内容就是从零开始,从前端到后端全栈开发,并支持自定义定制可视化图表,方便用户查看数据。说干就干,于是开始每天加班码代码到很晚,悄无声息埋头苦干近两个月,除了自己之外也没有人知道他在做什么、做到什么程度。到了月末,产出了一个看似强大、完善的系统,但结果却是几乎没有什么人在用,也没有解决什么实际的痛点问题,对业务的价值几乎为零。

很明显,两种不同的习惯与行为方式,给人的体感是完全不同的,最终的效果也会存在比较大的差距。更重要的是,失败的向上管理不但会影响到结果与目标不一致,还会影响的团队内部的沟通效率与信任感,长期以往不去纠正的话,对团队和个人的负面影响都是巨大的。

3、OKR管理工具的使用

如果团队中只有不超过5个人,那么大家坐在一起,可以很容易地就快速产出一个目标和方向,执行过程中的沟通成本也会很低。但如果团队规模较大时,就务必得借助一些工具进行管理,帮助我们更好、更准确的在团队中对需要达成的关键目标结果达成共识,并且可以有效地追踪达成目标过程中的投入产出与进度风险。

OKR就是这样一个可以帮助到我们的工具,与KPI不同的是,它并不是为团队制定绩效指标,也不会与个人绩效考核挂钩。OKR关注的是制定一个自上而下的大目标,团队可以对这个大目标进行层层拆解,并通过若干个可明确量化的关键结果去描述和验证这个大目标的完成度,这样做的好处就是一旦在团队内部达成了共识,大家就可以普遍明确现阶段的工作重心,技术和业务上的工作也会有一个正确的方向,避免出现信息上传下达不通畅、目标不明确的情况,干起事情来也会更有激情、更有动力、更有成就感和认同感。我们团队中过去一年尝试了对OKR管理工具的使用,虽然实际落地效果和预期还是存在一定的差距,但我认为作为工具它一定程度上已经起到了它的作用,确确实实地帮助到了我们,解决了不少问题。

六、怎样面试选人

搭建自己的团队,第一件要做的事情就是招人、面试,我有幸在自己才工作半年多的情况下就接触到了这一领域,这对我而言是一个极大的挑战,因为我要面对的绝大多数是一些工作经验、技术能力、各方面沉淀都要远高于自己的候选人。因此,只有学会去站在更高的维度上,去与候选人进行沟通探讨,才有可能做到更为准确的考察对方,发掘出真正适合自己团队的人。

随着自己经验的不断增长,各方面能力的提升,以及在面试经验上的日益丰富,我也总结出一些自己在面试考察这件事上的一些经验方法:

1、避免一问一答式的考试

很多刚开始做面试工作的技术面试官同学,很容易陷入的误区就是将面试变成一问一答式的提问,类似于学生时代的考试,事先准备好一套题目,尤其是一些自我比较熟悉或者强项领域的知识,甚至是一些直接从网络上copy来的面试题。然后在面试过程中就去一条条地过一遍,最终按回答正确的命中率来评判这次面试的结果。事实这并不是一种高效、准确的面试方式,一方面对候选人体验不好,仿佛是在用一条条的知识点来衡量一个人的能力好坏;另一方面对面试的结果可能也会不利,这种固定死板的面试题是很容易被预测的,候选人可以事先做一些准备,营造一种自己在某处很擅长的假象。

记住一点,面试并不是面试官和候选人之间的PK,然后用PK的成功与否决定面试的结果。面试应该是一个求同存异的过程,双方在沟通中去不断互相碰撞思想,彼此去考量对方是否是自己接下来想去长期共事的人,价值观与公司团队是否契合,双方是否能够有一个高度接近的目标方向并且在接下来一段时间内的协作方式上可以达成共识。只有这些方面都彼此相对契合时,才能对这次面试的结果做出一个相对比较准确的决策。

2、STAR法则

上一条提到对候选人的考察不宜用简单的知识问答来考察,那应该如何考量一个人的能力高低呢,答案其实还很明显的,就是解决问题的能力。那么面试官又该如何在面试环节中去评判候选人解决问题的能力呢,一般我们会推荐使用“STAR法则”,引导候选人去描述自己过去在解决一些问题上的经历,通过这种方式,去收集自己想要获取的信息。

“STAR法则”分为四个环节,分别是Situation(问题背景)、Target(目标)、Action(采取行动)Result(最终结果),这里就不详细展开去介绍,网上有很多系统化的介绍和教程。这个法则的主旨思想还是在于我们前面多次提到的:如何用技术解决一个实际场景中的业务问题,然后我们去观察候选人在描述这个解决问题的经历的过程中所表现出来各方面的素质和能力。

3、聊些别的

面试中除了考察技术、业务理解、以及一些团队协作相关的能力之外,我一般还喜欢问一些工作之外的事情,从其他方面去全方位了解一个人,这样获得的认知才会更加立体。例如我会常问候选人最近在看什么书、喜欢运动健身吗、有没有长期和短期的规划、有没有什么迷茫和困惑等等。总之,面试不是考试,而是双方在为自己挑选一个接下来很长时间都要一起共事的伙伴。

上述这些技巧和方法,不光在面试过程中可以借鉴和应用,还可以在工作日常中与团队同学做沟通、聊天谈心时也作为一个参考,引导团队的同学去描述自己在解决的问题、遇到的麻烦、获得的收获等等。

七、绩效怎么打

绩效考评是目前大多数公司都会采用的一种员工考核方式,用来量化评估员工的阶段性工作产出与个人成长。团队TL则是绩效考评的直接执行者,一次绩效打的“漂亮”与否,很大程度上能够体现出这个团队TL管理的相关素质和能力的程度高低。会有一部分TL把打绩效看成是一个老大难的任务,觉得出力不讨好容易得罪人,或者走形式主义,不痛不痒想蒙混过关。事实上打绩效对团队TL而言是一次很好的深入团队同学,发现问题,进行沟通,彼此之间建立起联系的渠道。对于TL自身,可以对团队内部进行盘点,总结复盘发现问题;对团队同学而言,可以对自身做一次阶段性总结,查漏补缺,做好向上管理,对齐目标,了解团队下一阶段的重点方向、自己需要努力的方向所在。

在这里,我根据自己这近三年的经验,加以一些案例,总结出几个关键词,可以帮助到TL打出一次“漂亮”的绩效。

1、管理第一

其实上面提到的考评或者打分,只是整个绩效管理中的一小部分而已,要想真正的做好绩效考评与打分,整个绩效管理周期的各个环节与细节都至关重要,换言之我们不仅要做好绩效考评,更要做好绩效管理。

绩效管理一般分为绩效辅导,绩效面谈两大部分,两者之间息息相关,密不可分。其中绩效辅导我们一般按照“GROW法则”去执行,即与被辅导的同学之间就Goal(目标),Reality(现状),Options(方案),Will(承诺执行)这四个部分达成共识。并且要特别注意的一点是,过程中要尽量避免自己主观地去帮同学制定方向,指手画脚,而应该是作为一个教练的角色,诱导其自发地去思考这些问题并得出结论,只有内心自发产生的意志,才会更积极主动、更有执行力,别人强加灌输的思想是很难获得认同感的。另外辅导沟通的过程中给予同学充分的尊重也是非常重要的,一个相对私密、舒适、良好的周围环境能为你一次谈话的成功奠定基础。

到了绩效面谈环节,基于之前已经达成共识,此时能够比较容易地给出一个公正的评分。需要注意的是在真正的谈话开始之前,务必做好事前通知,这样能够给双方都留下思考和准备的时间,对于TL而言可以预先制定好此次谈话要达到的目标,以及自己所需要准备和搜集的信息资料。谈话过程中需要注重谈话技巧,面对不同类型、不同经历、不同性格的同学,方式上都会有差异,关于这一点我下面会分享一个案例。谈话结束后,双方需要达成一些共识或改进建议,如果其中有一些需要书面签字确认的,也要务必要当场执行完成。这一点在不同公司和团队可能会有差异,具体细节可以事先与HRBP做好沟通,避免沟通结果和预期出现偏差。

2、发现问题

无论是在绩效辅导、还是在绩效面谈的过程中,发现问题都是一个至关重要的关注点,同时更重要的是,需要通过引导的方式,让团队同学自己去发现自己的问题。然后我们再去结合问题本身及目标,识别出中间的差距所在,制定相应的改进计划。而对于一些在沟通过程中态度不积极或很难靠引导就得到有效反馈的同学,TL可能需要更多的去关注对方的一些内心诉求。

例如今年在和团队中一名女同学的一次面谈过程中,遇到了类似的问题。这位同学平日是一个比较乐观开朗的女生,业务能力还算过关,但是在团队基建和一些技术项目上参与度很低,容易给人一种没有技术追求,不思进取的印象。一番讨论和引导之后,她也能说出自身现阶段存在的一些问题,但当到了总结改进计划的环节,我发现无论如何引导,这位同学都很难思考出一个比较合理中肯的方案,支支吾吾,有种有苦难言的感觉。于是我结合平日对这位同学的观察,和事先收集的一些合作方信息,立马意识到问题的关键所在,就是这位同学在自身技术能力上缺乏自信心,所以当团队中有一些技术建设的机会出现时,虽然有兴趣,但是担心自己会出错,没有勇气去主动接触和承担,最终导致自己的参与感和存在感都不够强。于是我针对提升基础能力与技术深度这两方面对她提出一些辅导建议,商量得出一些改进计划,很快便达成了共识,她也欣然接受,愿意通过努力做出改变。

3、心要慈刀要快

当团队中有同学与团队的契合度很低,或者长期难以达成共识,此时选择离开未免不是一件能让双方共赢的事情,切忌捉摸不定态度不明确,或者有所隐瞒、沟通不诚恳,最后都会导致惨淡收场,双方不愉快,误人误己。

我的团队中也出现过类似情况,有位同学在加入两年以后,个人的成长方向、发展兴趣与团队的大方向上发生较大偏离,长期很难在团队中找到自己的定位,干的不是很开心。于是我找机会尝试与他沟通,共同分析探讨之后发现其实换一个环境对这个同学而言才是更有利的选择,最终该同学找到现阶段更适合自己的新环境,并对我们的团队留下了很好的印象,大家私下里仍然保持着不错的沟通和联系。

记住,如果你不是一个真正善于操纵语言技巧的人,那么请拒绝善意的谎言,我们需要不加掩饰的将自己的想法用最直接、最诚恳的方式传递给自己的伙伴。

八、关于未来

工作三年,带团队两年半,这种比较特殊的经历让自身成长路线和大多数技术人相比较,多少显得有些“非主流”。自己当前待改进的地方现在也是心知肚明,比如说业务sence还不够强,业务思考还是过少;自身技术债欠下不少,技术细节上的深入不足,最近也在积极补课。好处就是很早的就尝试去站在更高的维度去看人看事,明白了解决人的问题大于解决事的问题。另外,也会注重于建立起人与人之间的连接,用关注人的方式去解决团队的问题。

前阵子一位公司前辈告诉我的一段话,对我颇有帮助,大概是这么说的:何为成长,成长就是不断地在看清一些过去自己无法看清的问题和事情,然后伴随这个过程不断有收获,偶尔还会有一些意外的收益,仅此而已。对我而言,还有在这个过程中结识的这群兄弟,与他们之间建立起来的联系,都是我成长过程中最珍贵的收获。

关于未来,我还要做的就是继续不断地去发现自己的问题,解决这些问题,实现自我价值获得认同感。如有余力,还能帮助到身边的人们发现问题、解决他们的问题,让他们也能更好地工作和生活,如此足矣。