这是很有趣的一个话题。
工作很重要的两个目的：搞钱、发展。
每个职场人都想要，但往往求而不得，得到了又开始追赶下一次的调薪、下一次的晋升。
工作里的发展本质上就是一场游戏，大家都参与其中，玩了很久。
有的人玩了好多年，还是在原地踏步，工资只跟着物价有了小幅调整；
有的人也玩了很多年，深得游戏技巧，早早就开始了爆金币，走向“打工皇帝”的道路。
最近，有些朋友的公司对调薪机制做了调整。
把过去固定时间的调薪，改成了随时提报式的调薪。
这两种调薪的制度有什么区别？
先介绍一下这两种调薪方式。
固定时间的调薪，比如：每半年公司就会开放名额，由于人数太多，公司不会全审，一般是定好明确规则、调薪人数比例、调薪包后，就交给各级部门执行。
随时提报式的调薪，比如：部门里只要觉得有合适的人员，需要调整薪酬，就可以上报到公司，公司做审批。
两种模式有什么区别？看起来好像都是有名额限制、额度限制。
核心区别有两点：
固定调薪，公司只会根据规则，哪些人能调哪些人不能调会比较清楚，控好人数比例、奖金包就行，至于你要调整哪些人，都是部门里决定的。
提报调薪，虽是部门提交，但公司会审核，所以被提拔的人必须要有事迹说明。
这样就带来了很大的麻烦。
大家如果每年年底都要填写奖项申请、申报项目，应该就会有很深的感触。
一大堆的材料要写，要举证项目的价值、项目的意义，为什么要做，为什么值得获奖。。。
但现实生活里，往往有这样一个问题：“高绩效≠有关键事迹”。
什么意思？
这种情况可以拿团队里最高档的绩效么？肯定可以。
但可以成为申报事迹的内容么？肯定不行。
一般，我们去申报事迹的时候，内容会怎么写？主要是写产出、写贡献对吧？
打个比方：
小明负责数据库改造的项目，这块的技术栈团队里没有人熟悉，小明能主动负责起来。
原本预计需要三个月完成的项目，最终提前了一个月完成，大大超出了预期。
数据库改造完后，有这几点变化：
1、查询性能大幅提升，提升了10倍，网站上的所有查询耗时均小于2秒。
2、切换了数据库底座，为未来业务布局做好了准备。
在事迹描述里，“努力”、“刻苦”只是用来做补充、做修饰，这些不是重点，都是绿叶。
绿叶是要来衬托鲜花的，所以更多是要讲具体做成了什么事情，取得了什么效果。
如果你所处的公司，也是这类的调薪制度，那不妨你问下自己，你是否有适合的事迹可以写的？
如果只是：“工作兢兢业业、按时按质完成、版本里的需求能做好”。这一类是比较难调整的。
所以，这类制度下的调薪，一定要有一个合适的理由、合适的事迹。
一、事件驱动型的调薪，逻辑是什么？如果所处的公司是这类的薪酬制度。
那有些时候，领导是不愿意为你调薪吗？
这里先按下不表，看完全文你心里应该会有一个答案。
首先，在这种制度下，调薪的逻辑是什么？我们先走一遍流程看看。
领导要写一份材料，写清楚谁，什么事迹，涨幅多少。
领导提交到上级单位。
上级单位和HR审批。
如果上级单位觉得理由不充分，则不批；觉得理由太荒唐，还会被当作负面案例。
那领导去提报，无非关心这两点：
领导会考虑理由是否合理，肯定不想被上级单位批评。
领导会考虑理由是否充分，能争取到成功调薪。那作为基层干活的你，就需要能提供一个“合理的理由”，让你的上级愿意去为你提报。
这就是在这个制度下，怎么去获得调薪的底层逻辑。
你得有一个合理的理由，让你的上级能和他的上级讲，并且能讲得通，才能得到调整。
把你的上级当作一个路由器，他充当一个基本的筛选与内容转发，帮你把消息带到他的上级那边去。
道理是这样没错，好像也懂了。
但有的小伙伴就会有疑问了，内心独白可能是这样的：
我干的都是很日常的工作。
对开发而言，我就是跟着需求、实现需求，做业务开发。
怎么才会有这种事迹呢？
我能把手头上的事情，按质按量的完成就不错了。
确实是这样，大多数人做的都是很日常的事情，那有那么多的事迹可以讲的。
平常、琐碎的日常才是正常的情况。
那正所谓“上有政策，下有对策”，要怎么去应对？
我也没标准答案，只能提供一些思路供大家参考吧。
多去解决事件性的问题，多去做专项。
保证绩效在中上游的水平。
解决特定事件和做专项，这类的事情，本质上就是有很明确的目的。
比如说，我们平台的性能随着业务发展，可预见就是会下滑，但目前没人投入解决。
如果你能去把这个事情做了，也做好了，并且这件事情的工作量和难度也不小，那就会值得在事迹上写下一笔。
这件事情如果比较重要，领导看到这样的事迹，也很愿意去为你上报，上层领导看到了也不会多说什么。
保证绩效在中上游，那就更好理解了。
如果绩效很差，但组织上会给你调薪，那对于其他员工而言会有影响，会难以服众。
所以，绩效是在默认规则里的一条，要确保你的长期贡献是稳定不错的，并且还有一些关键成果。或者换句话说，如果你取得了一次事件型的调薪，那你当下这段时间的绩效考核应该不会太差。
只有这两点结合，才能更好保证达成调薪的目标。
二、怎么找到机会，有没有机会？那平时怎么去发现这些事件性的问题，或者是发现一些专项呢？
一般有两种方式：
第一种，你的领导给你派活，把好的活、容易出成果的活派给你了，帮你指好了明确的路，你只需要把事情做得漂亮就行。
第二种，得自己多留心去发现，主动去揽活，并且减少其他活。
那怎么发现？
大体上，我觉得还是两种方式。
第一种，做好当前的事情，然后想办法把这件事情的影响放大。
第二种，做好当前的事情，发现一些问题，将这些问题包装成专项，并说服领导让你投入去做。
这两种方式看起来差不多，但我举两个例子，你就懂区别了。
案例一：你是一个软件测试工程师，目前负责版本里的测试工作。整个版本的质量比较差，你主要的工作有两点
1.完成版本里的测试用例编写与执行。
2.将“测试左移”的理念与方法论给开发传递，使得开发能保障好代码质量。
过程里，你发现开发对左移的概念不理解，造成了大量的漏测。你深入分析，并给开发做了培训，使得质量有了一定程度的提升，千行bug率下降了xx，xx%的问题在开发阶段就得到了解决。
然后，你又发现开发对左移概念普遍都不理解，不仅包括自己所在的小组，包括部门以及其他研发的团队。
所以，你主动与项目管理团队沟通，并将测试方法、左移的一些理念在公司研发团队里做了一些分享，对整个公司都带来了价值。
高亮部分的字体，就是把你做的一些业务成果，再将其放大。
技能、方法的价值，取决于影响了多少的人、多少群体。
如果一个技能只作用在你身上，那只有你收益；如果一个技能作用在整个团队身上，那将是整个团队的收益。
放大后，自然就是一个标杆案例了。
有些时候，我们做了很多技能、方法，但是在最终阶段的打磨和放大上，做得太少。
案例二：你是一个软件开发工程师，你跟着产品经理，在迭代里打螺丝，你主要的工作是：
1.按期按质的完成需求开发
工作职责更简单了，但是会很分散。
现在互联网普遍都走敏捷开发模式，这个迭代在改A模块，下个迭代你在改B模块，再下个迭代又把A模块推翻了。
过程中，你发现平台很多功能与公司其他平台很类似，并且使用群体都是公司的某个交付部门，做的很多需求也是与别的平台一致的。
所以你提出了一个大胆的想法，将两个平台融合，相似功能需求在未来能直接复用，并且交付部门只需要登陆一个平台，也减少了他们交付业务需要登陆多个平台的问题。
经过你的初步分析，大概改造的工作量在1-2个月2个开发人力就可以达成目标，但是你拿不定主意，没办法决策。
你将这个想法和你的上级讲了，你的上级很支持并且推动了双方部门的配合，最终项目由你牵头并且完成了落地。
高亮部分的字体，就是在过程中识别问题，包装成大的专项，并提出来去解决。
可能在现实情况不一定会那么理想，但流程是类似的，你得找到一些痛点。
这些痛点可以是你上级的，也可以是业务的。
本文由人人都是产品经理作者【鹏鹏的工作日记】，微信公众号：【鹏鹏的工作日记】，原创/授权发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
