五、需求开发与测试
需求进入开发测试阶段后，大部分产品经理认为无需进行需求管理工作，只需等待上线即可。其实不然，若在该阶段出现延期、开发测试质量等问题，仍会影响需求的交付。因此，在该阶段，需求管理工作仍必不可少！
接下来，分别从“需求开发”与“需求测试”详述产品经理应做哪些需求管理工作，以保证需求顺利交付。
5.1需求开发
在需求开发阶段，产品经理要重点关注以下两点：其一，关注开发是否按计划进行，有无风险。其二，关注开发质量，保证高质量交付。
首先，关于第一点。产品经理应熟练掌握项目管理相关技能，并对需求进行常态化项目管理。例如组织产研测日站会、项目周会、需求进度沟通会等。通过定期与研发盘点开发进展及问题，从而提前识别风险，并及时采取措施，避免延期。
其次，关于第二点。虽然产品经理不参加开发工作，无法直接为代码质量负责，但可以通过建设合理的开发流程，以实现高质量的交付。建议：①增加“技术方案概要设计、技术方案详细设计”评审环节，且产品经理参与评审，把控技术方案符合产品诉求。②增加“代码评审”环节，架构师参与评审，把控代码质量。（Ps:如果读者公司没有以上流程，产品经理可以发起流程变革，但确实无法增加，那么只能自求多福了。）
5.2需求测试
在需求测试阶段，产品经理要重点关注以下两点：其一，关注测试是否按计划进行，有无风险。其二，关注测试质量，保证高质量交付。
首先，关于第一点。参考上文需求开发第一点。读者可同时管控开发、测试进展及问题。
其次，关于第二点。建议：①增加“测试用例评审”环节，且产品经理参与评审，把控测试场景覆盖全部功能场景。②要求测试人员记录并反馈测试问题，并追查问题产生原因，以提升产品、研发、测试质量。③测试完成后，产品经理要进行线上验收。
六、需求验证
这个环节是最容易被产品经理忽略的环节。大多数产品经理认为，需求上线后就完成了自己的工作，对需求目标是否达成不太关心，并将这视为业务部门的职责。然而，这种想法往往会导致我们错失成功的机会。所以，作为产品经理，我们必须“以始为终”，始终牢记需求的初衷，在需求验证环节中确保需求目标得到充分的实现。只有这样，我们才能最终摘取成功的果实，也才能让需求管理的旅程更加完美圆满！
接下来，讲解在需求验证阶段，产品经理应该采取哪些需求管理工作。
首先，产品经理应该重点关注和参与“三个计划”的制定与执行。“三个计划”即：灰度计划、推广计划、运营计划。虽然它们从职责上是属于业务方（需求提出方）工作，但它们却是影响需求能否取得业务结果的关键因素。产品经理应采取如下管理动作：其一，灰度计划。与业务协同制定灰度目标、场景、时间等，确保灰度期间快速验证产品方案的可用性及可行性。其二，推广计划。与业务协同制定推广目标、范围、时间等，确保产品方案可复制，达成业务预期目标。其三，运营计划。与业务协同制定稳定、长期、高效的日常运营流程，确保产品方案持续产生稳定的业务结果。（读者尤其要注意，以上三个计划，虽有先后顺序，但尽量一起制定，避免脱节。）
其次，在制定和执行三个计划时，同时要建立业务数据指标体系。数据指标体系应包含可衡量项目过程和结果表现的指标。指标体系应是客观的、可量化的，以便更好地监测和评估项目进展以及业务成果。建议参考亚马逊：Input、Output、观测指标方法。
最后，迭代产品方案或调整计划。通过对数据指标体系的监控及分析，找出产品方案、灰度&推广&运营计划中存在的问题，分析原因并制定解决方案，及时调整计划或迭代产品方案。
七、需求结项
需求结项是需求管理旅程的最后一个环节。一般情况下，只有单独立项或较大项目才会有这个环节，其它需求在需求验证通过后就已结束。需求结项阶段的核心工作是进行需求结项文档编写，并组织结项会议，完成项目的结项。
作为产品经理，需要完成结项文档的编写及结项会议的召开。接下来，分别从“结项文档”和“结项会议”讲解产品经理如何进行需求管理。
首先，结项文档内容主要包含四个方面内容：回顾目标、评估结果、分析原因、总结规律。其中，回顾目标：主要是编写当初的目标是什么。评估结果：评估现有结果，判断是超额完成目标、符合预期目标，还是未完成目标。分析原因：分析实际结果与当初目标差异原因。总结做的好或不好的原因是什么。总结规律：通过对问题的原因分析，从中总结经验和规律，为以后工作起到指导作用。
其次，结项会议要组织相关业务、产品、研发、测试等人员参加，针对结项文档进行阅读和讨论，共同学习经验和规律，促进团队成长。
最后，关于需求结项工作，有几点需要着重关注。首先，结项文档的撰写应该客观、实事求是，不扭曲事实。其次，在讨论问题时应强调事情本身，而不是关注个人责任。第三，结项会议旨在总结经验、教训和规律，而不是追究责任或抱怨。最后，我们需要总结好的经验和规律，同时也需要总结不良经验，即我们在过程中遇到的问题和诸多挑战，进而汲取教训，防止重蹈覆辙。
八、总结
需求管理是产品经理日常工作中非常重要的一环。本文详细地讲述了如何从需求产生、需求分析、需求优先级、需求开发与测试、需求验证、需求结项六个方面实现有效的需求管理。但要更好地完成需求管理工作，读者必须不断练习和多次应用，积累经验并不断优化。愿读者通过此文的指南和建议有所进步，也欢迎各位读者留言交流经验！
九、案例分享：排期那点破事
这个故事是这样的，我有个业务项目，需协同其它研发团队开发。但是评审完成后，该研发团队反馈暂时没有资源开发，等待资源释放后再定。给出的理由主要有两条：
第一、相比其它业务线项目，项目收益太低，以后再做。（潜台词：项目太小，成绩不显著，不想做，要做就做大的）
第二、如果想做，那各业务线之间先协调下项目优先级。（潜台词：资源就这么多，我能怎么办？业务线自己PK去吧，谁赢了做谁的）
作为业务体量较小的产品经理，你是不是也遇到过上述场景？是不是很卑微、无助且可怜？接下来，让我告诉你，我是如何处理并解决这个问题。
针对第一个理由“相比其它业务线项目，项目收益太低，以后再做”。
首先，你要了解各业务线发展情况，以及自身业务线处在什么阶段，要做到知彼知己。结合自身业务实际，我是这样处理回复的。
第一、不同业务线的市场规模是有大小之分的，这是天生属性，进行横向收益对比是不公平的。虽然我们业务线市场规模小，但都是关键头部客户，也是公司整体重要市场之一。因此规模不是衡量收益的唯一准绳，而应看项目对业务本身发展的重要程度。
——潜台词：对不起，你的排期逻辑我不认可。如果按照你的逻辑排期，那么市场规模小的业务线项目收益永远最低，岂不永远无法排到？
第二、我们业务线产品建设阶段已经从“初期大规模建设”发展为“功能迭代优化建设”。去年已经完成大规模基础建设，现阶段就是针对上阶段进行补充和优化。该阶段项目的特点就是项目小、收益低。这是产品生命周期发展的必经阶段，预计未来会长期处于该阶段，大家需要有清晰的认知和共识。
——潜台词：要认清不同阶段，工作是不同的。这个阶段工作就是这个特点，难道这个阶段的项目都不做了么？
针对第二个理由“如果想做，那各业务线之间先协调下项目优先级”。
这个理由也是研发常使用的，往往产品经理此时也会让业务内部进行横向沟通，其实是不对的。我是这样处理回复的。
第一、各业务线仅为自身发展负责，不为其它业务线发展负责，也仅知道哪个项目对自己最重要。
——潜台词：哪个业务会舍弃自身发展，而成全其它业务线发展，不管自己的绩效了？通俗点，都是屁股决定脑袋，两个业务都觉得自己最重要，怎么办？
第二、需求管理的职责应在平台型研发部，而不在各业务。各业务线需求应单独管理，且应预估各业务线需求量，提前准备和分配研发资源。避免各业务线资源冲突，否则就会出现被业务投诉资源安排不合理、贻误业务发展等问题。
——潜台词：认清自身职责，不要甩锅，甩锅的结果就是被反噬，不如提前做好需求管理工作。
以上，就是我处理该问题的方式，你也可以结合自身情况调整策略，抓紧试下吧！当然，虽然场景是发生在产品与研发之间，你可以进行总结归纳，灵活应用到不同公司不同岗位上。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
