项目管理思考总结
作者：陈华平
日期：2007-11-24
在项目管理过程中，总会出现许许多多的好的或者不好的东西，有人说人生如同一个大的项目，在这个过程中，有些人规划的很好，成功了；也有大部分人从来就没有一个很好的规划，所以一直不是很好^__^。
成功的人往往是善于总结的人，如同生活不可能总是一帆风顺一样，项目也会遇到许许多多的问题，但只要我们做好应对措施，问题终归是会解决的。项目中的许多问题，好的或者坏的，都需要我们对它进行总结和思考，在总结经验的同时，我们也在成长。
下面是本人对项目管理的一点总结，下面的内容都是结合以前在网上看到的好的帖子和自己的亲身体会。
由于时间仓促，本文目前还不完整，而且有些词语可能描述不是很准确，在今后的工作和生活中会继续补充和完善。
一．坚持“以人为本”的过程改进的管理思想
我们都知道项目的三要素：进度、成本、质量，项目管理就是综合三方面的因素，在项目进行过程中不断平衡三方面的目标，最终依照目标完成任务。这三个方面是相互制约和影响的，项目经理的工作就是在不断平衡三者之间的关系。
软件界已经达成一个共识：影响软件项目进度、成本、质量的主要因素是“人、过程和技术”，在这三个因素中人是第一位的，其次是过程，然后是技术。
CMM/CMMI 是致力于软件过程改进的，然而许多软件公司在实施CMM/CMMI的过程中沉溺于CMM/CMMI的理论，过于强调“过程”，照搬CMM/CMMI中的理论，没有依据本公司的实际情况进行合适裁减。
CMM/CMMI 主要是致力于软件过程改进的，没有对成本管理进行很好的定义和说明，一个真正的项目经理在进行实际项目管理过程中应该结合CMM/CMMI和PMBOK中的内容进行思考，PMBOK 中提到的五个过程域和九大知识领域的管理是每个成功的项目经理都必须掌握的内容。
做过研发项目管理的人都知道，企业研发管理的指导思想是：结果导向，并且关注过程。
“结果导向”是指：以最终产生的经济效益来衡量研发项目的业绩，追求利益最大化。
“关注过程”是指：将期望的结果分解到每个过程域（即工作环节）去实现，努力把每
项工作做好，从而得到好的结果。一般地，好的过程才可能得到好的产品，而差的过程只会得到差的产品。
然而在关注过程的同时，很多人往往忘却了人的重要性，任何一个项目都离不开人。记得一次出差在火车上有幸与一位企业家聊天时，聊到创业什么最重要的时候，我当时的回答是：找到一个好的项目是最重要的。本以为他也会赞同我的看法，然而他给我的答案是：最重要的是要找到一个优秀的团队，一个有着共同目标的人组成的优秀团队。这件事情已经时隔一年多了，但是他的这句话一直在我脑海中，在这之后的过程中，我一直在思考着这句话，现在我已经体会到这句话的真正意义。
正像那位企业家说的那样，一个好的团队胜过一切，有了好的团队，要找到好的项目并不是难事。曾经有人问过比尔.盖茨。。。
项目成功的关键是人，项目执行过程中主体是人，再好的过程如果没有人去很好的执行也是白费。成功的项目离不开一位成功的项目经理，项目经理在项目执行的过程中会运用正确的项目管理方法来对项目开发过程中的各个过程域进行跟踪和控制，成功的项目经理应该深深懂得“以人为本”重要性，并在项目管理过程中，对项目过程进行不断改进和总结，只有这样才能不断的提高项目管理的质量，才能一次次创造成功项目的神话。
正当各个企业对CMM/CMMI 狂热追求的同时，各种敏捷过程方法论相继被提出，这些方法论的提出从某种意义上说就是对过于强调过程的一种反思。其中“XP”中的“人比过程更重要”的思想是值得我们借鉴和思考的。
项目管理是一个柔性化的管理过程，而柔性管理以“人性化”为标志，关注的是项目中的人，从而可知，“以人为本”的管理思想在项目管理中的重要性。
总之，一个项目的成功离不开人、过程和技术，如何处理这三者之间的关系是项目管理人员必须长期思考的问题。就像我前文中提到的研发管理思想：结果导向并且关注过程，同时技术在软件项目执行过程中也扮演着不可或缺的角色，技术又是由人去学习和掌握的。一个成功的项目离不开一个好的过程，然而再好的过程也要有正确的人去正确的执行，项目经理在项目管理过程中应该坚持“以人为本”并且不断的进行过程改进，强调过程与人的和谐统一。
二. 如何做好项目管理中的进度管理
首先，按照既定的计划执行，并及时进行跟踪与监控项目进度以及项目质量，最好采用多多询问的方式（因为最直接，也最快捷），该方法借鉴了走动式管理的管理思想,该方法一直在使用,经过实际证明,效果很好;
该做法的好处是:
1) 看得见的管理,通过面对面的询问的方式,能够就项目中存在的问题和项目当前的进度进行一个直接的沟通,以最直接和最快捷的方式获取项目当前的信息;
2) 更直接,更快捷的获取当前的项目进展状况及各个队员目前的进度情况 ,便于及时的调整项目计划,同时也为项目的跟踪与控制提供了依据(及时性和真实性);
其次，对项目进度进行全程的实时监控，对于项目中出现的问题及时作出响应和相应的应对措施，并对项目计划进行及时地调整，确保项目按照既定的目标和进度顺利进行；
（项目管理的目标就是。。。）
对于中小型项目(项目组人员在15个以下),可以采取如下的管理方式控制项目进度:
1) 每天早上上班前一个小时内PM 向每一位开发人员询问当前项目进展情况,有什么问题没有解决,估计需要多长时间,让开发人员给出一个时间,然后说明自己期望的时间期限或者项目规定要求的期限,同时询问项目组成员需要需要帮助,对于能够给予的帮助,尽力帮助队员解决;
2) 每天下班前一个小时内,再次询问各个队员的完成情况以及还有那些工作没有完成,原因是什么,需要什么帮忙,未完成的工作估计时间多长等等,做到有问题及时沟通解决;
3) 每周周例会上,项目组成员对各自的负责的部分进行汇报,对于没有完成的工作作出时间估算,本周完成了那些工作,那些工作在时间上有延误,原因是什么,下周的工作安排等等.对于项目中的问题,在会议上分析原因,并尽量在会议上谈论找出解决办法.另外,项目周例会上指派一名人员进行会议记录,会议记录的内容在散会后通过邮件发送到每个团队成员的邮箱.
以上只是对项目进度管理做了小小的总结和描述,在真正的项目管理过程中,有很多方
式可以对项目进行控制,主要看公司的环境和项目的大小等各种因素来选择最适合实际情况的方法.
我们知道，我国医学讲究阴阳平衡，儒家学说讲张弛有度，道家说要无为而治，老外一会说矩阵式管理有效，一会金字塔管理是好方式，再一会走动时管理为之推崇，此外，还有很多说不完的管理方式和名词。
我们究竟要学什么？用什么？教什么？讲什么？解惑什么？
管理技术没有最好，只有最合适，如果脚长得不好，非要怪鞋子，只能说明一个问题：鞋子选错了。就像很多人经常提到的每个人有各自得管理风格和做事作风，不能说谁的好，谁的不好，适合实际环境和实际情况的就是好。IBM 引进IPD取得了成功，于是很多其他企业也开始效仿，孰不知任何一种事物都有其生长的环境，同一种方法放到不同的企业不同的环境会产生不同的效果。
另外,我本人喜欢把重要的事情记录在笔记本的备忘录上,把事情分为重要紧急,重要不紧急,紧急不重要,不重要不紧急,最先做重要紧急的事情,然后大多数时间都在做重要但不紧急的事情.每个人的记忆力是有限的,再好的记忆力都有可能忘记事情的时候,所以我选择了先在纸上记下的方式.养成每天都翻开笔记本看看当前有什么事情需要解决的习惯,时间长了,就成了习惯.
三. 处理客户关系
与客户搞好关系,让客户把我们当作自己人(最近切身体会),对于项目今后的工作有直接的帮助和影响.
多多与客户交流,特别是客户方相关负责人(注意点: 积极主动去找客户交流,前期多花点时间在客户处,在某些情况下可以给客户提供一些帮助和方便. ),要明确告诉客户,项目中有任何问题可以直接找你,让自己成为客户直接联系人,切不可让客户在需要的时候不知道找谁或者找不到我方的负责人,与客户建立好良好的相互信任关系,关系到项目今后阶段的开展.
四. 避免镀金现象的发生
在项目开发过程中,避免镀金现象的发生,不可全部接受用户提出的所有要求(目前本人正在着手的一个项目简称A项目我们去客户那边走访做的很到位,对用户提出的新的修改要求都做了相应的修改. 但我个人认为这并不是最好的方式,多多去客户处走访固然很好,但为了害怕得罪客户,一味的满足客户,并对客户提出的所有要求都答应修改是不明智的做法,这种做法的结果是,我们的开发人员为了修改用户的要求加班加点,客户却感觉是应该的,并没有一点感激的情绪,这是一种典型的吃力不讨好的做法).
项目开发过程中一个很重要的也是很多公司在项目开发过程中经常犯的错误就是项目镀金现象的发生.
需求变化带来的问题
用户的需求永远在变,一味满足用户提出新的要求会给项目带来如下问题:
作为软件开发商，当接到一个项目后，一般的做法是首先由用户提出需求，然后开发商根据用户的需求作出一个系统实现方案，而用户通常并没有实质地理解方案，随即通过了方案，开始了软件的开发工作。根据笔者所开发过的多个系统，开发前期，大多数单位并没有明确的想法，也提不出确切的需求，因为业务人员不了解计算机技术是怎样实现业务流程的。用户总是希望开发单位根据当前的业务流程先做出一个样板来，然后再进行改造，而多数用户认为软件修改很容易。
尽管已经做好了系统规划，签订了功能较明确的合同，然而随着系统分析、系统设计和系统实施的进展，当客户在项目部署后看到真正的软件系统的界面及操作方式，客户的需求就被激发起来，会根据自己的对软件的理解和日常工作的习惯，对软件的处理及操作方式提出修改要求，而这种修改往往比较随意，因此导致开发方需要对流程、界面、以及相关文档经常的大量的修改，这些成为开发方的一个很大的负担，而这种负担对用户基本是看不见的(这种现象在业务型软件项目中尤其突出, A项目在这方面就有很明显的表现)。
在本项目中的一个切身体会是,需求的不断变化,如果不能很好的应对,会导致整个项目的进度和质量都难以控制. 开发人员只是一味的对用户提出的要求进行修改,由于大部分时间都在修改用户的新的要求,导致软件系统本身的稳定性测试时间减少,最终软件经常出现这样那样的问题, 开发人员要开始忙着修改问题, 出现一片混乱的局面, 旧的问题没有修改完,接着又要应对用户提出的频繁改变和增加各种要求.
在项目开展过程中,几乎天天面对用户的需求变更，切身感受到，如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，用户的耐性渐渐消逝，研发人员的士气也越来越低落，最后所有的人都在等待一个结果：项目最好马上结束。
如果不对以上问题加以很好的应对和控制,其直接结果是项目的周期大大超过预期,项目发生亏损或者项目没有达到预期的赢利目标.
一个真正成功的项目是在预期的时间内,高质量的完成项目既定的目标,并且同时项目获得了最大的利润.所以说,项目最终是失败的.
如何应对用户频繁的需求变更
首先,切忌对用户提出的需求拍胸脯，在此之前可以扪心自问：“如果拍了胸脯，以后不能按时完成，我能不能负担全部责任？”这样冷静一下就不会胡乱应承了。
其次,在用户提出新的需求时,我们要对照<<用户需求规格说明书>>,如果该需求不在说明书范围内,需要先估计一下改动所需的工作量的大小以及改动后对原有系统的影响,从而作出相应的应对.
对于一些不合理的要求,我们可以以不在合同范围内为由进行拒绝;
对于一些改动较小,且改完后对原有系统没有影响的需求变动可以给用户修改,但要让用户知道我们为改动需求花费了不少时间,让用户知道我们作出了牺牲;
对于某些改动比较复杂但合理的需求变动,我们应该让用户以文档的形式提交给我们,不要当场拍胸脯,最好的做法是:”您提的这些问题改动很大,我回去把这些情况和其他人商量一下再给您答复”,通情达理的客户都能接受这样的回答;
上面是对于用户频繁的需求变更如何应对,除此之外,我们最好有一套预防用户需求不断变化的方法,比如:采用UI 原型设计法等.
合理拒绝用户不合理的要求,防止项目镀金现象
…
五. 如何把好测试关
1. 开发人员
从项目立项的第一天起,在项目启动动员会上,就要强调每个开发人员对自己开发的模块务必加强测试关,对于开发人员开发完后提交测试人员的成果,一旦测试人员测试出BUG ,必须对所有的BUG 进行记录,并同时对同一类型的BUG 进行归类统计,对于同一类型的BUG 反复出现的情况,必须在每周项目例会上提出来,避免同类问题重复发生.
2. 测试人员
在项目早期就作好充分的测试计划工作. 测试人员在需求分析阶段就应该参与到项目中,测试人员应该与需求分析人员一起去见客户,获取用户需求,只有这样测试人员才能对系统架构和用户需要什么东西有一个更深层次的理解,测试人员在测试的时候就会从用户的角度去测试系统,这样测试出来的软件才更接近用户的需求.
3. PM 测试
在项目开始启动的时候就应该对项目的测试有一个详细的规划,并且在项目执行的全过程中把关好每一个测试环节.
项目中的问题发现的时间越早,对项目的损失就越小,越是到项目后期,发现问题进行解决所带来的代价越大,这点必须引起高度重视(A项目前期测试力度不够,导致后期全面测试时暴露出很多问题).
个人认为好的测试,必须有两个或两个以上的人经过确认,才能说明基本上测试通过. 另外,项目经理不要太过于相信测试结果, PM 最好亲眼看一看测试是否真的如开发人员/测试人员说的已经没有问题了(本人就有亲身经历,当时开发人员保证说测试了很多遍,没有问题,但我要求我在最后审核一遍,结果出问题了),如果时间允许的话,PM最好对所有的测试都看一遍 ,做个最终的确认测试.
4. 代码规范和测试规范
。。。
_______未完，待续______
日期：2007-11-24
在项目管理过程中，总会出现许许多多的好的或者不好的东西，有人说人生如同一个大的项目，在这个过程中，有些人规划的很好，成功了；也有大部分人从来就没有一个很好的规划，所以一直不是很好^__^。
成功的人往往是善于总结的人，如同生活不可能总是一帆风顺一样，项目也会遇到许许多多的问题，但只要我们做好应对措施，问题终归是会解决的。项目中的许多问题，好的或者坏的，都需要我们对它进行总结和思考，在总结经验的同时，我们也在成长。
下面是本人对项目管理的一点总结，下面的内容都是结合以前在网上看到的好的帖子和自己的亲身体会。
由于时间仓促，本文目前还不完整，而且有些词语可能描述不是很准确，在今后的工作和生活中会继续补充和完善。
一．坚持“以人为本”的过程改进的管理思想
我们都知道项目的三要素：进度、成本、质量，项目管理就是综合三方面的因素，在项目进行过程中不断平衡三方面的目标，最终依照目标完成任务。这三个方面是相互制约和影响的，项目经理的工作就是在不断平衡三者之间的关系。
软件界已经达成一个共识：影响软件项目进度、成本、质量的主要因素是“人、过程和技术”，在这三个因素中人是第一位的，其次是过程，然后是技术。
CMM/CMMI 是致力于软件过程改进的，然而许多软件公司在实施CMM/CMMI的过程中沉溺于CMM/CMMI的理论，过于强调“过程”，照搬CMM/CMMI中的理论，没有依据本公司的实际情况进行合适裁减。
CMM/CMMI 主要是致力于软件过程改进的，没有对成本管理进行很好的定义和说明，一个真正的项目经理在进行实际项目管理过程中应该结合CMM/CMMI和PMBOK中的内容进行思考，PMBOK 中提到的五个过程域和九大知识领域的管理是每个成功的项目经理都必须掌握的内容。
做过研发项目管理的人都知道，企业研发管理的指导思想是：结果导向，并且关注过程。
“结果导向”是指：以最终产生的经济效益来衡量研发项目的业绩，追求利益最大化。
“关注过程”是指：将期望的结果分解到每个过程域（即工作环节）去实现，努力把每
项工作做好，从而得到好的结果。一般地，好的过程才可能得到好的产品，而差的过程只会得到差的产品。
然而在关注过程的同时，很多人往往忘却了人的重要性，任何一个项目都离不开人。记得一次出差在火车上有幸与一位企业家聊天时，聊到创业什么最重要的时候，我当时的回答是：找到一个好的项目是最重要的。本以为他也会赞同我的看法，然而他给我的答案是：最重要的是要找到一个优秀的团队，一个有着共同目标的人组成的优秀团队。这件事情已经时隔一年多了，但是他的这句话一直在我脑海中，在这之后的过程中，我一直在思考着这句话，现在我已经体会到这句话的真正意义。
正像那位企业家说的那样，一个好的团队胜过一切，有了好的团队，要找到好的项目并不是难事。曾经有人问过比尔.盖茨。。。
项目成功的关键是人，项目执行过程中主体是人，再好的过程如果没有人去很好的执行也是白费。成功的项目离不开一位成功的项目经理，项目经理在项目执行的过程中会运用正确的项目管理方法来对项目开发过程中的各个过程域进行跟踪和控制，成功的项目经理应该深深懂得“以人为本”重要性，并在项目管理过程中，对项目过程进行不断改进和总结，只有这样才能不断的提高项目管理的质量，才能一次次创造成功项目的神话。
正当各个企业对CMM/CMMI 狂热追求的同时，各种敏捷过程方法论相继被提出，这些方法论的提出从某种意义上说就是对过于强调过程的一种反思。其中“XP”中的“人比过程更重要”的思想是值得我们借鉴和思考的。
项目管理是一个柔性化的管理过程，而柔性管理以“人性化”为标志，关注的是项目中的人，从而可知，“以人为本”的管理思想在项目管理中的重要性。
总之，一个项目的成功离不开人、过程和技术，如何处理这三者之间的关系是项目管理人员必须长期思考的问题。就像我前文中提到的研发管理思想：结果导向并且关注过程，同时技术在软件项目执行过程中也扮演着不可或缺的角色，技术又是由人去学习和掌握的。一个成功的项目离不开一个好的过程，然而再好的过程也要有正确的人去正确的执行，项目经理在项目管理过程中应该坚持“以人为本”并且不断的进行过程改进，强调过程与人的和谐统一。
二. 如何做好项目管理中的进度管理
首先，按照既定的计划执行，并及时进行跟踪与监控项目进度以及项目质量，最好采用多多询问的方式（因为最直接，也最快捷），该方法借鉴了走动式管理的管理思想,该方法一直在使用,经过实际证明,效果很好;
该做法的好处是:
1) 看得见的管理,通过面对面的询问的方式,能够就项目中存在的问题和项目当前的进度进行一个直接的沟通,以最直接和最快捷的方式获取项目当前的信息;
2) 更直接,更快捷的获取当前的项目进展状况及各个队员目前的进度情况 ,便于及时的调整项目计划,同时也为项目的跟踪与控制提供了依据(及时性和真实性);
其次，对项目进度进行全程的实时监控，对于项目中出现的问题及时作出响应和相应的应对措施，并对项目计划进行及时地调整，确保项目按照既定的目标和进度顺利进行；
（项目管理的目标就是。。。）
对于中小型项目(项目组人员在15个以下),可以采取如下的管理方式控制项目进度:
1) 每天早上上班前一个小时内PM 向每一位开发人员询问当前项目进展情况,有什么问题没有解决,估计需要多长时间,让开发人员给出一个时间,然后说明自己期望的时间期限或者项目规定要求的期限,同时询问项目组成员需要需要帮助,对于能够给予的帮助,尽力帮助队员解决;
2) 每天下班前一个小时内,再次询问各个队员的完成情况以及还有那些工作没有完成,原因是什么,需要什么帮忙,未完成的工作估计时间多长等等,做到有问题及时沟通解决;
3) 每周周例会上,项目组成员对各自的负责的部分进行汇报,对于没有完成的工作作出时间估算,本周完成了那些工作,那些工作在时间上有延误,原因是什么,下周的工作安排等等.对于项目中的问题,在会议上分析原因,并尽量在会议上谈论找出解决办法.另外,项目周例会上指派一名人员进行会议记录,会议记录的内容在散会后通过邮件发送到每个团队成员的邮箱.
以上只是对项目进度管理做了小小的总结和描述,在真正的项目管理过程中,有很多方
式可以对项目进行控制,主要看公司的环境和项目的大小等各种因素来选择最适合实际情况的方法.
我们知道，我国医学讲究阴阳平衡，儒家学说讲张弛有度，道家说要无为而治，老外一会说矩阵式管理有效，一会金字塔管理是好方式，再一会走动时管理为之推崇，此外，还有很多说不完的管理方式和名词。
我们究竟要学什么？用什么？教什么？讲什么？解惑什么？
管理技术没有最好，只有最合适，如果脚长得不好，非要怪鞋子，只能说明一个问题：鞋子选错了。就像很多人经常提到的每个人有各自得管理风格和做事作风，不能说谁的好，谁的不好，适合实际环境和实际情况的就是好。IBM 引进IPD取得了成功，于是很多其他企业也开始效仿，孰不知任何一种事物都有其生长的环境，同一种方法放到不同的企业不同的环境会产生不同的效果。
另外,我本人喜欢把重要的事情记录在笔记本的备忘录上,把事情分为重要紧急,重要不紧急,紧急不重要,不重要不紧急,最先做重要紧急的事情,然后大多数时间都在做重要但不紧急的事情.每个人的记忆力是有限的,再好的记忆力都有可能忘记事情的时候,所以我选择了先在纸上记下的方式.养成每天都翻开笔记本看看当前有什么事情需要解决的习惯,时间长了,就成了习惯.
三. 处理客户关系
与客户搞好关系,让客户把我们当作自己人(最近切身体会),对于项目今后的工作有直接的帮助和影响.
多多与客户交流,特别是客户方相关负责人(注意点: 积极主动去找客户交流,前期多花点时间在客户处,在某些情况下可以给客户提供一些帮助和方便. ),要明确告诉客户,项目中有任何问题可以直接找你,让自己成为客户直接联系人,切不可让客户在需要的时候不知道找谁或者找不到我方的负责人,与客户建立好良好的相互信任关系,关系到项目今后阶段的开展.
四. 避免镀金现象的发生
在项目开发过程中,避免镀金现象的发生,不可全部接受用户提出的所有要求(目前本人正在着手的一个项目简称A项目我们去客户那边走访做的很到位,对用户提出的新的修改要求都做了相应的修改. 但我个人认为这并不是最好的方式,多多去客户处走访固然很好,但为了害怕得罪客户,一味的满足客户,并对客户提出的所有要求都答应修改是不明智的做法,这种做法的结果是,我们的开发人员为了修改用户的要求加班加点,客户却感觉是应该的,并没有一点感激的情绪,这是一种典型的吃力不讨好的做法).
项目开发过程中一个很重要的也是很多公司在项目开发过程中经常犯的错误就是项目镀金现象的发生.
需求变化带来的问题
用户的需求永远在变,一味满足用户提出新的要求会给项目带来如下问题:
作为软件开发商，当接到一个项目后，一般的做法是首先由用户提出需求，然后开发商根据用户的需求作出一个系统实现方案，而用户通常并没有实质地理解方案，随即通过了方案，开始了软件的开发工作。根据笔者所开发过的多个系统，开发前期，大多数单位并没有明确的想法，也提不出确切的需求，因为业务人员不了解计算机技术是怎样实现业务流程的。用户总是希望开发单位根据当前的业务流程先做出一个样板来，然后再进行改造，而多数用户认为软件修改很容易。
尽管已经做好了系统规划，签订了功能较明确的合同，然而随着系统分析、系统设计和系统实施的进展，当客户在项目部署后看到真正的软件系统的界面及操作方式，客户的需求就被激发起来，会根据自己的对软件的理解和日常工作的习惯，对软件的处理及操作方式提出修改要求，而这种修改往往比较随意，因此导致开发方需要对流程、界面、以及相关文档经常的大量的修改，这些成为开发方的一个很大的负担，而这种负担对用户基本是看不见的(这种现象在业务型软件项目中尤其突出, A项目在这方面就有很明显的表现)。
在本项目中的一个切身体会是,需求的不断变化,如果不能很好的应对,会导致整个项目的进度和质量都难以控制. 开发人员只是一味的对用户提出的要求进行修改,由于大部分时间都在修改用户的新的要求,导致软件系统本身的稳定性测试时间减少,最终软件经常出现这样那样的问题, 开发人员要开始忙着修改问题, 出现一片混乱的局面, 旧的问题没有修改完,接着又要应对用户提出的频繁改变和增加各种要求.
在项目开展过程中,几乎天天面对用户的需求变更，切身感受到，如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，用户的耐性渐渐消逝，研发人员的士气也越来越低落，最后所有的人都在等待一个结果：项目最好马上结束。
如果不对以上问题加以很好的应对和控制,其直接结果是项目的周期大大超过预期,项目发生亏损或者项目没有达到预期的赢利目标.
一个真正成功的项目是在预期的时间内,高质量的完成项目既定的目标,并且同时项目获得了最大的利润.所以说,项目最终是失败的.
如何应对用户频繁的需求变更
首先,切忌对用户提出的需求拍胸脯，在此之前可以扪心自问：“如果拍了胸脯，以后不能按时完成，我能不能负担全部责任？”这样冷静一下就不会胡乱应承了。
其次,在用户提出新的需求时,我们要对照<<用户需求规格说明书>>,如果该需求不在说明书范围内,需要先估计一下改动所需的工作量的大小以及改动后对原有系统的影响,从而作出相应的应对.
对于一些不合理的要求,我们可以以不在合同范围内为由进行拒绝;
对于一些改动较小,且改完后对原有系统没有影响的需求变动可以给用户修改,但要让用户知道我们为改动需求花费了不少时间,让用户知道我们作出了牺牲;
对于某些改动比较复杂但合理的需求变动,我们应该让用户以文档的形式提交给我们,不要当场拍胸脯,最好的做法是:”您提的这些问题改动很大,我回去把这些情况和其他人商量一下再给您答复”,通情达理的客户都能接受这样的回答;
上面是对于用户频繁的需求变更如何应对,除此之外,我们最好有一套预防用户需求不断变化的方法,比如:采用UI 原型设计法等.
合理拒绝用户不合理的要求,防止项目镀金现象
…
五. 如何把好测试关
1. 开发人员
从项目立项的第一天起,在项目启动动员会上,就要强调每个开发人员对自己开发的模块务必加强测试关,对于开发人员开发完后提交测试人员的成果,一旦测试人员测试出BUG ,必须对所有的BUG 进行记录,并同时对同一类型的BUG 进行归类统计,对于同一类型的BUG 反复出现的情况,必须在每周项目例会上提出来,避免同类问题重复发生.
2. 测试人员
在项目早期就作好充分的测试计划工作. 测试人员在需求分析阶段就应该参与到项目中,测试人员应该与需求分析人员一起去见客户,获取用户需求,只有这样测试人员才能对系统架构和用户需要什么东西有一个更深层次的理解,测试人员在测试的时候就会从用户的角度去测试系统,这样测试出来的软件才更接近用户的需求.
3. PM 测试
在项目开始启动的时候就应该对项目的测试有一个详细的规划,并且在项目执行的全过程中把关好每一个测试环节.
项目中的问题发现的时间越早,对项目的损失就越小,越是到项目后期,发现问题进行解决所带来的代价越大,这点必须引起高度重视(A项目前期测试力度不够,导致后期全面测试时暴露出很多问题).
个人认为好的测试,必须有两个或两个以上的人经过确认,才能说明基本上测试通过. 另外,项目经理不要太过于相信测试结果, PM 最好亲眼看一看测试是否真的如开发人员/测试人员说的已经没有问题了(本人就有亲身经历,当时开发人员保证说测试了很多遍,没有问题,但我要求我在最后审核一遍,结果出问题了),如果时间允许的话,PM最好对所有的测试都看一遍 ,做个最终的确认测试.
4. 代码规范和测试规范
。。。
_______未完，待续______