背景

人员组织结构

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部署支撑起来有点吃力。
新服务上线面临诸多挑战，要如何帮助服务成功，快速上线