上次我们介绍了「DevOps与研发效能落地的GPPPI框架」，提出流程、人、平台三要素有机结合支撑企业目标达成，具体如何做呢？接下来我们开始围绕软件研发全流程介绍DevOps的核心实践和平台工具。
DevOps的第一步是计划（Plan），即对项目和需求的规划，包括下一步做什么、项目和需求的排期如何、项目如何管理等。
毫不夸张地说，需求是DevOps全流程中最重要的一步。如果要交付的需求没有价值，后续的开发、测试、上线、运维等工作都可以说是无用功，无法给企业带来收益。我们说DevOps是提升研发效能的最佳实践，研发效能的目标是可持续、高质量交付有效价值，所以做好需求管理，尤其是需求的业务价值管理尤其重要！
那么，需求管理领域的优秀实践有哪些呢？我们先从需求管理的几个阶段说起，了解了需求管理的几个阶段后，能够能方便了解需求管理实践的方式和方法。
++01++
++需求管理的五个阶段++
需求收集
需求管理的第一步就是需求收集。我们做一款产品、迭代一个需求，首先需要心中有数的就是受众。需求收集应全面识别各类需求干系人，并通过不同的方式获取各干系人的需求信息。不同的产品有不同的需求干系人，产品简单可分为ToB和ToC的，ToB的产品就要向我们的目标客户了解需求，ToC的产品就要深入挖掘目标用户的需求。
需求收集的方法多样，可以通过访谈、调查问卷等。需求收集时，要注意收集要素信息，包括不同客户/用户的背景信息、使用场景、痛点，对产品的核心诉求和目标期望等。需求收集人，一般是产品经理，也要注重记录相关需求，可采用需求跟踪矩阵表等对需求进行分类分级，为后续需求分析做准备。
需求分析
收集来的需求信息要进行分析，需求需要经过去伪存真、分类分级的处理，需要从商业目标和资源配置等角度进行需求的深入分析。需要聚焦客户/用户价值，立足商业模式，聚焦战略和业务目标实现，充分与相关方沟通，明确需求的重要紧急程度，对需求合理划分等级，如分为高、中、低三种，对不同级别的需求明确不同的质量要求和交付期限。
需求分析也要能满足需求需要，也要谨防过度设计。需求分析结束后，应产出产品需求文档、产品原型和项目迭代计划等方案材料，且应通过团队内审核。重要项目需要经过企业高管审核，以防产品重要方向走偏。
为验证需求上线后的效果是否符合预期，应考虑非功能的设计，对需求使用、关键业务指标等预先埋点，按需采用A/B测试等方案，以便需求上线后，分析验证需求的合理性和有效性，以便不符合预期时及时调整产品策略。
需求评审
需求的产品方案需要与业务人员对齐，需求的的实现需要UI设计、开发、测试等相关人员协作进行，都需要产品经理组织进行需求评审，包括：
1、业务评审：对齐需求的背景、问题和目标，共同评估产品方案的内容和价值，包括方案的合规性、合理性、全面性、友好性等。
2、技术评审：聚焦产品方案的功能实现和质量、安全要求等，共同评估产品方案的合理性、可行性、兼容性等。
需求评审后，应产出会议结论，相关方达成一致。
需求实现
以需求评审达成的结论为依据，由开发、测试等相关人员对需求进行实现、交付。
需求验收
需求开发测试完毕后，一般需要产品经理或业务人员进行验收，验收通过后方可上线。验收的关键内容包括：产品功能是否满足需求，质量、性能、安全性是否满足需求等。
++02++
++需求管理的优秀实践++
了解了需求工作的各个阶段后，我们再介绍下DevOps和研发效能中需求管理的优秀实践有哪些？
业务探索
上面我们说过，需求有价值是研发流程工作的重中之重，因此我们首先需要做的就是探索有价值的业务需求。比较知名的方法包括：商业模式画布、设计思维、影响地图、最小可行产品（MVP）等方法。
后续我们再逐个详细介绍，可以先看一个MVP的示例：
精益
精益是DevOps CALMS核心理念之一，不仅仅是MVP的思想，每一个需求都可以是满足精益思想的。精益需求倡导小批量管理需求，每个需求的规模和颗粒度应该都比较小。相比于产品需求文档需要花费大量的时间描述需求，精益需求倡导的是用户故事的形式来表达需求，需求之间的关系采用故事树等方法进行管理。
用户故事专注用户价值，一般采用“作为[用户角色]，我想要[系统提供的功能]，以便[实现什么业务价值或目标]”的形式。用户故事遵循INVEST原则，即独立的、可讨论的、有价值的、可估计的、小的、可测试的。
敏捷
敏捷宣言为软件开发提供了很好的指导，敏捷协作主要有以下要点：
1、目标是交付价值，10人左右的小规模团队高效协作。
2、团队尽量同地办公，可面对面高效沟通。
3、团队使用Scrum、看板方法、精益的优秀实践，通过拉动、减少浪费等提高项目管理和协作效率。
++最后++
今天，我们主要介绍了需求管理的五个阶段和需求管理三个方面的优秀实践。后续，我们将针对需求管理实践的业务探索、精益、敏捷等进行深入介绍和探讨，开启一场需求管理领域优秀实践的学习之旅，敬请期待！