又到了一年一度喜闻乐见的okr修订时间。去年定的okrs今年基本没完成，本来有点不想写这篇来打脸的😂不过我怕我真不写的话有些小事以后记不住

2024需要夸夸自己的事

总结一下，我终于多做了一点点自己并不喜欢但是应该做的事情。

  1. 讨厌读书的人比往年多读了几本不是故事书的书，虽然读完的只有一本😂（感谢Helen锲而不舍的安利I Will Teach You To Be Rich，让我发现我一个不懂理财的人的财产portfolio其实做的挺好的，也顺便刺激我终于出走Wells Fargo转投全世界ATM随便取钱的Schwab）
  2. 讨厌所有形式的运动的人终于坚持了半年多每周运动俩小时（经期除外），也就是说我每周忍着上了俩小时的刑，太不容易了😭
    • 不过我感觉我2025年不一定坚持的下来。现在在思考买个单车出去骑会不会比跟着Switch蹦蹦跳跳更有趣一些，但是冬天我又不想出门……

然后讲讲自己喜欢且做的好的事情

  1. 终于终于看了传说中的东非动物大迁徙，以及！我的导游工作超额完成，能让我爸夸我有眼力见儿可真不容易！
  2. p图水平有了质的飞跃！

2025需要继续努力的事

工作，绝对是工作😭

我自知我并不是什么很有责任感的人，工作的两大动力是“不被开”和“喜欢工作内容本身”——后者更甚于前者。对于我喜欢的项目，就算我写代码的时候烦的想砸电脑，我内心也深知feature上线的那一刻的成就感值得这份煎熬。

而整个2024年我好像从来没有在工作中找到过这种感觉……（其实有，但年底才定好UX，交付要等明年了）可能因为看似没啥挑战性所以我接项目的时候也没看清里面的各种坑，结果都完成的不咋样。。。

事件1

年初发生的。需求是在4个不同的地方加特效。4个特效长得大同小异，那么我作为一个（自以为）成熟的前端程序员，写法肯定是设计一个新的封装好的view，hardcode“大同”的部分，“小异”的部分则通过传参/改变量实现。我以正常速度写好了design，找了俩别的程序员review了一通，自以为没啥问题了，于是按时写好了这个view，并且成功把它应用在了头两个特效里。

结果写到第三个特效的时候发现目前的代码好像有个地方靠我目前写的这个view实现不了呢……说不得，只能原来那个view里面把这个功能加上，再加个变量控制它。到这个时候进度还算稳，只是原本的小屎包升级成了一坨屎山，摇摇欲坠又固若金汤🤷‍♀️

终于我们来到了最后一处特效，然后我发现……它和前三个特效，虽然确实用了同一波素材，但把这些素材组装起来的指导思想……完，全，不，同。

打个比方就是，前两个特效相当于扑克牌从2到10，第三个特效相当于JQKA，虽然牌面不是把同样花色重复n次，但加班加点也能短时间内重新画出来。结果最后一个特效竟然是大小王，而我提前画好的这个view的先决条件是需要有花色的，那么要不然单独从零开始撸大小王，要不然把之前写好的组件拆了重写……

而且这不怪UX只能怪我自己，因为UX mock上把这些需求模拟的很清楚，完全是我忽视了细节（

最后就只能多花了点时间重构了一下原来那个view（还好倒也不至于完全重写，代码质量还变好了点）再花点时间心思把这个“大小王”特效做出来（即使是重构以后的view元件也没法直接拿来用，需要套个壳）。交付是不可能按时交付的了，好在没影响前三个特效的交付，但终归也是说好的事情没做到。

事件2

是最近刚解（砍）决（掉）的一个问题。大概是我开始觉得工作过于无聊了，于是夏天接了大佬们画的个饼，跑去做跨部门集成的项目了。然后就收到一个需求——设计一个AB test，除了对照组以外大概长这样——

  • A组: 给重度用户开启功能甲，给重度+中度用户开启功能乙
  • B组: 给重度+中度用户开启功能甲，给所有用户开启功能乙
  • C组: 给重度用户开启功能甲，给所有用户开启功能乙

