以下内容多是一些形而上学的东西，都属于泛泛而谈，很多内容都是完全正确的废话，请选择性、辩证性的看待

命题：怎们衡量产品、研发人效，项目人员需求测算，需求审核，怎么排期，怎么合理安排人员

1.  产研团队绑定业务团队的目标，用目标牵引产研团队提升交付质量和效率

1.1.  目标绑定

• 从公司的整体目标中，拆解出业务目标，围绕公司的整体目标，拆解出各个业务指标。
• 产研团队主要负责系统研发工作，承接新的业务模式，以及提升已有业务的整体运营效率。
• 考虑到产研团队无法独立对整体的业务目标负责，但也是达成业务指标中不可或缺的一个关键环节，在设计产研的整体考核时，整体业务目标的达成应占据产研团队考核权重的20%-40%，在实际应用的过程中，产研团队按期交付对应的业务系统能力也只能达成及格的考核水平，要想拿高绩效则需要深入业务关键目标，协同市场、运营一起达成业务目标。

1.2.  聚焦业务目标

• 在任何公司，不管公司的体量如何，业务需求总是无止境的，但公司在研发侧的投入总是有限的。因此在设定业务的整体目标时，需要聚焦，集中力量优先解决主要问题，每个季度、每个月都需要聚焦在主要问题上，优先解决关键问题，逐步完善、优化系统对业务的支撑能力
• 在执行过程中，需要通过季度会议，月会、周报等方式同步各自的工作进度，及时同暴露问题，以便及时调整工作计划避免出现信息不对称、协同脱节、目标不一致的情况

1.3.  产研考核体系的设计思路

• 产品、研发在设计考核方案的时候，遵循先定量，再定性的原则
• 产品的考核主要围绕新业务模式的支撑，运营效率的提升，业务现存问题的优化等
  • 开发的功能、系统的考核以能支撑新业务模式顺利落地为导向，并以最终的业务指标作为考核标准，在设计的时候业务模式能顺利落地只是及格，协同业务侧交付、落地才能拿到高绩效
  • 针对运营效率的提升，需要通过业务流程进行拆解，探讨初步的方案并就方案对效率的提升效果进行估算，以估算的值作为考核指标
  • 现存的业务问题通常也会带来运营效率问题，或者是对业务支撑能力不足，能定量则优先定量，不能定量则定性

• 研发在整个研发体系内，位于产品的下游，研发的考核主要围绕交付质量和交付效率，业务目标的达成在研发侧考核的占比的权重应略低于产品。研发侧需要协同产品共同考虑以灵活的产品、系统架构应对业务的拓展，提前在系统基础能力上做相关的前瞻性建设。

2.  如何量化产研团队的交付质量、交付效率

• 在量化整个产品、研发团队的交付质量、交付效率时，主要从需求的交付效率（同时需要考虑需求的颗粒度以及对应的研发人力投入情况）以及交付后缺陷的数量来评估
  • 交付效率 = 周期时间内完成的需求数量（需要换算成故事点）/周期时间内投入的人力
  • 交付质量 = 周期时间内新上线功能导致的BUG数量/周期时间内新上线的需求总数
• 通过需求的整体概览可以量化出目前需求的整体数量、状态分布、优先级分布、停留时长等，这些指标主要用于掌握目前需求的整体概况，也便于对后续的工作进行合理规划，也能反应出产研团队处理需求的吞吐量
• 在运用研发度量指标体系的时候，需要把重点放在效能的提升上，以达成业务目标为前提，把业务目标达成作为重点考核对象，综合运用研发度量指标体系的相关数据指标，找到研发体系中各个环节存在的问题，持续优化、改善、提升研发的整体效能。单纯的考核产品、研发的人效反而会造成刻意刷需求数量、过度使用短期解决方案、牺牲系统架构的灵活性和扩展性等问题。从公司层面可以用研发人力成本/业务营收的占比，IT设备成本/业务营收的占比来长期牵引、指导产研团度持续提升人效，降低成本。
• 在整个研发体系内，产品需要对需求的有效性、业务需求是否最终满足业务诉求、需求的整体交付质量负责，可以用需求停留时长、需求分析时长、紧急需求插入占比、需求变更率来衡量产品的交付质量和效率
  • 需求停留时长、需求分析时长（完成最终的PRD）可间接反应出业务需求正式交付后的产品处理效率，通常而言，在迭代启动之前需求能正式定稿并交付到研发即可，不易过渡追求产品的交付速度
  • 紧急插入需求可能由一些大客户的紧急个性化需求导致，也可能由线上业务问题导致，当发生这样的情况时需要深挖发生紧急需求的原因，尽可能的避免插入紧急需求，打乱既定的研发节奏。使用紧急需求插入率结合需求的变更率在一定程度上可以评估出产品团队对业务场景的理解是否到位，评估产品的需求交付质量
