10 天的开发量,老板让我 1 天完成,怎么办?

大家好,我是树哥!

昨天,我在文章《业务开发做到零 bug 有多难?》和大家聊了下影响零 bug 的一些因素。其中,我提到了开发时被压缩工时,应该怎么做。今天,我们就来聊聊这个话题。

只要工作过几年的小伙伴,必然会遇到过背压工时的情况。面对这种情况,不同的工作年限、在不同的公司、不同的团队氛围下,都会有不同的反应。如果你是一个刚刚毕业的萌新开发,很大情况下你会选择自己加班服从。甚至加班都完不成的情况下,你还吭哧吭哧不出声。

最后等待你的结果就是 ------ 成为被复盘的对象,被批评。那么如果遇到了开发时间被压缩,或者被质疑的情况下,我们除了默默加班接受之外,还能做些什么来让自己没那么苦逼吗?

在我看来,自己一个人傻傻加班是下下签,是最后实在没办法才做的无奈之举。一旦有其他选择,你都不应该提出自己加班加点做完。那么,到底有什么办法可以解决工时被压缩这一问题呢?

解释工时构成

如果你的开发时间被压缩,那么较大可能是 leader 质疑你评估出的工时。假设你的工时评估并没有问题,那么就是你考虑到了一些风险点,而你的 leader 并没有考虑到。毕竟这也很正常,对于一个很久没有写代码的管理者来说,其会习惯性地忽略一些细节性的东西。

这个时候,你要做的不是胆怯地接受。而是要主动去找 leader ,跟他解释工时是怎么评估出来的。你考虑到了某些风险点,为什么是这么多工时。如果你的 leader 不是傻子,那么相信他会接受你的解释。但这里要注意的是,解释的时候记得要语气好些,不要怒气冲冲地找别人,不然话没说然就吵起来了。

减少需求内容

假设你和 leader 已经进行了友好地沟通, leader 也认可了你的评估时间。但是他说:没办法,老板就要求那个时间点做完,没办法给你更多时间了!

这时候,萌新小白就会老老实实回去座位上加班,最后还是干不完被批斗。但对于职场老油条来说,他就学会与 leader 以及产品沟通 ------ 能不能少点需求内容。例如:我们要做一个员工列表,那是不是只做列表就可以,不用做筛选和搜索了?员工详情是不是也可以先不走了?

老板可以指定最终完成的时间,但是他基本不会干涉到具体的细节上面。这时候就给我们留下了沟通的空间,这也就是作为开发的你可以争取的东西。对于一个有经验的产品经理来说,如果研发给他提出了减少非核心功能的诉求,他一般也会答应的。

申请更多资源

如果产品说:不行,我们每个功能点都得做,一点需求都少不了!

这时候你可以再向你的老板提出诉求 ------ 申请更多资源。

前面你也解释过工时的构成,做这么多功能确实需要这么多时间。如果最终上线时间不能推迟,那么就只能投入更多的资源了。

在这种情况下,如果公司还有富裕的研发资源,那自然会优先考虑你这边的诉求。对于你来说,你的研发压力也自然变小了。

分摊开发压力

如果实在又申请不到更多资源,这个项目又只能由你们团队 5 个人来完成,怎么办?

很多时候,不同开发人员的开发压力不一样。可能你开发压力比较大,其他人开发压力比较小,这时候你可以提出 ------ 是否可以让其他小伙伴帮忙做点工作,这样可以减少一些压力?

我想,如果你的 leader 也应该会考虑你的诉求。千万不要自己明明完成不了,还要硬抗。到最后加班干了几个星期,需求还是完成不了,不仅辛苦的付出得不到理解,还被批斗。那可就真的是赔了夫人又折兵啊!

千万不要觉得这种情况不会发生,在我去年工作的时候,就发生了这样一个事情,我也是很同情那位同学的。如果那位同学能看到这篇文章,那么或许他后面就不会踩坑了吧。

推迟上线时间

上面说得是最终上线时间无法变更的情况,但很多时候并没有这种倒排需求。很多需求的上线时间并不是一成不变的,你只要给出足够合理的解释,也都是可以沟通的。

因此,如果在上面的沟通方法都行不通的情况下,你也可以沟通看看是否可以推迟上线时间。毕竟相对于研发速度来说,研发质量肯定更加重要。

终极绝招

大多数情况下,如果你能合理应用上面提到的几种沟通方式,被压缩工时的问题一般都能解决。但有些小伙伴会问:那如果真的所有办法都失效了呢?那怎么办?

其实,大多数情况下,不太可能到了需要使用绝招的地步。但如果真的到了这一步,那你就做好「殊死一搏」的准备,用上这个绝招吧 ------ 调预期、表态度。

调预期,就是给你的 leader 打预防针,提前告诉他这样做的后果就是 ------ 质量差、很难做得完。如果他还是这么坚定地推进,那么如果真的做不完,相信他也理解,不会太过于责怪你。

表态度,就是得加加班。如果你之前已经说了压力很大,甚至加班都做不完。那么你至少还是得表表态度,不能像往常一样早早下班,这样即使最后搞砸了。由于你态度还算端正,还不至于被责怪得太狠。但如果你要是又说做不完,又每天早早下班,那别人就觉得是你态度问题了。

走到这一步,实属是无奈,但这也是最后的保命之举了,除非你不想在这干了。

总结

今天分享了几种沟通解决「被压缩工时」的方法,包括:

  • 解释工时构成
  • 减少需求内容
  • 申请更多资源
  • 分摊开发压力
  • 推迟上线时间

本质上来说,就是不要自己一个人傻傻地抗压力,不要让自己背负着太大压力。我们要明白自己能做到什么程度,而且不要早早把「自己加班」这一最后的保命、卖惨利器祭出。他应该是自己的保命技能,而不是为别人锦上添花的技能。

特别是,不要因为赶进度、赶工时,而去牺牲开发质量。因为如果你这么做了,后果就是你付出了很多时间和精力,最后你会在项目复盘会上检讨 ------ 为什么你的功能代码质量这么差。这是另一个话题了,后续有时间我们继续聊。

希望大家都能够活学活用,下次在和 leader 以及产品沟通的时候,用上这些沟通技巧吧!希望大家都不要加班,准时下班!

如果你觉得今天的文章对你有帮助,欢迎点赞转发评论支持树哥,你的支持对于我很重要,感谢大家!

相关推荐
不知更鸟1 小时前
Django 项目设置流程
后端·python·django
黄昏恋慕黎明2 小时前
spring MVC了解
java·后端·spring·mvc
G探险者4 小时前
为什么 VARCHAR(1000) 存不了 1000 个汉字? —— 详解主流数据库“字段长度”的底层差异
数据库·后端·mysql
百锦再4 小时前
第18章 高级特征
android·java·开发语言·后端·python·rust·django
Tony Bai5 小时前
Go 在 Web3 的统治力:2025 年架构与生态综述
开发语言·后端·架构·golang·web3
程序猿20235 小时前
项目结构深度解析:理解Spring Boot项目的标准布局和约定
java·spring boot·后端
RainbowSea5 小时前
内网穿透配置和使用
java·后端
掘金码甲哥6 小时前
网关上的限流器
后端
q***06296 小时前
搭建Golang gRPC环境:protoc、protoc-gen-go 和 protoc-gen-go-grpc 工具安装教程
开发语言·后端·golang
GOTXX7 小时前
用Rust实现一个简易的rsync(远程文件同步)工具
开发语言·后端·rust