工作说明书 (SOW):拯救你和你的项目
在一个美好的蓝色星期一早晨,客户给你发了一封邮件,要求紧急视频通话。你作为一名优秀的项目经理,始终将项目进度状态和其他所有细节掌握在手。因此,毫不犹豫地,你接通了视频通话,并开始与客户讨论。
在你们最初的寒暄过后,客户突然抱怨说你的方向错了。他查看了你昨天在第一阶段结束时发布的应用程序,并且非常失望,因为最初他提到的需求与你开发的需求不符。此外,他还对项目的预算和交付时间提出了质疑。
你现在陷入困境,这是一个典型的两难境地。你知道项目正在按照最初与合作伙伴讨论中记录的需求进行。所有需求都已妥善记录并保存在项目资源库中。
由于你拥有所有需求文档,因此毫不犹豫地声称项目正在朝着正确的方向发展,并向客户展示了这些文档。但令你惊讶的是,他断然否认这些需求是他提供的。什么?!他怎么可能否认?你知道这些需求是他提供的,你的业务分析师也很好地记录了它们。
你现在该怎么办?任何事情都可能发生。你无法让合作伙伴相信你的话。也许他会相信你,或者你需要根据他提出的更改来修改应用程序,这将抹去迄今为止完成的所有工作,从而可能使你的项目脱轨/延期。而且,如果你不同意他,你的项目可能会被取消。
那么,为什么会发生这种情况?问题出在哪里?你拥有所有证明的文件,但他却不愿意相信你。为什么?因为合作伙伴在提供需求时没有签署这些文档。他没有正式签署。在这里,工作说明书 (SOW)的重要性就体现出来了,它可以避免这种情况在最初就发生。
工作说明书 (SOW) 是一份正式文件,描述了项目中需要完成的工作范围。这是一份正式文件,陈述了所有各方共同商定的需求和可接受的交付成果。最重要的是,这份文件由双方的指定代表正式签署。
工作说明书包括:
- 工作范围
- 交付成果及其交付日期
- 商定的验收标准
- 项目成本和付款计划
正如我们所讨论的,工作说明书的重要性与目的,让我们看看模板,它是什么样子的
工作说明书 (SOW) 模板
引言
提供项目背景的一般信息。项目的目的是什么以及项目最终的收益。
例如:
ABC 手机集团计划在其成功的“GoGO”应用程序基础上构建一个新的应用程序。需要对现有的游戏平台进行升级,以达到新的水平。它将更加用户友好,并提供丰富的图形以增强用户体验。ABC 手机集团寻求将新级别的完整开发、测试和实施外包。他们期望新增的功能将增加其市场份额,以及公司的收入。
范围
在本节中,你需要提供项目范围。详细的需求可以在“需求”部分中说明,在这里我们需要说明什么在范围内,什么不在范围内。
例如:
- 包含在范围内的:
- 需要完成的设计工作
- 应用程序的开发和测试
- 在预生产环境中实施
- 在生产环境中实施
- 不在范围内的:
- 生产后,ABC 手机集团内部团队将负责未来的维护工作
工作地点
在这里,你应该说明要执行的工作地点。在某些情况下,客户可能会坚持在其场所的实时环境中执行测试阶段。因此,你需要根据双方商定的内容详细说明这些内容。
例如:
- 设计和开发阶段将在位于印度海德拉巴的 XYZ 软件公司场所进行。
- 测试阶段应由 XYZ 软件公司的测试工程师执行,但在位于美国弗吉尼亚州的 ABC 手机集团办事处进行。
需求
在本节中,我们需要详细说明实际工作,这将需要成功完成项目。本节需要尽一切努力尽可能详细地包含所有内容。
例如:
- 项目启动
- 应进行正式审查和演练流程
- 计划阶段
- 项目计划、测试计划和其他文件应由供应商准备,并由买方审查。最后,获得批准。
- 设计阶段
- 新级别的设计应由合作伙伴审查和批准
- 开发阶段
- 编码应根据批准的设计架构进行
时间表
在这里,我们需要提供每个交付成果和重要里程碑的分阶段时间表。日期应在所有各方达成一致后说明,所有利益相关方都应遵守这些日期。
例如:
- SOW 签署:2016 年 8 月 25 日
- 项目启动:2016 年 9 月 10 日
- 设计阶段审查:2016 年 10 月 1 日
- 开发工作开始于:2016 年 10 月 15 日
验收标准
在本节中,我们需要提供合作伙伴可接受的交付成果状态。它应包括阶段/工作何时可接受的描述以及代表公司授权和接受工作的授权人员的详细信息。
例如:
- 设计阶段将由 ABC 手机集团的架构师总监审查和接受
- 在开始实际开发工作之前,应交付原型
- 第一阶段的发布应包含发布清单和所有相关文档
合同模式
供应商和买方之间存在不同的合同执行模式。有些是固定报价项目,成本是固定的,而有些是时间和材料合同,成本按小时或按单位支付。在所有各方达成一致后,应清楚地说明合同模式。
例如:
这是一份时间和材料合同,成本应根据参与项目的工程师的费率和他们在项目中工作的小时数来计算。
里程碑付款
本节包括付款计划的详细信息,如果是分阶段或里程碑式付款项目。付款方式、发票日期和频率也应在此处说明。
工作说明书应始终清晰简洁,并为所有相关各方理解。它被视为服务购买方和服务提供方之间的正式协议,并且可用于解决项目生命周期中可能出现的任何争议。因此,在准备时要特别注意,仔细说明我们在本文中讨论的每个部分的详细信息。