软件开发，都会涉及到需求，无论这些需求是来源于最终客户、设计团队还是其他的人(例如市场调研)。需求管理系统，简单的可能是“需求讨论会 + 专人整理跟踪(Word, Excel)”，复杂的可以是“需求管理制度 + 软件 + 专人跟进”。但是无论是简还是繁，需求管理系统对于研发团队和研发项目是不可缺少的。我们为什么需要管理需求？我们怎么做才能管好需求？以下是我的一些体会，与大家分享、讨论。

 

1. “需求”需要被收集和汇总

需求的特点：需求往往是来源广泛、放置分散

管理的目的：形成需求汇总和集中的规范化渠道

 

    比较典型的是管理性质的软件的开发，需求往往会有各种来源：可能来自客户方，也可能来自软件团队自身。客户方可能会推出需求的人包括客户的决策层、各级各类管理层、开发方对口的IT管理部门、具体使用和操作的人员等等。他们的各种要求会通过销售人员、客户实施人员、客户支持服务人员反馈回来。软件公司内部各个参与到软件设计、开发、部署运维、实施、支持服务的部门也会提出各种要求和建议，有时甚至你的老板会直接打电话给开发软团，要求修改或补充相应的功能。

 

    与此同时，如果没有有效的需求汇总、保存和跟踪的机制，那么需求提出来以后，会被非常散乱的放置。也许张三、李四分别记了两三条，但是事情一多(别且也没觉得很重要)就没有报给项目经理，之后就忘了。也许王五接到老板提的一个要求，直接就把程序给改了，而其他人既不知道老板提过这样一个需求，也不知道王五为什么要这么改。长此发展，软件开发必然会进入一种混乱无序的状态。

 

    原始需求和想法的产生有很大的随意性，也许是录入人员操作时感到的不方便、也许是管理人员看报表时发现的局限性、甚至可能是老板灵机一动想到的。如果你为了规范和统一，把提需求的过程搞得很死板或麻烦的话，人家也许干脆就不提了。规范的目的是为了更好的服务客户，决不是为了限制客户的需求。

 

如果能够有一个基于Web的非常简单的需求提交工具：

* 方便：人们随手就能提交一个需求；

* 反馈：提交需求后，人们第一时间从软件团队得到反馈，如果不明白，他们会问；如果采纳，他们会表示感谢；如果拒绝，他们会解释理由；

* 跟踪：人们可以看到自己所提的需求被采纳、被安排进相应版本的产品设计、被开发、被测试和发布，直到体现在自己实际使用的软件产品中。

 

给人们一个给你提需求的理由？

需求和建议是一种宝贵的资源，人们愿意无偿地贡献自己的知识、经验、创造性，前提是能够得到反馈和鼓励、能够看到进展和结果。

 

2. “需求”需要被跟进和明确化

需求的特点：来源于非专业人员的需求往往缺乏清晰的表达和明确

管理的目的：因为表述不清而“无效”的需求不应被无视和抛弃，它们首先需要被提炼和明确化，然后才能判断其有没有价值。

 

    很多向我们提出需求的人(他们可能是客户，也可能是我们的市场、实施或者支持人员)， 他们不具备软件产品设计的基本知识和素质，所以他们对于需求的描述，经常是不清晰的和不明确的。例如某个客户可能会对你抱怨说某个功能“不好用”。如果这作为一个需求被提交到者程序员手中，估计没有人能“正确理解”吧。

 

    很多情况下，这样的需求被“无视”了。但是，我们这样处理对吗？这样“无厘头”的需求的背后，很有可能隐藏着我们设计中的用户体验问题、UI的不合理、甚至是管理规则或者流程上的错误，但是它们就这样被忽略掉了，我们这样处理对吗？人们提出了需求，意味着有可能存在问题。在经过专业人员跟进和梳理，弄清楚它真正的含义之前，我们没有理由对这个需求的价值妄下结论。

 

同样是这个情况，客户通过Web工具提交了一个“XXX功能不好用”的抱怨：

* 及时：由专人每天检查需求系统，对提交的需求及时的处理和反馈；

* 专业人员：不明确的需求，由专业人员(项目经理/产品设计师)通过多种手段(留言、邮件、IM工具甚至是电话直接沟通)与客户澄清需求；

* 澄清需求：搞清楚“XXX功能不好用”的原因是什么。是“界面太复杂，逻辑不清晰”？是“操作太复杂，需要简化”？是“数据反复录入，应该有自动记录”？还是“需要在不同页面之间来回切换、比对”？弄清楚这些原因，这个需求就变成一个设计人员和开发人员都能理解的有效需求。

 

给需求跟进人员一个认真负责的理由？

