项目准时交付和需求管理密不可分的关系

lsekfe

很多人可能都还不明白需求分析和需求管理之间的区别，通常我们说起来最多的都是需求沟通和需求分析，开会都是讨论需求如何如何做，这其实是需求分析的过程如何如何，而与需求有关的其他活动提及的比较少。其实需求沟通和需求分析都只是需求管理过程中的两个环节。
　　一个项目做了很久，人力投入越来越多，大家都像打了鸡血一样天天加班，但是感觉总是做不完，就像一个“无底洞”。想尽快完成这个项目的时候，总有新的需求要做。实际上，这里涉及到一个需求管理的概念。项目中哪些该做，哪些应该先做，做到什么程度，都是由需求管理的过程来决定的。
　　通常需求管理是对需求生命周期的管理，从需求的产生到需求的结束，过程可以划分为以下几个独立的阶段：
　　一、需求整理
　　与PO进行需求沟通，并对沟通的需求进行归类整理，形成文档。这个过程需要对业务建立起一个概念模型，以便对其进行抽象描述。也会用到一些工具像markdown、思维导图、原型设计的工具等。文档是一个梳理思路非常好的方式，在文档中把自己的想法书写出来，配上流程图、状态图、时序图，即方便自己的积累又便于别人的理解。文档越详尽、越清晰越好，最好的文档就是一个新人也能根据文档快速的理解方案并写出代码。
　　二、需求初判
　　围绕项目的业务核心，目的是找到实际要做的需求。需要在沟通需求时，对需求的实现方案、所耗成本和资源、预期效果、是否有实现同样目标的低成本替代方案等，有一定的判断力，即需求方案初判。
　　三、需求定义
　　根据需求沟通和需求分析的结果，进一步定义准确无误的项目需求。需求定义的过程更多的是对需求进行准确的描述，从需求方的角度、功能操作流程的角度等方面，对分析出来的真实需求做出完整、无二义性的定义，准确理解PO意图，澄清不明确点，让其他相关人员能准确的理解需求。
　　四、需求分析
　　需求分析主要是明确需求执行的优先级。在通过上述两个过程后，会挡掉一些不合理或可以采取更轻的解决方案的需求，对于留下来的需求，需要记录进需求池。在记录进需求池的时候，需要对需求的优先级进行排序标注，有两种常见的排序方法。一种是基于四象限法则，另一种则是基于KANO模型。
　　在判断需求是否重要时，可以参考如下：
　　·先做，会造成问题和负面影响
　　· 后做，会产生正向的效应和影响
　　在判断需求是否紧急，可以参考如下：
　　· 后做，错误会持续发生并造成严重影响
　　· 后做，短期内可控但长期会有糟糕的影响
　　· 先做，立刻能解决很多问题、产生正面的影响
　　· 先做，在一段时间后可以有良好的效果
　　五、需求评审
　　需求评审是各方对需求进行确认的重要环节。各方对需求进行确认的过程，达成统一认知和共识，使需求能够推进实现落地。在需求评审的过程中，一定要说明清楚需求的背景、价值、意义，而不是纯粹的需求讲解，这样有助于各方对需求的理解。
　　需求评审的重要性体现如下：
　　评审过程本身也是一个知识传递过程，产品经理、SM与评审人员一起讨论用户需求，这有助于评审人员获得用户需求的前期认识。
　　评审过程中可能发现不明确的或者遗漏的需求，这需要SM和产品经理进行二次需求分析和定义。
　　在确认了To-do List需求后，SM需要综合该产品线的全局需求优先级情况，对该需求进行版本排期，并根据版本排期推算大致的可上线时间范围。
　　评审过程中可能发现某些特殊需求，这时产品经理、SM和评审人员可以群策群力共同思考解决问题的方式。
　　当局者迷、旁观者清。再有经验的产品经理也可能犯错，评审人员可以提出更合理或者更有建设性的想法供产品经理参考。
　　六、需求排期
　　需求评审完成之后，进入到设计开发阶段。需求排期需要SM制定出需求实现的生产要素UI设计、前端开发、后端开发、测试各需要的时间以及并行分工的情况。
　　七、需求跟踪
　　需求跟踪是产品经理日常必须完成的工作。跟进需求的设计实现过程，保证需求的实现不打折扣，并随时关注需求的变化。通过比较需求定义与后续工作成果之间的对应关系，建立与维护需求跟踪列表，确保产品依据需求的定义进行开发。
　　正向跟踪：检查已安排的每个需求是否都能在后续的实现过程中有相对应的部分，确保没有漏做的需求，并保证需求的实现程度和需求定义要求的一样。这就需要每天都与后续的各个负责实现的人员进行确认。
　　逆向跟踪：根据已有的交互设计稿、系统设计文档、测试用例文档等成果文档，反向检查是否包含了所有已安排的需求。
　　八、需求变更
　　需求变更最考验产品经理需求把控能力。当因为外部环境变化或者内部需求定义错误导致需求需要更改时，要做好变更的管控，防止因为变更而导致需求执行的过程无法进行下去。
　　总之，需求管理是一项十分重要的工作，在众多失败的项目中，项目的失败主要是需求管理失败导致的。因此，需求管理对产品能否最终实现产生至关重要的影响。