|
范围管理主要贯穿于整个项目的生命周期，包括需求、编码、单项工作要求和可交付成果，从而促使项目工作成功的完成。实际上，这里涉及到一个“范围管理”的概念。项目中哪些该做，哪些不该做，做到什么程度，都是由“范围管理”来决定的。范围管理的概念包括两方面，一个是产品范围，即产品或服务所包含的特征或功能，另一个是项目范围，即为交付具有规定特征和功能的产品或服务所必须完成的工作。我认为项目管理中的范围管理是最主要的一步。
接下来我就谈一谈曾在项目管理中，遇到关于范围管理的问题：
一、收集需求
收集需求就是为实现项目目标而定义并记录干系人的需求的过程。仔细掌握和管理项目需求，对促进项目成功具有重要作用。需求是指发起人、客户和其他干系人的已量化且记录下来的需要与期望。项目一旦开始，就应该足够详细地探明、分析和记录这些需求，以便日后进行测量。收集需求旨在定义和管理客户期望。需求是工作分解结构的基础。成本、进度和质量规划也都要在这些需求的基础上进行。需求开发始于对项目章程和干系人登记册中相关信息的分析。
通过与客户相关干系人交流后，产生的需求都记录在案生成需求文件，由于每次交流的内容的不同，同时为了方便管理这些需求，我们利用两个文档来实现，分别为需求管理计划和需求跟踪矩阵，每次与客户交流的内容是通过需求管理计划来管理，每次需求采集和需求的变更是通过需求跟踪矩阵记录在案，为以后项目遇到问题时，便于查看遇到问题的阶段。
但收集需求遇到的问题有，其一，客户不配合我们了解需求；其二，需求是我们主观的去收集；其三，收集需求期间客户错误引导需求方向。以上三个问题最后都会产生系统做出原型后，满足不了客户的需求，对于我们也会产生很大的工作量和成本。为避免这样的后果产生，我建议在收集需求时，最好让直接干系人和高层参与，高层不能每次都参与时，在每次收集需求时，也得让高层知道情况，这样会增加客户的重视程度，直到需求采集完成。
二、范围定义
曾有这样情况的客户，客户方的信息化很差，想把他们现在的日常工作做成信息化系统来提高办事效率，具体开展工作的情况如下：
第一，对客户的日常工作做出了调研，在这同时还做出整个系统DEMO供他们参考。给客户看后，客户口头上同意这样来开发，并且说等到真的系统开发出来后，他们再看看具体的情况，有业务上的不满足时，我们再来做调整。
第二，系统开发开始了，经过半年多的开发时间，信息系统成型了。在第一次系统演示时，客户只是提出了一些页面的问题，在场的同事都很高兴。第二次系统演示时，客户的大批领导来观看，当场就对我们开发的系统提出了质疑，说出了他们的业务不是这样，也满足不了现在工作的需要，一定要修改。当时我方无话可说，只好把客户方的领导反馈信息记录在案。
具体细节不谈了，这个项目反复工作就这样开始了，反复的次数都数不清了，直到项目结束时，总结经验教训时，具体了解到本项目周期为一年，现在是两年才把项目结束。
为了避免以上问题的发生，最好在范围定义完成后，我们整理出相应的文档，让客户方再书面签字确认，并且让双方的高层和直接干系人了解此事情，在商务合同上也可以把此项列入相关项当中，如出现以上问题时，我们也可列出依据给客户参考。
三、需求变更
]项目情况是这样地，在项目前期的工作都很顺利，比如：需求调研和用户需求说明书的签字。就这样在一个半月后，项目进入了开发阶段。等系统开发完成一个流程时，第一次去客户现场进行系统演示时，客户就提出了没有满足他们需求，也不能满足他们现在的业务需要，我们就开始针对客户提出不满足需求的方面进行反复修改，这样的反复工作直到把整个系统开发完成后，在最终验收时，客户方领导又对整个系统提出了翻天覆地的变化，针对我方来说是需求变更是需要付钱的，但是客户说是我们的开发没有满足他们的需要。高层们也更加关注此项目了，进行了一轮商务上的谈判，最终结果是跟客户重新开发系统，直到客户满意为止，在此我说一句：“兄弟们好辛苦啊”！
需求变更在项目中是不可避免地，但变更的东西跟以前项目范围定义时，完成不一致，或是根本就是新增的需求，客户也不认为是需求变更或新增需求，只是说系统应该满足此要求。前提是有完善的项目范围定义，为避免此问题必须在商务合同上可以把此项列入相关项当中，如出现此问题时，我们应该遵从什么方案来实施项目。
从以上问题，我在作项目总结时:
第一，项目的范围定义要明确；
第二，项目范围变更要明确并记录在案；
第三，开发之前必须要让所有干系人知道（包括双方的高层），得到需求与demo确认的书面文件；
第四，在商务合同中添加防止以上问题的相关附加条款。再进行接下来的工作。
来源：http://www.pmsalon.net/viewthread.php?tid=6624 | 
收藏
分享
有用
无用