而据我所知，甲功能和乙功能已经存在了，之前单独做过AB test。“区分用户群体”也是现成的。唯一需要大动干戈的feature code就是乙功能的触发机制——这个功能并不是我们大组开发维护的，算是第三方库里的东西，这个库是另一个部门的另一个组开发和维护的（为了方便就叫他们X-team吧）。他们之前的AB test也是在他们自己的平台上搞的，如果我想做到“以用户所在群体作为触发此功能的条件”，得新写个API从客户端传参传到服务器；我找过X-team的同事问过怎么写代码，他们也给了我一些现成的例子，基本上我照抄就行了。我也确实在半天之内写出了代码prototype。

于是老板和PM问起来的时候我又双叒叕放大话了——放心，年底肯定交货！

……此时此刻我竟然忘了一个常识：改别人的代码是很难的！！！难的不是看代码也不是写代码，是人情世故💥💥💥

来来回回踢皮球的事情我就不赘述了，简言之就是X-team比我想象的大挺多的，里面也有搞产品的和搞infra的。我司code review经常是程序自动摇人，我这趴刚好给我摇了个infra大佬和一个产品大佬，这俩人意见不一致，最后当然是我的代码入不了库……

于是我就给我自己项目的老板和PM讲了这事儿，想说要不然让老板去push X-team的老板，PM去push他们PM。结果PM那边也碰到不少幺蛾子——他当时之所以把“乙功能”列入了实验范围，是因为X-team PM当时表示了兴趣，但之后再去问，发现他当时好像也只是“随口一说”。更绝的是……是的，X-team马上要re-org了（不愧是我司）😂

最后PM决定干脆把“功能乙”从这个AB test里砍掉，倒是皆大欢喜，只有我想到两个月前说的大话感觉无比愚蠢☠️

经验教训

I’ve always believed in “under promise and over deliver;” apparently I failed to practise what I preach.

可能是因为我很清楚自己是个只能被deadline驱动的懒人，所以并不相信自己”under promise”完了就一定会”over deliver,” 潜意识里可能甚至有在故意over promise刺激自己over deliver.

显而易见的结论自然是“先仔细调研再给准话”，但巧了，不先“给准话”的话我没动力“仔细调研”。这个恶性循环短时间内大概无解，毕竟治懒癌很难，而且我好像也不想治。

不过也有最直接也最可行的解决方案——

  1. 碰到跨组合作的项目，在预估timeline的时候，一定一定一定要把沟通成本往高了算……
  2. Involve all relevant PMs in the conversation. I used to make the mistake of only involving partnering engineers.

好了来检查okr了

2024 okrs

  • Keep having a job ✅
    • Stretch: 升职 ❌
  • 去非洲 ✅（天河之渡也看到了！）
  • 自我提升，达到以下N个目标中的一个❌（达到了令人惊讶的0个目标！喵的🙄）
    • Dionysus v2.0目测是上架不了了除非我改变产品方向……我想做的那个功能果子不支持我也没办法

2025 okrs

  • 把今年读了一半还没读完那两本书读完
  • 2024顺延：学会钢琴调律，至少把买的那本Piano Servicing, Tuning and Rebuilding跟着读完
  • 继续2024顺延：开始！开始！开始！写一个小游戏……游戏这玩意儿难写的很，上不上架的过两年再说

最后是个要靠个人的努力但更要靠历史进程的目标，与其算okr不如说是对自己的美好祝愿吧：

希望自己走出职业倦怠期（当然，是不以失业为代价的前提下……）毕竟5月份我就在业界混满10年了

正准备发出来，发现离西五区已经进入2025了！那就祝大家新年快乐，万事胜意🎉❤️