软件项目如何控制需求蔓延

当销售人员兴冲冲的告诉你又接了一个单子,只见合同上对需求内容只是寥寥几行时,你是否又头大了。对于销售人员接单是他们的目的,在客户处他们往往把话说的很满,这也能行、哪也能做。实际,很多功能的实现要让我们付出非常大的代价,那我们在项目需求管理方面要怎么做呢?

对于一名项目经理来说,做出让客户满意的产品是我们的终极目标。但实际情况会是这样吗?现实,我们在项目开发过程中会遇到各种问题。

需求范围不明确

合同中规定的内容往往都是模糊不清的,需求不明确,或者只有几行说明,而且还可能有大断的套话、官话。对于项目参与者往往对客户业务不一定了解,如果对客户真正想要的需求没有真正了解,往往会导致后期无何止的修改。

需求理解不一致

我们经常会遇到,按照客户书面上记录的需求进行开发后,客户却并不认可,而实际情况,客户对自己写的书面内容也并无异议。原因是对同样的内容客户的理解与我们的理解不同。例如,需求中写道:“购物后付款”,开发人员开发出来的是用户选择好商品进入购物车直接付款。而客户实际想要的是到购物车付款前先向客户发送一条短信验证码,让购买人二次确认无误后再付款。同样的文字,对细节的理解可能就是不同的,但实现的细节客户提供的需求里可能根本就没有提。

有些需求并没有直接写出来

中国人喜欢儒家思想,话多为隐晦而不直白的说出,客户提的多是自己期望解决的需求,而对于最基本需求往往不说,因为他认为你就应该有。如做一款手机,手机打电话的功能客户是不用说的;再如,智通面包机,做面包的功能也是不需要说的,他只会说如何智能法。

项目结束前客户总有提不完的需求

客户总是会在结项前提出各种需求,前期没有讨论过的各种需求都会在这个时候冒出来,让项目被动受制。这种情况原因一般有两种,一种是在项目开发过程中没有与客户充分的沟通。另一种就是客户生怕项目一结束付款,你们就不会再很好的支持我们了。那么所有需求不论重要与否,你都要在结束前给我做完。

项目经理无条件的迁就客户

虽然项目成功的标志是客户满意度,但无条件的迁就客户最终可能导致项目预算超期或时间超期,反而会导致项目失败。客户在提一条新需求时可能自己都没有想清楚,也可能只是他的灵光一现,许多需求可能只是冗余需求。客户往往不懂程序,随便说出的需求,可能让我们付出很大的代价。

沟通不顺畅,老吴以前做项目时也经常遇到对计算机一点不懂的客户,他们的许多想法根本无法实现,跟他解释他又很难理解,最后弄得好像我们什么都做不了似的。对于这种客户有时会让我们有种无力感。

一个项目的成功需要多方面原因,人力资源、需求范围、项目成本、进度控制、质量监督、风险监控、资源采购、干系人沟通,每个方面出问题都可能会导致项目的失败,所以项目管理也要有一套系统的管理办法。对于无边界的需求蔓延,我们应该怎么办?

上面我们已经提到了可能导致需求的不可控原因,哪我们来说下具体可操作的解决办法吧。

确定项目范围

项目一定要有清晰的目标、准确的方向,大海航行靠舵手,项目经理要有把撑好项目范围的能力,尽量把项目需求让所有项目干系人(范围相关的所有人)知晓,尤其要得到客户的认可,必要时要让用户确认。以前经常听有的项目经理说:“需求最后一定要让客户领导签字”,老吴本人认为这有点难度,以前我做政府类项目时哪个领导愿意签字的,谁愿意背这个责任,还有真要有必要需求增加时,签了字如何增加,客户会有一百个不愿意。如果你真有这能力,能弄到客户签字哪对项目是极大的帮助。

多问问为什么

对于客户每提出的新需求,我们尽量多了解他的目的是什么,多问、多想,当我们知道客户的终极目标时,我们就可以主导客户需求了。同时,我们了解了客户提此需求的目的后也有利于我们对需求的更好把握,不至于项目需求出现偏差。

需求理解要一致

项目经理要对项目进行跟进和监控,需求要很好的贯彻到每个人,不要出现理解偏差。记得看过一篇图文的短文,大致意思是客户想要的产品、项目经理理解的产品、设计人员设计的产品、开发人员要做成的产品、开发人员最后做出来的产品、测试人员看到的产品都不一致。每个人在信息传递过程中让需求不断出现损耗和变形。需求理解的一致性是项目成功的基础,在项目管理的各个阶段,要让所有相关人正确的了解和把握需求。

