【曹工杂谈】 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日，于宝安图书馆