胡必波+薛春楠

摘要：该文结合项目管理实践经验，围绕“互联网+时间”电商系统项目的范围管理进行论述。首先，简要分析项目范围对项目的意义和进行项目范围管理的主要过程。然后，详细地介绍了我们在项目实践中遇到工作分解结构过于细化，范围确认客户不配合、控制范围时产生范围蔓延等问题逐一化解，最终项目成功上线。最后对项目范围管理中几点不足作了总结。

关键词：范围管理；WBS；确认范围；控制范围

中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2017）28-0284-01

共享经济时代，各种社会闲散资源正在得到有效利用。当你有一技之长或任何兴趣爱好，你可以将你的技能、兴趣明码标价按照时间来收费，这就是时间电商的概念。伴随移动互联网技术的发展，这种基于互联网+时间电商商业模式的第三类产业服务类O2O交易平台逐渐兴起，市场潜力预计有上千亿元的规模。

本系统是由某市信息技术有限公司发起的以“兴趣共享”为核心内容，涉及250多个职业分类，汇集5万多提供个性化服务跨界达人的大型时间电商交易平台。该系统采用云计算集群架构，可承载千万级应用，具有实时份、高并发、高安全、平滑升级、永不掉线等特性。线上通过PC、微信、App等多个终端实现全网接触，商家需要进行实名认证，交易双方资金由平台托管保障，线下扫码确认完成交易。系统提供商家各类职业技能发布服务，同时，还有评价系统、投诉系统，类似淘宝的卖卖评论系统。

项目管理的“三项约束”范围、时间和成本中，，项目范围影响是很重要的，直接影响到项目时间和项目成本。为了控制项目按既定的时间、成本、质量完成项目目标，必须严格执行项目范围管理，它包括确保项目做且只做成功完成项目所需的全部工作的各过程，定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内。项目范围管理过程包括规划范围管理、收集需求、定义范围、创建工作分解结构、确认范围和控制范围。

面对互联网+时间电商交易平台系统这样建设周期长、干系人众多、业务范围涉及面广，业务模式不统一的创业型项目，我作为项目经理，针对项目实施中遇到的：工作分解结构过于细化、范围确认客户不配合、控制范围产生范围蔓延等问题，一一化解。由于篇幅所限，本文就创建WBS，范围确认和范围控制结合实践进行具体论述。

1 创建详细工作分解结构

我们首先邀请公司相关领域的专家帮助，使用MSProject2013作为项目管理工具，采用三层WBS结构。PC、微信、App三个子系统作为WBS第一层；每个子系统的功能模块作为WBS第二层，如PC网站包括：用户模块、商家模块、网站管理模块；以每个功能模块的功能点作为WBS第三层，同时对WBS的每个任务明确了其可交付物。

由于系统涉及250多个职业分类，汇集5万多个性化服务，WBS的分解粒度细化控制比较困难。我们组织项目组成员充分讨论，依据范围管理计划、项目范围说明书、需求文件等，将复杂的工作包大小控制在80小时内，每个任务都细化到每个人一周内可完成，保证每项任务都是可控的。同时制定完善的WBS字典，范围变更计划及规程、项目核实标准。详细项目范围说明书和范围基准完成后，提交业务主管部门，经检查和审核后确认，多方进行签字确认，由项目组和业务管理单位共同实施。

2 与客户紧密合作，确认项目范围

作为承建方在项目每个阶段末，自然希望客户尽快确认项目可交付成果，以便开展后续相关工作。但客户对项目可交付成果进行检查、度量、核实时，总会有这样或那样的疑虑和想法。

例如在项目的某个阶段末客户检查某次可交付成果后认为，原有的商家发布服务方式中服务时间设置不够灵活只有单一时间模式可以选择，提出应修改为服务有效期、固定服务时间、服务需预约等三种方式才能签字接受。我们首先查阅项目管理计划、需求文件、需求跟踪矩阵表等文件发现之前定义的项目范围并不包含这一客户要求。然后我们与客户进行良好沟通，告诉他们，尤其是客户业务运营领导，确认范围虽然是正式的，但并不意味着项目范围不可更改，只是无论是现在还是将来更改范围，都会引起项目的时间、进度和资源的变化。客户也接受我们建议将这一范围外计划放到下一期项目进行，同意在“需求确认单”签字留档。最后我们也以此作为依据，继续进入阶段收尾过程。直到完成项目所有阶段性成果的确认后，项目核实活动才算结束。

3 项目范围跟踪控制，避免范围蔓延风险

控制范围主要是监控项目范围状态、管理范围基准变更的过程。引起项目范围变更常见的原因有项目外部环境发生变化、范围计划不周密详细，由错误或遗漏、市场上出现了或是设计人员提出新技术、新手段或方案、项目实施组织本身发生变化、客户对项目产品或服务的要求发生变化等。未得到控制的变更通常被称为项目范围蔓延，它是项目失败的原因之一。

如本项目在实施过程中客户的业务运营部门的领导换了，原来的领导认可的东西，现任领导觉得不好，还需要增加用户兴趣爱好分享社区功能，并认为只需要增加少量的费用即可。我们很担心按照这样下去什幺时候项目才能够结束。本来计划四月份就结束的工作，项目已经拖延了一个月。这一范围变更是项目进展过程中所意料不到的。计划改变了，人事也重新安排了。为了做出决策，我依据项目管理计划、需求文件、需求跟踪矩阵、工作绩效数据，经过偏差分析并计算了这一变更所需的真实费用，列出了与这一变更申请相关的分解细目及全部成本，是原预计的两倍有余。在得出项目所需的时间以及投入的精确估算后，经过沟通后，客户最终采纳了我们建议，取消变更请求，同意将有限资源运用在项目主要需求上，避免了项目范围蔓延风险。

4 结论

在多方领导关怀下项目团队团结协作，克服种种困难，如期完成项目。经客户验收，产品符合质量标准，获得客户好评。回顾该项目的范围管理过程，仍有不足之处。项目实施过程中由于不断添加额外的工作而并不经过仔细的考虑，导致超出预算，延误工期。这也提醒我们项目的渐进明细一定要在项目的边界之内进行，以避免渐进明细演变成范围潜变。项目团队个别成员为了讨好客户、擅自承诺、送人情、好大喜功或者追求尽善尽美，干了许多不该自己干的活。我们应向团队成员提倡给客户提供你答应提供的东西，而不要多提供一些额外的东西，从而避免镀金的产生。

参考文献：

[1] 朱少民，韩莹等.软件项目管理 [M]. 2版.北京：人民邮电出版社，2015.

[2] 王雪峰. 浅谈IT项目范围管理[J]. 项目管理技术，2016（11）：66-68

[3] 刘荣杰.论信息系统项目范围管理[J]. 信息技术与信息化，2015（8）：140-142.