避免重要需求遗漏的思路

避免重要需求遗漏，首先我们需要反问一句 —— 为什么这些紧急重要的需求无法更早预见？同样的，我们需要了解：

具体是哪些外界原因？这些原因是否有共性，有的话，那就针对性处理；
增加的需求有无共性特点？有的话，可以针对性处理；
临时增加有多临时？我们是否有提高或改善响应能力的空间，如果我们可以更快调整和响应，使得这些临时需求对我们产生不了什么影响，那么这个问题也就不再是问题了；
既然是常态，为何我们的流程没有做出调整去应对？是调整过流程或工作方式，还是无法解决问题，还是说不知道该怎么调整流程或工作方式去适应？

具体操作方法

具体操作，可以按照事前、事中、事后各个阶段来采取不同的措施处理。

一、事中的处理

根据具体情况不同，在发现需求遗漏的当时，可以采取如下一些做法：

重要需求遗漏，不紧急：既然不紧急，按照常规做法增加进去即可，但如果经常出现遗漏，就要考虑是否是需求分析和规划的实践做法有问题，才会导致问题持续出现，这种情况，应强化需求结构化管理，从全局出发进行思考和规划，避免因为思考的片面化和局部性导致的遗漏；
重要需求遗漏，紧急：既然是又重要又紧急的需求，那么必然就得调整当前开发工作的顺序，把这个遗漏的重要紧急需求插进去，把工作安排下去；然后就要考虑从需求的优先级和需求的结构化管理两个方面入手复盘，并切实改进，避免类似情况再次发生；
需求遗漏：如果是不太重要的需求遗漏，按照常规做法处理即可；可以根据其紧急程度和影响，决定是否调整工作顺序让这个需求插队；如果这种情况反复出现，那建议可以考虑进行复盘，从需求结构化管理的角度进行分析，并商讨改进措施；

二、事后的处理

事后其实就是复盘，复盘的关键是要基于盘来推演和分析，这个盘就是事前制定的模型和规范。是我们有模型有规范，但执行出了问题？还是说这几个需求情况特殊，模型比较简单没有覆盖到这些特殊情况？还是说模型和规范都没问题，就是人员能力不足，导致判断偏差大？只有找到正确的根因，才能够真正有效的解决问题，所以我们不复盘则已，要复盘就务必要认真严格地进行复盘。

怎么复盘？复盘也是有方法有套路的，业界也有相关书籍可供我们参考借鉴。例如温伯格在《成为技术领导者》中提出的MOI模型就可以用作复盘的一种思路。

M：激励（Motivation），是不是人们没有动力去做这件事情？
O：组织（Organization），是不是无组织无纪律、一片混乱，人们不知道自己或别人该做什么？
I：想法或创意（Idea/Innovation），是不是缺少如何解决这些问题的点子或创意，不知道有什么办法解决这个问题？

复盘时要注意，受限于能力或经验以及出问题次数多少的影响，我们可能无法得出一个准确的结论和必然有效的解决方案。此时一方面需要秉持持续改进的心态，我们可以先落实当前已经比较明确的改进措施，后续再观察效果，持续复盘、持续改进即可。另一方面我们也可以先采取一些临时措施。

预留时间：比如，如果确实很难分析清楚为什么总是会遗漏需求，无法进行非常有针对性的处理时，也可以采取较为模糊应对的方式。可以拉取过去一段时间的工作记录，评估这段时间每个迭代的突发需求所消耗的工作量投入，可以取个平均值，然后在后续进行迭代工作安排的时候，固定的预留出一定量的时间，用于应对极有可能会出现的突发需求。
需求拆细：当出现突发需求，导致我们需要调整工作顺序时，很有可能会因为需求颗粒度大以至于腾挪余地有限，而难以避免突发需求带来的影响，因而还应该尽可能地采取拆细需求的方式，将颗粒度比较大的需求拆分为较小颗粒度的需求，可以增加调整需求工作顺序时的灵活性；

