逐日

V1

2022/02/12阅读:133主题:红绯

2021在鹅厂干了一年,我的一些感悟

2021在鹅厂干了一年,我的一些感悟

前言

2021年没怎么写文章,状态很是不太对,包括现在状态也是不太对,写这篇文章,打开了typora,发现竟然新版本要收费了,看来确实是好久没打开这个软件了。可能是因为之前在国企,事情没那么多,除了赶项目的时候要加班,其他时间都还好,工作上也没有很强的绩效压力。空闲时间一多,每天学学技术、写写文章,都还算是比较惬意,唯一的缺点,可能就是技术挑战不大,钱也比较少,日子紧紧巴巴的。

2021年在鹅厂干了满满一年,说实话,还是比较累的,而且,累的方式不太一样,手上做的事情,用到的技术倒是没多大挑战,主要是心累,手里的事情做得并不好,没有拿什么奖,绩效也相当一般,组内没有影响力,感觉就是,瞎忙了一年,班加得不少,但好像没什么效果,没得到外界认同。

一年两次绩效,半年一次,上半年是组长A打的绩效,然后年中的时候,组长A离职了,出去朋友公司当cto去了;下半年,换了一位组长,组长B打了下半年绩效。两次绩效的结果都一般,先不扯什么pua之类的,那基本还是能说明一些问题的,至少还是要反思下,怎么去适应大厂的这种职场环境,怎么在这种环境下活得好。

所在小组的职责介绍

我们组呢,是做运维平台的,用户呢,是研发人员,比如开发、运维,我们这边是偏向于管控:对线上环境进行的各种变更。

线上环境的变更,有很多种类,比如网络、存储、防火墙、操作系统、中间件、业务应用程序,部分由运维负责,如网络、防火墙、部分中间件;部分由开发负责,如业务应用版本迭代。

最简单直接的变更方式,那自然是ssh登录上去一顿操作,经常还是root登录;这样的风险无疑是比较大的,小公司还能忍,大公司是肯定接受不了的,要是来个删库跑路,影响巨大,所以,自然需要做成各种内部网站、工具、脚本,去把这些工作安全、高效地进行。

既然是做给内部同事用的,那可以想象,内部同事和外部客户是不一样的,资源投入少得多;比如,微信这种程序,服务外部客户,那基本上人力资源非常充分,各类工种非常齐全,比如产品经理负责需求收集、分析、原型图设计;UI负责如何让界面美观大方;前端负责将UI设计的界面,转化为实实在在的系统界面;后端负责提供接口。

我们这边不一样,我们一个人 = 产品 + UI + 前端 + 后端,产品这块,有些需求靠自己想,领导就是很抽象的几句话:“我希望达到xxx效果”,“我想xxx”,意思就是,领导可能也不知道具体要怎么做,只有一个目标/指标;有些需求,来自于周边合作团队;有些需求,来自于用户投诉吐槽、客服系统。抽象需求拿到后,接下来,你还要转化为具体需求(至少要让UI/前端/后端能够明确知道要干啥),具体需求的承载形式,一般是原型图。原型图ok后,UI这一步,我们这边基本是没有的;前端、后端阶段,需要根据原型图去做实现方案,实现方案也不是我们自己就定了,还需要拉会,让大家评审。评审通过了才开始去具体开发程序。

2021上半年--新员工的我为啥总在返工

过程

上面花了好多篇幅,去介绍小组的现状,是有必要的,可以看看我下面的经历。

我们组这边,对于新员工,一般是给一大块的新的事情,比如3个月试用期内,自己一个人做一个新系统、新模块,由于是新系统,此时还没人用这个系统,不涉及维护,不需要当客服去处理用户使用中的各种问题;我猜测,领导的考虑是,这样方便考核成绩,也方便考察这个员工自己一个人做事、独当一面的能力。

我进来就分了这样一个新系统,完全全新的东西,这中间就涉及我上面说的,一个人要充当好几个角色:产品 + UI(内部系统好像不需要这个)+ 前端 + 后端。

一个全新的东西,自然是长什么样子都不知道,刚开始,了解了大概的需求文档后,知道了要做啥事情,但是,界面/流程怎么设计,这个是没有的,要靠我自己去解决。

