一：对不起，需求瘫痪了
有些需求由于过于动态或者本身存在矛盾而根本无法解决，需求总在变化，项目团队找不到需求阶段的出口
在产品经理或者业务分析师尝试解决歧义问题完成一个足够稳定的需求范围的过程中，珍贵的时间和资源就白白浪费了。在传媒业和广告业更是如此，需求可以称得上朝令夕改
在这样的环境中工作实在让人灰心，参与者都清楚工作没有进展。团队在这种状态的时间越长，就越需要更好的激励才能让他们回到正轨
总结：需求瘫痪的问题，归根结底只有一个原因——想让需求确定下来
二：需求太多了
仍然有很多IT团队是非常严肃的对待需求规范的，有需求池和一大堆的需求列表。当我们跟需求方去探讨这些需求时，往往发现这些需求是因为需求方了解的是公司产品的过时信息，那他们实际的需求是什么呢？
往往我们会对需求按优先级排序，排序过程中会发现一部分需求可有可无，甚至是超出范围之外。
需求，一定是相关方的共同需求，比如需求来自一个人或一个部门，这就要跟其他部门或相关方进行协商讨论，得到他们的接受和认可，因为对功能的开发需要耗费时间和金钱。
总结：想要解决这种真实存在的问题，建议了解敏捷项目管理，了解开放范围的需求管理在敏捷项目管理中的强大之处，真正的需要总能在系统中找到自己的位置
三：需求太少了
需求太少，想要获得早期或初始的评估，或者对计划进行迭代，都将会是个挑战。然而事实是，需求终究会出现，糟糕的是项目快结束了需求才出现。
这种情况经常发生在刚刚交付了第一个或主要的版本，而团队还得继续为新版本工作，修补一开始没想到的事情。
总结：敏捷项目不是追求建立一个完美的需求集合，这个模型在开发生命周期的初期动态吸纳新发现的重要需求的方法，从结果上看，敏捷项目的计划将在项目早期能够包含新识别的重要需求。
敏捷方法，是一种框架，可以容纳变更的软件工程框架，需求在项目开始时是未知的或含糊的，敏捷框架有内建的机制使项目得以处理并减少这些不确定因素，这些机制对应不同的敏捷实践做法不完全相同，但如果缺少这些实践，敏捷项目都将是不完整的。
应广大粉丝要求，我们建立了一个【PMO前沿交流群】，小伙伴们热情踊跃，目前人数已经上万人了，不能直接进群啦，想要进群的添加小编微信，拉你进群。两个添加其一即可！
欢迎加入中国最大的PMO&PM社区