与客户以及其他部门沟通，澄清各种不明确的需求，需要有很好的耐心，有时候它甚至会成为一个费力不讨好的工作。怎么确保需求处理人员认真负责地对待每一个需求？你需要给他们一个理由。各个公司或者团队可能会有不同的方法，但是原则上要依靠“绩效考核”和“激励政策”，包括物质的和精神的，或者两者的结合。

 

举个例子：客户提的一个需求，原本是模糊的一个意向，经过需求人员分析澄清，发现是对产品改进有重大意义的高价值的需求。之后，经由产品设计师、开发人员、测试人员的工作，直到产品更新上线，提升了客户价值。这样的事件，将被评为一段时间内的“明星事件”，而参与其中的这个包括“需求、设计、开发、测试、支持”相关人员在内的组合，被评为“明星组合”在公司宣传，并给予诱人的物质奖励。

 

一套管理制度和管理系统的推广，仅仅对公司有价值还是不够的。需要将其转化为对每个参与者和执行者的价值，这个东西才会真正能够生存和发展下去。

 

3. “需求”需要被评价和筛选

需求的特点：需求是无限的，但开发成本是有限的

管理的目的：通过评价和筛选，使发散的需求收敛，进而成为制定产品策略的依据

 

需求可以是无止境的。把有限的开发力量和开发时间投入到发散式需求的汪洋大海中，被“淹死”是必然的结果。所以我们要把需求放到一种叫做“评价和筛选”的漏斗里面，使其从一种“发散”的状态变为一种“收敛”的状态。这样之后，它才能成为指导产品战略的重要依据。

 

A. 从哪些角度去判断和评价需求？

“评判一个需求哪有那么复杂，不就是重要不重要，然后是做不做嘛”。

 

但是你仔细想一想，这个“做不做”的判断其实涉及到各方面因素的考察，它往往是需要综合各方面的因素以后做出的判断。出于这些因素的考虑可能对该需求分别提出了支持或者反对的意见，但是这些支持或者反对分别重要或严重到什么程度，如何做出取舍判断，就需要量化。这里的量化并非要做到1+1=2的那种程度，最终还将是人为的判断。

 

* 价值考量

产略层面：与公司产品战略冲突/符合？战略性的转变/机遇？战略性的新思路/分支？

市场角度：整体市场竞争力的提升(往往对应构架上的变化)？新的卖点/亮点/宣传点？

客户角度：个别客户/通用客户？该(类)客户对公司的重要性？影响客户的操作层/管理层/决策层？

影响性质：没有就用不了？改善使用/管理/决策？大幅度提升？本质上的模式性变化？

 

* 成本考量

技术实现：已经掌握的成熟技术？成熟技术但未掌握(自研/外包/招人)？前沿技术？

开发量级：改进已有功能(1-2周)？增加新的功能(1-2月)？构建新的产品(6-12月)？

(有的功能特性虽然可以实现，但是非常“麻烦”，投入大量时间，但是“不出活”，这个因素也要考虑，否则你的一项设计遭到开发团队的无理阻挠，你还不知道是怎么回事呢。)

其他成本：硬件和部署成本(服务器/带宽)？技术支持和服务成本？等等

 

B. 如何组织对需求的评价，客观地作出决策？

 

小的需求，其决策者可以是产品经理、项目经理或者产品设计师。而大的需求，往往是由老板来拍板的。如前面所说，需求的决策，需要参考的因素很多，需要来自各方面专业意见的汇总。决策者当然不能仅仅凭自身拍脑袋来决定啦，所以，“大家开会吧”。很多公司都是这样，我们经常需要开大大小小的各种需求研讨会，其目的都是为了帮助决策者提供一个判断的依据。

 

需求讨论会，头脑风暴，可以很好的激发大家的灵感和创造性。但是它的前提是：所有参会者的主动性和平等性。所以，在更多的情况下，这种讨论会受到领导意见以及少数强势发言者意见的引导，形成20%的人贡献想法，80%的人仅仅是在旁听的局面。很多本来可以有想法的人，不提了；甚至本来可以去独立思考的人，不去想了。所以，就像我们提需求要有一个小工具一样，评价和筛选需求，有一个小工具也会大有帮助。

 

如果能够有一个基于Web的非常简单的需求评价和筛选工具：

* 每人：每个有必要参与需求评价的人都会被要求独立思考，从自己负责的领域和专业角度给出判断和评价；

* 汇总：各方面对需求的评价和讨论会依据不同的评价角度和来源汇总，实施更新，并展现给需求评价参与者；

* 循环：评价和判断不是一次就下结论的，对问题的认识需要循环深入的过程。评价-->汇总-->参考各方面的意见、有更全面的理解-->讨论并修正意见。

