敏捷项目管理之需求管理

作者：叶朝萍

[1499392921893_7114_1499392923068.png]

背景

在近几年比较火的敏捷开发大背景下，我们的项目团队的需求管理，也一直在探寻着敏捷开发的轻量化管理的原则，并且由于我们团队采用了Feature team 的团队运作模式，所以版本的需求都是由各个FT 自己独立管理的方式，理想状态是，各FT 自己管理需求，自己去做质量管理，自己评估把控进度和最后版本的顺利发布。而现实往往和理想之间，总会存在差距。下面就来谈谈，咱们浏览器项目需求管理那些事 ~

需求管理1.0 时代 --- FT 自管理+excel 规划表

我们知道，敏捷价值观中有一个是关于文档的，认为：

[1499393074848_4910_1499393075444.png]

这个原则本身是一种比较好的价值观，认为在开发过程中，有可用的软件好过详尽的文档描述，来引导团队快速迭代做出可用的软件。我们的项目需求管理1.0 时代，就是用excel 列表的方式来轻量化去管理需求，通过项目群来同步版本需求规划。

这种方式，确实简化了需求的定义，对团队来说是一种比较轻量的管理方式，但实际应用后，我们发现没有了需求文档的详细说明，和集中的需求设计交互管理，我们的版本需求质量也就也会受到一定的影响，因为没有文档，可能有些需求会被反复更改，导致需求变更增多，变更的增加也造成版本管理出现一些问题：版本需求不可控，质量影响、版本延期等。

[1499393186282_2664_1499393187556.png]

• 首先，是版本延期由于需求大多是一句话需求，没有明确的交互或详细描述，产品经理的想法也会不断变化，而开发的理解也会有所不同，这样就造成额外的劳动量。使得开发无法按期完成需求，而造成版本的延期。
• 其次，需求变更多

由于版本延期，已经开发好的FT又会觉得与其等待别的FT，不如自己也加入到需求新增的大军中，继续开发，这样互相影响，从而导致本一再延期，整个项目的周期也被不断拉长。

• 需求的沟通、维护成本加大1、需求描述就是一句话，大大增加了开发难度和测试难度，可想而知，沟通成本加大。 2、 需求靠excel维护，更新和同步都是需要收集人及时更新excel并要同步到相关人员，维护成本高。
• 版本质量不可控

因为需求不明确，版本需求的新增或变更也难以控制，导致缺陷量也比较多，版本稳定需要更长的周期。面对遇到的问题，我们进行了总结和改进，开始了需求管理的2.0时代。

[1499393465904_7859_1499393466807.png]

项目需求管理2.0时代 --- TAPD集中管理+需求评审

1、 需求的工具化管理：变excel的人工维护，为TAPD集中管理方式，每条需求的TAPD单上有明确的交互设计，解决需求的维护和沟通成本。

2、需求评审机制：设立产品版本规划管理委员会。建立需求评审机制，由这个专门的需求决策者来对每个版本规划的需求质量和范围进行评审确认。这样在版本开发前就确认各FT的需求是否可以上这个版本，确保版本需求可控。

这样运作一段时间，基本解决了人工维护的成本和需求不明确的沟通成本问题，延期和变更有一定改善，但是延期和需求变更仍然存在，版本仍会有较大的发布延期情况，需求变更率也非常高，版本整体波动较大。

针对问题，我们继续进行相关的总结分析，发现主要原因还是需求的质量控制不够：虽然我们的需求在迭代开始前，有了评审的机制，但实际开发的过程中，由于需求本身复杂度、技术方案选择，或者开发时间的评估不足等，仍然会导致我们的需求开发有一定的可能会出现延期的情况。而且由于当时评审的仅仅是需求的设计文档或交互稿，有时候做出来后产品或老大可能会觉得和预期不一样，仍然会存在变更的可能性。

针对这些问题和总结的原因，我们继续寻找更好的需求管理模式。

[1499393594722_2314_1499393595812.png]

需求管理3.0时代 --- TAPD集中管理+合流评审

经过不断的总结和根因分析，我们的需求管理方式又做了如下调整：

1、 针对需求评估不足或者变更引起的延期，我们的需求仍是采用TAPD工具管理的方式，但这里的管理会有所变化，这里的需求评审由FT内自己评审完成，同时要求FT内必须要要完成内部的需求评审，这个需求的把关由FT自己负责。而评审的完成时间必须是在版本规划的第0周内完成。

[1499393636719_3697_1499393637259.png]

这个变化将需求的评估充分放权给FT内部完成，你需要根据火车版本的周期，来评估和规划，版本周期内可以完成的需求，而不是所有的需求都想挤上同一趟火车。

2、 我们将产品管理委员会对需求的评审时间，延后到合流阶段，建立了合流评审的机制。这样做的好处是，当开发到合流阶段时，需求功能已经基本完成并可以使用了，这样给到老大进行评审时就比较直观，这样再评审后的既定时间内稍作修改基本就可以达成需求的预期，也减少了合流后的需求变更带来的质量风险。同时，对需求的变更管理也进行了规范，需求的重大变更或新增均需要有充分的理由给到GM审批，通过才能合入。

[1499393676583_2642_1499393677121.png]

经过一段时间的运作，我们来看下实际的效果：

（1） 版本从延期不可控 到 逐步可控 再到基本无延期；

（2）需求变更逐步改善，变更率下降了到67%；

（3）质量逐步提升，千行缺陷率也下降明显；

大大降低了项目的时间和人力成本，同时也为产品需求的快速上市提供了保障。

当然，敏捷项目需求管理的方法，我们仍在不断总结和迭代优化中，希望大家也一起来多探讨更好的管理模式，期待更优的需求管理4.0 时代的到来！

[1499393752388_3612_1499393753363.png]