怎样的工作量评估更合理?

时间:2024-05-19 07:52:45

如果你在外包公司工作过,或者你正在外包公司工作。我相信你一定会遇到评估项目工作量的情况,或者你是评估其中一部分的功能。在PMP里面介绍,评估工作量最好是找最熟悉这个功能的人,也就是专家判断。所以肯定非你莫属了,毕竟你已经成为了专家。但我相信也肯定会遇到一种情况,工作量评估提交给客户后,客户开始砍工作量。然后你们进入一段工作量争论的时光中。

我一直在考虑为什么每次提交工作量评估给客户,都要进行一顿争论。客户会觉得你报这么多工作量是不是坑我,我觉得挺简单的功能真的要做这么久?我们又会觉得,客户啥也不懂就这砍那砍。所以总结起来就是,客户觉得你这个工作量不合理,但我们又说服不了客户,让客户觉得这个工作量合理。所以我决定基于这个论点:工作量可以多,但一定要合理。怎么做到工作量评估更合理,这就是我们要解决的问题。所以我就根据目前公司的工作量评估方法,得出一套方法论。

原则:一定要合理

再次强调一遍原则:工作量可以多,但一定要合理。可以不准确但一定要合理,因为合理并不代表准确。以下我以一个全新的项目展开讨论。

当我们接到一个项目进行工作量评估时,可以分为几个大模块去评估。分别是:需求阶段、设计阶段、编码阶段、SIT阶段、Support UAT阶段、上线支持阶段。我相信不会有人认为,工作量评估只是评估开发的工作量就好了。这样就太不严谨了,在开发的过程中会很多坑的。所以我认为一个项目工作量的评估一定要包含以上几个阶段,无论大小。有些路走了才不会遇到怪兽。

需求阶段

在做项目工作量评估的时候,我觉得一定要定好一个主评估人,让主评估人起到一个牵头和整合的作用。为什么?因为在这个评估的过程中,可能专家们只负责其中的一部分。如果没有主评估人,就没有主要负责人,这个评估时没有灵魂的。更重要的是没有人去整合评估出来的工作量。需要阶段的工作量评估,要计算你理解需求的时间(类似看文档和理解文档),把需求分解为功能点的时间。这个阶段可能会几个人参与,都要算工作量,要记住每个人上班都是拿时间换钱,所以时间就是金钱,不是白给的。假设,一个需求介绍会议:需要4个人参加,Web端工程师,后端工程师,app端工程师,PM项目经理。一个小时的会议,工作量就是4*1=4个小时,也就是半天了,评估时不能只算一个人的工作量,没有算其他同事的。还有我觉得在开需求介绍会之前,一定一定一定要提前看需求文档,自己理解需求。并不能等客户讲解时再去看,这样太懵懂了,其实你会很多问题要问的,但是你不够了解,根据提不出问题。这就跟读书的时候一样的,听老师讲课之前要自己预习,这样听起来才能理解透彻。特别是主评估人一定要提前理解需求,这样为后面的分解提供很大的帮助,要不你只会不断问客户,这样太不专业。

设计阶段

设计阶段的评估,包括三个方面的内容。功能设计分析和讨论、编写功能设计文档、跟客户确认功能设计文档。在我们需求分析和分解功能点做完后,就是开始与专家(也就是说后端同事,web同事,app端同事)讨论这个功能到底要怎么实现,业务逻辑是怎样的。讨论出结果后,就是开始编写功能设计文档了,内容就是:功能到底怎么实现,具体可以细app或web端点击什么按钮,请求什么接口,上传的字段,获取的字段都在这里定义好。这份文档对开发人员来说就是,一个说明书,向导,告诉你怎么做。对客户来说意味着这是基准,后期如果提出功能设计文档没有涉及的内容时,你就可以拿出来说,文档没有,这是变更,要做可以,加钱。如果没这份文档,只能陷入无限争论之中。太难了。所以写好功能设计文档,一定要跟客户确认,客户确认后,才能进入开发。一天不确认,一天不开发。编写功能设计文档我们需要考虑,我们要写几个端的?假设需要写后端、app端的。则需要考虑,每个接口都要写,作用什么,上传的字段有哪些?返回的字段有哪些?业务逻辑是怎样的?还有数据库脚本,数据库表设计等等。如果功能复杂且很多的,一个文档可以写到一周。

编码阶段

上述所述的把需求分解成功能点或者可交付成果,但是我们评估工作量时,还需把可交付成果与功能点继续分解成活动。在PMP中做进度计划前提是,把可交付成果分解成每个可执行的活动。再根据每个活动的持续时间合算成一起组成功能点的时间。这样跟客户谈起来,你才能有理有据。并不是随随便便拍脑袋的。最好在每个功能点估算旁边进行备注,让客户知道你要做哪些事情。

内部测试阶段SIT

有三部分的工作要做:编写集成测试的用例、根据测试用例进行测试、再来一次回归测试。回归测试我的理解就是,你在测试过程中,出现的问题记录下来。在回归测试的时候,再测试一次。这里属于质量保证的一种方式,要确保项目交给客户时,没有那么多问题。给客户留下好的印象,也能体现出我们的专业。编写测试用例的时间估算是根据功能复杂程度的。比如:后端接口,算出来有多少个,一个接口至少有3条用例,接口如果是20个 就是20*3=60条用例,一条用例用10分钟编写就是 60*10 = 600分钟,就是10个小时,就是一天多了。然后加上前端的功能测试这样一步一步算出来。有理有据,并不是凭空说的。

Support UAT

UAT的周期可以根据项目大小而定,如果是100天以上,最好是分几轮UAT,每轮的周期为1-2周。如果是10天以内的,就一周可以啦。然后我们评估出在这个期间需要付出的工作量,如果是项目很复杂的话,则一周3天以上。如果是简单的,一周一天就可以啦。根据实际来,这里的工作量,包括改bug,以及客户的一些问题,需要你协调或解答的时间。

Support 上线

上线支持的时间也是根据项目复杂程度进行计算的。不过进行前面SIT和UAT的过滤,我们已经是解决了大部分的bug或问题。所以这里的时间不用太多了,一周1天,或者一个月2天就差不多了。

约束

除了上面的几个阶段,我们还需在文档里面写明一些约束。作用是有些东西我们需要澄清,还需告诉客户有哪些范围我们不包括,不做,不提供的。假如:支持上线4周,4周后系统不属于我们维护范围了。要维护就要给钱了的。这些都是需要跟客户说清楚。不要到了后面,发生没必要争论。这样多不好

总上所述,就可以写出以下这份文档的格式了。

怎样的工作量评估更合理?

希望能帮助你们评估工作量的时候提供一种思路,如果你有更好的方法请告诉我。我也还在继续研究中,继续优化,向合理更靠近点。

相关文章