先划分出各端（前端、客户端、后端），每个端单独评估。需要时间最长的端即为研发所需的最少时间。

对每个端评估时，列出参与这个项目的所有人员。为了便于描述，我们把其中技术能力最强或工作效率最高的人称为 A。

A 一天（除去加班、小憩时间）能完成的工作量定义为 1 人天（也有叫”人日“的，注意两个字合起来是一个量词/单位），同时 A 的战斗力定为 1.0。这个需求按照 A 的标准要几天才能完成，则它的工作量可量化为多少人天。

再把其他人员逐一跟 A 比较做评估，如果 B 一天能完成的工作量是 A 的 70%，则把 B 的战斗力定为 0.7。假如还有 C 的战斗力 0.5，则这个团队的总战斗力为 1.0 + 0.7 + 0.5 = 2.2。

如果某个需求的工作量是 11 人天，则最理想的情况下，这个3人团队需要用 11 / 2.2 = 5 天来完成。

团队的人数越多，花在沟通上的时间也会增多。再加上可能有技术评估不准、部门会议、临时请假的情况，在估算整体所需时间时，应乘以一个大于1的浮动系数（例如 1.2）来作为最终时间。在上例中，向项目组报备的工作量应为 5 * 1.2 = 6 天。类似地，如果要 996，则可乘以一个小于 1 的系数，可以是 0.85。

在实际情况下，并非所有团队成员都全天参与此项目，同时参加多个项目的情况很常见。如果 A 对本项目只投入一半的时间，则团队的总战斗力应算成 1.0 * 0.5 + 0.7 + 0.5 = 1.7。

除了编码技能外，影响一个人或团队的战斗力的因素还有：

• 代码熟悉程度，是否需要先学习前人写的代码
• 需求是否可拆分给多人合作；多人合作会不会反而更慢
• 历史遗留问题多不多，会不会踩坑
• 修改的地方是否重要，牵扯面是否广，引起的回归测试量是否大
• 是否有技术方案未确定、需要预研的部分
• 跨团队合作的部分是否有依赖，沟通是否顺畅
• 代码质量，bug 产出率
• 工作配套的硬件设施是否满足要求，如电脑配置

另外特别注意的是如何定义“完成”，“完成”是指编写完代码还是自测完毕还是解bug完毕？要明确好这个概念的意思再向项目组报备所需工作时间。测试过程的时间一般是写代码时间的5%~15%，具体看人的能力。

把所有技术的部分用对应的领域替换后，这种评估方法也适合产品、测试人员。

总之要做好团队合作哦~~~