因s1專案為公有雲部署，開發團隊異地集中，採用遠端辦公方式，無需客戶開發人員承接。所以開發階段主要工作一是跟進度，二是協調介面開發。遠端開發，難在進度把控。特別公有雲專案，若評審通過後定為產品標準功能開發，則要遵照產品的版本規劃。有時由於方案變更、或產品、設計團隊進一步討論，專案二開與產品開發發生轉化，拉長了前期時間。即使是專案二開，過程的效率也很難把控。因此對於開發進度，只能要求專案經理提供開發任務，每一項的技術負責人是誰？以目標時間跟進。對於開發資源不做硬性要求，先確定工作量，再根據目標日期看要投入的資資源。
向專案經理要專案總技術負責人及開發清單明細時，碰到了困難。但這屬於正常要求，如何公升級，甲方總有辦法。付款、戰略合作夥伴關係、合同條款、通過商務向交付領導反饋。同時提前定義好專案狀態，進度正常綠燈，3日內delay黃燈，一周內delay紅燈。若是紅燈，每日需開發leader匯報狀態，發現任何問題第一時間報告，直到趕上進度。統計開發量時，需標識標準功能所佔的比例，作為評估專案開發的一重要資料。
因同時多個專案並行展開，以專案集方式運作，總介面數上百了。對於外圍系統介面，需要配合的資源，盡早提供。聯合專案組會統計全部專案介面需求，但線下也要盡早打好招呼，並定期確保資源仍可及時到位。開發階段，也要跟緊切換上線清單、資料準備情況，操作手冊、培訓/宣傳資料，盡早開始收集。
需求提報需求編號
**功能模組
優先順序需求描述
需求開發項
需求背景
提出人提出日期
期望完成時間
預計開發完成時間
技術負責人
需求評審
需求型別
評審結論
需求優先順序
需求分類
重要程度
產品人天
技術設計
前端人天
後端人天
人天備註
功能設計
設計負責人
預計完成時間
實際完成時間
技術設計
技術負責人
預計完成時間
實際完成時間
技術開發
開發人員
故事編號
開發時間
預計完成時間
開發進度
實際完成時間
驗證測試
測試處負責人
完成時間
發版計畫
發版時間
S1專案 專案集
s1專案實施期間，並行開展了其他6個專案，其中與3個存在關聯。碰到的問題如下，乙個業務需求，可以拖長達兩個月。兩個系統互相推脫，對於由哪個系統承載，無法達成共識 對接系統提出的要求，業務對財務 財務對上游系統，兩個專案組調研 方案不同步，進度受影響，方案面臨大改 介面開發，各系統進度不一致 都走企業...
S1專案 測試階段
排主計畫時，uat一般只預留1 2周時間，且遇到趕進度需調整主計畫時，壓縮的往往是測試時間。一是侯世達定律作祟，大家想著萬一uat順利呢，一周使用者測試 一周改bug，時間足夠了 二是從整個專案交付來看，測試顯的 不重要 開發完乙個功能 介面，體現的是實際進度變化，無法縮減，否則系統少功能，是顯性取...
S1專案 上線準備及切換階段
專案uat測試簽字通過後，準備期初資料 資料需提前收集 整理 及cutover plan。上線業務範圍，是先試點關鍵業務部門，還是全業務線使用？上線的功能範圍，先上哪幾個模組 保證業務正常流轉前提下 或者全平台上線？舊系統如何處理，是雙系統並存，在途單據在舊系統走完，還是直接關停，資料遷移到新系統中...