需求管理的那些事

       是不是为甲方的需求变更抓耳挠腮？是不是被需求的优化无从下手？是不是新增需求预算不足感到头秃？究竟对于项目交付过程中遇到了项目需求问题应当如何应对，怎样能快速做好需求交付，且满足项目相关方的利益。

一、需求收集

       需求即业务痛点，针对目前的所处的阶段，业务所需要提升的功能模块，亦或者是业务所需要新增加的业务场景等。

       1、业务提出痛点，战略执行业务不满足，需要增加的点；2、目前业务流程执行需要更改的点；3、目前业务操作中客户体验优化的点；4、业务竞标之后需要增删改的点；5、系统性能需求等。尽可能穷尽所有涉及的需求。

二、需求优先级

       当收到很多业务需求之后，如何明确应该将开发资源优先分配到哪一个板块，如何进行迭代计划，所以需要进行优先级排序，从业务的角度出发，进行roi计算（ROI（投资回报率）=[(收入-成本)/投入]*100%），或者业务紧急程度进行分析，或者从技术层面为业务提供更优解决方案。

       介绍一种需求优先级的工具：KANO模型法：是以业务根据不同类型的需求与用户满意度之间的关系，将影响用户满意度的因素分为五类：兴奋型需求、期望型需求、基本型需求、无差异需求、反向型需求。

kano模型

兴奋型：用户意想不到不到的需求，有了此类需求，用户的满意度会大大的提升，没有此类需求，用户满意度不会降低。

期望型：有此类需求用户的满意度会提升，如果没有此类需求用户的满意度会下降

基本型：有此类需求用户满意度不会提升，如果没有此类需求用户满意度会大幅度下降

无差异型：无论提供或者不提供此类需求，用户的满意度不会有差异

反向型：有此类需求用户的满意度反而会大大下降

     可根据需求类型进行分类，找到优先级：基本型>期望型>兴奋型>无差异型>反向型

三、需求分析

       收集到很多条需求之后怎么样进行分析找到最有价值的需求，且能为客户提供更完备的产品，需要从产研角度出发，按照优先级进行分析讨论。1、项目需求提出需求的技术可行性分析；2、需求技术实施方案分析确认；3、需求评审是否合理

四、需求排期

       根据业务需求及技术可行性分析进行排序，促使业务参与敏捷活动，方便运用看板进行迭代，为后期版本规划做好铺垫。

        排期的基础：1、发布日历；2、需求优先级；3、需求工作量评估。明确此三项，可建立项目需求池，每次迭代完成之后开需求排期会确认下一迭代需要开发的需求，确认好之后可转化为用户故事，进行管理，推进。

五、需求开发

       根据需求评审会确认的迭代任务，转换成用户故事：用户故事应该遵循INVEST原则：Idependent（独立的）；Negotiable（可协商的）；Valuable（有价值的）；Estimatable（可评估）；Small（小的）；Testable（可测试的）。确认之后放置看板进行管理，进度包括：待开发，开发中，待测试，完成。在需求开发中根据梳理好需求需要实现的关键点，及后台接口数据逻辑，开发过程中做好自测。

六、需求变更

       开发过程中难免遇到业务需要变更需求，在敏捷项目中是拥抱变化的，故欢迎业务进行变更以便在市场中获得更大的收益，但是变更不是一味的只求边，这样开发根本无法执行开发任务，需进行评审走流程。

      1、要建立需求变更的流程及审批：确认变更什么、变更影响、是否接受变更；2、开发过程中如要新增其他需求，需适当移走本次迭代的其他非紧急需求；3、变更之后的需求拉入本次迭代管理；4、如果增加需求没有在项目基线中，可协商进行二期开发，更好的控制预算；5、属于优化变更的需求也可以惊醒需求分析排期下一迭代。

七、需求验证

       开发完成之后的需求经过测试验证，给出测试报告之后方可预上线，预上线中业务可以进行UAT验证，是否验收通过，验证通过即可上生产验证。

综上：业务需求提出到最后上线是一个生命周期，中会遇到很多的问题，需平衡各方资源，及时沟通，集业务、开发、测试共同努力达成共识输出满意度较高的产品。