在职场中，每个人都渴望自己的薪酬能够快速增长，但并非每个人都能如愿以偿。本文将带您深入了解如何通过合理的策略和方法，争取到更多的调薪机会。文章详细分析了固定时间调薪与随时提报式调薪的区别，并提供了实用的建议，帮助您在职场中获得更多的认可和奖励。

一、前言

这是很有趣的一个话题。

工作很重要的两个目的：搞钱、发展。

每个职场人都想要，但往往求而不得，得到了又开始追赶下一次的调薪、下一次的晋升。

工作里的发展本质上就是一场游戏，大家都参与其中，玩了很久。

有的人玩了好多年，还是在原地踏步，工资只跟着物价有了小幅调整；

有的人也玩了很多年，深得游戏技巧，早早就开始了爆金币，走向“打工皇帝”的道路。

最近，有些朋友的公司对调薪机制做了调整。

把过去固定时间的调薪，改成了随时提报式的调薪。

这两种调薪的制度有什么区别？

先介绍一下这两种调薪方式。

固定时间的调薪，比如：每半年公司就会开放名额，由于人数太多，公司不会全审，一般是定好明确规则、调薪人数比例、调薪包后，就交给各级部门执行。

随时提报式的调薪，比如：部门里只要觉得有合适的人员，需要调整薪酬，就可以上报到公司，公司做审批。

两种模式有什么区别？看起来好像都是有名额限制、额度限制。

核心区别有两点：

1、固定调薪，公司只会根据规则，哪些人能调哪些人不能调会比较清楚，控好人数比例、奖金包就行，至于你要调整哪些人，都是部门里决定的。

2、提报调薪，虽是部门提交，但公司会审核，所以被提拔的人必须要有事迹说明。

这样就带来了很大的麻烦。

大家如果每年年底都要填写奖项申请、申报项目，应该就会有很深的感触。

一大堆的材料要写，要举证项目的价值、项目的意义，为什么要做，为什么值得获奖。。。

但现实生活里，往往有这样一个问题：“高绩效≠有关键事迹”。

什么意思？

“小明在团队里工作产出最高，每次都能按时按质的交付项目。”

这种情况可以拿团队里最高档的绩效么？肯定可以。

但可以成为申报事迹的内容么？肯定不行。

一般，我们去申报事迹的时候，内容会怎么写？主要是写产出、写贡献对吧？

打个比方：

小明负责数据库改造的项目，这块的技术栈团队里没有人熟悉，小明能主动负责起来。

原本预计需要三个月完成的项目，最终提前了一个月完成，大大超出了预期。

数据库改造完后，有这几点变化：

1、查询性能大幅提升，提升了10倍，网站上的所有查询耗时均小于2秒。

2、切换了数据库底座，为未来业务布局做好了准备。

在事迹描述里，“努力”、“刻苦”只是用来做补充、做修饰，这些不是重点，都是绿叶。

绿叶是要来衬托鲜花的，所以更多是要讲具体做成了什么事情，取得了什么效果。

如果你所处的公司，也是这类的调薪制度，那不妨你问下自己，你是否有适合的事迹可以写的？

如果只是：“工作兢兢业业、按时按质完成、版本里的需求能做好”。这一类是比较难调整的。

所以，这类制度下的调薪，一定要有一个合适的理由、合适的事迹。

二、事件驱动型的调薪，逻辑是什么？

如果所处的公司是这类的薪酬制度。

那有些时候，领导是不愿意为你调薪吗？

这里先按下不表，看完全文你心里应该会有一个答案。

首先，在这种制度下，调薪的逻辑是什么？我们先走一遍流程看看。

领导要写一份材料，写清楚谁，什么事迹，涨幅多少。

领导提交到上级单位。

上级单位和HR审批。

如果上级单位觉得理由不充分，则不批；觉得理由太荒唐，还会被当作负面案例。

那领导去提报，无非关心这两点：

领导会考虑理由是否合理，肯定不想被上级单位批评。

领导会考虑理由是否充分，能争取到成功调薪。那作为基层干活的你，就需要能提供一个“合理的理由”，让你的上级愿意去为你提报。

这就是在这个制度下，怎么去获得调薪的底层逻辑。

你得有一个合理的理由，让你的上级能和他的上级讲，并且能讲得通，才能得到调整。

把你的上级当作一个路由器，他充当一个基本的筛选与内容转发，帮你把消息带到他的上级那边去。

道理是这样没错，好像也懂了。

但有的小伙伴就会有疑问了，内心独白可能是这样的：

我干的都是很日常的工作。

