需求的工作量不应该通过人日来评估，因为不同团队，对于相同功能点的开发时长是不同的。需求的工作量的单位应该是分解到最后的功能点数量。再细化一些，对于服务端是领域模型、领域服务数量，流程分支节点数量，对于前端、交互我不是很了解，但偏展示层可能更多的是页面区块、交互流程、行动点的数量。这些已经有量化的可能性了。
四 定义、衡量研发成本
研发成本，在一般的工程效能里面有时候会被简单的理解为人日，单纯的交付人日的衡量，其实比较简单，整个团队的人数*工作天数。但容易被流程设计者忽视的是，站在企业成本的视角，交付人日，可能还要按照开发人员的收入进行加权。从这个角度来看，技术团队效能里面的研发成本，准确的来说就是公司对于研发的金钱投入，包括购买服务器、云服务、培训、行政投入。
这部分对于提升效能的启发是：
哪些功能自研、哪些功能靠购买，有时候真的得算一笔帐。
软件开发是一个边际成本递减的行业，如何让功能更简单的得到复用，可能是对效能提升最有帮助的部分之一（复用50个人日的功能模块，就几乎等于省了50人日的研发成本。当然也可能存在复用及后期维护的成本大于新建成本的情况，需要有良好的设计去规避）。
五 定义交付时长
我自己之前曾经陷入一个误区，认为交付时长就是从开始开发，到完成上线，这个就是交付时长。但是回到客户价值这个维度来思考，技术团队交付时长（这个时候可能说产研团队更合适一些），应该是从业务的一个想法，到验证、立项、完成发布、灰度，到最终用户可以真正使用的时长。
于是单位价值的平均交付时长，就变成了以下公式：
需求的交付价值量/需求功能真正被用户使用的时间-业务提出该功能、产品立项的时间
六 如何衡量交付时长
衡量交付时长其实也比较简单，记录下业务提出该功能的时间以及功能开发的时间。难点可能是整个价值流交付过程中细化的指标，而细化的指标更能帮助我们发现问题。于是我们可以从一般项目的生命周期来看，哪些节点的时长会影响我们的交付：
需求立项到评审的时长
需求评审到技术方案评审的时长（如果项目很大可能会有多个层次的设计方案）
技术方案评审完成到开发完成自测的时长
自测的时长
多端联调的时长
测试的时长
bug验证的时长，bug的数量（reopen可以数量+1）
环境部署等待的时长
代码合并的时长（主干发布的情况下）
回归的时长
发布的时长
灰度的时长
这部分对于提升效能容易忽视或有启发的点是：
需求的拆分成基本的功能闭环进行迭代（以不引入或少引入测试的重复回归为标准），或许能比较有效的降低需求价值量的平均交付时长。
自测充分、减少bug数量，最终减少联调、测试回归的次数和时长，在一定的单测覆盖率要求以前，是收益大于成本的。
代码合并有时候冲突解决很麻烦，会导致一次部署的时间很长，且代码合并引入了更多次的测试回归工作（这可能是某些BU往主干开发分支发布走的原因之一）。所以基于业务的理解，进行应用的拆分，减少单个应用的并发数量，也可以提升研发效能。
在缺乏有效的项目管理的情况下，资源的相互等待可能是项目延期的一大因素，有时候某端开发完了，另一端资源没到位，一直不能联调提测。项目管理的同学对于资源目前的分工和瓶颈应该给上游及时的反馈。
容易陷入误区的点是：
技术方案（架构、详细设计）的评审既然是很大的一块耗时，是不是可以直接写代码，少写方案。我理解在技术方案写不熟练的情况下，写技术