要让客户参与到项目的各个阶段

项目经理要拉着客户参与到项目的各个阶段,需求分析、总体设计、详细设计、编码、测试,要让客户参与到项目的每个阶段,并随时让客户了解和提出自己的真实想法。这样就不会导致项目在最后时客户提出各种需求,变被动为主动。尤其是在需求分析和设计阶段,当整理完需求文档和设计文档时,一定要请客户一起参与评估,以避免需求理解不一致,需求范围不确定等问题。我们以前常提敏捷软件开发方法,敏捷开发又不至于项目出现更大问题的办法就是让客户随时参与项目的各个阶段,让客户与我们的项目管理人员一起把关。

要让客户对需求进行确认。当多次与客户确认需求后,尽量让客户签字认可,如不能签字也尽量让客户方领导在正式场合当面确认。

这样的好处有:

  1. 可以有效的控制需求,当客户再有想加的需求时总不至于那么理直气壮;
  2. 如客户真要加需求时,我们可以因需求变更而提出一定的经济补偿;
  3. 如果需求增加了,项目经理可以凭借着签字在公司内部规避自己的责任,毕竟客户以前是认可的,这回再提增加需求,就不是项目经理能力范围了,可以请领导出面;
  4. 有了客户确认的需求,项目组可以放心的去完成项目,以减少需求变更所带来的影响。

做好服务,要让客户信任我们

客户之所以在项目结束前尽量让我们把所有能想到的做好,有时还提出各种刁难,就是怕我们在项目结束后就不能很好的给予支持了。对于公司和团队,我们要建立完整的服务机制,要让用户看到我们的服务。如果客户对我们公司和团队认可了,相信以后的服务过程中有了问题,我们还会及时处理,那么客户会允许我们把部分非核心需求放到将来处理的。信任是种力量,让客户信任我们就要始终如一的做好服务。

做好需求变更机制

有时需求的变更是不可避免的,当发生需求变更时,我们要有一定的需求变更机制。首先要冷静看待需求的变更,与客户沟通好,要对需求变更的工作内容、工作量进行评估、因变更所产生的费用、针对需求变更提出的方案,并填写需求变更文件让客户签字,要让客户知道需求变更对项目产生的影响,对于需求的变更客户也要承担一定的责任(时间或经济)。

条条大路通罗马

对于客户提出的需求,不要一味的迁就,客户永远是对的的思想在项目开发过程中不一定正确。项目成功的标志应该是在规定的时间内利用有效的资源完成项目并使客户满意,为了一味满足客户的需求,而使项目进度超期、预算超期都不能算成功的项目。当客户提出一个不好解决的需求时,我们只要了解客户的目的,帮助客户分析后应该可以找出其它同样能达到相应效果的方案来,并让客户知道他的方案会给项目带来什么样的影响,客户还是会接受我们意见的,这样比与客户直接冲突要理智。

综合以上,项目需求的管理是一个复杂的过程,它涉及到项目所有相关人的利益。有效的避免与客户的冲突,多给客户一些中肯的意见。同时,也要让客户参与到项目的各个阶段,要让客户了解项目的各个过程,让客户了解我们公司和团队,建立起信任度,在有信任的前提下做事,友好的沟通,会让我们工作起来更加舒畅。

时间: 2024-11-07 05:21:09

软件项目如何控制需求蔓延的相关文章

浅谈软件项目的需求管理

软件项目区别于其它项目的最显著的特征是其不可见性,它不像硬件购销.建筑工程,都是实实在在可见的东西.而软件项目在系统交付之前很长一段时间,客户是无法感知自己想要的系统究竟是什么样子.因此,需求管理就显得十分重要,据相关统计数据分析,软件项目90%以上失败的原因都在于没有重视需求或者需求管理方面做的不到位导致的. 需求管理作为软件项目管理的一个重要内容,贯穿项目实施的全生命周期.俗话说:万事开头难.需求作为软件开发的第一个环节,其重要性不言而喻.市面上关于需求管理的相关理论和书籍很多,但多数停留在

需求蔓延相关疑问

书中经常提到需求蔓延,但从未对需求蔓延有一个概括性的定义. 需求蔓延是产品需要控制的一个重要方面. 我认为要想控制需求蔓延,首先要明白需求蔓延是什么,其次还要明白需求蔓延产生的原因. 但是书中并未给出这些最基本的,在网上只能查到人们对需求蔓延控制的疑问. 需求蔓延对我来说是一个大概能明白的概念,但是我无法清晰地对其认知,也无法清晰地明了原因.

软件项目量化管理(CMMI高成熟度)实践经验谈——之项目管理过程监督与控制篇

