大家好，我是树哥！
昨天，我在文章《业务开发做到零 bug 有多难？》和大家聊了下影响零 bug 的一些因素。其中，我提到了开发时被压缩工时，应该怎么做。今天，我们就来聊聊这个话题。
只要工作过几年的小伙伴，必然会遇到过背压工时的情况。面对这种情况，不同的工作年限、在不同的公司、不同的团队氛围下，都会有不同的反应。如果你是一个刚刚毕业的萌新开发，很大情况下你会选择自己加班服从。甚至加班都完不成的情况下，你还吭哧吭哧不出声。
最后等待你的结果就是 —— 成为被复盘的对象，被批评。那么如果遇到了开发时间被压缩，或者被质疑的情况下，我们除了默默加班接受之外，还能做些什么来让自己没那么苦逼吗？
在我看来，自己一个人傻傻加班是下下签，是最后实在没办法才做的无奈之举。一旦有其他选择，你都不应该提出自己加班加点做完。那么，到底有什么办法可以解决工时被压缩这一问题呢？
解释工时构成
如果你的开发时间被压缩，那么较大可能是 leader 质疑你评估出的工时。假设你的工时评估并没有问题，那么就是你考虑到了一些风险点，而你的 leader 并没有考虑到。毕竟这也很正常，对于一个很久没有写代码的管理者来说，其会习惯性地忽略一些细节性的东西。
这个时候，你要做的不是胆怯地接受。而是要主动去找 leader ，跟他解释工时是怎么评估出来的。你考虑到了某些风险点，为什么是这么多工时。如果你的 leader 不是傻子，那么相信他会接受你的解释。但这里要注意的是，解释的时候记得要语气好些，不要怒气冲冲地找别人，不然话没说然就吵起来了。
减少需求内容
假设你和 leader 已经进行了友好地沟通， leader 也认可了你的评估时间。但是他说：没办法，老板就要求那个时间点做完，没办法给你更多时间了！
这时候，萌新小白就会老老实实回去座位上加班，最后还是干不完被批斗。但对于职场老油条来说，他就学会与 leader 以及产品沟通 —— 能不能少点需求内容。例如：我们要做一个员工列表，那是不是只做列表就可以，不用做筛选和搜索了？员工详情是不是也可以先不走了？
老板可以指定最终完成的时间，但是他基本不会干涉到具体的细节上面。这时候就给我们留下了沟通的空间，这也就是作为开发的你可以争取的东西。对于一个有经验的产品经理来说，如果研发给他提出了减少非核心功能的诉求，他一般也会答应的。
申请更多资源
如果产品说：不行，我们每个功能点都得做，一点需求都少不了！
这时候你可以再向你的老板提出诉求 —— 申请更多资源。
前面你也解释过工时的构成，做这么多功能确实需要这么多时间。如果最终上线时间不能推迟，那么就只能投入更多的资源了。
在这种情况下，如果公司还有富裕的研发资源，那自然会优先考虑你这边的诉求。对于你来说，你的研发压力也自然变小了。
分摊开发压力
如果实在又申请不到更多资源，这个项目又只能由你们团队 5 个人来完成，怎么办？
很多时候，不同开发人员的开发压力不一样。可能你开发压力比较大，其他人开发压力比较小，这时候你可以提出 —— 是否可以让其他小伙伴帮忙做点工作，这样可以减少一些压力？
我想，如果你的 leader 也应该会考虑你的诉求。千万不要自己明明完成不了，还要硬抗。到最后加班干了几个星期，需求还是完成不了，不仅辛苦的付出得不到理解，还被批斗。那可就真的是赔了夫人又折兵啊！
千万不要觉得这种情况不会发生，在我去年工作的时候，就发生了这样一个事情，我也是很同情那位同学的。如果那位同学能看到这篇文章，那么或许他后面就不会踩坑了吧。
推迟上线时间
上面说得是最终上线时间无法变更的情况，但很多时候并没有这种倒排需求。很多需求的上线时间并不是一成不变的，你只要给出足够合理的解释，也都是可以沟通的。
因此，如果在上面的沟通方法都行不通的情况下，你也可以沟通看看是否可以推迟上线时间。毕竟相对于研发速度来说，研发质量肯定更加重要。
终极绝招
大多数情况下，如果你能合理应用上面提到的几种沟通方式，被压缩工时的问题一般都能解决。但有些小伙伴会问：那如果真的所有办法都失效了呢？那怎么办？
其实，大多数情况下，不太可能到了需要使用绝招的地步。但如果真的到了这一步，那你就做好「殊死一搏」的准备，用上这个绝招吧 —— 调预期、表态度。
调预期，就是给你的 leader 打预防针，提前告诉他这样做的后果就是 —— 质量差、很难做得完。如果他还是这么坚定地推进，那么如果真的做不完，相信他也理解，不会太过于责怪你。
表态度，就是得加加班。如果你之前已经说了压力很大，甚至加班都做不完。那么你至少还是得表表态度，不能像往常一样早早下班，这样即使最后搞砸了。由于你态度还算端正，还不至于被责怪得太狠。但如果你要是又说做不完，又每天早早下班，那别人就觉得是你态度问题了。
走到这一步，实属是无奈，但这也是最后的保命之举了，除非你不想在这干了。
总结
今天分享了几种沟通解决「被压缩工时」的方法，包括：
- 解释工时构成
- 减少需求内容
- 申请更多资源
- 分摊开发压力
- 推迟上线时间
本质上来说，就是不要自己一个人傻傻地抗压力，不要让自己背负着太大压力。我们要明白自己能做到什么程度，而且不要早早把「自己加班」这一最后的保命、卖惨利器祭出。他应该是自己的保命技能，而不是为别人锦上添花的技能。
特别是，不要因为赶进度、赶工时，而去牺牲开发质量。因为如果你这么做了，后果就是你付出了很多时间和精力，最后你会在项目复盘会上检讨 —— 为什么你的功能代码质量这么差。这是另一个话题了，后续有时间我们继续聊。
希望大家都能够活学活用，下次在和 leader 以及产品沟通的时候，用上这些沟通技巧吧！希望大家都不要加班，准时下班！
如果你觉得今天的文章对你有帮助，欢迎点赞转发评论支持树哥，你的支持对于我很重要，感谢大家！
参考资料
- 工作中别人质疑你，压你工时怎么办？ - 掘金
- 关于项目排期的问题，如何更好的排期？ - 黑石的回答 - 知乎
- 在敏捷开发，如何评估开发任务的工时更合理？_一个接口评估工时-CSDN博客
评论区