关于软件项目的需求管理

需求是一个项目的重要基础，所有项目都是自需求开始，也是因为满足了需求而结束的。项目成功的一个关键性因素就是需求的管理。那么，怎么管理需求呢？

在管理需求之前，需要先认真讨论一下需求的本质和组成。

那么，需求的本质是什么呢？需求的本质就是要达成的业务目标。也就是基于这个需求，要实现的目的。我们所有需求调研工作都应该是围绕这个目标展开。要探查这个目标，要注意几个问题：1、这是谁的需求？2、目标是完成这个事最根本的原因，而不是他要做的事。

我举个例子：某部门要建设一个系统，希望通过这个系统采集业务工作流程中的信息，并将其形成统计结果展示给领导，便于领导掌握全局工作情况。

这是个最简单也是最典型的信息化建设需求。从字面理解，基本上来说有两件事，一是信息采集，二是统计分析。那么要了解信息采集的需求就找到具体业务工作岗位，了解其日常工作内容，看哪些能够通过信息化手段采集到系统中。统计分析一般需要找到相关内勤工作岗位，找到具体业务报表，看如何通过信息化手段呈现出来。但是，真的就是这样如此简单吗？在调研需求之前，是否考虑过，是谁要建设这个系统？他要解决的问题是什么？仔细读原文可知，建设这个系统是为了领导让掌握全局工作情况。也就是说，这个系统服务的首要用户是领导。而不是业务工作岗位，也不是内勤统计岗位。也就是说，我们调研的首要对象应该是领导或者知道领导实际需求的人。那么，领导通过这个系统要干什么呢？从原文可知，要掌握全局工作情况。那么，我们就要从这个目标出发，看领导要掌握的全局工作内容包括哪些？是事前掌握、事中掌握、还是事后掌握？是实时掌握，还是在岗工作期间掌握？是掌握到各类事项的细节，还是仅掌握到结果就行？这些都会影响到具体的设计与实现的细节。比如，事前掌握就需要了解工作计划及其执行情况；事中掌握就需要介入事务办理流程；事后掌握看到总结和统计结果就行；要实时掌握就要考虑设计移动端；在岗期间掌握在PC端就行；掌握到具体工作细节就需要能够通过层级下钻看具体工作详情等。这些信息，从业务工作岗位、统计分析岗位都无法得到，如果不搞清楚，就可能使设计结果南辕北辙。

我们进一步思考，这个系统建设的根本目标是什么？从字面理解，是帮助领导掌握全局工作情况。但是，深入来想，真的就是这样吗？在建设这个系统之前，领导无法掌握全局工作情况吗？如果无法掌握，为什么无法掌握呢？掌握了全局工作情况，能做什么呢？这些问题，都是调研过程中，需要深入了解的。就这个项目而言，经过调研得知，这个单位刚刚换了领导，新领导希望推动组织机构改革，精简优化人员，提升工作效率。也就是说，他的真正目的是为组织架构调整提供数据支持。基于这个目的，前文的一些假设可能都是不成立的，在系统设计过程中，需要围绕人员绩效、工作流程监控进行考虑。

搞清楚了需求的本质以后，我们接下来就要深入了解需求的构成了。首先，需求从纵向上来说，是一个多层级的结构，也就是说，我们基于基本目标，派生出来第一层级目标，基于第一层级目标，派生出第二层目标，逐层分解，直到最底层的目标。每一个需求，都是由围绕这些目标进行展开的一系列要素组成。以刚才的例子来说，最基本的目标是组织机构改革、人员优化、工作效率提升。由此派生出的目标是绩效考核、业务流程监控和工作质效分析。由绩效考核派生的目标包括绩效目标制定、绩效信息采集、绩效结果评估分析等。再进一步，由绩效目标制定派生出的目标包括绩效目标填报、绩效目标审核、绩效目标发布等。到此，基本就到了最底层的目标了。接下来就要横向展开了，也就是说，这些基础目标衍生出哪些需求要素。按照以往经验，可以派生出以下要素：业务场景、操作者、流程、限制条件、输入或输出内容、其他便利性要求等。这些要素就是组成我们需求的基本内容。也就是说，我们调研的目的，就是搞清楚这些内容。

