Luna职场 | 来还个愿
0. 前言
这周在工作中接连发生了好几件堪称「突破性成就」的事情，值得写篇文章来还个愿。
- 三年中，绩效第二次拿到 4 分（满分 5）；
- 公司项目从启动到上线的流程改革，这周终于跟所有部门和利益方都敲定了，下周正式实行；
- 关于跨部门合作，突然开窍了，发现唯有遵循流程才能保护程序员团队的长期健康；
- 想到了一个绝佳（至少我是这么认为的）的团队奖惩措施；
- 实质上成为了公司内部自动化工具的产品负责人，月底前要给高层做一次产品蓝图和里程碑相关的演讲；
接下来就一件件事情聊~
1. 绩效第二次拿到 4 分
每半年一次的绩效考评，5 分制。
我在三周年工作总结文章里面提到，第一次我拿到 3 分，还以为这是个不太好的分数，后来才发现 3 分就是平均值，拿 4 分就是要升职了。
我上一次拿到 4 分是 2020 年下半年。
2022 年上半年的绩效自评，我给了自己 4 分，因为我觉得我做了很多有价值的事情，承担了各种新的职责，同时还在非常努力地在把每件事情做好（管理、团队培养和激励、流程重构、技术等）。
这周跟领导做绩效谈话，虽然有一丢丢小波折（细节不展开），但我还是如愿以偿拿到了职业生涯的第二个 4 分~~~超级开心！！
Luna 说
关于绩效考评，我的心得是：
- 首先自己要真的做了有价值的事情；
- 其次要在跟领导的每次 1 on 1 中，汇报自己的工作进展，对齐目标，调整方向；
- 最后要在写绩效报告的时候，把自己做的事情有条理有主次地展示出来；
我发现很多职场新人在写绩效自评的时候，总是过于简洁，比如明明做了个很复杂的项目，却一个词带过，默认看报告的人了解你在说什么，这其实是非常不可取的！！
因为假如你想要升职（争取 4 分），那么你的直属领导需要说服 TA 的领导你为什么值这个分数，而 TA 的领导平时跟你接触很少，只能通过你的绩效自评+你直属领导的汇报来做最终决定。
所以升职这件事，关键在于实力过硬 + 懂得汇报 + 领导赏识 + 一点点的运气。
管理者如何保证自己给下属的绩效评估是基于事实的？
我在给下属做绩效评估之前，特地创建了一个能看到每个人前 6 个月工作情况的 dashboard，来避免自己被个人喜好/固有偏见影响，给出不合理的判断。
用个时髦的词：Data-Driven Decision Making。
当然，也不能单纯地根据数据来一锤定音，管理者还需要综合去考虑这个人平时跟团队成员的合作情况，软技能，以及别人给的一些反馈意见来给出最终的评级。
我认为自己做的比较好的地方是，我会先看每个下属的表现（数据+观察），然后根据 TA 的个性和能力来思考这个人如果想要进阶，需要提升哪些方面。
同时，我也会结合公司的「潜规则」来给建议，因为不同公司看重的东西可能稍有不同。
我最终想传达给下属的信息是：你想在这个公司进阶，你需要把注意力放在哪些点。
我的满足感来源
我为什么如此注重对每个团队成员「因材施教」？我想是因为这几点：
- 我深刻意识到，一个人在职场上的发展，很大程度受限于 TA 领导的水平，好苗子遇到会带人的好领导，可以少走很多弯路，直接上快车道；
- 我在初入职场时遇到了一个好领导（完美世界上海公司的 CEO），在 TA 的培养下，我养成了好的职场习惯，也开拓了眼界；
- 我希望我团队中的这些年轻人，不论能在这家公司和我共事多久，等他们回首人生第一份工作的时候，能记得我做过的一些对他们有帮助的事情；
基于这个原则，当我看到团队中的人进步升职时会很开心，感觉自己的努力没白费~~
2. 公司流程改革
这应该是我第一次做这种公司层面的，大刀阔斧的流程改革。
契机
目前的流程过于繁杂，很久没有做复盘和更新；有些流程会阻碍项目的推进；过度依赖某个人的作用，无法 scale……
这次是老板牵头，跟我讲了他准备要改这个流程，我跟他一起定了初稿，然后我负责去跟不同的团队负责人进行沟通，收集反馈意见，修改，最终定稿。
时间线
流程改革从开始到落实（下周一），大概用了一个月不到的时间，中间还有穿插公司旅游。
因为公司规模是中型，我跟每个部门的负责人关系也比较好，明白大家的痛点在哪里，想要达成的目标是什么，所以聊起来是相对很顺利的~~
学到的
- 自上而下：我这次做流程改革，是有高层的支持，所以推行的阻力相对较小；
- 需要跟每个部门讲清楚流程改革的目标：让大家做事更规范，让项目推进更快，完成公司的战略目标，所以对每个人、每个部门来说，都是一件有长期利益的好事；
- 分清权责：项目推进的每个流程，都需要有明确的负责人/部门，这样可以避免扯皮和推诿（共同承担责任=谁都不负责）；
- 不追求完美：告诉大家，这个流程不完美也不可能 100%正确，我们会每个月进行复盘，听取大家的意见来进行调整；
- 善用自动化工具：流程改革最大的难点在于如何让大家都能遵守流程，我的偏好是借助自动化工具来保障规则（比如我们用的 Azure DevOps board，可以定好每个 state 的一些自动化行为）；
接下来就看这个流程后续的执行情况啦~~~这次改革方案我还是比较满意的，破除了好几个长期存在的痛点和瓶颈，接下来我会做更多的自动化来减轻大家「记住流程」的认知负担。
3. 识别「死胡同问题」，早点转弯
这个认知上的「开窍」来自于我的一个人生原则：
当我明明已经竭尽全力，却依然在同一个地方跌倒，那就说明，我的努力已经没有用了，我得让自己的脑子转个弯，换个方法来解决问题。
最近遇到的事情是：客户部门的不同成员，总是会找我提一些「小需求」，希望我能快速给他们搞定。
我一开始的做法是「做个好人，能帮就帮」，但是我现在手头的工作已经超级忙了，即使是个小需求，也至少要花掉我一小时左右的时间才能做完 + 测试完。
我跟上级说了自己的烦心事，上级给了一个「高维方案」，这种小需求不应该由不同的客户经理给你提，他们要去找他们的老大，他们的老大告诉你应该把哪些事情排上优先级。
喔~豁然开朗了！
有时候，定规矩还是非常必要的，我需要保护自己的注意力，也需要保护我的团队，同时，更重要的是，在跨部门合作的过程中，分清关键干系人，对接一个有决策权和全局观负责人。
还学到了「向上级求助」的重要性，这种「死胡同问题」不能总想着自己扛，要及时把遇到的困难汇报给上级，一起找到更好的解决方案。
4. 团队奖惩方案
我们做项目的过程中，会要求程序员给出程序的交付日期，然后测试会根据程序交付日期来给测试预估时间以及项目上线时间。
这个过程中，我发现有些程序员总是会推迟交付日期，导致测试时间被压缩，或者交付时间被推迟（客户部门的人不爽）。
我多次苦口婆心地跟团队成员说：大家预估时间尽量给个比较准确的，因为你改时间会影响到其他部门的计划，不要过于乐观……
然而，收效甚微。
某天，我在想，我到底想要达成什么目标？
- 我希望每个项目的交付日期都是准确的（比如今天是 8 月 12 号，你的项目程序交付日期写的是 8 月 10 号，你还没做完，那就说明你没有及时更新这个日期）；
- 我希望程序员能意识到修改程序交付日期是有后果的，不是随心所欲想改就改；
- 我希望能够区分那些认真做计划按时交付任务的程序员，和那些拍脑袋/过于乐观但总是延期的程序员；
于是我决定制定这个奖惩机制：
- 一个连续三次按时交付项目的程序员，可以有半天的自我提升时间（看技术课程等）；
- 一个连续三次项目延期的程序员，我会找 TA 的领导和 TA 一起开会，来分析延期的原因以及后续的改进方案；
希望达到的效果
- 破除「鞭打快牛」问题：人性使然，我们会给做的好做的快的员工分配更多的任务；
- 公开认可并奖励「优秀员工」：做得好就应该有奖励，我希望通过这种奖励措施，让优秀员工感到被重视和认可；
- 让那些总是延期的成员意识到问题的严重性，承担应尽的责任：你给的时间节点，你就应该去努力达成，而不是随意修改，随意修改是有后果的。
5. 内部工具的产品负责人
大家如果有阅读我之前的文章，应该猜到了我对产品这块蛮感兴趣的，尤其是团队内部的自动化工具。
我这个团队（Platform Team），国内叫中台部门，主要任务就是内部流程自动化。
我们现在要做的这个自动化工具，目标是让程序员们摆脱繁琐的手动配置工作，一键生成一个新客户的模版，并且要结合 CI/CD，打通从收集需求到正式上线这条脉络。
我自己对这个产品是非常非常兴奋以及期待的。
我对公司的项目上线流程已经很熟悉了（毕竟是三年老员工），但我也发现，一些好的工作习惯（比如字段命名规则）很难传授给每个程序员，大家心情好的时候会对自己做的东西要求高一些，心情差或者忙起来就不注重细节了（甚至会给下一个接手的人挖坑）。
我的最终目标就是通过这个工具来确保最佳实践能够被复制，convention over configuration，解放程序员~
不过说实话，我从来没做过这种项目……所以我内心还是有一点点虚的。
但是不做，就永远不知道自己需要学什么，永远不知道自己能做到什么程度，所以我乐于接受这个挑战，并且我会按照自己一贯的行为准则——做任何事情都要 100%用心，对得起自己的时间成本——来做这个产品。
念念不忘，必有回响
其实我觊觎这个产品负责人的机会已经好几个月了，也不断地在跟上级沟通自己的想法，之前都没有得到一个明确的信号。
万万没想到，这次我直接被指定为跟高层去做产品里程碑沟通的演讲者；这是个蛮大的挑战（我心里大概只有 50%的把握），但我知道，这是个能展示我能力及意愿的绝佳机会，我一定要把握好。
大家为我加油吧~
Talk to Luna
Support Luna
