個人數字化IT項目管理體系

        今天跟你們分享一下，我創建的IT項目管理體系，根據公司的實際環境創建，目前運行很是順暢。

        從項目的申請，到項目的驗收付款，每個環節都經過系統展示出來，我本身給這套體系叫作「數字化項目管理體系」。這套體系不依賴於個人能力，即便我休假或離職，也能夠很好地運行，我是徹底遊離在體系以外，觀察並優化其瓶頸，我也時常戲稱爲去中心化式的項目管理體系。

        這套體系包括OA系統中的項目申請流程，Redmine項目管理系統，開發管理系統和IT項目展現系統（咱們內部叫紅燈系統）四個模塊。經過以上四個模塊，將項目的各方（用戶，IT工程師，外部開發人員，領導或利益相關方等）都很好地鏈接起來，提升項目溝通效率的同時，項目進度管理和項目質量管理也就水到渠成。

        開始以前，先聊聊以前的項目管理存在的問題，或許會有共鳴。

一、缺少目標：項目沒有明確的、共同的目標。如用戶和IT工程師並不徹底清楚項目最終將實現的效果，或很模糊；項目沒有明確的上線時間，作到何時就何時上線，若是忘了就不了了之。好比OA系統中還有兩年前的申請未結案，無論是用戶，仍是IT工程師根本就忘了這事，直到有領導過來罵人。

二、缺少用戶導向：項目沒有惟一的負責人。由於咱們IT團隊開發能力不足，80%的開發都是外包，若是有熟悉ABAP，JAVA，.net開發的朋友，也能夠跟我聯繫，或許會有兼職外包開發的機會喲。若是一個需求涉及多個業務系統，用戶須要提交多個申請，對每個申請分別拋外包開發PO。不一樣的申請由不一樣的IT工程師負責，相互之間沒在關聯和交流，常常會出現一個系統的開發完成了，用戶滿心歡喜地覺得能夠上線試用了，被告知你去問問B工程師那邊作完了沒有，B工程師一眼蒙逼，你沒有給我提需求啊，我都不知道這個事兒。好吧，用戶還得乖乖地再提一個B系統的申請，就這樣，一個簡單的需求，因爲沒有統一管理，時間跨度會很長。

三、對「完成」的理解有誤差：IT工程師報告的完成是指開發完成，而不是指項目上線給公司帶來真正的效益。好比剛開始時，工程師彙報說這一項已經完成了，就隨口問了一句，那如今用戶使用中是否有問題？獲得的答案是隻是咱們開發完了，還在測試系統測試，請問這是完成了嗎？這又回到第一點，咱們IT部門的目標是使優化成果給公司帶來經濟效益，而不是簡單地作了這件事情。

四、缺少交付標準：同一件事情，不一樣的工程師交付的結果是不同的。如OA流程界面能夠說是百花齊放，函數的命名規則、字段的命名規則等。

以上只是簡單列舉幾條較嚴重的問題，針對這些困局，我提出了觀察、梳理、高效三步曲。

        對IT工程師的要求是軟、硬技能兩手抓。硬技能包括學會繪製LOVEM流程圖，學會利用思惟導圖收集用戶需求，學會製做原型圖和用戶確認，學會編制項目相關文檔。軟技能包括提升項目管理能力、時間管理能力，提高思惟模式和解決問題的方法論。部分PPT及培訓文稿請出門左轉。

        對人的要求如此，對系統的要求更是如此。

        只有人和系統的完美結合，才能使IT項目管理高效的運行。對人的軟、硬技能培養部分有機會再講，今天先回到咱們的正題 - 數字化IT項目管理體系。

