需求管理

我们已经做了需求采集，需求分析，现在似乎应该甩开膀子干活了，但经验告诉我们不是这样的，一个实际的例子：

网店版二期上线后两个月，各方各面提出过的需求也许有四五百个，经过PD们的初步判断，记下来供团队讨论的有200多个，决定暂缓的有60多个，七月一个月发布掉了70多个。其中每个需求的去留，去的怎么去，留的怎么跟进，是一定需要管理的，这时候我们要考虑的，是在评估出“性价比”的情况下，到底什么时候来做，谁来做。

其实在功能列表上做一些简单的扩充，就可以得到一个简单的需求管理工具了。

 

 

 

首先，功能列表是静态的，现在要变成动态的，对每个功能（视为一个需求）加上跟踪状态的属性，让我们能实时看到“何时做，谁来做，状态如何”。

负责人：细分为需求提出者（很可能是用户，有必要备注一下最原始的需求）、需求负责人、开发负责人、测试负责人，属于哪个项目……

需求状态：通常有“待讨论”、“拒绝”、“暂缓”、“需求中”、“开发中”、“已完成”几个状态，可以按照实际情况有所增减。

时间信息：提出时间、录入时间、发布时间……

有了如上信息，然后我们就可以制定每个需求的状态变迁的流程，举个例子， “待讨论”状态的需求应该多久讨论一次；讨论完了就应该转为三个状态：“拒绝”、“暂缓”、“需求中”；而“暂缓”的又应该再多久以后激活，等等。

此外，各种状态的需求个数，也可以通过excel的基本统计功能的实时监控。

做完这些，基本就可以得到文中的图了。

至于更专业的需求管理方法和工具，也看了一些书和软件（比如IBM的Rational RequisitePro），确实是相当的有学问，不过还是觉得暂时不合适游击队，而对于正规军是绝对必要的。

最后说一下我对管理的理解，管理并不是部门经理们才需要掌握的技能，而是每个人都必备的，只是每个人可以使用的资源不同，所以需要管理的资源也不同。当资源充分的时候，我们会觉得“正确的做事很重要”，事实也确实如此，比如被分派了某个重要任务的时候，我们的目标就是做好这件事。而一旦资源出现了瓶颈，“做正确的事”就立刻变得更重要了。比如同时有3个人要请你吃饭（当然这种好事比较难得），资源（你的时间）不够了，你就需要迅速判断吃谁的请更有价值，谁的请可以搁置住但不会丢掉……

每个人需要管理的，必定有自己的时间，也许还有自己的抽屉、硬盘空间、钱等等。经理们需要管理的通常有人员、经费等等。一个共同的特点，这些资源总是处于不足的状态！管理做的事情就是合理分配不足的资源让结果最优。

 

链接：http://iamsujie.com/category/1000/