要确定到底要预留多少时间，可以利用DevCloud的Epic-Feature-Story结构，把突发需求汇集在一起，便于统计。例如创建一个特殊的Epic“突发需求”，下一级是为每个迭代创建的Feature，用来承载各个迭代里面具体的那些突发需求（体现为Story），并做好工时的记录，迭代结束后，就可以来计算出现了多少个突发需求、投入了多少工作量了。

也可以采用“模块”字段来辅助记录和统计突发需求的数据。例如，新建一个模块，取名“突发需求”，所有突发需求都标注为这个模块，那么后续就可以基于模块进行筛选或查看报表等方式来统计突发需求所消耗的工作量了。

三、事前的处理

事前的处理放到最后来介绍，是因为之所以会出现问题一般都是因为事前没有做好，但已经出现了问题就需要在当时尽快处理，所以先介绍了事中的处理。但当我们处理完问题也完成了事后复盘，就需要考虑未来的事前，尽可能的避免问题发生。
简单来讲，事前的话，就是要做好需求的结构化管理和需求的优先级管理，以及做好相关规范的宣导、人员的动员和能力的培养，这样就能够有效的避免或减小突发需求带来的影响了。

参考附录

如何避免重要需求遗漏？相关推荐

【华为云技术分享】【DevCloud · 敏捷智库】如何避免重要需求遗漏？
避免重要需求遗漏的思路避免重要需求遗漏,首先我们需要反问一句 -- 为什么这些紧急重要的需求无法更早预见?同样的,我们需要了解: 具体是哪些外界原因?这些原因是否有共性,有的话,那就针对性处理: 增 ...
干货！最全需求评审指南，让你不再怕被怼
本文由作者冰冰酱发布于社区对于产品新人而言,日常最头疼的会议就是需求评审. 在做产品的这几年,笔者开过上百场需求评审会,曾经被研发在会上怼哭过一次,也遇到过研发和产品大吵半小时.最终有一方摔门而 ...
笔记-高项案例题-2015年下-需求管理
2015下半年高级信息系统项目管理师下午案例分析真题 [说明] 某公司2014年初承接了一个周期为一年的OA信息系统项目,并指派项目经理小张负责.该项目属于定制型项目,涉及的用户方较多,小张根据自己的 ...
从需求到交付——论敏捷过程中的需求管理
背景在之前组织的一次敏捷线下活动中,有家企业问道:"我们公司刚做敏捷转型不久,遇到一个比较头疼的问题--团队每天都很忙,从转型到现在已经两个多月了,基本没有一个迭代能做完全部任务,问题出在 ...
项目需求的重要性和开发步骤
项目管理研究所(Project Management Institute)表示:"47%的失败项目之所以未能达到目标,是因为糟糕的需求管理." 什么是项目需求? 项目管理知识体系( ...
论信息系统项目的需求管理
最近有朋友让我将我写论文的经验写出来,并写个例子给她.拗不过,只好回忆.本文以我自己在2009年下半年项目管理师考试的论文题目为例,说明如何写论文. 论文的编写其实不难,关键是要将题目的内容都覆盖到, ...
软件需求和测试需求实用理论
软件需求及分类 1.软件需求的定义 IEEE软件工程标准词汇表(1997年)定义软件需求: -用户解决问题或达到目标所需条件或权能(Capability): -系统或系统部件要满足合同.标准.规范或其 ...
需求，这真的是“需求”吗？——论需求的层次及若干问题（1）
需求的漫画: 关于需求问题,有一幅漫画十分生动地展现了这些问题(这幅漫画我其实最早是在07年一次"敏捷中国"一次软件开发技术人员日上上见到的),如果我们认真剖析后面的东西,还是会给 ...
软件项目需求变更频繁，如何做好有效的需求管理和规划
概述围绕项目需求变更频繁,如何做好有效的需求管理和规划,本文从背景.问题分析.解决措施.如何进行需求结构化管理?如何进行需求优先级管理?如何避免重要需求遗漏?几个方面进行了细致解答.全程干货. 背景 ...

如何避免重要需求遗漏？