先劃分出各端（前端、客戶端、後端），每個端單獨評估。需要時間最長的端即爲研發所需的最少時間。
對每個端評估時，列出參與這個項目的所有人員。爲了便於描述，我們把其中技術能力最強或工作效率最高的人稱爲 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 產出率
- 工作配套的硬件設施是否滿足要求，如電腦配置
把所有技術的部分用對應的領域替換後，這種評估方法也適合產品、測試人員。
總之要做好團隊合作哦~~~
