[东方大唐]的博客:
http://dfdt.mypm.net
对项目需求管理的认识和体会

下面是对一位项目经理关于需求管理的访谈:

做了那么多个项目,我深深感到对项目的需求把握管理好了,是项目成功的关键。对需求的管理大概有那么几个活动,首先是需求获取,这是一个确定和理解客户的需要和期望的过程,为实现项目目标而定义、记录、分析干系人的需求; 其次,是要求获得相关人员对需求的认可和承诺;最后,即使是需求确定下来之后,也不可避免得会有变更,如何控制和管理变更,是保障项目目标的实现的重要环节。

2010年,我担任了公司一个重要项目,老挝TAIS系统的项目经理,该项目是一个系统集成项目,在此之前,我并没有做过类似项目,为谨慎起见,严格按照需求管理的规范执行,收获了很多经验,也保证了项目的顺利交付。

1、需求获取 需求获取分为两个阶段,需求调查、需求定义。需求调查和需求定义在逻辑上存在先后关系,但实际工作中二者通常是迭代进行的。需求分析的工作则贯穿于“需求调查”和“需求定义”两个阶段。 需求调查的目的是通过各种途径获取用户的需求信息(原始材料),产生《用户需求说明书》。

需求分析的目的是对各种需求信息进行分析,消除错误,刻画细节等。需求定义的目的是根据需求调查和需求分析的结果,进一步定义准确无误的产品需求,产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。

在进行现场需求调查之前,我首先需要了解的是,这个项目是什么样的项目,大概做什么事情?并仔细阅读了售前阶段产生的所有文档资料,和售前阶段参与人员交流沟通,进一步了解项目是谁提出来的,目的是解决什么问题。

不单单听介绍,特别关注了与合同具有同等效力的那些文件,如技术协议,工作说明书(SOW)、实施方案等等。从而知道,该项目是一个老挝TAIS (THSCAN-ASYCUDA Integration Solution)项目是我司集装箱/车辆检查系统与海关数据系统整合解决方案的简称。目前在老挝境内,8个地点部署了6套车载式系统和2套组合式系统,老挝海关使用的海关自动化业务系统叫ASYCUDA,TAIS就是要实现NUCTECH扫描设备与海关数据系统的高度集成和信息共享。

了解都项目的业务领域之后,我又对客户干系人进行了分析,这样,就能保证正式调研需求时,能够选择一些典型的客户代表进行需求调研。刚开始没有经验,参与人员太多,提供的信息过于零散,减慢了收集需求的进度。后来我们制定了现场访谈计划,一次讨论不超过10人。效果就好多了。通过和客户的有效沟通,获取了大量的信息。

我发现,跟客户交流时,提的问题最好是开放式的,比如 “是否确认进度检查确认方式”比“如何确认进度检查确认方式”可以获得更多的信息。“项目计划编制完成后,是否征求下级部门意见,如果下级部门不接受上级部门分配的计划,如何协调和处理?”这样一个问题就可以了解客户的计划批准和协商过程。现场调研的工作很顺利,共去了3次。

除此之外,我们还参观了用户的工作流程,观察用户的操作。 初步的需求信息得到以后,要对需求进行分析。需求分析有很多方法,“问答分析法”、“结构化分析法”和“面向对象分析法”,总之,是要对得到的信息进行处理,提取这些信息间潜在的逻辑关系,分成不同的类别,这样才能充分理解它们。

这就要求项目经理不仅要尽可能记录客户信息,同时还要做一定的整理,否则,所有的讨论只剩下一个模糊的印象,需求仍然是一件遥远的事情。只有进行深入收集和分析,才可以消除任何冲突或不一致性。 信息量越大,对准确理解客户的需求越有帮助,但同时,对需求的分析也就越难。

对于软件项目,我认为这可能是最困难、最关键、最需要交流的工作。因为软件不是硬件,不是主板,显示卡之类看得到摸得着的东西,软件是思想,是理念,是规则,是对真实世界的抽象。软件项目的交付物是有形的,可又不同于其他行业,比如汽车的构造是固定的,其组成部分是不变的。而一个软件系统的模块划分则可以有多种方法,多种结构。这个特征导致对软件项目经理的抽象思维能力要求很高,要求要有较强的逻辑性。否则,就有可能表现为缺少全局概念,对项目整体的范围和业务系统把握不够,在项目过程中被客户牵着鼻子走,今天客户说要个什么功能,就添加个什么,明天要修改个什么,就跟着修改什么,被动至极。 将客户信息结构化,编写成需求文档。这是需求定义的工作。公司的《产品需求规格说明书》的主要内容包括:“ 产品介绍;描述用户群体的特征;定义产品的范围; 阐述产品应当遵循的标准或规范;定义产品中的角色;定义产品的功能性需求;定义产品的非功能性需求,如用户界面、软硬件环境、质量等需求;”仅有这份需求文档还不够,我上现场调研时带了个美工,将我们和客户沟通好的软件部分用图形界面UI画了出来。 需求定义是需求获取中最“痛苦”的一件事情,为了尽量避免日后的扯皮,我们力图使每个需求都应当用陈述句说明“是什么”,如果“是什么”的内涵不够清晰,则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的,那么应当解释“为什么”,追究“是什么”和“为什么”的目的是获得正确、清楚的需求。对需求定义的标准大致如下: 需求存在二义性吗?2 需求文档的上下文有矛盾吗?2 需求完备吗?2 需求是必要的吗?2 需求可实现吗?2 需求可验证吗?2 需求的优先级确定了吗?2

