需求如何管理

需求如何管理

传统的项目往往产品从业务方处获取需求，然后产品独自构思prd，邮件给开发和测试。测试组织需求评审，制定排期。开发开始写代码，然后提交测试，提交bug、解决bug，最后开发来上线。

这个看似完整的过程存在哪些问题？

1.产品拿到的需求真的是业务方想要的吗？这么实现可以带来什么样的效果？对系统性能有无影响？

2.开发按照产品意淫的prd就可以戴着耳机，闷头写代码了吗？如果有分歧就只是prd描述的不够准确？开发可以通过这一纸文档了解业务的根本目的吗？

3.若出现bug，要不就是代码的问题，要不就是测试用例评审不够细致？测试用例评审后就可以涵盖所有测试用例？

敏捷团队里，把项目拆分成若干个用户故事。进入迭代内的每个用户故事的需求是产品、开发、测试通过沟通而达成一致的，而不是通过prd来传递的。拿到需求后，多问几个为什么，往往能感知一些需求背后的隐情，预测可能存在的需求变化。在开始开发前，就把代码实现的步骤（表结构、接口定义）完成，尽可能避免可能存在的分歧。

发生变化时，Scrum master和产品经理紧急召集开发、测试一起分析需求变更的原因及应对策略，我们以开放的心态来迎接良性的变更。通讯基本靠喊，不要等待咚咚的回复，不要吝啬宣讲的机会，我们都是一个战壕的兄弟，一荣俱荣，一损俱损。我们的目的只有一个，快速有效的解决问题。