续:软件项目量化管理(CMMI高成熟度)实践经验谈--之概述篇 续:软件项目量化管理(CMMI高成熟度)实践经验谈--之项目管理过程策划篇 2.项目监督与控制 项目监控是围绕项目实施计划,跟踪进度.成本.质量.资源,掌握各项工作现状,以便进行适当的资源调配和进度调整,确定活动的开始和结束时间,并记录实际的进度情况,在一定情况下进行路径.风险.决策.度量.量化管理等方面的分析.在实施项目的过程中,要随时对项目进行跟踪监控,以使项目按计划规定的进度.技术指标完成,并提供现阶段工作的反馈信息,以利后续

软件项目需求开发过程实践之业务建模用例图

本次软件工程项目是重建办公业务流程管理平台,需要在继承原370个流程基础上,还需要提供快速流程开发能力,并要求体现出流程管理的规范性,以及流程的执行力.效率.效益,最终为企业管理创新提供流程再造的能力. 在项目前期及需求分析阶段,开发人员致力于"降低成本",以最小的代价完成项目,其可预见性的软件产品是经过系统平台升级的,并经过改良的第二个办公业务流程管理平台.按客户验收要求,"只能打60分,是不能给予验收". 在软件开发中,需求工作致力于解决"产品好卖&q

软件项目需求评分表

   软件项目需求评分表 组序号:23      组成员:何健勋 王岸城 苏月          评分人:苏月 序 号 N(需求) A(方法) B(好处) C(竞争) D(交付) 1 -4 -4 -4 -4 -4 2 -3 -3 -3 -3 -3 3 3 3 3 3 1 4 -2 -2 -2 -2 -2 5 2 2 2 2 2 6 4 4 4 4 4 7 5 5 5 5 5 8 -5 -5 -5 -5 -5 9 -6 -6 -6 -6 -6 10 -1 -1 -1 -1 -1 11 8 8 8

软件项目需求开发过程实践之软件需求说明书

软件需求说明书为谁而编写?把这个问题搞清楚是非常有意义的. 先讲个故事. 在软件项目开始时,需求及架构设计人员把需求和架构方案讲给开发人员听,开发人员还在设计"他那辆车",没有听明白?需求及架构设计人员接着写出一些列文档后,开发人员还在设计稍作调整"他那辆车",沟通出现了问题了吗?项目完成后,最后结果仍是开发人员所设计的,已经变形的"他那辆车". 问题的源头当然在需求,需求人员又如何把需求调研结果无损的分享给"相关人员"呢?其

软件项目外包,如何与客户谈需求

接项目最重要的一步是与客户谈需求.客户对软件的需求是项目规划和实施的根本,所以在与客户谈需求时,一定要让用户将所有的想法尽可能的阐述清楚,并把所有的要求罗列出来.这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量.而应该直接明白地要客户把项目的要求一条条地列出来.这时先把条理.归纳.分析先都扔到一边去,用纸笔将用户最原始.最完整的要求准确地记录下来.假如项目在你对客户的需求没有完全了解清楚的情况下就匆匆上马,那么就会随时发生意想不到的变更,轻则使项目延期或超出预算,重则使得原来已经做

有什么方式可以接软件项目需求,怎么接项目

软件团队最为关心的一点是在哪里可以找到项目做,也就是到哪里可以找到有软件需求的客户.对于一般人来说,广交朋友然后通过熟人介绍还是接项目的第一途径,但这要求你的朋友或熟人要在企业或公司里有比效重要的管理位置,对于像那些每天只能是埋头写代码的程序员这显然是不太现实的.所以大家不能等着项目来找你,而是要主动的出击去找项目.接项目最重要的一步是与客户谈需求.客户对软件的需求是项目规划和实施的根本,所以在与客户谈需求时,一定要让用户将所有的想法尽可能的阐述清楚,并把所有的要求罗列出来.这时候不应该害怕"勾

软件开发项目进度控制浅谈

一.影响软件开发项目进度的因素 要有效地进行进度控制,必须对影响进度的因素进行分析,事先或及时采取必要的措施,尽量缩小计划进度与实际进度的偏差,实现对项目的主动控制.软件开发项目中影响进度的因素很多,如人为因素.技术因素.资金因素.环境因素等等.在软件开项目的实施中,人的因素是最重要的因素,技术的因素归根到底也是人的因素.软件开发项目进度控制常见问题主要是体现在对一些因素的考虑上.常见的问题有以下几种情况: 1.80-20原则与过于乐观的进度控制 80-20原则在软件开发项目进度控制方面体现在: