技术同学如何提高职场话语权

前段时间，星球有位同学提了一个问题：测试同学如何提高在项目中的话语权？

其实这个问题，在职场中是普遍存在的一种现象。大家都希望能提高自己的话语权，按照自己的想法去推动工作的进度。但实际上，有了话语权就真的能解决问题吗？不尽然。

这篇文章，我想聊聊我对于所谓“话语权”的一些想法。

话语权的本质是什么

现代职场，很少有单打独斗就可以完成的工作了，基本都是通过多人协作配合，在流程制度的约束下，才能尽可能的按照预期完成项目。而且按照预期完成项目达成目标还有一些隐形前提，即良好的职业素养，一定水平之上的专业技能，合理的流程规范以及比较好的项目管理手段，这些因素缺一不可。

但在实际的工作中，我们经常遇到的问题是预期 100 分的项目，能做到 80 分就已经很不错了，然后就是复盘，总结做的好的地方，反思做的不好的点，然后提出改进方案，逐步优化。为什么会出现这种问题？原因有这几点：

• 流程规范虽然有，但在实际执行中总会出现偏差；

• 团队中每个人的专业技能、职业素养各不相同，导致细小的环节出现偏差；

• 多人协同过程中，信息同步延时，理解不同带来的信息失真，导致执行出了问题；

• 项目开展过程中需求变更，人员变更以及其他偶发问题带来的不可控风险；

回到标题，因为工作在具体的执行细节里和预期出现了偏差，不同岗位的人有自己的工作职责，因此会按照自己的想法去试图纠正偏差。但职场中除了明显的上下级关系带来的命令，所谓的话语权，只不过是个体自己的一厢情愿罢了。

话语权是否解决了问题

很多人想要的话语权和实际的话语权，在我看来是存在偏差的。

• 想象的话语权：你要按照我的想法去做，否则就会出现 xxx 问题，这样会导致 yyy 风险。潜台词就是我不想因为你这么做而导致我的工作难做，我也不想背锅，困难你去克服。

• 实际的话语权：我要求按照我的方式去做，这样做的好处是 xxx，解决了 yyy 风险，如果由此带来新的问题或者风险，责任我来负责。

如果话语权不能解决问题，预防风险，并且为自己的建议或者话语权附带的结果负责的话，那所谓的话语权并没有解决问题。很多人不明白的一点是，每个岗位都有自己的岗位职责，职代表这个岗位你要做的事情，责代表你要为做这些事的结果负责。

记得之前面试某企业的测试负责人岗位时，和他们的研发负责人聊过一个问题：测试和开发的职责范围和具体内容不一样，如何保证最终的交付质量？

我的回答是这样：虽然岗位职责和工作内容不同，但是目标是一致的，那就是线上交付的软件质量符合预期，不影响业务目标达成，不影响用户使用。与其强制要求，不如从一些软性的角度驱动。比如：以结果为过程定性，绩效驱动，目标驱动。共同为线上质量负责，流程规范交给工具，各种配置变更通过自动化流水线来解决，在需求阶段定义好目标，在研发阶段做好测试左移和评审，尽早的暴露风险，做好应对风险的冗余措施，制定应急响应机制。

相比于话语权，影响力更重要

其实职场中对于普通人来说，大家想要的是安稳做好自己的工作，少出问题，该拿的绩效和加薪拿到，不该背的锅不背。但实际情况总会和理想出现偏差，无论是开发提交代码忘了合并，还是运维配置变更搞错了，或者测试同学漏测等情况在所难免。

出现问题解决问题是正确的思路，但是在执行时，尽可能的以共同的目标和利益驱动去解决问题，比如：有个 bug 开发不及时修改，测试同学可以说如果不及时修改，会导致整体测试进度延后，这样的话我们可能要加班了，而且产品或者项目经理那边每天都会统计数据，会影响我们的绩效。而不是说如果你不及时修复提测，我就去发邮件告诉你领导或者项目经理这种造成对立的操作。

话语权看似很爽，但背后需要对自己的行动和结果负责。相比于话语权，对普通职场人来说，影响力反而更重要。如何建立自己的职场影响力呢？我个人的经验如下：

• 除了自己的本职工作，主动多做一些事情，能给同事带来帮助的小事就多做；

• 遇到问题及时沟通协调，从对方的角度思考问题，从共同的利益出发驱动工作进度；

• 自己主导或者负责的项目，汇报时只说问题，不牵涉到具体的部门和人，尽可能汇报当前进度，风险解决方案；

做这些事，其实就相当于给自己打造一个职场人设，比如技术好、爱分享、乐于助人、主动承担责任、工作认真负责。有了这些潜在的 buff 加持，大家都喜欢这种同事，你的职场影响力最终也会给你带来意想不到的好的结果。