测试管理 堆人可以把项目干好么

CKL的思考 · 2023年07月19日 · 最后由 Barry250 回复于 2023年07月24日 · 4611 次阅读

如果有人问你,在 IT 系统的建设过程中,当项目进度存在滞后的风险,靠堆人能解决问题吗?相信多数人的回答都是:不能。

那,是否真的是这么绝对呢?

“当意识到进度的偏移时,下意识(以及传统)的反应是增加人力。这就像使用汽油灭火一样,只会使事情更糟。越来越大的火势需要更多的汽油,从而进入了一场注定会导致灾难的循环。” --《人月神话》

01

针对人月(工作量单位,指 1 个人在 1 个月内的产出),时间和人数是否存在真的换算关系?书中给出了 4 类关系,如下图所示:

不需要交流的事:比如厂线上的计件活动,他是可以通过堆人的方式,把所需时间降下来。各类标准化的活动,都可以按此曲线解释。

无法分解的事:增加人手也无法追赶进度的事,典型的十月怀胎,无论是多少人,都得是十个月。这类事通常是不以人的意志为转移的。

少量沟通的事:仅需要少量沟通,就能快速复制的事。这个场景与第一个场景的区别在于,这类事是非标准化的,还存在沟通,所以它的下限会比较高,也就是不能堆太多的人。人一多,沟通成本就上来了。

大量沟通的事:基本上 IT 的活动都是这类场景,需要大量的沟通对齐,所以会说 IT 的事堆人是没什么用的。

前面两种情况在 IT 活动中基本不存在,所以不讨论,本文主要讨论后两种情况在 IT 中的实践。

02

先聊聊第三种情况:少量沟通的事,在 IT 的场景中,什么情况下会出现呢?这时候适当堆人其实是能解决问题的。这种场景的适用前提是:非标准化的少量沟通。

背景:某团队在 UAT 环境中,遗留了近 200 个 P2 级别的 BUG(一般问题及优化建议,不影响主流程使用。嗯,我们业务比较友好,所以不用计较为什么有这么多还能上线),业务希望在上线后的 1 周内修复完成。但现在研发团队只有 8 个人,还需要负责后续迭代的研发,按当下的资源肯定是无法按期交付的。

解决方案:经过团队内部评估,可以通过堆人来解决这个问题。原因是这些 BUG 都是比较简单就能修复好的,不会有太大的影响。所以就紧急抽调了同一个产品线上的其他其他人员来支援(注意这个前提,是同一产品线上的人,他们对系统同样熟悉,只是在做别的版本),共来了 10 个人,配合着每日严格的任务规划,还是把这 200 多个 BUG 完全修复并交付上线。

大力还是能出奇迹的,只要条件和方法合适。解决方案的选择,需要理解前提条件

03

再聊聊第 4 种情况:大量沟通的事。这个是 IT 团队大量存在的问题。敏捷研发过程强调的就是沟通。那么,在这种情况下,如果项目滞后,存在延期风险,堆人显然不是合理的方式了。

“向进度落后的项目中盲目增加人手,只会使进度更落后” --《人月神话》

背景:在某个 730 版本的研发过程中,原计划需要 2 个迭代来完成,但是第一个迭代由于各种原因有延期,需要在第二个迭代中追赶回来,由于需求已经澄清,各开发也只有自己了解自己的 Story 内容,这个时候堆人是解决不了问题的。

解决方案: 没有什么好的解决方案,而且不能给团队传导更多的压力,让士气变得更低落。向全员透明情况,通过加班,把时间变多来,集体攻坚,让进度赶上来。负责人需要提供好各类后勤保障。当然,这不是一个长期的解决方案。(如果你有更好的解决方案,可以沟通)

在这种场景下,管理应该反思为什么没有及时发现风险。因为延期不是突然发生的,它一定是在某种外部变化下,人员去处理其他的其他的问题了,或者是某个前置依赖的 Story 延期了,导致后续一连串的延期,又或者只是某个人员的请假,风险没有被及时识别出来。

04

不论是哪种情况,都不能盲目乐观。不能期待一切都将运作良好,每一项任务仅花费它所 “应该” 花费的时间。

就像第一个例子,虽然我们及时解决了问题,但中间还是花了 1 天的时间让团队做好交接。第二个例子,最终还是 Delay 了。

做好前期规划,关注团队变化的细节,给排期预留一定的冗余时间。尊重团队实际产能。才能让延期的事少发生。

魔幻的延期,需要未雨绸缪。

共勉。

共收到 8 条回复 时间 点赞

我司某个项目上线日期定好之后,几乎每个版本都延期

水山 回复

每个版本都延期,也是一种不延期😂

不要把《人月神话》神话了。设计、过程文档和工具准备到位的情况下,追加人手效率可能会下降,但绝大多数情况下,一定会比人手少做的更好。

针对项目进度落后这件事, 之前考 PMP 的时候,有说这几种情况的处理方法:1、项目的计划变更;2、快速跟进(把串行的事变成并行,比如分批提交测试使测试时间与部分开发时间并行);3、赶工(所谓的追加资源,比如加人力或者加班);4、重新谈判(这点个人觉得主要是对接外部或者跨组织项目时进行安抚和谈判,这种做法本质上是将延期的风险转嫁给了他方)

多数人回答不能,但是还会本能的堆人。
1 个人导致的项目进度问题,和加了人还导致进度问题,你是当事人,你选不选堆人

楼主这个模型感觉有点过于简单了,实际项目情况会更复杂。

比如因为会议多或者人员并行任务多,导致效率低,此时加人分担一部分任务,提高关键人员的专注度,是可以提效的。
另外,系统模块或者需求拆分足够合理,情况会接近场景 3-少量沟通,此时加人也可以提效。
还有一种情况,就是人员能力问题。可能本身项目里人员能力不足导致的进度不及预期,此时如果加一个能力强的,也可以提效。

单纯堆人大部分情况确实对项目进度没有帮助,但至少增加了解决问题可以选择的方法,合理利用还是有办法提效的。

PS:如楼上所说,加人是最常见和最容易实施的解决项目进度落后的手段。在领导看来,不加人会被理解为你没有尽最大的努力,此时最合适的解决方法,还是要加人。

理论和实际总会有出入,本文讨论的只是一些可能,在符合 3 模型的条件下,加人是合理的。

不能因为延期经常出现,就觉得他是合理的。

防微杜渐,未雨绸缪。尊重团队产能,才会做的更好。

堆的是什么样的人,很重要

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册