那么，我们如何了解这些内容呢？我们不能做一个表格，让用户直接填写，或是我们自己拿着个表格直接问客户，这样，一般都无法得到想要的结果。其根本原因就是我们根据以往经验针对需求的一个分解，基于这些内容，我们能开展后续设计工作。但是，确不是用户真正业务场景下真正的工作内容。也就是说，我们要跟用户对接，实际上要从业务场景入手，带着这些问题，将用户的业务工作内容，还原出这些需求要素。我们再举个例子，我们要了解制定业务目标的相关需求，就需要从业务场景入手，通过逐步提问，搞清楚这些业务问题。例如：日常工作中，有谁参与制定绩效目标的？他们都具体负责哪些工作？这些工作的先后顺序是什么样的？这些工作的开展有哪些制约条件？一个绩效目标包括哪些内容等等。这些问题不是固定的，目的就是要搞清楚刚才说的那些需求要素。当你发现有没有搞清楚某些要素的时候，就需要继续提问题。但是，一定要记住，所有问题都要围绕业务工作展开，用业务语言进行沟通。

上面我们说到了需求的本质，也谈了谈需求的构成。那么，到底如何进行需求调研呢？我认为，需求调研，分为以下几个阶段：

一是需求目标体系构建阶段，这个阶段主要工作内容就是要搞清楚之前的那两个问题，这个系统的最终用户是谁？他的最终目的是什么？为了搞清楚这个事，我们需要组织一次需求研讨会，邀请甲方关键用户参加。会前，我们需要深入研究招标文件、合同等原始资料，从中获取有关需求目标的假设，并基于这些假设构建相关问题。便于在会上引导客户，回答出刚才要搞清楚的两个问题。这个会不一定是一次就能搞定，有些时候，甲方自己也没搞清楚这两个问题，需要我们逐渐引导并进行深入探讨。有时候，因为这个目标需要层级分解，涉及不同层次的用户，逐一推到需要一个过程。总之，在大体搞清楚这个目标树之后，这个阶段就算完成了。这个阶段的输出成果物应该是一个树形的思维导图，在这个思维导图上，将业务目标层级分解出来。

二是具体业务需求调研阶段。这个阶段就是基于业务目标，通过提问的方式，将业务需求分解成业务场景、操作者、流程、限制条件、输入或输出内容、其他便利性要求等要素。具体可分为如下几个小的阶段：

1. 调研准备阶段，这一阶段要根据业务目标，仔细研究招标文件、合同等文档资料，基于以往项目经验，拟定相关需求调研问题。这些问题要围绕上文所说的需求要素展开。这个阶段的输出物是调研提纲
2. 调研阶段。这一阶段主要是基于准备的问题向对应的业务用户调研相关需求，如前文所诉，在提问的过程中，主要是要注意一定要基于业务语言进行沟通。这一阶段的输出物是调研结果草稿。
3. 调研确认文档整理阶段。在这一阶段，主要是将调研过程中记录的信息整理成确认文档，以便在下一阶段向用户确认。此处要注意，这里整理的是用户确认文档。所以，要偏向业务语言。同时，着重描述业务场景、操作者、流程等与业务关系更为紧密的要素。另外，此处如果具备条件，建议配合界面草图进行确认。这一阶段输出的是调研确认文档。
4. 需求确认阶段。在这一阶段，主要是基于确认文档，与用户就需求进行确认。确认过程中，建议先进行业务场景确认和操作者确认，然后确认流程等。最后，如果有用户界面草图，进行用户操作界面确认。

三是需求规格说明书撰写阶段。这个阶段的主要任务是基于需求调研结果，形成需求规格说明书。需求规格说明书不同于之前的调研确认文档。它的阅读对象不仅是用户，也包括设计人员。所以，其主要内容要与设计衔接，重点体现业务流程、数据结构、界面原型等辅助设计工作的相关要素。

