如何让你的工程师不要厌倦工作?

496 2020-07-02 145
如何让你的工程师不要厌倦工作?

作为一个工程师,我从来没有在同一家公司工作超过两年。每换一份新工作都是一次很好的职业变动,在这个行业里跳槽如同家常便饭。但是我的前东家们对我的离去并不开心,他们其中一些人花了很大力气想要挽留我,但是我已经对一成不变的工作感到厌倦了,真的不想在同一家公司再待下去。

如今我成为了 Enki 公司的合伙人与 CTO ,同时我还要负责在公司里面打造工程师文化。我工作内容的一部分就是确保我们的工程师不要对工作感到厌倦,就像我过去那样。

在团队的帮助下,我们设计了一整套策略去帮助工程师们对抗工作中产生的厌烦情绪,并将这些策略运用到了公司的实践当中。距今为止这套方法还是挺管用的,因此我想要和大家分享一下。

在 Enki 我们的工程师很幸运地一直从事着具有挑战性的工作。我们有很多有趣的事情需要去写程式,还有大量有意思的问题极待解决。因此如何解决「无聊」这件事情对我们来说并不很紧急。但是所有的工作都不会一开始就让你感觉厌烦,无聊这种情绪是随着时间推移蔓延开来的,并且会在最糟糕的时刻爆发出来。

这就是为什幺我们从公司成立之初就开始着手预防这类问题,并依靠建立起一种企业文化去帮助我们的工程师克服工作中产生的无聊情绪。

下面就让我们总结一下为什幺工程师会感觉工作无聊,以及如何避免发生这些状况吧。


1、专案时间延续太长,学不到新东西

引发工程师无聊情绪最常见也最明显的原因就是一个开发专案拖得时间太长。

我在自己的第一份工作中就充分体验到了专案时间过长带来的无聊感。我的团队要做的是通过一个通用 API 去处理金融数据。一开始这项工作确实令人兴奋,因为这些数据十分複杂且规模庞大,很有挑战性。我从这项工作学习到了如何高效分析数据以及 API 接口设计。但是在一年之后,我们依然在针对相同的资料库工作,使用的也是同样的技术。我在这一针对性很强的领域已经成为一个专家了,在这项工作中再也没有什幺新东西可以让我学习。

我不可能再去别的团队或者专案,因为公司感觉把我留在这个专案里才是最合适的。我明白在这个专案中现有的数据与技术已经用的太顺手,所以不可能被替换。我无法说服公司仅仅为了让专案组成员学习新知而改变原本使用的技术。我向公司表达了自己的这种厌倦情绪与沮丧心情,但是无济于事,那幺我只好换一份有挑战的新工作了。

如何阻止无聊情绪的产生?

在我们的团队里会试着避免让任何一个工程师接触相同的程式码、产品或者资料库超过三个月的时间。将时间设定为三个月也许比较武断,对于大公司来说这段时间可能也太短了。但是我们相信让工程师在不同专案中快速轮转是正确的。

为了实现这一设计,我们在公司里提倡一种全能工程师文化,团队里的每一个工程师都能够承担任一部分的编码工作。

预防无聊情绪滋生的另一个方法就是开诚布公地讨论这个话题。我们每週都会进行一次直接、开放的一对一谈话。如果一个工程师在工作中已经感到太过舒服没有挑战,或者是已经在这一方面过于专精,那幺就是时候让他轮转到另一个专案当中去了。

2、维护程式码这种遗留问题让人感觉太无聊
如何让你的工程师不要厌倦工作?

你能够很清楚地分辨出何时专案就开始进入了维护模式,不论是从正式的渠道还是别的途径,只要当你的工程师花上了 90% 的时间去修补 BUG 而不是开发新功能,那就代表着他们已经进入了程式码维护期。有人会说维护程式码是一项不可避免的工作,老旧的程式码需要不断得到支援。开发软体就像建房子,你总是需要维护和翻新房子的,不是吗?

既是,也不是。这项工作确实需要有人去做,但是问题通常会出在工作态度上。

我曾经的一位职场前辈对于维护程式码具有强烈的抵触情绪,他理所当然地认为维护程式码这种事情根本没有什幺好做的,软体开发完毕之后就让它们自己去运行好了。生活简直糟透了,你还不得不适应它。

如何缓解这种抵触情绪呢?

专案开发工作进入无聊的维护模式有时候是由于糟糕的技术决策与缺乏勇气的双重作用。

一个拥有着複杂的依赖关係的庞大整体程式码库需要额外的付出时间去做维护工作,于此相反的是,一个架构良好的微服务基础设施拥有更强的灵活性。当一个微服务架构出现缺陷时,你可以立即採取措施去修复。你可以重新写一遍程式码,使用不同的编程语言或技术。通过这种方式,你会学习到新的东西而不是仅仅在遗留下来的程式码上修修补补。如果你的架构不允许你重新来过,你还可以採取别的措施来改善,并且在这个过程中学到一些 DevOps 的技巧和运维这两个领域的合併,可将原本笨重的开发与运维之间的工作移交过程变得流畅无碍)。

想要解决工程师在维护程式码中产生的无聊情绪有很多种方法可供选择,公司採用微服务战略只是其中一种可行方式。还有别的公司会通过打造智慧工具去让程式码维护工作变得更有效率也更有意思。一个比较极端的例子就是 Facebook 对他们的海量 PHP 程式码库所做的工作。 Facebook 开发了他们自己的编译器以及带有 Facebook 风格的语言,这使得他们的 PHP 程式码库不仅便于维护,也改善了工程师的工作体验。我猜想这种方式并不能完全解决程式码维护的遗留问题,但是它确实让这个工作听上去更有趣了。

3、工作只剩下複製/ 粘贴这种小儿科的东西

工程师所做的工作就是不停写程式码。

我在之前的工作岗位上曾经产出了大量没有什幺意义的程式码。比如说我曾经为数据集成而编写了 Groovy 与 Python 脚本。这些数据相当複杂,包含了许多不一致的资料库对象集合,因此也不能够自动化运行。鉴于此我不得不编写大量程式码,我的同事都猜想我肯定从中学习收穫了很多。

然而并没有,为什幺会这样呢?

因为 50% 的程式码是我直接从 Stack Overflow 複製粘贴过来的。还有 40% 的程式码是从其他脚本中複製过来的,有一些来自我同事的程式码,还有一些是我之前写过的。工作变成了一种重複劳动,其中没有一点创造性与学习长进可言。

我们如何避免这种情况?

作为一个团队,我们都会花时间去了解团队其他成员写了哪些类型的程式码。我们在程式码审查、同步以及工作回顾的时候去完成这件事情。如果一个人花了一星期时间却只写出了毫无创造性的程式码,我们就会试图去弄明白在他身上到底发生了什幺。

如何让你的工程师不要厌倦工作?

有时候问题的根源来源于你所用的技术。我们可能使用了过多的脚本,或者是做了许多本不应该做的配置工作。如果是这种情况,我们就会添加更多的自动化设置。有些时候我们进行程式码的複制粘贴是事出有因的,在这种情况下大家就会一起分担这项不得不完成的无聊工作。
4、只能使用内部工具也太没劲了

作为一个工程师,我们喜欢打造一个自定义的内部工具来解决某些特定问题,因为动手创造是一件令人兴奋的事情。而且,构建一个定制化的解决方案通常要比找出一个现有的方案进行再利用要好得多。

然而相比于学习一门时下流行的开源技术,学习一个内部专有工具的趣味性只有前者的十分之一。这到底是为什幺呢?

因为它不能成为你和朋友聊天时的话题,你也不能到处吹嘘,你不会在 Hacker News 上读到关于它的新闻,你也不可以在黑客松活动中使用它,当然了你也不能将其用到自己秘密开发的副业专案中。

很多公司都跌入了打造内部工具的陷阱当中,因为它随之而来的就是给工程师带来更多的无聊情绪。换句话说:你为了解决一个短期问题所开发的内部工具反而带来了更多后患无穷的长期问题。

在我的上一份工作中就对于这个问题有着切身体会。我被限制只能使用公司自己开发的针对大规模数据集成的 DSL 语言,而我此前一直学习的完全是另一种 SQL 语言。我更希望能够用上哪怕是 Spark 这样开放程度没那幺高的语言。如果不使用内部工具,我将会 10 倍投入工作,写出的程式码也会 2 倍优于现有的水平,还会让我的生产力提高 5 倍。

什幺样的企业文化能够避免这一困境?

在我们公司中不会对开源技术抱有偏见。如果能够重新利用相关开源技术,我们当然很乐意去做。我们不会迴避前沿技术,一旦开源技术变得足够成熟能够取代我们现行的专用语言,我们就会立马抛弃原有的客製化程式码投向开源技术的怀抱中。在我们自己开发的定制化程式码变得足够通用之时,我们就会将其开源。

这幺做也偶尔会犯错。比如说我们曾经使用过一段时间 agenda.js 去安排我们的后端工作,因为感觉这种技术既尖端又令人兴奋。但是不久之后它就变得太过複杂了,我们只好重新用回了之前老旧但是可靠性更高的技术。即便如此,我们依然不后悔曾经尝试过,因为这也是一种宝贵的学习经验。

5、如果不知道自己为何写程式码,必然厌倦工作

糟糕的人力管理也是造成工程师对工作心生厌倦的常见原因。更具体地说就是:针对工程师的自上而下的独裁式管理会让他们产生抵触情绪。

心怀良好意图的管理者经常在不知不觉中就使用了这种独裁式工作方法。尤其在一个开发专案进行的不是那幺顺利或者是截止日期临近之时,这种管理方法就更为常见了。在巨大的专案压力下,管理者很自然地就会缩短团队讨论时间,减少头脑风暴,直接命令工程师去写程式码,却不解释为何这幺做,也不接受任何争辩。而管理者通常这幺做的出发点就是想要节省时间,尽快完成工作。

如果这种管理方法能够被理解,也不是每一次都会招致厌烦;事实上,有一些人还挺能接受你简单直接地告诉他应该做什幺。当然了,这也是建立在你的说话语气是能被对方接受的基础上。

使用这种独裁式管理方法也有隐藏的成本。通常工程师在明确知道写什幺程式码之前,需要有一个将智力与创造性进行转换的固有思考过程。换句话说,如果你不让他想明白其中的关键,只是一味地命令他去编码,他就会变成一只会写程式码不会思考的猴子。

如何让你的工程师不要厌倦工作?

更重要的是,你应该鼓励工程师去追问「为什幺」,这样他们能够更加投入到自己所做的工作中去。除非你们现在所做的是一个剑走偏锋的极端东西,或者是一个临时补丁,不然的话都应该和工程师交代清楚。如果一个工程师不再关心与专案有关的重要决定,也不再思考这些决定背后的逻辑,那幺他应该是已经準备跳槽了。

如何防範这一问题?

想要解决这一问题最需要的就是在企业文化中建立起公开讨论问题的机制。要留出固定的讨论时间,让整个团队都参与讨论接下来该做些什幺、如何计划。想要保持这种开放讨论的企业文化,每个人都要对独裁式的管理方式保持警觉。

尤其是在团队遭遇困难的时刻,团队成员需要更大声地表达出自己的意见,而管理者则更需要小心谨慎地聆听大家的心声。

6、日复一日的工作总会不可避免地走向无聊

还有一点不得不提的是:在一个封闭的工作环境里长时间工作绝对会扼杀人感知生活的乐趣。这一点不仅仅是针对科技行业工作者或者是工程师岗位,放诸于其他行业也是一样的。这一条几乎适用于任何一个后台操作岗位,每一天在相同的办公室里,见着同样一帮人,做着一成不变的工作,也没有什幺不同文化的碰撞。即便是在一个快速增长的企业环境中,纵然所有的事情从客观角度看都在「良好」运行着,人们也会感觉自己有资格去寻找一些乐趣,并且会从不那幺好的事情中感到沮丧。

如何与日常工作中滋生的无聊情绪做斗争?

解决这一问题的关键就是尽力创造多样化:招聘拥有不同背景以及来自不同国家的员工。如果你每天看到的同样一帮人能够给你带来不同文化的冲击,那幺上班这件事肯定会更有趣一些。

同时,我们会积极地创造一些走出常规工作环境的机会。

例如我们会一起去参加一些行业聚会以及黑客松活动。我们还会一起打造工作之外的副业,共同研究我们喜欢的开源工具。除此之外我们还会不时地帮助其他团队完成一些不那幺技术性的工作。这幺做并非因为我们都擅长这些工作,只是为了在日常工作中寻求改变。

如何让你的工程师不要厌倦工作?

我们还会组织一些团队活动,我们每週还有一个固定的不需要事先预设主题的团队活动时间。在这个自主活动时间里,有时候我们会一起专研技术,有时候会头脑风暴出一个新点子,有时候仅仅是聚在一起玩 LOL,或者是约好一同去泡吧。这个自由活动的美好之处就在于当我们坐下来讨论该该去玩啥的时候,不到最后一分钟根本就不知道要去干什幺。

给生活增添这一小小的未知数成为了我们对抗无聊的终极一招。就像其他对抗无聊的方法一样,这也不会是非常完美的解决之道。我们要做的就是在原有基础上不断调整,找出一些新招数,并且将其不断地运用到对抗无聊的战斗中。

欢迎加入「Inside」Line 官方帐号,关注最新创业、科技、网路、工作讯息
如何让你的工程师不要厌倦工作?