项目描述怎么写_范例食品雪花酥，项目描述怎么写范例？

「综合知识-概念解析」项目范围说明书（一）

二、项目核心文档——项目范围说明书

项目范围说明书（Project Scope Statement），是项目最核心、最基础的文档之一。

它是定义范围管理过程的核心输出，也是后期众多项目计划领域管理过程的重要输入。

项目范围说明书，最核心的作用，就是划分清楚项目工作的边界，具体又可以分为对客户的承诺和对责（自）任（己）的明（保）确（护）。

教程中对项目范围说明书文档有专题介绍，但缺少基于特定项目案例的连贯性示例，不利于缺乏实际项目管理经验的考生理解。

本文以大型企业信息门户升级项目为背景（「论文写作-范文示例」进度管理-信息门户），详细举例介绍一下该文档的组成部分，以及相互之间的逻辑关系。

2、验收标准

针对第一部分描述的产品范围，在项目结束时，最终需要客户方进行验收。而验收的过程与标准，则需要甲乙双方达成一致。

这一部分内容就是尽可能清晰描述产品与服务必须满足的验收条件，并定义与之相对应的验收过程。

与本项目相关的验收内容，至少包括：

• 功能页面验收：主要描述系统功能页面在什么情况下，即可被视为达到项目要求。例如：正式上线后，连续15个工作日内，没有收到用户访问页面异常的报告。
• 响应性能验收：主要描述系统性能达到什么标准可被视为达到项目要求。例如：在连续三个周一或小长假节后第一个工作日8点到9点，业务高峰时段，各类页面响应速度不低于产品范围描述中规定的指标。
• 浏览器兼容性验收：主要描述系统在浏览器中的访问效果达到何种标准被视为满足项目要求。例如：不同的浏览器访问不同的典型页面（登录页、内嵌页、自开发页等，需要提前在此部分定义）时，静态色彩展示一致、动态切换效果一致等。
• 屏幕分辨率适用性验收：主要描述系统在各个屏幕分辨率条件下的访问效果达到何种标准被视为满足项目要求。例如：在规定的各种屏幕分辨率下，系统展示典型页面能够自适应缩放，不能出现显示内容不全、底部有横向滚动条或存在灰白边框等异常情况。
• 系统容灾验收：主要描述如何对系统的高可用性是否达到项目要求进行验收。例如：对于请求转发服务器、应用服务器、数据库服务器、中间件服务器进行典型的故障模拟与恢复演练，相关指标达到产品范围描述的要求。
• 知识转移验收：主要描述如何对系统培训内容进行验收。例如：项目要对用户进行远程集中视频培训，培训材料要录屏形成后期可自学的视频材料；项目要对后台管理员进行系统配置类培训；项目要对后期系统IT运维人员进行技术培训等。
• 项目文档验收：主要描述项目实施过程产生的文档必须要达到哪些条件。例如：最终确认版本的方案文档必须是WORD形式，不能是PPT；文档格式要符合客户方提供的文档模板要求；文档分类要符合客户方提供的目录结构（立项文档、调研文档、方案文档、项目计划文档、开发文档、测试文档、运维文档、上线初始化文档、培训文档等）要求。

3、可交付成果

对于客户而言，信息化项目的验收，是产品与服务正式投入使用的重要标志，是一个新阶段的开始。

客户必须对本期项目所提供的产品与服务结果保留尽可能完整的、正式的文档资料，才能在后期的系统运行运维以及迭代升级过程中遇到的问题进行分析与处理。

这一部分内容就是要定义所有重要的需要向客户交付的成果。这些成果除了产品与服务本身，也包括与项目管理工作相关的其他辅助成果。

与本项目相关的可交付成果，至少包括：

• 可正常运行的信息系统：主要是指最终交付的无差错、可稳定运行的生产环境新版企业信息门户系统。
• 为客户定制开发的源代码：主要是指自定义开发的源代码程序。通常情况下，合同会约定为客户定制开发的代码，知识产权归属客户所有。这部分代码是最终交付成果的重要组成部分。
• 项目功能类文档：主要是指与产品与服务本身相关的文档。例如：需求调研报告、业务解决方案、技术架构方案、网络架构方案、压力测试方案、压力测试报告、技术开发文档、系统应急演练报告等。
• 项目管理类文档：主要是指与项目实施过程有关的文档。例如：项目计划、会议纪要、项目汇报材料、培训签到表、系统培训视频、数据收集与初始化方案、上线策略与计划、上线问题列表、安全漏洞修复前后的渗透测试报告等；
• 后期运维类文档：主要是指后期系统进入正常运维阶段所需的文档。例如：系统正常启停操作手册、服务器安装配置手册、系统应用安装配置手册、系统日常运维手册、系统用户管理手册、系统日志管理手册、系统备份与恢复管理手册等；

