事情拖到 DDL 效率特别高?程序员如何摆脱 deadline 驱动

共 2698字,需浏览 6分钟

 ·

2021-05-07 04:40

技术编辑:小魔丨发自 思否编辑部

公众号:SegmentFault




打工人谁不知道 deadline,尤其是那句「Deadline 是第一生产力」。deadline 本身没什么问题,很多情况下它的确能够提高生产力。但 deadline 需要合理的理由来支撑。「只是因为」(没别的原因)可不是什么好理由,这会给开发者带来伤害。

12 岁开始编程、具备十多年开发经验的 JavaScript 开发者 Rene Pot 讲述了他的经历。

Rene Pot 自述:不合理的 deadline 给我带来伤害

我曾经在一家创业公司待过,当时的前端和后端团队都只有 3 个人。我们在开发一款移动 app 的新版本,当然公司设置了上线的 deadline。但 deadline 是公司 CEO/CTO 设置的,理由并不充分。

当然,说它完全不合理似乎也不对,deadline 的设置应该基于对开发者能力的估计。

如果你是一名开发者,或者经常和开发者合作,你应该明白问题所在:「估计」只是估计,通常并不准确。其背后的原因不是开发者能力不够,而是对整个项目作出估计是件非常困难的事,很多完全预想不到的因素会将你的事先估计完全颠覆。

当时对那个项目的预测是经过两天会议讨论得出的结果,会议探讨了新特性,并将每一个部分彻底分解。每一部分都经过了估计、交叉估计,UI 和 UX 设计已完成,所需时间也得到计算,再加上一些缓冲时间,最终得到了 deadline。

你可能会想,既然 UI 和 UX 设计已经完成,还考虑了缓冲时间,这个估计应该很不错了啊。

然而,事实并非如此。

最终的开发时间估计是 3-4 周,这对于小团队的新 app 发布项目而言并不算充足。

的确如此,两周后,项目进程已经跟不上日程表。原因不是开发者干活太慢,而是事情的发展往往与预期不同。

后端团队在实现移动 app 的 API时,发现该系统无法正确处理简单的 add-on 组件,这意味着他们必须将现有 API 的一部分进行重写,这就导致 API 端点的完成时间比预期推后了两天。

而由于重写,API 的运行与之前会议所探讨的略有不同,这又导致团队重写了 app 的一部分,花费了数个小时。

这类重写对于任意规模的应用而言都是惯常操作,没啥可惊讶的。但是,这个项目有 deadline!现在我们已经落后了。

该怎么办呢?第二天我们被要求在原有 8 小时工作时间的基础上再加 4 个小时,公司免费提供餐食,但一天 12 个小时的工作量实在是太多了。不过,我们总算赶上了进度。

一周后,app 更新上线了。但我们并没有特别兴奋,短暂的庆祝后,我们又回到了电脑前,像是无事发生。

该更新没太大的厉害之处,只不过它必须那天上线而已。甚至用户都不知道 app 更新了,也没有人依赖它。新特性确实还不错,但更新发布时间推迟一天会有什么影响吗?会伤害任何人吗?

而非按 deadline 完成项目伤害了开发者。开发者之间会互相抱怨,他们与领导之间的关系也受到影响。

而且这种情况并非偶然,而是经常发生。

那么我们从中得到什么教训呢?完全丢弃 deadline?

当然不是。deadline 本身是个好事情,但它应该是一个目标,而不是僵硬的死线。新特性发布时间比预期晚个一两天无伤大雅。产品负责人真的要为了 deadline 给开发者施加那么大压力吗?在加班状态下,代码还能保持高质量吗?

特别是加班状态下开发者的心理状态很可能是「赶紧把这个做完」。有时候开发者甚至会选择「走捷径」,工作看起来是暂时完成了,但之后还需要重构。有时候这些「捷径」会导致重写,有时候甚至会被遗忘,开发者自己都未必注意到这些捷径,因为写的时候已经太累了,只想着回家。

如果捷径还需要被重构,那么这意味着需要更多时间。此外,加班时间写的代码往往会出现bug,而在生产级应用中发现 bug 后开发者的受挫感也会增加。

我认为,加班带来的收益是短期的,看起来是赶上了 deadline,但是下一个呢?由于可能需要重写,下一个 deadline 会落后于预期。开发者的幸福感降低、挫败感增加。这还不包括那些在版本发布后可能对用户造成影响的 bug。

如何改变?

设置 deadline 的人应该把时间花在正确地做事上。他们需要倾听开发者,追踪项目进度。如果项目进度落后于 deadline,而项目本身并不紧急,推后!当然,推后不意味着无限期,而是在当下的节点上重新对项目时间进行估计。鼓励开发者注意风险和拖延,并及时告知项目负责人。如果开发者注意到某些事情落后于进度了,他们应该及时告知产品负责人,然后负责人根据具体情况调整发布日期。

如果超前完成项目呢?这当然是好事,对每个人来说都是双赢。首先,这给 QA 留出了更多的时间。其次,产品负责人还可以请开发者改进已有代码库。

deadline,想说爱你不容易

Rene Pot 这篇文章被转发到 reddit 后,引起了大量讨论。

有人引用了英国作家道格拉斯 · 亚当斯 (Douglas Adams) 的名言:「我喜爱截稿日期,我喜欢它们飞逝而过时发出的呼啸声。」

还有网友调侃道:

没有 deadline,我怎么知道什么时候开始工作呢?

没有 deadline,你怎么知道什么时候可以停止工作呢?

但评论区更多的是对随意设置 deadline 的吐槽,甚至出现了「摸鱼指南」:

我一般会无视 sprint(冲刺)计划,很多任务一周时间完全不够用。而且截至目前,我并未被辞退。

sprint 计划其实是:要求你在 deadline 之前完成任务,这样当你没有完成后就会因为愧疚而加班。解决办法就是,把 deadline 丢回给制定它的人。

作为开发者,你认为什么样的 deadline 是合理的,什么样的 deadline 带来了伤害。请留言告诉我们。

参考链接:

https://javascript.plainenglish.io/how-setting-arbitrary-deadlines-can-hurt-developers-aa663df4d7ad

https://www.reddit.com/r/programming/comments/n4kgxi/how_setting_arbitrary_deadlines_can_hurt/



- END -

浏览 33
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报