需要说明的是，以上过程不是一蹴而就的。期间可能需要多轮迭代。其主要原因是需求的了解和分析、确认本身就是一个过程。无论是用户还是需求调研人员，都需要经过反复磨合才能逐渐达成统一认识。其过程，可能如下图所示：

最后，我想就需求调研中，要注意几个问题再一起探讨一下：

1. 不要想着一次搞清楚所有需求。像前文所述，对需求的认识是一个渐进的过程，如果想把所有需求搞清楚再进入设计阶段，可能会浪费大量的时间。我的建议是迭代式开发，就是了解一部分需求后，就进入设计阶段，设计结果确认后，就进入开发测试阶段，开发完成后就开始上线试用并进入下一轮迭代。在下一轮迭代中，除了继续了解下一部分需求外，用户通过试用还会提出反馈意见，此时，我们可以根据反馈意见修正需求，调整设计，完善功能。有人认为这不是返工吗？但是，这一过程是不可避免的，因为往往在用户真正看到并使用系统后，才能有针对性的提出对需求的修正意见和完善要求，期望通过文字或是原型就搞清楚全部需求，几乎是不可能完成的。
2. 不要想遮掩和隐藏需求。我们在需求调研中，经常会碰到这种情况：与客户交流需求中，你基于以往的经验，发现了一些隐藏的需求。也就是说，你发现既然客户提出了这个需求，将来很可能提出另一个的衍生需求。或者你发现了基于这个需求更好的实现方式，但是，可能工作量比较大。遇到这种情况，我的建议是两点：

1. 如果隐藏需求不超出合同范围，你最好还是提出来吧。因为，随着用户使用，大概率他也是要提出来的。 你要是主动提出来，会增进客户对你的信任。如果将来客户提出来，可能会适得其反。他有可能觉得你明知道有这个需求，确不说，会觉得你这个人不可靠。另外，主动提出来，把将来可能的变化一并考虑到设计中，还会降低将来客户再次提出来时返工的风险。
2. 如果隐藏的需求不在合同范围内，但是，确是一个关键性需求，如果不实现，会对系统完整性和用户体验造成比较大的损失。此时，我的建议也是提出来。但是，一定要与客户说清楚。如果工作量能接受，可以免费给用户做。此时，要向客户表达出来，此部分需求不在合同范围内，但是，从我们的专业考虑，如果不做会对系统造成很大的影响，我们考虑再三，决定做了。一定要让客户领这个情，在将来碰到不好解决的问题的时候，双方会有个缓冲；如果工作量不能接受，也要跟客户实话实说，委婉的表示，此需求超出合同范围，工作量太大，我们没法做，建议再后续系统建设中再考虑。
3. 如果隐藏的需求不在合同范围内，也不是什么关键性需求。其实是可说可不说的。此时，如果考虑客户满意度，增加客户与你的信任，工作量可以接受的话，也可以说出来。否则的话，你可以先不说。但是，要考虑到将来客户提出这个需求的时候，如何应对。如果可以的话，在设计中也要有所预留，以便将来不得不变更的时候，不付出太大的代价。
4. 如果不是一个新的需求，只是当前需求的一个更好的实现方式。这种情况下，如果工作量不是十分大，我的建议也是提出来。一方面，这种实现方式用户在使用中早晚会想到的，如果到时候由客户提出来，由于不超出合同，大概率，你还是要做的。此时，就会出现之前说的情况，可会对你的满意度下降，还可能返工。另一方面，你主动提出来，真心为用户着想，客户也会领这个人人情。在后续交流中，如果遇到其他冲突的时候，也可以有个缓冲。

总之，我的建议是需求调研中，一定要真诚，不要想着欺骗或偷懒。一个项目实施周期会比较长，你可能会与客户打交道很长时间，所谓日久见人心。如果总是留一手，是没办法长期合作的。要记住，客户的信任，往往比多投入点工作更重要。