那时候就是开会。组长,导师,在白板上面画,讲要做成什么样子,但是呢,白板又能承载多少东西,很多东西都漏了,等到具体去做的时候,发现自由发挥的空间非常大(比如是点了一个按钮后,是直接弹框,还是新打开一个界面;展示几个并列的东西时,是用tab组件,还是用步骤条上一步下一步这样串起来)。

就是因为自由发挥空间很大,一开始呢,我就和导师(鹅厂制度,导师就是组内同事,前面会有导师带你几个月)确认要做成啥样子,比如用弹框而不用新节目,设计成这样而不是那样。

做了一个月,一小块功能基本成型后,拿去给组长看,结果组长提了好多问题,觉得和他设想的很多不一样,然后组长一般喜欢用笔记本,我们的网站是基于大屏幕设计的,基本没考虑笔记本(适配笔记本很难搞,而且我们基本都是业余前端工程师),组长笔记本打开网站一看,那叫惨不忍睹。

于是,开始按照组长的意见改,改了之后又拿去看,总之就是这样反反复复。加班加得飞起,全是在返工。

然后中间做着做着又有各种新问题,新问题出来后,就拉会议,会议就说:那再加个这个功能进去,反正这个没上线,就趁着这次做新系统,把这个问题一起解决了。 总之,中途就临时又收获了不少需求,然后就做,依然是做--检查--返工,只是慢慢地,系统稳定了,返工会少一些了。

最终呢,3个月转正的时候,系统还没开发完;到半年的时候,系统也才勉强上线。

最终半年度绩效非常一般。

该阶段的总结

其实这中间暴露了很多问题。

返工的问题主要是沟通问题,包括沟通形式。人的记忆是不怎么可靠的,光靠说,听的那一方,能吸收多少呢? 尤其是,这中间还涉及到了3个人,我、导师、组长。刚开始,看组长非常忙,就和导师沟通,确认要做成什么样子,等到功能做完了,才去找组长验收,组长自然有自己的想法,比如掌握的外部信息更多,知道用户到底需要什么,用户的核心痛点等等。于是,组长觉得这个设计有问题,自然就要返工。

所以,这里的问题确实是我自己的问题,我在上家公司,只需要做后端,没有做过需求分析这类工作,需求都是有产品经理弄好了给我们,只需要照着做即可。这里的问题,就是需求分析工作没做好,如果是我现在来做的话,肯定是要学习画原型图的,在2021年下半年的工作中,我也确实吸取了教训,开始画原型图,然后拿着原型图和前端后端方案,拉会议,让大家评审。

其次的问题是,需求管理的问题。这个系统,刚开始是预期3个月,但是做着做着发现了一些没考虑到的问题,然后相当于临时加了需求,导致整体的时间大幅度往后了。当时也没有需求优先级管理的概念,组长这么说,那就这么干呗。其实,当时也可以先上线一个版本,再逐步迭代,至少,最终说起来不会是,一个系统,搞了大半年没上线,对外部也会有个交代。

2021下半年

过程

经过上半年的事情后,下半年感觉做事好了很多,在快打绩效的前一个月,甚至自己感觉应该绩效还可以,结果没想到又是个悲剧。

手里的系统其实是两个子系统,上半年搞得是子系统B,子系统A是同事做的,但是做完子系统B后,组长让我把子系统A也接手过了,因此,就同时维护A、B两个子系统。

同事做的那个子系统,在我接手过来后,下半年又来了好多需求,我就去做这些需求去了;而我原来手里的系统,虽然说上线了,但其实用起来还是有点磕磕绊绊的,有些小bug和用户体验上的问题。

同事那个子系统,下半年接了好多需求,都是外部团队的,外部团队动不动就让你确定个日期,类似于deadline那种,就是让你承诺啥时候可以搞定。ok,比如我基于6月份当时的工作量,估一个时间,假设是7月中旬交付需求;但是,你发现,6月又来了一些紧急需求,导致你时间被极大压缩了,你就只能加班加点地赶在7月中旬把那个需求搞定。下半年基本就是这个子系统的需求就没停过,我也是一直忙着灭火一样,去搞定各个需求。

由于需求多,又时不时插入紧急需求,其实有些需求的交付质量也一般,因为我赶着把手里积压的需求做完。

到绩效考核的时候,结果,组长的意思是,我上半年那个子系统,收到了不少用户投诉,评价不高,因此绩效就一般。

我当然可以说,你看我做了那么多需求(都是同事那个子系统的),接手的那个子系统,评价很好啊,没多少用户投诉啊。但是,组长说的问题也确实存在,两个子系统,一个投诉多,一个投诉少,那重点到底是哪个呢?

该阶段的总结

下半年的问题在于,需求的优先级管理很有问题,对于自己的核心目标(okr里写的核心目标是要保证我自己那个子系统)没有做好。

需求优先级管理,不只是我存在,在组内其他同事那里也广泛存在,大家事情都很多,那要怎么去决定精力分配呢?

  • 放弃“把事情做完”的想法;我算看明白了,大厂的事情那是真的多,这啊那啊的,事情是做不完的

  • 既然做不完,那应该怎么办呢?在外部需求这块,要仔细去了解需求背景,有时候一个人给你提出的需求,不是他真实的需求,你挖出他背后的真实原因后,你也许可以提出更简单的做法,或者是发现这个需求,放在别人那里做,更合适;如果发现需求确实是应该在自己这里,那也不能一口答应一个准确的日期,而需要综合自己手里的所有事情后(可以在组内的周会上,提出来,让组长和其他核心成员去判断这个事情的优先级),再去对外沟通,同时也要避免太绝对的承诺,万一有临时紧急需求,可能就会导致承诺未兑现;给承诺的时候,也尽量不要给对方过高的预期,尽量不要用那种“绝对”,“完全没问题”这样的话,但是,一旦我们给了承诺,我们就要做到,同时,还可以比他预期中的,做得多一点。

    这个也是组内大佬教我的,低承诺,超预期。

  • 再说一下优先级的问题,一定要确保先完成自己的核心目标,其他需求,可以往后排,拿不准的,可以找组长沟通

其他感悟--拿数据说话

在做一个需求时,通常不止有一种解决方案。每种解决方案,有其自身的优缺点,对于我们一线开发来说,有时候可能明显感觉某个方案更好。

但是,拿这个方案去会议上讨论的时候,大佬们一般思维很发散,通常会问你:现在线上的xxx现状是怎么样的,有没有相关的数据。

这时候,如果没有提前做准备,基本是答不出来的;所以就要求我们,在提出我们的方案时,尽量要有数据支撑,而不是空谈,比如,为啥用快速排序而不用冒泡排序。你可以说,快排就是好。这时候大佬问你:有没有拿线上数据做个测试,看看各自花了多少时间?你可能直接懵了。

这也是鹅厂鼓励的一点吧:拿数据说话。

其他感悟--做产品的思路

这个也是组内高绩效大佬教我的,非常感谢。

做产品,一般是提供某个服务,一般会有个主流程。比如之前用滴滴单车,当时有个活动,领骑行卡之类的,我就跟着流程走,大概是要绑卡还是干嘛来着,走着走着还要我手持身份证拍照啥的,我嫌麻烦,就没弄了。

这个就是主流程不顺的一个体现。

大佬给我分享的是:

  • 主流程要顺,要快
  • 每天自己去用一下这个流程,自己发现问题,看看自己愿不愿意用;而不是等到用户投诉了再来改。可以看看相关错误码、耗时等
  • 针对发现的问题,不断去优化
  • 找一些使用该系统的用户,和他们沟通,听听他们的想法。如果负面反馈较多,可以安排个优化专项,优先级可以和组长商量

只是,这些观点,我现在好像也还没去实施,依然忙着手里的各种需求,这可能就是绩效差距的原因吧。

2022年,准备按照这个流程试试。

总结

我也毕业好些年了,前些年,喜欢看小说+文学,最近几年基本只看技术+少量历史,而现在,我觉得,我们也要看一些书:关于做产品、关于个人管理(如时间分配)等,入职鹅厂的时候,公司发了一本:《卓有成效的管理者》,之前我在想,我一个大头兵,懒得看你这些鸡汤,最近思想改变后,看了下,里面就有需求优先级管理相关的观点--要事优先。 所以我觉得如果有人和我一样,以前从不看这些鸡汤的话,也可以考虑看两眼。

上半年,组长走的时候,已经是12级专家的他(鹅厂干了16年还是17年),送了几句话给我们:

最后送上我理解我们这类型职场上的9字方针,“多想事、干好事、会呈现”。

​ 逐日于2022年2月12日,于宝安图书馆

分类:

后端

标签:

后端

作者介绍

逐日
V1