公司的理念是能讓系統作的事就不要讓人來作，機器作更穩定，不易出錯且效率更高。因此，公司的信息化水平還算不錯，全部的信息系統都已打通，優化端到端的流程，消除了信息孤島。固然，咱們IT部門也很苦逼，累成狗。但給公司帶來了很大的利益，系統效率提升了，操做人員減小了，節省了很多人力成本。獎金是沒有的，只能本身苦中做樂，尋求一些成就感！哈哈！

        咱們的IT項目管理按項目大小分爲兩類，較大的項目如：新系統開發或實施，舊系統在新公司實施等。本體系主要是適用於另外一類，即IT優化類項目。較大的項目咱們採用敏捷管理框架，IT優化類項目採用的瀑布管理模型，爲何這麼選，這可能就是最佳實踐 。

        因爲是內部優化項目，爲簡化管理，咱們只重點管理項目範圍、項目進度、項目風險和質量等維度。

        從項目實施的時間順序，劃分爲項目申請，項目評估，項目實施，項目測試，項目上線及驗收五個部分。並未嚴格按照PMP的五個過程組，十大知識域。

一、項目申請

        項目申請主要經過OA系統中的項目申請流程，也能夠稱之爲立項。

1.一、提出需求

        全部的需求必須經過OA系統提交申請，以便於經過系統集中管理。這是項目的入口，必須嚴格要求，尤爲是外地子公司。

        IT項目將採用項目經理負責制，一個需求，不管涉及多少業務系統或多少位IT同事，用戶都只需提交一個申請，由項目經理對整個項目負責，協調內、外部資源。這一步經過從新設計優化OA流程來實現，對項目的進度管理起到相當重要的做用。

        多囉嗦幾句，之前一個需求涉及多個系統，須要提交多個申請，是由於OA系統向PO拋訂單的問題未解決。經過從新設計OA流程，一條OA流程能夠同時拋多個PO，對應不一樣的外部開發顧問。

        提交申請時需主要填寫如下信息：

1)  項目名稱或申請主題：用一句話描述項目的主要內容。

2）發起人：發起人是項目的實際發起人，也是項目最重要的干係人，可能與申請人不是同一我的。

3）項目適用範圍：選擇項目適用的公司名稱，可多選。在後面項目測試和項目上線時將做爲管控對象。

4)  業務現狀描述：對業務現狀的描述，即未開發或未優化前的業務狀況。

5)  但願實現的目標：對業務優化、改善的詳細描述。

6)  主要風險控制點：業務實現過程當中已知和未知風險，須要用戶和IT工程師共同識別。

7)  涉及或受影響的部門負責人：若是項目涉及到其它部門，須要歸入進來管理其需求，至關於項目干係人管理。

1.二、認領項目或指定項目經理

        根據用戶提交申請時選擇的系統類型，流程會自動推送給相關的IT工程師，根據工做分擔狀況，IT工程師認領項目，併成爲該項目的項目經理。IT項目採用項目經理負責制，由項目經理負責整個項目的進度和質量，並協調內、外部資源。

二、項目評估

2.一、IT工程師評審需求，即需求分析

        需求分析是整個項目管理的重點，是決定項目是否可以近期交付的關鍵。

        以前的舊模式是，用戶郵件或電話給IT工程師，或召開會議講一遍需求，而後IT工程師就開始着手開發。一方面需求未通過深刻討論，可能用戶本身也沒想明白或講明白，或者是需求來源於某一領導口頭指示，提交申請的人本身也沒搞明白；另外一方面IT工程師的理解和用戶的實際需求之間有很大誤差。結果就是測試時老是沒法知足用戶需求，反覆修改，最終上線的產品和用戶的原始需求相距甚遠，用戶，IT工程師和外包開發工程師都苦不堪言，項目無限期延期，領導也極不滿意。

        在需求評估環節，須要完成如下工做：

1）和用戶及相關部門充分溝通需求，制定方案，對於複雜的項目，須要編制流程圖、繪製原型圖向用戶確認。

2）項目任務分解，相似於WBS，但和WBS還不徹底同樣，按功能和用戶的操做步驟拆分，一步步描述，以便於用戶測試確認，越細越好。

3）識別項目的風險，填入OA表單中，以便於用戶測試時逐一確認。