2、 需求确认 需求确认是指开发方和客户共同对需求文档进行评审,双方对需求达成共识后作出书面承诺,使需求文档具有商业合同效果。 在需求调研的过程中,我发现对项目范围的定义和当初了解的存在误差,这也是很正常的,因为未签订合同前,谁也不能做很深入的调研,只能了解个大概要求。但我们的原则是不轻易更改工作范围,只是在原来的框架内做一些小的调整。 而且每次和客户讨论之后,我们都写一份会议纪要,请客户签字确认。但即便如此,对需求的确认也是一件很让人头痛的事情。如何划定边界?做到什么程度就可以了?因为只有提供需求的人才能确定是否真正获取需求,我们都尽量请客户参与讨论并更正。 需求评审会议非常重要,但是以前几个项目的评审会都开得不很理想,大家事先不认真阅读文档,会上乱哄哄的,你说一句,我问一句,往往花费了很多时间,却啥结论也没有。这一次,我吸取了教训,组织了一个非常正规的需求评审会议,将部门领导、公司的业务专家、技术骨干都请来当评审人员。并自行设计了《评审准备表》和《评审记录表》。会前两天提前发了老挝项目的需求文档《老挝TAIS项目方案建议书》、《老挝TAIS项目调研报告》,发放了《评审准备表》,让大家提前将问题记录在评审准备表中,并反馈给我,我一直等到反馈意见收集的差不多了,才召开评审会。评审会开的很成功,效率很高。我让人整理了评审发现的问题,放在了评审记录表中,方便下去追踪。

3、 需求变更控制 需求变更控制是指依据“变更申请-审批-更改-重新确认”的流程处理需求的变更,确保需求的变更不会失去控制而导致项目发生混乱。

需求变更难以避免,重要的是不能没有章法得变,要遵循一个标准的变更控制程序,使得变化有序起来。 如果不进行变更控制,那么,项目就不能得到及时的警告,常常会因为进度超期、预算超支而陷入泥潭,成为“烂尾”工程。但是变更实在太频繁,如果每次变更都走变更流程,也会大大影响项目进展。按照变更控制流程,需要对变更做影响分析等等。

既然变更在所难免,不可能只要有变更就执行严格的变更控制程序,这个过程也是有成本的,所以,和项目组成员讨论的结果,只有重大变更时,才执行变更控制程序。比如影响了项目里程碑的达到,工作量超出了原先估计的30%等等。

这样一来,既保证了变更的有序性,又保证了项目进展。 除此之外,我还对需求的稳定度做了一个度量,度量了原始需求的个数,增加、删除、更改的需求个数;并分散在项目各个阶段,如需求分析、概要设计、详细设计、编码阶段、测试阶段等等的需求数,并将每次需求变更的提出人、变更原因,是否走了正式的变更流程都记录了下来。一来是为以后的项目做参考,二来跟客户沟通时也有话说。不至于拿不出令人说服的事实和根据来。

比如这个项目,初始的软件需求共有142个,中间增加了21个,删除了6个,更改了34个。总体需求稳定度在30%左右,对于一个软件项目来说,就很不错了。 老挝项目于2011年12月底结束,项目获得了老挝海关的好评,目前系统运行正常,系统已经融入老挝海关工作流程,成为海关工作不可分割的一部分。公司也收回了该项目所有尾款,实现了公司的价值。

在此项目中,我们做到了一下几点:尽早开始需求调研,清晰进行需求定义,随时和客户进行沟通,及时记录需求变更,统计需求变更的影响和工作量。因此,项目进行得很成功,期间克服了很多困难,比如人手紧张,客户方接口人变动等等。但因为工作范围没有什么改变,需求一直在掌控之中,项目一直按计划执行和完成。    

东方大唐 发表于 2018-9-6 10:44:34 阅读全文 | 回复(2) | 引用通告 | 编辑 | 收藏该日志
Re:对项目需求管理的认识和体会


深圳市东方大唐信息咨询有限公司                                
网站:http://www.buildpmo.com     
邮箱:xwx2008712@163.com
电话: 151 123 30394
东方大唐发表评论于2018-9-13 16:33:00 个人主页 | 引用 | 返回 | 删除 | 回复
Re:对项目需求管理的认识和体会
深圳市东方大唐信息咨询有限公司专注于企业科技管理信息系统的咨询规划、定制开发和落地服务。以自主研发的Alta框架平台为基础,相继推出了项目组合管理、科技外包管理、ITSM管理、管理驾驶舱等一系列解决方案。
东方大唐发表评论于2018-9-12 9:01:00 个人主页 | 引用 | 返回 | 删除 | 回复

发表评论:

    昵称:
    密码:
    主页:
    标题:
公 告
登 陆
日志日历
搜 索
日 志
评 论
链 接
统 计