• 在整个研发体系内，开发、测试主要对需求的整体上线质量、系统的稳定性负责。可以综合运用用需求测试阶段的bug数量，上线后的bug数量，线上系统的故障、事故次数来评估开发、测试的整体交付质量。可以综合运用需求功能点的实际开发时长、测试时长来评估开发、测试的交付效率
  • 需求测试阶段的bug数量通常反应开发的交付质量，BUG通常有三类组成，对需求理解不到位，未按照产品的文档、UI/UE设计实现功能，功能开发完成后未进行自测直接流转到测试环节，产品方案有问题，未充分考虑业务场景未能实现业务闭环（应剔除该部分数据对开发交付质量的影响），通过建立指标可牵引开发人员形成规范，逐步提升需求交付质量，从而加快整体的研发效率。
  • 上线后的bug可能是由测试用例未覆盖全面漏测导致，也有可能是因为产品在需求阶段方案存在场景缺失导致，漏测可能会影响一些业务场景，线上系统的故障可能由系统服务不稳定、程序、接口设计不合理等原因导致，一般通过事前对技术方案进行评审，事中建立完善的服务监控体系（例如：服务可用性监控、接口异常监控自动告警等），事后复盘等多种措施来保障系统的整体稳定性和可靠性。复盘后要就问题出现的原因列出可落地执行的改进措施，并把相关的待办事项落实到具体的责任人，并对待办事项的进展进行跟踪直至问题得到解决、改善。

3.  如何管理、提升产研团队的交付质量、效率

3.1.  如何管理、提升产品交付质量、交付效率

3.2.  一些管理、提升产研交付质量、交付效率的工具和工作方法

3.2.1.  三段式开发

• 对于稳定的团队，可以引入三段式开发提升产研交付效率，如下图所示，对产品、设计、开发、测试都有较高的要求。
  • 对产品而言，需要提前1-2个迭代完成相关的需求设计，预留足够的时间给设计团队完成设计，否则会出现没有足够的时间完成文档、参与验收。
  • 对于开发而言，需要保障提测后的BUG数量相对可控，否则会导致消耗大量的精力在BUG修复上，并且会压缩测试时间，导致测试时间不够，出现交付质量不达标的情况，也会打乱后续的迭代节奏。
  • 对于测试而言，节奏会非常紧促，在展开迭代测试的同时又需要接受新的需求。

3.2.2.  产品需求质量把控

