下面是笔者整理分享的关于如何进行需求进度管理？的文章，内容包括团队内达成明确的版本共识、精细化任务分配管理、合理的资源分配（正确的人做正确的事）等等的相关内容，大家一起来看看吧！
一、团队内达成明确的版本共识
团队内明确且达成共识的版本目标，确保当前版本周期内的每项工作都是在为实现这个目标贡献。
常用方法：
OKR（目标与关键结果法）
- 目标（O）回答的是“我们想做什么？”的问题，是定性的；
- 关键结果（KR）回答的是“我们如何知道自己是否达成了目标要求”，是定量的。
- 限定周期是要为目标的执行过程设定一个有效衡量周期，毕竟很多项目、需求、工作都有较强的时效性；
- 定期更新是为了能及时衡量目标的健康程度，根据关键结果的进展，判断团队效能。
一般来讲，双周为一个小版本，一个季度为一个大版本进行，以下仅为示例：
二、精细化任务分配管理
1. 明确版本范围
团队版本研发的第一步是明确版本的范围，通常以版本功能清单作为管理基础，通过需求澄清会同步给研发团队。随着迭代开发的不断推进，版本中会包含当前版本新增需求，对历史版本的优化需求和修复缺陷的需求。这三类需求共同组成一个版本，并作为版本的关键成功在版本公告中进行体现。
2. 精细化的任务拆分
为了方便评估风险，最大限度减少不可控因素，需要对版本需求进行逐级拆解，要将所有需求分解到不能再分且可验证，明确需求边界，让每个任务的粒度足够完整且最小，再根据任务优先级进行排期。
3. 任务责任到人
将版本的功能由上至下逐级拆解完成后，估算工作量，并为任务设置唯一负责人。常见的工种分为需求、UI、后端、前端、测试
4. 规定截止时间
所以，为了最大限度规避延期风险，在执行过程中，为每项任务设定确定的截止时间，这样，一方面可以随时了解研发进度，评估风险，及时调整工作节奏；另一方面，对于一些无法确定完成时间的任务及时采取“平替”策略，降低延期的影响范围。
三、合理的资源分配（正确的人做正确的事）
在版本规划和需求澄清时，可以识别到哪些任务的开发复杂度较大，存在哪些技术关键点，结合优先级和技术团队的能力进行合理分工。
可以参考的资源分配方案如下：
- 集中优势力量解决难点。
- 相近开发周期，分配任务优先选择旧版本的开发人员，降低需求澄清的沟通成本。
- 充分利用相似项目开发经验。
记录方式比较多元，常见工具主要为基于甘特图的各类看板和研发日志。
四、保证做正确的事
除了根据检查情况调整任务目标、资源、进度，并修改计划这类常规操作外，更要注意团队内部的高效沟通和版本记录管理。
1.“复述”需求
需求澄清会后，针对不同的工种，可以采用不同的“复述”方式。主要的目的是为了做正确的事。通常研发团队内，可采用UI介绍设计理念、前端演绎交互需求，后端介绍流程的方式来确保各阶段的准确开发。
2. 版本记录
各类工种进行各自工作时都需要进行版本记录，这样能比较全面的描述任务发展的前因后果、相关人员、更新记录等，通过这种方式，新加入人员从记录上就能获取80%的任务相关信息，迅速厘清关系并找到相关人员进行询问。
五、自动化和标准化基础工作
产品的研发工程就是一个流水线生产的过程，这个过程的标准化和自动化程度越高，研发团队的沟通成本越低。
1. 在线协同
使用一些在线管理工具将研发团队的工作放到线上进行协同和记录。例如研发团队基于用户故事将代码、bug、测试用例连接在一起，测试工作完成了，bug会自动同步给开发者。
这种小自动化设计在工作场景有很多，可以极大减少不必要沟通，同时，最大化透明工作信息。
举例，更新需求后自动提醒开发和测试进行调整；还有代码提交之后，自动同步开启测试任务。测试提交缺陷后，自动提醒开发，开发修复缺陷后，指定人员进行验证。
2. 规范流程
流程化的价值是让组织的每个人按照统一的规则做事，因此流程化是减少“偏见”的利器，流程并不是企业管理的毒药，好的规则和流程，能给团队减少冲突，极大实现企业员工之间的契约。同时，在人员流动率较高的企业中，可以按每个工作岗位打造出标准的螺丝钉，降低因为人员变动对研发的影响。
例如，需求的审批流程可以简化为，地方/部门市场专员发现商机或需求-地方/部门经理审批-总部经理审批-总部产品部评审-研发团队评审-版本规划-排期开发。
本文由 @薯角 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
