如何组织一个全方位的软件项目工作任务说明书

栏目: 数据库 · 发布时间: 7年前

内容简介:如何组织一个全方位的软件项目工作任务说明书

SOW的重要性

作为一个在软件服务行业工作了15年以上的老人,过去这么多年碰到的坑那是数都数不过来。

凯哥实施过SAP这样的套装软件,开发过业务系统,技术平台等,可以讲,没有一个项目不扯皮的。不论你和甲方的客户关系多好,不论这个项目的范围多么的清晰,都会碰到纠缠不清,双方理解不一致的情况。在这种情况下怎么办?

当然,作为乙方,服务至上,我们晓之以情,动之以理,能够接受忍让的范围也就辛苦一下加加班就过去了,但是如果需求变化很大,工作量增加很多,而且似乎甲方也没有意识到这一点,那该怎么办?

亲兄弟,明算账。为了在合作中能够减少摩擦,降低内耗,大家一起朝共同的业务目标,系统上线努力,在项目启动前,双方本着协作共赢的态度,花时间好好梳理一个共同认可的SOW是非常重要的,凯哥曾经跟很多项目经理说过,“SOW基本上决定了这个项目的一半的成败”。当然,很多同学可能会说,SOW毕竟是法律层面的东西,是合作的底线,双方尽可能都不会让一个项目走到拿合同和SOW对质的份上。

的确,到现在为止,凯哥负责实施的项目很少有碰到双方拿出SO来对质的场景。但是,恰恰是因为在前期花了很多时间,精心的准备了SOW,所以才能够避免这样场景的发生,因为其实编写SOW的过程是对项目管理人员一个预演的过程,这个过程,非常考验项目经理的全方位周到的思考能力。

一个好的SOW的编写过程就是项目管理人员对整个项目从前提条件、项目范围、准备工作,实施过程,变更应对,风险管理,里程碑,验收条款,付款阶段等关键信息的梳理和预测,充分体现了项目管理的能力。

好的SOW的构成要素

SOW是什么?

维基百科的解释: A Statement of Work (SOW) is a document routinely employed in the field of project management. It defines project-specific activities, deliverables and timelines for a vendor providing services to the client.

一般来说,工作任务说明书是作为商务合同的附属文件,与合同一起构成一个完整的项目交易约定。

下面这张图,是项目管理的主要内容,而SOW要尽可能的把这些内容都想的全面,都包含进来,想的越仔细,到后面可能出现问题就越好应对。

如何组织一个全方位的软件项目工作任务说明书

下面我们用一个常见的数据仓库报表系统的项目作为例子,挨个来说明。

项目背景

我们为一个能源集团定制一个数据仓库报表系统,基于一个商业软件进行定制化开发,项目分三阶段上线,全集团一级子公司使用。

1. 范围

项目范围是SOW中,最重要的部分,直接决定了这个项目的实施内容。但是很多时候,我们只考虑了软件实施项目本身的工作范围,而对于其他的范围考虑不够。

一般来讲,我们所指的范围包括:

  • 组织范围
  • 这个项目的用户应用范围,这个范围直接会影响推广、培训的工作量。

比如,这个项目我们的组织范围就是该能源集团的一级子公司。除了注明一级子公司外,最好把子公司的名称都列上,这样的好处是,万一在项目实施过程中,客户的组织结构发生了变化,我们就可以提出项目变更。

工作范围

这是项目实施的工作范围,也就是工作内容,具体做什么,这部分的内容越细致描述的越清晰越好,并且一定要和客户一起挨个对一遍,这样双方在前期达成工作的一致。

这里的工作范围要把项目实施的关键过程内容要注明,在可能的情况下,最好把每个关键工作内容结束后的交付件样例贴在后面,从而从颗粒度上进行控制。

在描述工作范围的同时,如果有需要甲方配合的情况,也必须重点注明出来,从而清楚的制定出分工界面,降低交付风险

比如,这个数据仓库项目的工作范围里需求分析部分的SOW可以这样写:

需求分析 在甲方的全力配合协助下,完成本数据仓库的需求分析,需求分析文档的样例见附件三。 甲方的权利配合协助包括但不限于:

  1. 按照项目需要安排对应的业务人员参与需求调研,提供真实全面的信息,并且进行签字确认 …...

2. 质量

作为软件实施项目,交付质量在SOW中的定义一般体现在交付成果和验收中。

比如,拿这个数据仓库项目的例子来说,交付成果验收包括:

如何组织一个全方位的软件项目工作任务说明书

验收流程:一般来说是乙方书面提出验收申请,然后甲方组织专家进行评审,都是这样的类似的流程描述。

验收标准。本数据仓库系统需要满足如下指标:

  • 性能指标
  • 易用性指标 …..

这里的验收标准一般来说定义的越模糊越好,因为项目的过程可能会发生变化,但是验收的流程要定义清晰。

3. 进度

进度,在SOW中,会以项目计划来体现。

比如这个项目我们会这么描述计划:

本项目计划于XXXX年X月X日启动,工作计划如下图所示。本计划所列出的各阶段工作可以在项目建设过程中并行开展或双方协商达成的一致进行适当调整,但双方需对调整所产生的影响进行评 估,并通过项目变更管理流程处理。

一般来说,我们会在项目计划中,加入关键里程碑节点。这个主要目的是将一个项目分成几个关键阶段,让用户配合我们阶段确认成果,从而保证最终成果的成功确认,将风险降低,同时也可以将付款分阶段按照关键里程碑来走。

4. 成本