对开发而言，我就是跟着需求、实现需求，做业务开发。

怎么才会有这种事迹呢？

我能把手头上的事情，按质按量的完成就不错了。

确实是这样，大多数人做的都是很日常的事情，那有那么多的事迹可以讲的。

平常、琐碎的日常才是正常的情况。

那正所谓“上有政策，下有对策”，要怎么去应对？

我也没标准答案，只能提供一些思路供大家参考吧。

多去解决事件性的问题，多去做专项。

保证绩效在中上游的水平。

解决特定事件和做专项，这类的事情，本质上就是有很明确的目的。

比如说，我们平台的性能随着业务发展，可预见就是会下滑，但目前没人投入解决。

如果你能去把这个事情做了，也做好了，并且这件事情的工作量和难度也不小，那就会值得在事迹上写下一笔。

“xxx负责了平台的性能改造，取得了xx效果，为未来1-3年的业务扩展打下基础。

”这件事情如果比较重要，领导看到这样的事迹，也很愿意去为你上报，上层领导看到了也不会多说什么。

保证绩效在中上游，那就更好理解了。

如果绩效很差，但组织上会给你调薪，那对于其他员工而言会有影响，会难以服众。

所以，绩效是在默认规则里的一条，要确保你的长期贡献是稳定不错的，并且还有一些关键成果。或者换句话说，如果你取得了一次事件型的调薪，那你当下这段时间的绩效考核应该不会太差。

只有这两点结合，才能更好保证达成调薪的目标。

三、怎么找到机会，有没有机会？

那平时怎么去发现这些事件性的问题，或者是发现一些专项呢？

一般有两种方式：

第一种，你的领导给你派活，把好的活、容易出成果的活派给你了，帮你指好了明确的路，你只需要把事情做得漂亮就行。

第二种，得自己多留心去发现，主动去揽活，并且减少其他活。

那怎么发现？

大体上，我觉得还是两种方式。

第一种，做好当前的事情，然后想办法把这件事情的影响放大。

第二种，做好当前的事情，发现一些问题，将这些问题包装成专项，并说服领导让你投入去做。

这两种方式看起来差不多，但我举两个例子，你就懂区别了。

案例一：你是一个软件测试工程师，目前负责版本里的测试工作。整个版本的质量比较差，你主要的工作有两点

1. 完成版本里的测试用例编写与执行。

2. 将“测试左移”的理念与方法论给开发传递，使得开发能保障好代码质量。

过程里，你发现开发对左移的概念不理解，造成了大量的漏测。你深入分析，并给开发做了培训，使得质量有了一定程度的提升，千行bug率下降了xx，xx%的问题在开发阶段就得到了解决。

然后，你又发现开发对左移概念普遍都不理解，不仅包括自己所在的小组，包括部门以及其他研发的团队。

所以，你主动与项目管理团队沟通，并将测试方法、左移的一些理念在公司研发团队里做了一些分享，对整个公司都带来了价值。

高亮部分的字体，就是把你做的一些业务成果，再将其放大。

技能、方法的价值，取决于影响了多少的人、多少群体。

如果一个技能只作用在你身上，那只有你收益；如果一个技能作用在整个团队身上，那将是整个团队的收益。

放大后，自然就是一个标杆案例了。

有些时候，我们做了很多技能、方法，但是在最终阶段的打磨和放大上，做得太少。

案例二：你是一个软件开发工程师，你跟着产品经理，在迭代里打螺丝，你主要的工作是：

1. 按期按质的完成需求开发

工作职责更简单了，但是会很分散。

现在互联网普遍都走敏捷开发模式，这个迭代在改A模块，下个迭代你在改B模块，再下个迭代又把A模块推翻了。

过程中，你发现平台很多功能与公司其他平台很类似，并且使用群体都是公司的某个交付部门，做的很多需求也是与别的平台一致的。

所以你提出了一个大胆的想法，将两个平台融合，相似功能需求在未来能直接复用，并且交付部门只需要登陆一个平台，也减少了他们交付业务需要登陆多个平台的问题。

经过你的初步分析，大概改造的工作量在1-2个月2个开发人力就可以达成目标，但是你拿不定主意，没办法决策。

你将这个想法和你的上级讲了，你的上级很支持并且推动了双方部门的配合，最终项目由你牵头并且完成了落地。

高亮部分的字体，就是在过程中识别问题，包装成大的专项，并提出来去解决。

可能在现实情况不一定会那么理想，但流程是类似的，你得找到一些痛点。

这些痛点可以是你上级的，也可以是业务的。