软件项目交付风险管控

背景

人员组织结构

XXX

周边集成系统

SSOProxy 1个接口
Classroom 2个接口
DocMan 2个接口
CodeHub 1个接口
ProjectMan 3个接口
APIGateway 所有开发云服务接口
判题系统 2个接口

系统部署架构

XXX

系统技术栈

C#语言 HTML/CSS/JS RAZOR模板引擎
Windows Server 2012 IIS容器部署

交付工作时间线

2017.11 决策接受系统开发任务
2018.1.8启动大赛平台的开发工作
2018.2.15~2018.2.21春节放假
2018.3.1大赛平台上线运行
开发工作是1月8日开始,3月1日截止,2月15月-2月21日春节假期,共计35天。
开发:易思智外包,2后台+1前台+1个实习生
测试:华为方1人+外包1人(1月15投入)
CIE:华为方1人(2月7日投入)

交付过程风险

TOP1 需求风险 (无人管控、随意变更、需求反复、重视不足)

(1)缺少需求列表
完全没有需求文档,需求细节完全靠问,时间都浪费在各种沟通中。
(2)领导改需求
开发到1月26日改了一版需求,首页页面完全基本换掉、其他页面调整、报名流程调整(增加25人天开发工作量)
(3)后期改实现方案
1、判题串行执行改并行执行,配合联调(增加5人力)
2、为了架构稳定性,同步接口改异步接口(增加10人力)
3、增加可测试行,增加灰度功能(增加5人力)
(4)需求反复
1、赛事直播页面先是移除,后又要上线
(5)PD投入不足
1月29日一周 杭州授课,事项委托姚传存
(6)需求基本处于无管控状态
HR那边的需求负责人换成一个完全不懂业务的人,基本什么需求细节都不了解,还得由开发给他讲业务细节。
(7)交付时间提前
原定交付上线时间是3月8日,提前为3月1日
(8)与开发云深度集成
与17年相比,最大特性是利用开发云进行开发活动,且集成开发云的4个服务。工作量比17年大大增加,预估工作量严重不足,预估工作量为14人天,实际工作量为3倍不止。
最开始需求为储存学生答案(DocMan),后经领导要求深入使用开发云功能

TOP2 周边系统风险 (集成系统越多,风险越大)

个人感受:真正的开发工作量其实只占了1/5,其余时间全是在等待、联调、验证、定位问题
个人体会:你能对自己系统了解,但你永远无法了解其他系统的风险。(添加成员无法加入仓库,后经定位为不支持跨租户成员添加,但是文档里也没有写)

TOP3 技术/架构风险 (前期考虑方案不全面,导致后期风险大)

我1月5日接受此任务时,各环境服务器资源没有申请、部署架构没有梳理。
(1)与开发云服务集成需经过APIGateway交付,这是我没有识别到的,导致内部开发时按照内网的对接,后又全部改为APIGateway对接。
(2)与CodeHub集成内部开发完成,后经了解网络不通,又改为新加服务来支撑此功能。
(3)与IAM直接集成后改为SSOProxy集成

TOP4 人力风险 (前期不紧张,后期时间紧任务重,再紧张已经晚了)

1、由于PO问题,外包进场比预计晚了1月。导致开发周期被大大压缩,17年大赛12月外包就进场了。
2、1月8日后陆续人力才到齐。
3、前年前后外包请假比较多,前年前后全员各3天,后经多方交涉派了两个人,还是阶段支撑,且新员工工作效率低。
4、从1月8日开始全部处于加班状态,基本都加班到10点,外包抱怨较多,周末至少加班1天,中间一名外包扛不住离职了。
5、易思智没有提供测试人力,后从Cloud BU协调了两名人力。
6、人越多管理成本就会越高。
7、一个项目全部围绕一个人转就会出现瓶颈,解决瓶颈就是要多培养对业务负责的骨干。

环境风险

研发环境(Alpha/Beta/Gamma/性能环境)

现网环境

性能环境搭建耗费大量时间,codehub、classroom出现大量功能问题,组织升级,定位耗时长(工作量14人天)

新服务交付面临巨大挑战(基础工作量大)

1、流水线搭建:组内没有人懂流水线,多方求助,慢慢搭建起流水线,编译构建、自动部署。
2、新服务上线要做大量的工作来满足性能、安全、可靠性要求。