4）項目經理確認實施人員，哪些是內部實施，哪些須要外包開發？填入實施人員，將自動彙總項目評估人天，自動計算項目的計劃上線日期，項目較多時，會根據評估的優先級排序，項目的實施成本，計入部門費用等。

        外包開發經過開發管理系統管理，須要外包的項目，會傳到開發管理系統。

        選擇發送給至少3個開發工程師，開發工程師將收到短信提醒，同時登陸平臺能夠看到完整的項目信息。評估需求後給出報價人天，內部IT工程師能夠看到各開發工程師的報價，選擇一個合理的報價便可。這個功能至關於一個簡單的招投標管理平臺。

2.二、項目方案確認及審批

        項目經理提交方案和需求清單後，先由產品經理再次確認，確認無誤後經需求部門領導審批、涉及部門負責人審批、IT部領導審批後，項目進入實施階段。

各級領導審批經過是項目啓動階段完成的標誌。

三、項目實施

        項目審批完成後，會通知IT工程師實施，若是有外包開發工程師，會經過短信通知。同時，OA系統會向SAP拋一個採購訂單憑證，處於鎖定狀態，驗收經過後，方可解鎖付款。

        項目經理組織項目團隊開始實施項目，並在實施過程當中控制項目的範圍、進度、成本、質量和風險，並積極地管理干係人的參與。實施過程當中，項目經理應與產品經理保持密切溝通，關注項目的變動狀況，產品經理也應積極主動地與項目團隊溝通，若有任何變動，應當第一時間通知項目經理，項目團隊評估變動對項目範圍、項目進度、質量和成本的影響，並將變動信息填入OA流程中。若是變動影響到外包開發成本，將返回需求部門事業部總經理從新確認。

3.1 Redmine項目管理系統

        Redmine是開源的項目管理系統，功能很是強大，再也不詳述，咱們自定義了大量的字段，而且與OA打通。

        項目管理體系建設初期，開發管理系統和IT項目展現平臺還未創建時，全部的項目都從OA自動傳送至Redmine，如今主要用於管理較大的項目。

        有須要溝通Redmine的朋友可留言或私下溝通。

3.2 開發管理系統

        開發管理系統是用戶、IT工程師和外部開發工程師交互的平臺，除了前面提到的得的詢價功能，還主要有如下功能：

1）開發工程師登陸後，能夠看到本身有哪些項目正處於實施的任何一個階段？是否有延誤？哪些項目已經完成？哪些項目能夠對帳×××等。

2）能夠看到本身的平均按時完成率，在當前全部外包開發工程師中的排名，以利於咱們評選優秀合做夥伴。

3）收到能夠實施的短信通知後，開始實施，實施結束後需上傳相關的文檔，如函數名、字段名、SAP傳輸請求號等。

4）用戶在測試過程當中發現的問題，直接在開發管理系統反饋，相似於BUG管理系統的功能，項目測試過程會提到。

3.3 IT項目展現平臺  

        IT項目展現平臺，不只能夠展現項目的總體指標，還能詳細地展現每一個項目的進度狀態（咱們內部叫紅燈管理），以下圖所示：

        有了這些數據，作分析統計，就很是容易了

1）能夠清楚地看到每個項目每一階段的標準時間和實際耗時，所以能夠初步預測項目是否可能延期？ 

1） 能夠清楚地看到各個階段有多少優化項目，每一位項目經理分別是多少？

2）按月份統計，每月有多少優化項目申請，每一位項目經理分別是多少？

3）每一位項目經理的平均響應時間，平均完成時間，平均按時完成率等。不過目前咱們的總體水平還沒這麼高，並且考慮到內部用戶的工做忙碌程度及配合程度，項目按時完成率方面不是過高。但考慮到全球的項目平均按時完成率只有60%多，咱們也很欣慰了。

        經過設計這些指標，從項目數量，完成質量上均可以很好地考覈，並實時展示出來。