* 决策：经过上述的评价循环过程，各方面的意见会得到统一，或者收敛到几个意见不同的点上。最终由决策者做出判断，并给出相应的结论和说明。

 

要是我说，还可以考虑在评价循环中，针对每个人的观点、评论、意见主张引入“顶”和“踩”的机制，你是不是会笑了？其实这些方式方法上不要拘泥，关键是激发各方面参与者的主动性和创造性，才能更全面和客观的评价并做出判断。

 

4. “需求”需要在整个开发周期中被跟踪

需求的特点：提出了需求就希望得到反馈和看到结果

管理的目的：需求的跟踪，向后续开发环节的延伸。同时，需求的反馈，应该是一个连续的长期的动态过程。

 

需求被采纳或者拒绝，并不意味着需求管理的结束。你的老板、客户、市场人员、支持人员都会经常地和反复地问一些问题“我们的需求完成了多少？”、“我们的需求什么时候能用上？”、“研发团队正在忙什么？”、“研发团队这么长时间都做了些什么？”当你的系统功能复杂、需求复杂、版本很多、甚至开发中又时不时被插入各种任务的时候，上述看似简单的问题就变得难以回答，有时候甚至开发人员自己都搞不明白。

 

想象一下软件团队所面临的实际情况：

* 需求提出：从各方面汇总过来的需求可能有上百条；

* 需求筛选：经过确认的有价值的需求有80多条；经过多方评价和最终决策，采纳其中的70条，另有十几条因为条件不具备，暂时保存在需求库中；

* 产品设计：70条采纳需求经由产品部分析排入产品计划，其中40几条排入近期产品计划并作出相应的设计，另外20几条排入中长期产品计划，可能会在下一个小版本中实现；

* 程序开发：40条需求所对应的产品设计往往需要分期分批地提交给开发部门。进入开发部门后，它们会被分解成开发任务，排入开发计划，逐一落实。那么至少会分成“计划中”、“开发中”、“已经开发实现”三种情况。如果进一步细分，还要考虑“实现但正在测试中”和“实现但正在Debug中”两种情况；

* 程序测试：在开发的同时，测试人员就需要设计测试方案和准备测试数据。即便是比较糟糕的情况，拿到一个版本再去考虑测试的时候，测试人员也需要搞清楚“这个版本有哪些新功能/特性？”。如果没有一个跟踪系统，仅靠开发人员去描述的话，他们往往只能知道个大概。这样的测试很难保证测试的完整和有效。

* 发布支持：在开发的同时，支持人员就需要为产品的发布做准备：产品新特性/功能的列表、产品手册的更新、客户培训的相关准备。离开有效的跟踪系统，这一切都会变得没有头绪。甚至当产品出炉的时候，支持人员都说不清楚这个版本里有什么没有什么。

* 动态变化：同时，软件产品的开发是一个动态变化的过程。新的需求随时可以插进来(往往是你无法拒绝的)、设计会修改、开发进度也会随时调整。这时候要想动态跟踪需求在整个开发过程中的流转和变化，如果没有一个需求管理系统和方便的工具帮你的话，会很困难。

 

看到上面这些，我们了解到，在产品开发周期中动态跟踪需求的变化和落实，是很复杂的一项工作，需要有系统的方法。但是，我们这么费劲地去跟踪需求，有很大的意义吗？值得吗？

 

对需求的跟踪，非常有意义，非常值得。

 

* 让客户更理解你：“我们的需求提那么久了，你们开发人员都在做什么呢？”

你可以告诉他们一共有多少需求被排入计划、预计在什么时间随哪个版本发布、已经实现了几个、经测试发现了多少Bug、已经修改了多少、新功能所对应的手册和培训文档准备了多少......那么你的客户还有什么理由对你不满意呢？

* 让老板更理解你：“我们忙得半死，老板三天两头插各种东西进来，还觉得我们很闲”

满足任何需求都需要各方面资源的投入与配合，都需要有一个时间过程。而老板站在他所处的位置，对执行层面的状态和各方面的难度与成本可能不会看得那么清楚。有些事情他安排下来以后，甚至自己都忘记了。这不是他的错，也不是你的错，而是你们需要有更好的跟踪系统。

* 更有效的衔接配合：软件产品的开发是一个系统化的过程，各个环节和部门间需要紧密的配合。

需求分析-->产品设计-->程序开发-->产品测试-->产品发布、培训、支持。软件产品的开发的各个环节需要紧密的配合。测试人员在开发人员提交内测版本之前就要开始准备测试方案和测试数据；支持人员在产品发布之前就要开始准备帮助手册和培训材料。协调他们的工作需要一个一致性的看板，而这个看板上很重要的内容就是需求和产品设计在开发各个环节逐步落实的动态跟踪。