个人总结

1、要合理管控PD提出的需求,往往PD对需求实现不了解,工作难度也不了解,所以要给PD合理的反馈,不要一味承接需求。
2、需求还是要有文档有邮件,可追查,不然就需求变更带来是全尽的痛苦。
3、项目交付全部依赖于人,多掌握几个能力强负责人的人是关键。
4、多培养几个对业务熟悉对架构熟悉的人,如果只有SL懂,那将成为整个项目进度的瓶颈。而且还会特别累。
5、项目交付是个工程事件,需首先从全局着手,切忌一头扎入实施细节,从而忽略了很多前期应该开展的工作。
6、系统的架构设计是不能出错的,后期改动架构是一件很痛苦的事情,这就要求我们一定要多方面论证方案的可行性。
7、如果集成的系统过多,那你就要小心了,这表明你花费的沟通成本将大大增加,不可控因素也大大增加。
8、遇到风险千万该求助就求助,该上升就上升。

反思

1、让自己成为项目团队的瓶颈
2、架构应该提前识别到网络风险,但是没有及时识别到。

改进思路

需求把控,PD要管控需求,不能在有限的时间承接无限的需求,SL针对不合理的需求要给出意见
可以并行搞的事情不要串行搞(环境搭建可以在开发活动开始时就开始,开发完成再进行就影响进度)
DevCloud工具要怎么帮助用户成功(真正提高研发活动效率,整个流水线搭建熟手都要一周)
周边系统要了解需求的背景,不然开发完才发现不对造成反复。(对端到端的业务没有明确的说明。 )
人很关键,交付过程中最重要的是人的能力,培养几个业务骨干,技术骨干
出现风险的时候,要调整,比如人力、功能特性( 12月份讨论方案只接入DOCMan,1月确定深入集成DevCloud )
架构设计要具有扩展性(需求变动不可避免,尽量做到可扩展,SSO方案)
交付流程精简,提高交付效率(从出包到上线要一天时间)
人员管理,调动人员积极性,让大家团结起来把力用在一点上
多投入华为人力(熟悉交付流程,投入SE对架构进行把控)
流水线搭建过程中,对C#编译构建,Windows部署支撑起来有点吃力。
新服务上线面临诸多挑战,要如何帮助服务成功,快速上线

原文地址:https://www.cnblogs.com/yaochc/p/8678713.html

时间: 2024-11-09 10:49:30

软件项目交付风险管控的相关文章

软件项目风险管理介绍

        软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响.软件项目风险会影响项目计划的实现,如果项目风险变成现实,就有可能影响项目的进度,增加项目的成本,甚至使软件项目不能实现.如果对项目进行风险管理,就可以最大限度的减少风险的发生. 项目风险管理 项目风险管理是指为了最好的达到项目的目标,识别.分配.应对项目生命周期内风险的科学与艺术.项目风险管理的目标是使潜在机会或回报最大化,使潜在风险最小化.风险管理涉及的主要过程包括:风险识别,风险量化,风

浅谈软件项目开发过程中的主要项目风险及对策

软件项目成果的需求分析方和软件项目的承担者都十分关心这样的一个问题:什么样的因素会导致软件项目的失败?与项目有关的因素的改变将对按时.按经费预算交付符合预定质量要求的软件成果产生什么样的影响?这些都属于软件项目开发过程中考虑的风险问题. 软件项目的风险是指在软件开发过程中可能出现的不确定因而造成损失或者影响,如资金短缺.项目进度延误.人员变更以及预算和进度等方面的问题.风险关注未来的事情,这意味着,软件风险涉及选择及选择本身包含的不确定性,软件开发过程及软件产品都要面临各种决策的选择.风险是介于

如何做一个软件项目经理? ----写给公司所有的开发人员

注:文本中的"我",均是网上作者(前三部分来自网络文章,第四部分除外). 第一部分:软件项目经理的要求 首先是一个管理者,其次熟悉某些工具,某几种语言,行业背景,项目管理技能. 软件项目经理面临的恶劣环境,我们绝大部分软件企业运行在相对混乱的状态(CMM一级),组织不大可能对项目以及项目经理的责任做出明确.合适的界定,所以,影响项目成功的一切因素都是项目经理的责任,包括客户.环境.考核.激励等等. 一.责任心.取得项目的成功无疑是项目经理的责任.项目经理只有把客户的满意和企业长期利益作