• 需求质量是研发团队交付质量的源头，需求质量差会导致浪费研发资源，交付不符合业务预期。可以从以下几个方面切入
  • 招聘：从源头把关，招聘一些基础素养高的产品，招聘阶段需要重点考察产品的逻辑思维能力，沟通表达能力，学习能力，业务理解力，自我驱动自我要求，以及是否具备目标价值导向。对一些专业性要求高的岗位可以适当综合考虑过往是否具备相关产品经验，方便快速上手，但是对于大部分产品岗位而言，基础素养高的产品都能快速学习业务知识，快速上手
  • 培训：产品需求质量差的根本原因是对业务场景的理解不到位，可以通过邀请业务专家做专场培训的方式帮助产品快速深入的理解、学习业务知识、业务流程、业务规则。
  • 跟岗作业：让相关的产品直接深入到日常的业务运作中去体验，发现，解决目前业务现存的问题。不少产品在日程工作中会陷入系统设计思维的怪圈，设计的方案在系统逻辑上是没有问题的，但是并不符合业务同事在日常使用中的实际情况，跟岗可以缓解这类问题，帮助产品更深入的理解实际的业务场景，从而输出更贴合实际业务的方案。
  • 评审：评审分内部评审、业务评审、需求宣讲。
    • 内部评审主要是对交付质量进行把关，避免出现一些方案设计不达预期目的，业务场景考虑不全面、体验不友好、无法扩展性的一些问题，也可以解决内部信息同步的问题，让团队内的小伙伴都知道彼此大概在做什么，因为工作侧重点不同，每个产品涉猎的知识面宽度和深度都不一样，有时候在内部评审阶段也能提出一些更好的方案解决问题，内部评审也是产品内部设计思路的一种交流方式。
    • 业务评审：业务同事因为日常工作的职责划分是业务系统的直接使用方，因此对业务的实际场景有更深刻的理解，业务评审主要解决设计的系统方案不符合实际的问题，但业务同事对系统设计的思路、原则理解不如产品，因此在业务评审的时候产品需要提前准备，辅助以流程图、UI/UE设计稿来解决沟通同频的问题。
    • 需求宣讲：在前面两个评审执行到位后，方案已经基本完善，推进到开发阶段，这个阶段主要是把做什么事、怎么做、做了后的效果传递到开发、测试。在这个环节开发、测试同事因为比产品更了解系统的业务模型、底层数据、系统逻辑，会提出一些细节性的问题，进一步帮助产品完善方案。
  • 产品周例会：产品内部可以通过例会的方式，就业务目标的重点工作、问题进行检视，也便于内部同步各自的工作进展，重点是保障业务目标的重点工作按时完成。
    • 各自承担的业务目标、以及业务目标重点工作的进展以及风险情况
    • 具体工作的当前进展，以及近期的工作计划，预计完成的时间
    • 同步、安排其他的一些工作事项

3.2.3.  燃尽图&甘特图

• 项目管理流程线上化
  • 严格执行项目流程管理规范，督促所有成员及时更新需求、任务、BUG状态，便于项目组成员及时通过燃尽图、甘特图等可视化图表掌握迭代当前的实际情况，及时暴露风险和问题
  • 在产品完成需求宣讲后，由技术负责人为每个需求分配相关的人员，再由相关的人员基于分配的需求，拆解研发任务
  • 从管理角度考虑，研发任务的粒度最少要拆解到每个需求，从精细化管理的角度考虑，最好能细化到每个需求具体的开发工作项，便于项目经理掌握、协调项目风险，评估需求排期是否合理，是否存在进一步的压缩空间。
• 燃尽图
  • 可用于评估迭代内容是否超出迭代承受能力，以便及时调整迭代需求范围。检视预估工时和实际工时的偏差情况，持续优化项目管理流程挤出工时预估中可能存在的水份，提升协作效率。

• 甘特图：
  • 当把迭代需求拆解到任务并完成每个任务的排期后，项目经理/技术负责人可以从需求/人员等多种维度实时掌握所有需求/成员的排期、工作计划、进度，以便及时协调资源冲突的问题，也便于更合理的安排工作任务。

3.2.4.  代码自动审核&自动化测试

• 代码自动化审查：引入代码自动化审查可以自动扫描出一些常见的错误，提升交付质量
• 自动化测试：测试的日程工作中，不少的精力消耗在迭代发布前的回归测试上，在条件允许的情况下引入自动化测试，可以在一定程度上提升测试效率，提升整体的交付效率和质量。

3.2.5.  迭代过程管控/复盘

• 迭代早会
  • 在早会开始前需要项目成员提前更新好各自开发任务状态，并主动、及时暴露风险，以便项目经理/研发负责人协调解决问题，保障交付的时效和质量。
  • 项目经理/研发负责人协调跟进风险问题，直至风险解除
• 迭代复盘会
  • 在迭代结束后，可以就迭代的整体情况通过燃尽图、需求变更率、紧急需求数量、BUG数量、迭代周期等各项指标回顾迭代过程中存在的问题，并就问题形成解决方案，督促各方改进，知道问题得到改善、解决。
  • 交付物：
    • 迭代中存在的问题清单
    • 问题改善/解决措施，对应的负责人/执行人，预计落实时间
    • 跟踪待办事项，直至全部落实