需求调研中的5W+1H定律

作者泓峥萧瑟（转载自mypm）　　2005年03月08日

　　对于软件的需求调研活动，虽然曾经写过三篇相关的需求管理文章，出发角度是从整体的需求管理过程考虑；在引入CMM（二）需求管理KPA活动的基础上，列举了如何进行需求调研前的需求管理计划活动；在失败的项目中，找出规范和管理软件需求过程的关健点及需求关联的模型架构（这些可以参考以前写过的《 CMM需求管理实践经验记录谈 》、《 从CMM角度考虑需求管理计划 》、《 如何用CRC模型来确定需求 》）。一直以来，感觉自己在经过几个项目试验的基础上对于软件的需求管理应该是有一定的基础和经验了，然而在最近参与的一个大型项目过程中，在新加坡项目经理的引导与帮助下，对于软件需求调研又有了更深一层的体会和认识；总结出需求调研中的5W+1H定律，在此把自己的一些过程和经验描述出来，希望能与各同仁一起分享与讨论。
　　项目背景 ：一个中型的企业信息化项目，其中乙方的项目经理是一个拥有PMP证书的资深项目管理人员。甲方的项目经理是一个有着丰富项目实施和管理经验的新加坡项目管理人员。（在这里需要补充的是，在调研产生冲突过程中，外籍人员如何用自己的经验和技巧，让乙方完全可以接收）
项目成员 ：
甲方：外包项目经理、外包项目管理人员
乙方：项目经理、系统分析员、界面制作人员
　　工作内容 ：项目需求阶段的活动，对于系统的需求，甲乙双方与最终用户能达成一致，甲方作为外包管理者，主要是对乙方项目组的项目进度、项目阶段成果进行跟踪与验收，以保证项目在预期的时间内完成预期的工作任务。
　　过程描述 ：项目启动后，乙方的项目经理列了一份详细的需求调研时间表、调研阶段成果目录清单、界面成果等的计划内容，可以用一个 “赞” 字来形容；从计划上看，乙方的项目经理计划真的是完美无缺；在与用户进行业务需求调研的活动中，乙方不仅记录下目前用户现有的业务流程，包括目前流程的局限性，流程的执行性等方面，还为用户进行了将来系统流程的规划，的确是一个不错的开始。可是在乙方提交其阶段的需求分析文档和界面时，却发现二者存在了种种的冲突和矛盾，我们无法将需求分析文档与界面结合在一起。此时，乙方的项目经理解释是因为文档比界面细，所以二者存在一些理解上的差异。而我们甲方却总觉得有些不太对劲，但因为同样存在着对用户流程细节的不熟悉，所以我们也提不出具体的问题，直到有一天，跟着乙方一起做用户的需求活动后，从乙方项目经理的提问方面，我们终于明白为什么他们会做出这样的文档和界面。
　　首先，乙方项目经理对用户的提问是没有序列的，我们所谓的序列就是项目经理的逻辑是否清晰，除了问及目前的流程外，最重要的引入项目（即新的软件系统）的目的，所需达到的效果，可以对用户辅助的东东，而这些甲方的项目经理一字未提与问，只记录用户所说的过程、局限和要求。这样，乙方项目经理在分析与规划系统的需求时，就没有一个明确的目的性和方向性，这里就要引入第一个W定律--- WHY定律 。WHY就是为什么用户要引入系统，引入新的信息系统对用户有什么帮助，在总体工作效能上如何实现一个最终的结果？WHY定律是要求在需求开始时，项目经理就应该明确的，这个项目是为了改进用户工作效率；提高部门间的协作机制；加快对客户反应的体系服务；提升企业的竞争力等等。有了这么一个WHY引入思想，项目经理就可以理清用户最终要的是可以提供给他们什么样的系统，在系统的定位和建立上，就有一个明确地最终目标。
　　其次，有了一个总体的目标性，从各业务流程的要求入手，引入第二个W定律--- WHAT定律 ，WHAT则是这个系统要做什么？实现什么？就是乙方项目经理提出的各业务流程问题、流程局限性问题、系统要解决的问题等，在这个WHAT的基础上，把系统划分成各功能模块，逐步弄清模块流程需求、功能需求、结构需求。引入WHAT定律可以让我们了解到系统的初步需求。
　　再次，引入第三、四、五个定律--- WHO、WHEN、WHERE定律 ，这个阶段其实就是需求细化阶段，在WHAT定律的基础上，细分系统的用户需求：分析什么人，在什么时间，什么阶段可以或必须操作这个功能，结合前面的WHAT定律，理清系统的流程阶段划分，记录并分析系统功能实现的细节，在这个阶段就可以产生系统需求的用例图（Use Case），作为下阶段设计的依据。
　　最后，就是所谓的1H定律--- HOW定律 ，就是怎样实现系统了，在前面的WHY、WHAT、WHO、WHEN、WHERE基础上，我们已经搭建了一个非常好的系统需求基础框架，如何在这些用户需求的基础上，分析系统的需求，如何进行需求规格的分析与下阶段的设计、实现工作，就是HOW TO ACCOMPLISH THE SYSTEM了。
在需求阶段引入这5W+1H的定律，在一定程度上保证了系统需求的准确性，也使得项目经理或需求分析人员可以非常有序的有条理的开展需求挖掘和调研活动，这样的安排用户在配合上也非常清晰，知道如何与项目人员配合。其后，在我们的建议下，乙方改进了工作方式，理清了一些工作序列，不过在最终文档的提交上，乙方的项目经理为了迎合我们的需求，一直对需求文档的格式与内容进行修改，没有保持需求分析中应该有的从粗到细的阶层分析，也导致其需求分析中的不确定性因素较多，后期的设计工作展开不顺，这些算后话，希望能在以后的外包管理方面，就存在的这些问题进行其它的分析和讨论。