软件需求之真正的需求管理

软件需求之真正的需求管理

一、引言

需求管理绝对可以算是产品经理日常工作中比较重要且高频的操作，今天我不聊高大上的马斯洛需求层次理论、也不去深挖人类需求池在产品上的表现形式，只想跟大家聊聊需求管理如何落地的话题。这个话题起意于目前我在梳理部门需求管理的流程，所以下面的阐述都是以我梳理的成果为例。

二、定目标、理概念、揪来源。

1.定目标。

在解决一个问题前，我们需先明确这个问题到底要解决什么？它的目标是什么？针对需求管理如何落地这个问题，我们明确了这个问题的是为了解决目前需求承接、记录、优先级判定、跟踪和反馈无序化、不规范的问题。所以针对这个问题，我定了以下目标：使需求的承接、记录、优先级判定、跟踪和反馈整个流程更加规范和有序。

2.概念界定。

解决需求管理的落地问题，首先要对需求有个定义，方便对流程要解决的问题聚焦。我给出的定义：待解决的问题。需求管理本质上是从接到一个问题到将这个问题解决的过程管理。这个过程中涉及需求的接收和澄清、需求的梳理和分析以及需求的跟踪和反馈。

3.来源分析。

我想大部分公司的产品经理所接收到的需求无外乎以下两种类型：产品自身优化迭代和功能完善而产生的需求；业务部门、运营人员、市场提交给产品的需求。因为不同的需求来源，会造成需求的流转和处理方式大有不同。我们此次讨论的需求来源主要是针对后一种需求来源：来自于产品之外的业务部门、运营人员、市场提交的产品需求。

三、选工具。

理清了接下来要做什么事、这个事要达到什么样的目标、解决什么样的问题后，下一步工作就是选择能很好支持这个工作的工具。摆在我们面前的有三个工具：redmine、confluence、tower。

1.分析现有工具使用现状。

redmine我们平常有在用，主要用于提交bug以及追踪bug解决进度，也用于提交优先级比较高、工作量又不大的产品优化需求。

优点：方便跟踪问题的处理进度、可标注问题的优先级、可将问题指派给某人、能生成唯一识别该问题的ID号方便后续跟踪。

缺点：组内成员无法针对某个问题展开讨论，且不支持将图片直接贴在问题描述区。

在此之前，confluence是充当需求管理和知识积累的工具。做知识积累还算可以，但是做需求管理，有以下几个优缺点。

缺点：不能及时追踪问题的处理进度、无法对问题标注优先级，也就是说confluence 是存放需求池的好工具，但是对需求管理整个过程却不是最佳的选择。

优点：成员可以方便讨论、评论者可@相关人员、并且是与公邮打通，一旦有需求变更，可公邮给相关人员。我最喜欢的一点：可以自由贴图片。

tower之前是没有用过的，但是对其进行了分析之后，发现tower更适合做项目或任务管理，不太适合做需求管理，所以我们讨论之后，就果断放弃了tower。

2.根据各工具的优缺点确定最后的落地工具。

我们最终选择的是redmine+confluence。redmine适合需求过程管理，confluence适合需求内容管理。两者结合，完美！

四、落地流程梳理。

在做流程之前，我习惯用抽象思维去假设我接收到了业务部门的某个需求，我该如何让这个需求承接住并解决掉，这个过程在我脑中开始跑起来，这方便我细化流程节点、分析每个节点的工作事项和目标。

1.需求的承接、记录和首次反馈。这个环节主要是使用redmine工具。

需求的承接

需求的承接是从需求来源转移至需求承接者的过程，我们确定了每天需求承接者是由每天值日的PM来承接，当然各个公司管理不一样，这个可能会有所差别。记录在记录需求时，也需要确定一些规则：需求来源、主题、描述、状态、优先级。这些字段是需求记录者必须要填写的事项。需求来源大抵是记录这个需求是由哪个部门的哪个人通过什么渠道提交的；主题是能言简意赅描述清楚这个需求的一句话；描述是对需求的详细的、进一步的阐述；状态有利于标记清楚这个需求的解决进度；优先级可以将需求划分为几个等级反馈

当需求记录者把以上的问题梳理清楚后，基本上就可以保存这个需求、生成代表这个需求的唯一ID号，方便日后的追踪。再将ID号反馈给需求来源者，大抵的意思是表明这个需求我们已经记录，会考虑优先级予以解决。

2.首次review。这个环节还是使用redmine工具。

记录到redmine中的需求需要定期过滤和梳理，时间周期因公司而异。这个过程主要解决的问题是：对需求进行进一步的分析，确定需求的优先级、状态。并且将需求指派给某个人全程跟踪和处理。这个工作节点的意义在于：集中处理需求好过单个PM决定，而且对需求review之后，给定优先级和状态，可以净化需求池，将优先级非常高需求可纳入版本计划。这个流程主要是消化需求的环节，被消化的需求有以下几个去向。

需求完全是伪需求或是无效的，这个需求就被标记为无效；需求是有必要实现的、但是短时间内还无法给出优先级，这个需求就被标记为需要再次回顾的；需求明显是很长一段时间之后才会考虑，有效但优先级极低，这种需求就可以被标记为被冷冻的需求，需要再次回顾的时候解冻；需求已经被大家认可是优先级比较高的、且需要解决的，这个需求被标记为进行中，由相应的负责人认领该需求。无论需求是上面哪种去向，都要把结果反馈给需求来源者，因为他们对需求的处理进度真的很关心。

3.被标记为需再次回顾和冷冻的需求，需要定期再梳理。

这两种类型的需求对于产品近期工作不会有太多的影响，但是却不能丢掉，可能里面的需求有十分亮点的，但是短期之内无法解决的，最起码先找个地方盛起来。

4.在confluence中对需求内容进行管理。

已经被标记为进行中或是列入版本计划中的需求，这时可以转移到confluence中进

行管理。主要原因是confluence十分适合知识和内容管理。

5.需求被满足后，需要及时变更需求的状态、并及时反馈给需求来源者。

需求一旦被需求来源者提出，需求的处理流程就被需求来源者密切关注，所以，在需

求处理的每个节点，都及时将处理的结果反馈给对方，能大大增强其它部门对产品部的好

感哦！

五、to do list。

没有具体到执行者的任务都是耍流氓！流程定好之后，除了执行外，还需要分配一个

任务列表。由于redmine的项目都是自定义，所以，为了执行上述的流程，需要在redmine里面新建一个项目，这个算是to do list。

六、写在后面。

树挪死、人挪活。流程是死的，人是活的，在流程执行过程中，应该发挥人的主观能

动性。对流程执行过程中遇到的问题，可随时修正流程，以保证大家基本上按照流程来走。