项目管理白皮书讨论稿v.docx
- 文档编号:25506735
- 上传时间:2023-06-09
- 格式:DOCX
- 页数:86
- 大小:695.13KB
项目管理白皮书讨论稿v.docx
《项目管理白皮书讨论稿v.docx》由会员分享,可在线阅读,更多相关《项目管理白皮书讨论稿v.docx(86页珍藏版)》请在冰豆网上搜索。
项目管理白皮书讨论稿v
项目管理白皮书
V1.0
北京阳光伟业科技发展有限公司
2012年7月
文档版本变更记录
版本号
说明
变更人
日期
1.0
初稿
展涛
2012.7
当前版本变更内容说明
章节
变更描述
变更人
1项目管理思路
1.1关于本白皮书
本白皮书是根据公司现有项目管理实践和通用项目管理思想结合,经过多次讨论落实到文字的公司项目管理体系的说明。
本白皮书由PMO编写,经项目管理委员会授权、审核和发布。
1.2目标:
确立项目管理体系
项目管理体系的确立,明确了项目管理要实现的目标与项目过程中的指导方针。
1.2.1必要性和作用
实施项目管理体系,
确立实施项目管理体系,让公司的各个层面的人员,特别是管理层面,在一个共同认同的框架上:
讨论问题、分析问题、解决问题、进行决策。
公司有认同的业务流程,有选择项目的标准,大家约定了做事的规则,而不必为每一件事都讨论,符合规则的顺利放行,与规则不符但需要进行的,大家做特别决定。
把管理者从日常运行中解放出来,去处理特殊的事件,进行决策。
项目管理体系实施后,建立项目成本核算和分析,帮助公司的管理上精细化、透明化,把目标管理和绩效考核落到实处。
通过项目管理体系的实施,能够显著地加强宏观和具体的项目管理能力,提高投资回报,降低成本和防范风险。
1.2.2现状和目标
阳光伟业在项目管理成熟度(相对于软件开发成熟度)的现状和目标:
Ø混乱级:
无序无方法。
✓简单级:
NBC现状。
公司组织架构已往这方面准备,单个项目的管理需指导思想落地。
Ø规范级:
2012年底前,第一阶段目标,探索、讨论、落实。
Ø精细级:
2013年,与预期业务规模相适应。
Ø战略级:
2013年后,现在就要打基础。
我们在“规范级”时要实现“四化”:
流程化、量化、优化、固化(标准化、制度化、信息化)。
1.3基本共识
1.3.1公司业务项目类型
目前,NBC是一个复合体,各种业务形态混合存在,也存在类似的几种业务:
类型
名称
特征描述
A类
准产品、类产品型业务
这种业务以重复型销售为主:
产品形态明确且描述清晰、服务内容范围明确且标准、价格标准,售出后短期内完成产品安装测试培训后,即可进入免费维护期(统一免费维护项目)。
目前属于该类的业务为:
公司A类产品销售(如协同等)。
管理特点:
必须有合同标准模板,可以不用销售立项审批;提交立项审批应从简。
如果付款方式、技术路线有重大改动,则必须按B类项目处理。
B类
数字校园方案推广类服务型业务
这种业务为项目提交典型类型:
项目内容较稳定,产品形态成熟可描述、服务内容和范围基本稳定,但由于客户不同需要定制开发。
目前属于该类的业务为:
数字校园/智慧校园类业务,B类产品的复用销售。
管理特点:
审批流程应走标准流程。
C类
有一定积累或能力的其他开发、服务型业务
这类项目基本上是公司没有积累或很少的项目,特别是以往未使用过的技术和产品、时间紧迫等因素使风险更高,复用效果一般。
核心要求是公司技术底蕴、项目管理积累、人员的敬业,公司应根据业务潜力、投入周期、投入产出比、项目甲方、项目影响、延展性等等方面综合考虑。
系统集成类项目属于公司规划中业务,应不予考虑。
目前属于该类的业务为:
前进二小生命价值教育系统等类似;需外包的开发模块等。
管理特点:
审批流程应走标准流程。
属于高风险项目。
D类
提前执行(WIP)和产品研发类项目
属于公司投入项目,应能后补合同或由公司其他类型项目支撑投入的产品开发。
管理特点:
必须走项目管理委员会决策流程。
我们公司正转变为一种典型的项目型业务模式,即企业通过完成项目的交付方式,为客户提供产品、服务或整体解决方案。
1.3.2项目和项目群组管理
对于IT服务公司,项目管理两个层面:
公司层面(PMO)、项目层面(PM)。
1、项目层面(PM):
员工(资源池中人员、项目经理、项目部经理)谈的项目管理。
属于看微观(相对于PMO),主体还是以完成“提交任务”为核心的一个过程,它所有的东西都以资源为衡量标准,所有东西都当成资源,然后谈这个过程的产出比。
有很多最佳实践和规范,项目管理的五个过程:
启动、计划、执行、控制、结束。
项目管理的九大领域:
范围、时间、费用、质量、人力资源、沟通、采购、风险、综合。
2、公司层面(PMO):
公司管理层谈的项目管理,不是同一个层面,是公司运营管理的核心之一。
以工时、费用等成本综合衡量,主要看宏观和横向,实际上就是说通过哪些指标、通过哪些现象、通过哪些指标性的性质,能够对整个公司运营产生什么影响。
它有一个统筹的视角,或者有概念性的一些数据,让管理层对这些东西能够判断,对还是不对,好还是不好。
1.3.3公司管理项目的范围
公司运营包括销售和生产,从项目管理角度看我们分为两部分,即产品或服务销售的管理和项目提交的管理,而且销售项目和提交项目又是通过项目管理紧密的联系在一起。
1、销售项目:
由营销中心按销售管理方法管理。
其中涉及到投标、演示系统等提交部门投入时,技术部(提交中心)作为提前执行项目处理。
在PMO的运营支持职能范围,销售线索(销售项目)的编号信息到PMO备案。
2、执行项目:
合同签约成功,进入实施阶段的项目,一般有软件开发、系统集成、IT服务等不同性质,所以特指合同项目。
而从执行角度,分4类,
Ø合同项目:
含提前执行的。
包括数校、类数校、有合同的运维服务等。
Ø产品研发:
产品管理部和产品研发部做需求方,提出研发需求文档,签研发计划,由产品研发部提交开发。
Ø免费运维:
所有类数校项目、部分数校项目(无后续项目的)结项后(无收款了),免费质保期间的运维投入,统一到实施部设立一个项目(每年度立一次项)。
Ø内部专项:
如网管专项、部门费用专项、公司内部系统开发(如办公审批系统、项目管理系统等)。
1.3.4矩阵型项目管理
在矩阵型组织中,来自各个职能部门的人员在可以为某一个具体项目专职工作,也可以同时在两个或更多个项目中兼职工作。
Ø由于人员属于职能部门,他们能够为适应项目的变化需要而在各项目间流动。
例如某个项目因为用户要求暂时停工,或者其它项目进度吃紧时,就可以将项目成员调配到其他项目中去。
这样通过在项目间共享人员的工作时间,可以充分利用资源,全面降低公司及每个项目的成本。
Ø在矩阵型组织中的基础核心职业技能可供所有项目共享,这些技能就能得到很好应用。
Ø由于项目团队成员可以通过两条渠道向项目经理和部门经理或开发经理反映情况,从而可以更及时的发现问题,提醒注意的潜在危险,提高反应能力。
在矩阵型组织中,项目经理管理和职能部门经理工作关系:
(1)项目经理是公司与客户之间的媒介,职责是确定做什么(工作内容、何时完成、进度计划)、多少成本(人工和费用预算)等问题,以实现项目目标、使客户满意。
应作好工作结构分析(WBS),确定那些工作由公司内部完成,那些工作由承包商完成。
同时组建项目团队,制定进度计划及预算,为公司相关部门划分具体工作任务、工作界面和预算,并监控项目有关部门执行情况,确保项目目标完成。
(2)明确研发团队成员汇报关系,以及对什么职责和任务进行汇报。
矩阵型组织结构中的研发团队成员有两层汇报关系:
临时性的项目经理(业务上)及相对永久性的开发经理(行政上)。
(3)项目经理与部门经理进行有效沟通以达到整个组织在时间、费用及效能之间更好的平衡,必要时应通过调整项目成员的配备来调节双方的矛盾。
要根本解决双方之间的冲突,项目经理及部门经理必须共同站在企业的高度上对项目加以认识及理解,才能对项目重要性、对资源的需求,以及资源的可获得性有一个更充分的认识,从而管理好项目。
(4)当两者之间的冲突难以解决时,由更高层的管理人员出面解决。
项目总监或项目管理委员会,作为项目经理的汇报对象,也是职能经理的行政领导,可以解决公司内两三个项目间在先后次序上的冲突,并对冲突进行仲裁。
1.3.5项目群管理机构
公司设立项目管理办公室或运营管理部(PMO),作为项目管理委员会的执行机构。
PMO作为公司层面项目管理的核心,执行以下三种角色:
项目管理的支持者、项目的控制者、项目战略的管理者。
PMO是在公司内部将项目管理的实践、过程、运作形式化和标准化的部门。
通过标准化的方法和流程实施和反复使用,可以确保项目成功的机率上升。
PMO是组织内部项目管理最优实践的中心,是公司提高项目分析、设计、管理、检查等方面能力的关键资源。
1.4成本共识
提交项目是要花成本的,而且是有限的成本,还要花的明白。
因此每一个人都要有成本意识。
1.4.1实施财年预算制度
预算的起点是销售预算,基础是高质量的销售预测。
预算的终点是财务报表预算,按照季度的财务报表预算,以及对公司业绩的分析等,确定是否符合了公司的发展计划。
预算是例外管理的一个重要组成部分,管理层注意力要放在没有按照预算进行的经营活动。
否则,大家会花费大量的时间与解释过去的活动,而缺乏足够的时间规划未来,临时性的决策可能花费更多的时间。
如果预算做的粗,又设计有投入,公司批起来就费劲!
(除非按部就班地支付成本,否则必须算清楚预算!
)
预算强迫我们制订计划,随着公司规模的不断扩大、业务的快速发展,我们制定计划、保障成功,业绩评估都要科学有效,高质量的预算绝对是保障!
管理层全员参与的预算过程,直至关注项目会计的层面。
同时要防止预算过于大胆,以及预算松散!
预算终结于财务报表预算,因此销售预算要收款时间,以保证现金预算能够同时产生。
财务的预算要保障支持应收款项、存货(包括资源池)和资本性支出的现金可得。
1.4.2项目财务管理模型
我们公司是项目型的IT服务企业,项目管理是公司运营管理的基础。
公司财务管理模型中的核心概念:
人工费率、营业收入的确认方式。
公司的财务管理模型中有四个主要管理对象:
公司、部门(部门、销售、执行等)、项目、人员。
其中有两个基本的模型,即项目财务模型和公司财务模型。
然后把部门和人员的反映到模型中,形成了一个有机的整体,即为公司的财务管理模型。
1.4.3立项才能投入成本
技术部门的所有提交的投入必须立项,项目有立项输入(基本信息、需求信息、商务计划信息等)、成本预算(人工、费用)、计划和里程碑等重要信息,并通过审批流程,获得项目编号,才具有成本投入的合法性。
所以,项目的合法性以取得项目号为标志。
不是取个项目名称叫什么就可以做提交投入了。
对于我们公司可管理的项目:
1、所有签订销售合同的产品销售、服务销售、解决方案销售等,或经评审同意提前执行的,都必须立项,纳入项目管理范围。
2、所有内部消耗人力成本的产品研发、售前支持、大项目投标都要立项。
产品研发按产品名称立项,售前支持年度统一立一个项目,大项目投标分别立项。
3、公司所有部门(主要是职能部门)公共消耗费用和人力,各立一个项目。
1.4.4项目成本预算原则
项目的成本从归类上说,有以下几种说法。
名称
含义
举例
直接成本
可以从项目上找到直接出处
技术人员工资
间接成本
多个项目分摊
水费、房租、管理费用
固定成本
不会随着产品生产数量而增加
计算机
可变成本
随着生产产品的数量增加而增加
原材料
可控成本
项目经理可以控制的
直接成本、可变成本
不可控成本
项目经理不能直接控制
间接、固定、其他
机会成本
因为选择另一个机会而放弃的机会原来可以获得的收益
为了选择A,放弃B,B的收益就是A的机会成本
沉没成本
WIP提前执行,以前花出去的费用,在确定是否继续做项目时不需要考虑
当项目最终结果是取消项目时,那么该项目提前执行就属于沉没成本。
我们具体到某个项目预算时,去掉采购和外包成本外,主要是和人相关的人工成本和直接费用。
人工成本是根据各种间接成本分摊后算出人工费率后作为参照的,直接费用包括项目执行过程中花掉的钱,再加上用作奖励的钱。
估算项目提交的投入人工成本,必须区分各任务或模块分别估算,再加总计算。
✧使用公司成熟产品的,应减去产品价格后算投入开发成本;减去部分统一放入集成工作进行估算工时投入。
✧采购产品时,同上。
✧全新开发模块的工时投入按开发的人工费率估计工时。
✧复用开发模块的工时必须由项目经理和研发部门负责人定出该模块的复用率,然后再按比例给出工时。
1.4.5按月分析项目执行
因IT项目一般周期较长,很多项目是跨公司财务核算周期的,所以按月进行项目的收入和成本分析。
公司对于大项目采用完工百分比(POC)的方式,确认项目收入。
1、按月进行项目的收入确认,以统计公司整体执行情况。
这个收入不是项目的收款,是公司提交部门投入成本(人工和费用)后,能产生的执行数。
具体就是每个项目总额度*当月执行比例,然后每个项目加总,就是公司管理层面的项目收入。
2、按月进行项目的成本计算,以统计公司整体提交代价。
提交的总成本包括各项目人工投入和费用投入加总,这个值不等于提交部门的工资与部门费用报销总和,但目标是接近和约等于。
这样我们的管理模式才能从传统生产的部门管理转变为IT服务企业的项目管理。
在接近的过程中,我们可以看到提交人员的效益产出比例、还有多少是能产生收入之外的管理成本和比例。
1.4.6项目挣值分析考核
PMO进行整体项目的挣值分析和评价工作。
具体单个项目的挣值分析有如下要素:
术语
解释
计划值(PlannedValue,PV)
应该完成多少工作?
BCWS
挣值(EarnedValue,EV)
完成了多少预算工作?
BCWP
实际成本(ActualCost,AC)
完成工作的成本是多少?
ACWP
完工预算(ggetatCompletion,BAC)
全部工作的预算是多少?
完工估算(EstimateatCompletion,EAC)
全部工作的成本将是多少?
完工尚需预算(EstimatetoComplete,ETC)
剩余工作的完成还需要多少预算,在当前预计的成本是多少?
剩余工作的新估算。
术语
解释
SV
=EV-PV
进度偏差
SV<0项目滞后于进度计划
SV>0项目提前于进度计划
CV
=EV-AC
成本偏差
CV<0成本超出预算
CV>0成本低于预算
SPI
=EV/PV
进度绩效指数
SPI<0项目滞后于进度计划
SPI>0项目提前于进度计划
CPI
=EV/AC
成本绩效指数
CPI<1成本超出预算
CPI>1成本低于预算
EAC
完工估算
BAC/CPI,AC+ETC
ETC
完工尚需估算
VAC
=BAC-EAC
完工偏差
项目完工时超出或低于预算多少
SV(%)
(SV/PV)*100%
进度偏差百分比
偏差百分比
VC(%)
(CV/PV)*100%
成本偏差百分比
PC(%)
EV/BAC
完工百分比,POC
PMO目前只考核进度偏差(SV),暂不考核费用偏差。
使用ABC三级评价。
每周项目总体绩效总分10分,对于每周评价,A加绩效考核1分,B不加分,C减1分。
项目每周总体绩效与最终项目奖金挂钩。
1.4.7项目奖金处理原则
项目奖金也是项目成本一部分。
因此对于那些预算了奖金的项目,项目费用预算的余额作为项目奖金。
奖金的分配和发放只考虑参与项目并在职的人员。
1、合同提交项目的奖金的计算和分配(项目经理给浮动比例,PMO分配)以项目竣工验收、通过PMO的项目审计为条件,奖金的发放以收全款为条件,奖金发放以发放日在职人员为范围。
2、产品研发项目的奖金的计算和分配(研发经理给浮动比例,PMO分配)以产品正式发布、项目结项为条件,奖金的发放以产品发布后3个月为条件,修补补丁开发不计算项目奖金,产品包含功能升级的补丁包应按正式产品研发立项处理,奖金发放以发放日在职人员为范围。
3、统一运维项目的奖金的计算和分配(部门经理给浮动比例,PMO分配)以年度(自然年)完成工作为条件,奖金的发放与公司年度奖金同期发放,奖金发放以发放日在职人员为范围。
奖金分配比例由量化的指标为基础参考数据,如投入工时、原则比例(分配人可上下微浮)、过程记录(开发人员看每次任务的提交和质量、项目经理按里程碑工作的完成情况等)、调节数等。
产品研发项目中,产品管理部人员不参与项目研发奖金分配,其奖金与销售和产品推广相关,即每销售一套产品按“产品销售价格*1%”计算。
与其他未参与项目提交的支持人员由年度部门奖金平衡。
1.5合作协调
1.5.1选择项目和项目初始过程
我们公司是项目型企业,也存在项目选择过程,是指从市场上获得商机到与客户签订项目合同的过程,当然也是被选择的过程。
在项目选择过程中,关键是对项目的定义和计划已经有相当明确的描述,应包括明确项目的目标、时间表、项目使用的资源和经费,而且得到执行该项目的项目经理和项目发起人(销售)的认可。
从公司的指导思想上看,“钱之前”、“钱之前之前”的过程为项目选择过程。
选择过程的关键结果、提交物就是合同,项目提交则是依此进行管理。
合同签订后,项目的责任人就是提交部门了,具体就是指定的项目经理。
执行项目的初始过程需要项目经理和销售人员一起沟通,确认任务、计划和资源的过程。
1.5.2项目售前售后分开管理
我们把“钱之前”、“钱之前之前”的过程看做项目选择过程,如果对其按项目管理思想管理的话,就是售前销售项目。
我们把“钱之后”的过程称为项目提交过程,按项目管理思想管理时,就是售后提交项目。
因为公司的销售和生产由不同的职能部门负责,为了便于管理和区分责权,公司管理项目时将两者分开管理。
对于售前销售项目来说,销售部门有自己的管理思路。
一个客户可有多个销售线索,每个线索必须有始有终,考核成功率。
因此,销售项目不是以客户为划分的,是以每个销售线索(将来能形成一个合同的前身,也就是能成立一个执行项目的可能的粒度)来管理的。
为了便于管理,对销售线索也以编号处理。
规则见统一编号规则,以X号位起始位。
销售线索可以没有编号,但最好有;销售线索纳入PMO的运营数据支持统计中。
如果有报销和花费,则必须有项目号,即正式销售项目立项;如没有报销,则无所谓,但开始投标或进入签协议前,必须销售立项。
当合同签订后,提交项目管理时,项目经理就是对外的接口,本项目的销售除了跟踪项目情况和负责商务事宜外,可抽出精力达成新销售项目的成功。
对于售后提交项目,我们重点关注的是在成本预算内、按时、按质完成交付。
1.5.3销售售前阶段提交资源投入
在销售售前阶段,如需要提交人员做短期技术支持,都要产生成本。
如果没有明确合同意向,这些投入都无法按提前执行项目管理。
类数校产品等演示试用系统安装时,基本用的资源都是实施人员。
实施人员的人工投入计入实施部门部门专项立项中,如有费用(主要是交通和误餐餐补)则由销售人员直接报销。
项目投标等调用提交人员资源时,各人员的人工投入计入各自部门部门专项立项中,如有费用(主要是交通和误餐餐补)则由销售人员直接报销。
销售报销(含咨询费),必须按销售项目报,不能报到执行项目中,不能按部门报。
销售签单报销考虑已签合同额和比例,年度承诺和预算等。
1.5.4立项时处理提前执行成本
只有销售立项后,才可以申请提前执行(WIP立项)。
中标、签合同后,由项目经理操作转正式项目,并在正式立项中核减已投入成本;确定无法签订合同时,提前执行成本计入销售成本和公司纯消耗成本,并作为销售成本计算,以便统计分析,不得计入同客户的其他项目中。
WIP项目在执行50%以上还没签合同时,必须经项目管理委员会决策是否继续执行,销售必须清晰介绍商务情况。
执行100%时还没有签合同,销售人员必须向项目管理委员会书面承诺落单时间。
1.5.5资金计划和收付款管理
资金计划作为收款、付款活动的体现,是体现项目收支现金流的重要形式。
必须以项目涉及的销售合同和采购合同或外包合同中的收付款条款设立。
收到合同款后,销售必须到PMO备案,或财务部给销售和PMO发收款通知。
公司新开发票必须由销售到PMO备案,PMO开始追踪收款进展。
采购合同或外包付款需PM、PMO审核后签字。
付款时,必须有发票财务部才能付;必须经PM、PMO确认采购或外包成果无问题签字后,后续公司层面签字。
不涉及项目保证金和质量保证金的管理,另行专门管理。
1.5.6产品管理和产品研发项目管理
产品管理部作为需求方,负责公司产品的生命周期管理。
产品的研发生产阶段是由产品研发部负责的,研发阶段的管理完全按提交项目管理方式进行管理,此时产品管理部的产品经理就是项目的“甲方、客户”,研发部的产品研发经理就是项目的“项目经理、项目负责人”。
产品的临时性bug修改不作为项目管理,产品的新需求必须集合后,才能进行立项研发。
产品生命周期和项目生命周期关系如下图。
产品生命周期,由项目组成的时间段,开始与一个产品的构思,结束于这个产品不再使用,总体上连续的,没有重叠的各个产品阶段的总和,产品阶段的名称与数量由组织结构的生产产量与控制需要所决定。
项目生命周期,通常连续的项目阶段的集合,由组织的需求控制决定。
1.6人才成长
1.6.1技术人才成长路线
项目提交是指在项目签单之后,技术团队依据合同规约,通过项目需求调研、设计、开发、测试、实施、上线运行、验收、售后服务等工作达成用户建设目标的行为。
参与项目提交的人员统称项目提交人员,其核心能力要求为:
重承诺、能提交。
(缺售前?
放在销售序列中?
!
)
在NBC,项目提交按提交工作性质的不同,可以分为以下几类工种:
1.产品/研发
研发,泛指软件研发为主,完成项目软件系统研发,并在用户现场完成系统部署、上线、运行、验收的项目提交工种,或者按照公司产品发展战略,完成核心软件产品的预研、设计、开发、并进行产品化的产品提交工种。
产品/研发设置5种岗位:
工程师、项目研发经理/产品研发经理、产品经理/部门经理。
2.实施/运维
实施,泛指将应用软件在多个用户现场推广实施的提交工种,它不涉及软件系统研发工作,其工作流程主要为:
需求调研、实施方案制定、系统部署实施、上线运行、验收等。
运维支持(售后服务),泛指项目上线运行时或验收后,为用户提供系统运行支持和保障的提交工种,服务方式可以分为:
远程支持、现场运维。
实施/运维设置3种岗位:
工程师、实施主管、部门经理。
3.项目/运营
项目/运营,指将对公司各种项目进行项目管理的提交工种。
项目是具体项目的管理,运营是对公司(PMO)整体项目群组的管理,包括项目管理支持和公司运营支持。
项目/运营设置4种岗位:
PMO人员、项目经理、部门经理、PMO主任(项目总监)。
4.测试/质量
软件测试,泛指利用各种测试手段对未定型软件系统进行软件质量测试,找出软件缺陷,并推动开发人员完善软件系统的提交工种。
其工作流程主要为:
熟悉软件系统、制定测试方案、编写测试用例、软件测试、bug公布与完善跟踪、软件发布等。
测试/质量设置3种岗位:
工程师、测试主管、部门经理。
5.UI/前端
UI/前端,泛指项目、产品界面设计和实现的提交工种。
UI/前端设置3种岗位:
设计师/工程师、支持主管(项目/产品)、部门经理。
6.系统集成
实施网络、安全、系统的整体系统集成。
本部分人员须等公司系统集成资质取得后再说。
设置2种岗位:
系统集成工程师、系统集成项目主管。
1.6.2量化绩效考核指标
OEC管理法即Overall(全方位)、Every(每人、每天、每件事)、Control&Clear(控制和清理),简言之就是五句话:
总账不漏项,事事有人管,人人都管
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 管理 白皮书 讨论
![提示](https://static.bdocx.com/images/bang_tan.gif)