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

如果你在外包公司工作过，或者你正在外包公司工作。我相信你一定会遇到评估项目工作量的情况，或者你是评估其中一部分的功能。在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周后系统不属于我们维护范围了。要维护就要给钱了的。这些都是需要跟客户说清楚。不要到了后面，发生没必要争论。这样多不好

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

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