四、項目測試

        內部優化項目不一樣於新業務系統上線等大項目，用戶領導的關注度較低，用戶也由於平常工做較忙，可能會疏於測試。正式上線以後，常常會發現不少場景根本就走不通或存在BUG，通常狀況還好，用戶找IT工程師修改便可，遇到較真或喜歡罵人的領導就麻煩了，任何一個小問題可能都少不了一頓臭罵。

1)  爲確保項目質量，在用戶測試前，項目經理必須組織項目團隊開展內部測試，達到交付標準後（即需求清單要求的功能都實現並已知足用戶指望），方可交由用戶測試。事實證實，這一步的效果很是差，緣由多是多方面的，反正短時間內不容易提升。

2)  項目團隊內部測試經過後，項目經理髮郵件通知全部的干係人開始用戶測試，郵件需註明測試時間段，正式上線日期，測試方法和注意事項等。因爲第一步的效果很是差，這一步就是最後一根救命稻草，不然，出了問題，用戶和IT工程師都會捱罵。所以，咱們選擇在這一環節由用戶和IT工程師共同測試。

3）用戶在測試過程當中發現的問題，直接填寫在開發管理系統，也即集成了BUG管理系統的功能，相似於之前經常使用的Issue list Excel表格。外部開發顧問，IT工程師和用戶均可以跟蹤處理進度。

4)  須要對每一家公司在項目需求評估階段列出的功能點和風險點逐一測試確認。爲了確保測試效果，由系統自動生成一份項目測試清單，以下圖所示。逐一測試經過後，用戶及直屬領導簽字確認後上傳，方可認爲測試經過。這一步把用戶的直屬領導拉進來，出了問題就有人替咱們IT背鍋了。

五、項目上線及驗收

        用戶測試經過後，項目團隊再部署至正式環境，開始上線試運行。

        新開發的功能部署至正式環境時，須要提交《IT變動管理流程》，按變動管理的要求執行。

5.1 項目上線試運行

        上線試運行通常爲1個月，新業務系統上線後試運行通常爲3-6個月。

        試運行期間，如發現Bug，由產品經理聯繫項目經理確認並修改，如須要對程序增減功能，此時再也不容許變動，待業務運行一段時間後，再從新提交新的優化申請。

        若是項目適用於多家子公司（根據申請時選擇的公司名稱），必須在申請單中逐一勾選並確認全部子公司都已上線，方可流轉至下一節點。

5.2 項目收尾驗收

        項目收尾是指項目經理和產品經理確保全部的項目工做都已完成，項目目標都已經實現後，需求部門對項目進行驗收確認，以及項目團隊對項目經驗的總結。

        項目收尾是公司內提升項目管理績效的簡單易行、立竿見影的有效方法，只有總結，才能持續改進、不斷提升，項目收尾也是最好的團建活動。

1)  項目經理應邀請全部合適的干係人蔘與本過程，參與人員包括項目團隊成員和關鍵用戶。

2)  總結項目經驗，分享在項目中的成功經驗和教訓。

3)  更新並歸檔項目文檔。包括但不限於：項目管理計劃、項目範圍、進度計劃、風險管理、變動管理文件等。

4)  若是項目包含了合同，在該階段也須要結束合同。若是項目失敗，仍然須要結束合同。

5)  會議結束後，項目經理須要郵件給全部干係人，包括外部兼職開發顧問，宣告項目結束。

        項目經過驗收並收尾後，標誌着項目管理的工做結束，正式進入運營階段。

5.3 對帳及付款

        因咱們80%的開發都是外包，項目驗收後，須要和外部開發工程師對帳並付款。

        外部開發工程師對帳和付款都在開發管理系統中完成，相似於SRM系統的功能，外部開發工程師能夠隨時查詢付款歷史，待付款金額等信息。外部開發工程師開好發票後，IT工程師選擇須要付款的項目（可多選），輸入發票號，點擊付款按鈕，便可自動生成OA系統中的《供應商月結付款流程》，無需用戶及IT部門再次審批，便可由財務部門完成付款，費用根據申請用戶的部門，計入對應的成本中心。