前段时间,星球有位同学提了一个问题:测试同学如何提高在项目中的话语权?
其实这个问题,在职场中是普遍存在的一种现象。大家都希望能提高自己的话语权,按照自己的想法去推动工作的进度。但实际上,有了话语权就真的能解决问题吗?不尽然。
这篇文章,我想聊聊我对于所谓“话语权”的一些想法。
话语权的本质是什么
现代职场,很少有单打独斗就可以完成的工作了,基本都是通过多人协作配合,在流程制度的约束下,才能尽可能的按照预期完成项目。
而且按照预期完成项目达成目标还有一些隐形前提,即良好的职业素养,一定水平之上的专业技能,合理的流程规范以及比较好的项目管理手段,这些因素缺一不可。
但在实际的工作中,我们经常遇到的问题是预期100分的项目,能做到80分就已经很不错了,然后就是复盘,总结做的好的地方,反思做的不好的点,然后提出改进方案,逐步优化。为什么会出现这种问题?原因有这几点:
- 流程规范虽然有,但在实际执行中总会出现偏差;
- 团队中每个人的专业技能、职业素养各不相同,导致细小的环节出现偏差;
- 多人协同过程中,信息同步延时,理解不同带来的信息失真,导致执行出了问题;
- 项目开展过程中需求变更,人员变更以及其他偶发问题带来的不可控风险;
回到标题,因为工作在具体的执行细节里和预期出现了偏差,不同岗位的人有自己的工作职责,因此会按照自己的想法去试图纠正偏差。
但职场中除了明显的上下级关系带来的命令,所谓的话语权,只不过是个体自己的一厢情愿罢了。
话语权是否解决了问题
很多人想要的话语权和实际的话语权,在我看来是存在偏差的。
- 想象的话语权:你要按照我的想法去做,否则就会出现xxx问题,这样会导致yyy风险。潜台词就是我不想因为你这么做而导致我的工作难做,我也不想背锅,困难你去克服。
- 实际的话语权:我要求按照我的方式去做,这样做的好处是xxx,解决了yyy风险,如果由此带来新的问题或者风险,责任我来负责。
如果话语权不能解决问题,预防风险,并且为自己的建议或者话语权附带的结果负责的话,那所谓的话语权并没有解决问题。
很多人不明白的一点是,每个岗位都有自己的岗位职责,职代表这个岗位你要做的事情,责代表你要为做这些事的结果负责。
记得之前面试某企业的测试负责人岗位时,和他们的研发负责人聊过一个问题:测试和开发的职责范围和具体内容不一样,如何保证最终的交付质量?
我的回答是这样:虽然岗位职责和工作内容不同,但是目标是一致的,那就是线上交付的软件质量符合预期,不影响业务目标达成,不影响用户使用。
与其强制要求,不如从一些软性的角度驱动。比如:以结果为过程定性,绩效驱动,目标驱动。
共同为线上质量负责,流程规范交给工具,各种配置变更通过自动化流水线来解决,在需求阶段定义好目标,在研发阶段做好测试左移和评审,尽早的暴露风险,做好应对风险的冗余措施,制定应急响应机制。
相比于话语权,影响力更重要
其实职场中对于普通人来说,大家想要的是安稳做好自己的工作,少出问题,该拿的绩效和加薪拿到,不该背的锅不背。
但实际情况总会和理想出现偏差,无论是开发提交代码忘了合并,还是运维配置变更搞错了,或者测试同学漏测等情况在所难免。
出现问题解决问题是正确的思路,但是在执行时,尽可能的以共同的目标和利益驱动去解决问题,比如:有个bug开发不及时修改,测试同学可以说如果不及时修改,会导致整体测试进度延后。
这样的话我们可能要加班了,而且产品或者项目经理那边每天都会统计数据,会影响我们的绩效。而不是说如果你不及时修复提测,我就去发邮件告诉你领导或者项目经理这种造成对立的操作。
话语权看似很爽,但背后需要对自己的行动和结果负责。相比于话语权,对普通职场人来说,影响力反而更重要。如何建立自己的职场影响力呢?我个人的经验如下:
- 除了自己的本职工作,主动多做一些事情,能给同事带来帮助的小事就多做;
- 遇到问题及时沟通协调,从对方的角度思考问题,从共同的利益出发驱动工作进度;
- 自己主导或者负责的项目,汇报时只说问题,不牵涉到具体的部门和人,尽可能汇报当前进度,风险解决方案;
做这些事,其实就相当于给自己打造一个职场人设,比如技术好、爱分享、乐于助人、主动承担责任、工作认真负责。
有了这些潜在的buff加持,大家都喜欢这种同事,你的职场影响力最终也会给你带来意想不到的好的结果。
标签:同学,偏差,自己,话语权,问题,测试,职场 From: https://www.cnblogs.com/imyalost/p/17384565.html