在SOW中,一般不会体现成本,但是在项目组织结构和计划中,会侧面有体现。项目管理人员,需要在项目启动前制定好各个阶段的项目组织,团队成员。根据这里的团队成员,就侧面体现了项目的人力资源及成本的投入情况。

5. 集成

很多的软件实施项目,会面临与其他软硬件系统的集成工作,这也是最容易扯皮和出问题的地方,往往因为第三方的准备工作不到位,导致我方项目组处于等待状态,浪费工期浪费资源。

  • 分工界面
  • 约束条件
  • 承接顺序
  • 违约条款

6. 沟通

作为实施项目,能否高效的沟通,是项目成功的关键因素,高效的沟通需要非常缜密的组织,需要甲方对于项目的重视。

所以在凯哥以前实施的大一点的项目组里,一般都会有个推进组,就是专门从事宣传和沟通管理的。而在工作任务说明书中,也要将沟通方式作为重要的内容提出来。

一般会约定以下的沟通管理方式:

  • 会议管理
    约定周会、协调会的召开办法,参与人,会议内容等,确保甲方对应的关键资源能够按时参加对应的会议。
  • 确认沟通
    对于有多个业务条线或者多个组的实施项目,在沟通管理中要确认甲方对应的负责人,从而保证沟通的内容是有效的,是可以代表甲方的。

7. 风险

风险管理,在SOW中随处都要主要到。比如在前面会有一章叫项目前提:

  • 一般前提
  • 项目管理前提
  • 项目范围前提
  • 服务实施前提

8. 变更

项目实施的过程中,变更是常态,但是如何让甲方接受这是个变更而不是因为我们的原因做错了,这就是在变更管理重要重点体现的内容。一般我们会有一个章节,叫变更管理,就是定义清楚什么样的情况是变更,如何管理变更,从而把变更作为一个常态的工作。

一般来说,变更对应的是工作范围,如:

任何超出本项目工作说明书第三章约定工作范围的工作内容,均可视为项目变更。

然后在这个章节中,定义出变更评估,变更批准和执行的过程。

9. 资源

在SOW中,那些对于项目实施有着关键影响作用的资源,如资产,信息,数据等,我们把它叫做项目实施的资源,这些资源会体现在项目前提,项目范围中。

10. 付款

作为合同的关键附件,付款条款是SOW中最重要的内容。包括付款的时间、方式、违约条款等。

一个典型的SOW模板

下面我们用这个数据仓库的真实的SOW模板作为样例来具体看一下:

1)项目背景

2)项目范围

  • 2.1 组织范围
  • 2.2 任务范围
    • 2.2.1 商务智能(BI)总体设计
    • 2.2.2 业务设计
    • 2.2.3 数据设计
    • 2.2.4 数据展现实施
    • 2.2.5 数据集成实施
    • 2.2.6 手工录入平台实施

3)项目原则及前提

  • 3.1 项目原则
    • 3.1.1 一般性指导原则
    • 3.1.2 “沉默即确认”原则
  • 3.2 项目前提

4)项目总体工作计划与组织

  • 4.1 项目总体计划
  • 4.2 项目组织
    • 4.2.1 项目组织结构
    • 4.2.2 各小组职责定义
    • 4.2.3 乙方核心成员职责定义
    • 4.2.4 甲方投入人员要求

5)项目工作方法

  • 5.1 项目实施方案
    • 5.1.1 前期准备
    • 5.1.2 现状与需求调研分析
    • 5.1.3 商务智能(BI)总体设计
    • 5.1.4 业务设计
    • 5.1.5 数据设计
    • 5.1.6 数据展现开发
    • 5.1.7 数据集成开发
    • 5.1.8 手工录入平台开发
    • 5.1.9 测试
    • 5.1.10 部署上线试运行
  • 5.2 质量保证措施

6)项目交付成果与验收

  • 6.1 项目交付成果
    • 6.1.1 交付成果及交付成果内容描述
    • 6.1.2 交付成果验收
    • 6.1.3 交付成果管理
  • 6.2 验收方案
    • 6.2.1 验收方式
    • 6.2.2 验收流程
      - 6.2.2.1   初步验收流程
      - 6.2.2.2   最终验收具体流程
    • 6.2.3 验收标准
      - 6.2.3.1   初步验收标准
      - 6.2.3.2   最终验收标准
    • 6.2.4 验收地点
    • 6.2.5 验收组织

7)项目培训与支持

  • 7.1 培训实施计划
  • 7.2 服务承诺
    • 7.2.1 时间安排
    • 7.2.2 支持团队
    • 7.2.3 试运行期现场支持服务内容
    • 7.2.4 质保服务期支持方式

8)其他

实录:《凯哥:工作任务说明书实战解析》

如何组织一个全方位的软件项目工作任务说明书

如何组织一个全方位的软件项目工作任务说明书


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

精通CSS

精通CSS

Andy Budd / 陈剑瓯 / 人民邮电出版社 / 2006 / 39.00

本书将最有用的CSS技术汇总在一起,在介绍基本的CSS概念和最佳实践之后,讨论了核心的CSS技术,例如图像、链接、列表操纵、表单设计、数据表格设计以及纯CSS布局。每一章内容由浅入深,直到建立比较复杂的示例。之后本书用两章讨论招数、过滤器、bug和bug修复,最后由Simon Collison和Cameron Moll两位杰出的CSS设计人员,将书中讨论的许多技术组合起来,给出了两个实例研究。本书......一起来看看 《精通CSS》 这本书的介绍吧!

MD5 加密
MD5 加密

MD5 加密工具

SHA 加密
SHA 加密

SHA 加密工具

XML 在线格式化
XML 在线格式化

在线 XML 格式化压缩工具