背景

人員組織結構

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部署支撐起來有點吃力。
新服務上線面臨諸多挑戰，要如何幫助服務成功，快速上線

軟件項目交付風險管控