4、项目的除外责任

正所谓“隔行与隔山”。从逻辑上讲，任何人不能认为在“产品范围描述”中没有提及的内容就一定不能做。此外，对于“产品范围描述”提及的内容描述本身，在项目组与干系人之间，不同的干系人之间也有不同的理解，容易产生偏差。

这些理解上的偏差恰恰是后期项目管理和验收过程中最容易引发纠纷的地方。

对于一个项目而言，细致定义项目不能做什么与项目能做什么同等重要，在特定场景下，甚至可以说更重要。

这一部分内容就是明确向客户澄清哪些工作不属于本期项目范围，是项目组底线原则的重要组成部分，也是管理干系人期望的重要抓手。

本项目相关的除外责任至少包括：

• 项目升级仅负责对接原系统已经对接的外围系统，新系统的接入不在本次项目范围内；
• 项目对于用户的需求仅负责门户系统的开发，需求涉及的门户内嵌其他系统的调整开发，由客户方负责与其他系统另行协调沟通；
• 项目仅提供企业内部信息的发布与展示功能。信息本身的合法与合规性，由客户全权负责；

5、制约因素

项目在实施过程中必定要遵循一些基本的客观存在或主观要求的硬性边界条件，例如特定的预算成本与实施周期等。

在此之外，基于前述定义的要“做什么”和“不做什么”的范围清单，项目还会产生一些特定的、仅与该项目特点有关的边界条件。这些边界条件也可以视作项目实施的红线。

这一部分内容就是要识别并详细定义出上述两种红线，为后续各类项目计划的制定提供边界约束。

本项目相关的制约因素至少包括：

• 系统必须兼容IE10和IE11浏览器的正常访问；
• 项目必须于12月1日之前上线试运行；
• 项目制定技术方案时，生产环境运行所需的服务器不能多于6台；
• 项目所有服务器日志必须有定期清理机制，而且保留的日志不能少于180天（满足国家相关法律法规要求「考试纵论-政策解读」信息系统网络安全管理义务）；
• 项目必须驻场业务调研、制定方案与开发测试，不得远程开展；
• 项目必须经过客户方认可的第三方安全公司渗透测试，并对所有漏洞进行修复，才允许上线试运行；

6、假设条件

在项目实施过程中，需要很多外部资源配合完成，包括各类软硬件平台、网络接入条件、系统用户基本能力等。

这些资源往往不是项目组人员从无到有，采购、搭建、安装、调试、培训出来的。诸如此类项目实施的外部基础因素，构成了项目的假设条件。

这些外部条件，不需要提前验证，即可视为是存在、正确、真实的，而且在项目需要时，在明确的时间内可以协调到位。

本项目相关的假设条件至少包括：

• 客户方能够在项目组正式提出申请后，14个工作日内提供所需的服务器资源；
• 客户方能够提供项目所需的互联网访问入口资源，包括域名、公网IP地址、外网WAF防护设备、外网DMZ主机设备等；
• 客户方能够协调外围系统供应商参与门户系统集成的联合测试，并及时处理各自系统的问题；
• 客户方在确认系统备份方案后，能够提供与该方案执行所匹配的存储资源；

最后需要说明的是：

• 以上内容只是粗线条地勾勒出范围说明书的轮廓，实际完整文档涉及大量的图表和细节描述，无法在本文中展开；
• 企业信息门户只是一个日常办公系统，涉及的业务环节少，通用性强。对于各行业内的特色业务管理系统，范围说明书内容会更复杂、更专业，涉及许多正向和逆向的业务流程处理等；
• 以上示例仅用于说明范围说明书的结构与主体内容，不能被理解为是完整的文档。

三、论文写作素材——范围管理

范围管理是信息化项目管理的基本也是核心管理领域之一。范围蔓延长期位居信息化项目失败原因的TOP3。

项目范围说明书是项目经理管理项目的总抓手，是一切计划与变更的依据。

因此，在项目范围管理的论文写作过程中，考生可以紧紧围绕范围说明书文档，先依托背景项目简单举例论述需求调研与定义范围，再以此例为基础，论述WBS的分解、范围变更等其他内容。这种写作方式能够让论文读起来更加真实而顺畅。