在鹅厂干了一年后的一些感悟。

你好呀，我是歪歪。

给大家分享一篇逐日大佬的文章。

我和他是 2020 年 7 月份认识的，刚刚认识的时候他还是一个在成都某国企搬砖多年的程序员，当时和他聊天的时候他就表达了自己想要出去看看的想法，他觉得在国企里面“太过安逸”了，待了好多年，虽然是程序员，但是根本没有互联网的感觉。

好在他一直在坚持学习，把握住了大量的工作之外的时间，学习了很多技术，输出了很多博客。

再后来得知他已经付诸行动了，在 2020 年年底的时候，从国企出来，冲了一波鹅厂，一冲即中，离开了生活多年的成都，奔赴了深圳，上了互联网的“贼船”，我想对他来说也算是另一种上岸吧。

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 那种，就是让你承诺啥时候可以搞定。

比如我基于 6 月份当时的工作量，估一个时间，假设是 7 月中旬交付需求。

但是，你发现，6月又来了一些紧急需求，导致你时间被极大压缩了，你就只能加班加点地赶在 7 月中旬把那个需求搞定。下半年基本就是这个子系统的需求就没停过，我也是一直忙着灭火一样，去搞定各个需求。

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

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

我当然可以说，你看我做了那么多需求（都是同事那个子系统的），接手的那个子系统，评价很好啊，没多少用户投诉啊。

但是，组长说的问题也确实存在：两个子系统，一个投诉多，一个投诉少，那重点到底是哪个呢？

该阶段的总结

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

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

首先放弃“把事情做完”的想法：我算看明白了，大厂的事情那是真的多，这啊那啊的，事情是做不完的。

既然做不完，那应该怎么办呢？

在外部需求这块，要仔细去了解需求背景，有时候一个人给你提出的需求，不是他真实的需求，你挖出他背后的真实原因后，你也许可以提出更简单的做法，或者是发现这个需求，放在别人那里做，更合适。

如果发现需求确实是应该在自己这里，那也不能一口答应一个准确的日期，而需要综合自己手里的所有事情后（可以在组内的周会上，提出来，让组长和其他核心成员去判断这个事情的优先级），再去对外沟通，同时也要避免太绝对的承诺，万一有临时紧急需求，可能就会导致承诺未兑现。

给承诺的时候，也尽量不要给对方过高的预期，尽量不要用那种“绝对”，“完全没问题”这样的话。

但是，一旦我们给了承诺，我们就要做到，同时还可以比他预期中的做得多一点。

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

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

其他感悟

拿数据说话

在做一个需求时，通常不止有一种解决方案。

每种解决方案，有其自身的优缺点，对于我们一线开发来说，有时候可能明显感觉某个方案更好。

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

这时候，如果没有提前做准备，基本是答不出来的。

所以就要求我们，在提出我们的方案时，尽量要有数据支撑，而不是空谈。

比如，为啥用快速排序而不用冒泡排序。你可以说，快排就是好。

这时候大佬问你：有没有拿线上数据做个测试，看看各自花了多少时间？你可能直接懵了。

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

做产品的思路

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

做产品，一般是提供某个服务，一般会有个主流程。

比如之前用滴滴单车，当时有个活动，领骑行卡之类的，我就跟着流程走，大概是要绑卡还是干嘛来着，走着走着还要我手持身份证拍照啥的，我嫌麻烦，就没弄了。

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

大佬给我分享的是：

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

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

总结

我也毕业好些年了，前些年，喜欢看小说+文学，最近几年基本只看技术+少量历史。

而现在，我觉得我们也要看一些书：关于做产品、关于个人管理（如时间分配）等。

入职鹅厂的时候，公司发了一本：《卓有成效的管理者》。

之前我在想，我一个大头兵，懒得看你这些鸡汤，最近思想改变后，看了下，里面就有需求优先级管理相关的观点--要事优先。

所以我觉得如果有人和我一样，以前从不看这些鸡汤的话，也可以考虑看两眼。

上半年，组长走的时候，已经是12级专家的他（鹅厂干了 16 年还是 17 年），送了几句话给我们：

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

在这里，也送给各位，与君共勉。

最后说一句(求关注)

好了，看到了这里了， 转发、在看、点赞 随便安排一个吧，要是你都安排上我也不介意。写文章很累的，需要一点正反馈。

给各位读者朋友们磕一个了：

··································

你好呀，我是歪歪。一个主要敲代码，经常怼文章，偶尔拍视频的成都人。

我没进过一线大厂，没创过业，也没写过书，更不是技术专家，所以也没有什么亮眼的title。

当年以超过二本线 13 分的“优异”成绩顺利进入某二本院校计算机专业，误打误撞，进入了程序员的行列，开始了运气爆棚的程序员之路。

说起程序员之路还是有点意思，可以看看。点击蓝字，查看我的程序员之路