软件项目开发环境构建之一:整体流程

通常情况下,一个大的项目,很难一个人完成,需要一个团队共同协作,大家彼此分工,共同完成不同或相同的模块,这时要求所使用的工具软件要具有分布式协同功能.处理冲突及持续交付功能,一般软件项目的整体流程如下: 一个软件项目的实施,要经过概念阶段.计划阶段.创建阶段.发布阶段及追踪阶段,Atlassion的软件族都有各阶段的对应软件. 一般,概念阶段,可以使用Confluence 进行需求管理,从最初的想法到最终的需求,能够通过Confluence强大的协同功能,高效的完成需求收集.整理.分类等工作(M

软件项目量化管理(CMMI高成熟度)实践经验谈——之项目管理过程监督与控制篇

续:软件项目量化管理(CMMI高成熟度)实践经验谈--之概述篇 续:软件项目量化管理(CMMI高成熟度)实践经验谈--之项目管理过程策划篇 2.项目监督与控制 项目监控是围绕项目实施计划,跟踪进度.成本.质量.资源,掌握各项工作现状,以便进行适当的资源调配和进度调整,确定活动的开始和结束时间,并记录实际的进度情况,在一定情况下进行路径.风险.决策.度量.量化管理等方面的分析.在实施项目的过程中,要随时对项目进行跟踪监控,以使项目按计划规定的进度.技术指标完成,并提供现阶段工作的反馈信息,以利后续

软件项目与过程管理第八周作业

内容:软件项目与过程管理课程内容总结 经过八周时间的学习,软件项目与过程管理课程已经逐渐接近了尾声.通过这八周的学习,我对软件项目与过程管理课程有了更深的理解. 一.关于团队项目. 团队项目是本次软件项目与过程管理课程中最重要的一部分.我们团队项目是作业管理系统.在项目开发的整个过程中,我们在项目经理的带领下,项目团队的每一个成员团结合作.相互沟通,团队成员之间相互学习彼此的优点和技术,在每个成员的共同努力下,基本完成了此次软件开发项目. 通过这次团队项目, 我的总结如下: 1.在项目的开发过程

软件项目:巧克力爱好者联盟

巧克力爱好者匿名(ChocAn)是一个致力于帮助各种吃巧克力上瘾者的组织.该组织的会员每月向ChocAn付费,然后他们就有权利向保健专家,如营养学家.内科医师和运动专家要求得到不受限制的资讯和治疗.每个会员得到一个塑料卡,上面刻有会员名字以及一个9位数的成员编号,同时卡中含有一个磁条,上面有编码信息.向ChocAn成员提供服务的每个保健专家(提供者)有一台专门设计的ChocAn计算机终端,它类似于一个商店里的信用卡设备.当一个服务提供者的终端开机时,要求该提供者输入他的提供者号码. 为了接受来自

Project Management: 软件项目估算与计划不是一般的难!

摘要:估算.计划.计划跟踪是项目管理的主要工作,难度之高超乎你想象!光靠学习项目管理理论难以管好项目,而往往真能管好项目的都是那些在具体项目中滚打出来的实干人士.本文将会让你全面学习项目估算.计划.计划跟踪的知识,体验实际项目管理的难度,学到提高项目管理水平的一些方法. 大纲:1.从建筑工程说起2.估算要估啥?3.估算如何做出来?4.计划有什么内容?5.计划是如何做出来的?6.如何跟踪计划?7.优秀项目经理是怎样炼成的? 特别声明:如需转载此文,请给出指向本网站的连接,如下:作者:张传波摘自:h

软件项目开发流程

软件开发流程(Software development process) 首先 看一下基本软件项目开发流程图 其中 1.需求分析: 通过对客户业务的了解和与客户对流程的讨论对需求进行基本建模,最终形成需求规格说明书. 2.总体设计: 通过分析需求信息,对系统的外部条件及内部业务需求进行抽象建模,最终形成概要设计说明文档. 3.详细设计: 此部分在对需求和概要设计的基础上进行系统的详细设计(也包含部分代码说明). 4.开发编程: 对系统进行代码编写. 5.测试分析与系统整合: 对所有功能模块进行模