Online @ 一百零五號

當要講到專案的開始期中和結束最重要的三件事情的時候，我們需要先對專案作一些定義：

專案：廣義而言，係指一個特殊而有一定限度的(Finite)任務，或由一群聚相互關連性的工作所共同組合起來的任務，而該任務是以獲得特殊結果或圓滿達成某種成就為目標。　　　～ http://www.npma.org.tw/　：什麼是專案管理

專案管理：根據美國「專案管理協會(Project Management Institute, PMI)」 所編訂「專案管理知識體系範本(PMBOK Guide)」的定義：「『專案管理』乃是將管理知識、技術、工具、方法綜合運用到任何一個專案行為上，使其能符合或超越『專案利害關係者(Stakeholder)』需求與期許的一種專門科學；在執行過程中它必須兼顧

(1)專案的範疇、時程、成本與品質目標的達成，及尋求 
(2) 『專案利害關係者(Stakeholder)』間不同的需求與期許和 
(3)確認的﹝需求﹞與不確認的﹝期許﹞間之均衡。」

簡言之，「專案管理」是一既有效率又有效益地將專案成功執行的一種程序與方法；而其所關切的是如何將一項任務能如期、如質及如預算的達成並充分滿足需求目標。 ～　http://www.npma.org.tw/　：什麼是專案管理　

專案經理就是管理專案的人。三件在專案進行的三個階段（開始，期中和結束）中最重要的事情：

開始：專案一開始的時候，由於專案經理對於需求呈現的是一種不了解的狀態或是了解但是不透徹，更由於對專案需求的不了解不透徹以至於對資源的需求的不確定，不確定的資源需求以至於成本的估算困難；更甚者對於Stakeholder 的溝通困難。雖然現在一般政府或金融機構對於大型專案有開相關的規格以利廠商成本的計算需求的預估，但是規格的制定通常會與實際專案執行人的想法會有些許的出入，所以當專案開始的時候要注意的三件事情就是：

1. 需求的確認
2. 了解Stakeholder 對專案的認知及期許
3. 利用第一和第二點來推估及Markup 相關的成本及資源需求

這邊其實應該還有一點，時程的規劃管理，但是根據經驗法則我把他歸到期中來注意，後面會在來詳述

期中：此時專案已經進行到一半了,通常專案的需求大致底定，相關的系統已經過了SA的階段，直接在程式開發，這時需要注意以下幾件事情

1. 需求的在確認與底定：專案進行到這裡，需求通常應該已經確認了吧，但是這是通常，根據歷史慘痛的經驗，需求是兩造雙方『溝通』的產物，因為是溝通所以會產生落差，所以常常會出現，見鬼的現象，但是見鬼還是好的，最怕是鬼打牆，這裡注意需求的在確認與底定是在依照先前討論的規範下最些許的變動以滿足Stakeholder 的期望，最好是產出相關的UI Prototyping 給Stakeholder or User看，減少兩造對『溝通產物』的落差。
2. 專案時程的管控：需求的在確認與底定後，會更進一步的瞭解到專案的相關時程規劃的是否出現極大的落差，作最後的確認，相關資源的需求到為是否會影想到專案時程的進行，之所以沒有在開始的時候特別強調這一點是因為有很多的變數會出現在專案開始進行的當下，而放到期中來看，是因為這時候再不看，你就等著被老闆罵了
3. 風險的管控：專案進行到這個時候風險的管控就顯得非常的重要，當然不是說之前不重要，而是很多事情都是一步接著一步的進行，很多環節是一個接著一個，其中會不會產生不可預期的事情以至於環節的斷裂波及到專案的成功與否，放在期中來看是因為這時候出現的狀況還來的及解決，而最多的風險也會在這個時候出現，舉一個例子來說好了：我曾經遇到過全省HP Server 大缺貨的狀況，這是在最初訂貨的時候不曾能預估到的風險（這很難事先猜到的），所以這時候如果能在期中因為時程的確認，就可以先行把相關的資源到位以避免風險的產生。

結束：結束是整個專案的靈魂，你可以前面處理的模模糊糊，你可以在前面混的一塌糊塗，結束專案的過程，是整個專案的重心之所在，所以千萬要把握好專案結束的最後一個階段，當然前提是你老闆前面都沒在管你，他是只看結果的話。雖然我的話是這樣說得，但是前面幾個階段你處理的不好，混的太兇，現在專案結束的尾巴，就是你苦難的開始。專案進行到這一個階段該完成的系統也大致交付給User開始作 UnitTest 甚至已經開始作系統整合測試。這時候你要特別的注意幾件事情：

1. Stakeholder 對專案呈現的感受：我這裡原本寫的是風險的管理，但是後來想一想，Stakeholder 對專案呈現的感受是非常的重要，因為如果他覺得你現在做的不是你要的，那就好玩了，這時候專案經理必須再不影響系統主架構及專案完成時程的前提下，盡量修改程式以符合Stakeholder 對專案呈現的期望，專案才能順利的結案。
2. 交付文件的齊備；交付文件的齊備是很重要的，最好是事先寮解到相關承辦人員對於文件的認知，或是最終使用者對文件的認知，盡量不要與這兩者產生太大的落差
3. 驗收的作業流程（付款流程）：這就是結束的Key，有些公司，會有什麼驗收會議，裡面可能包含說要有壓力測試的數據啦，還有就是一堆相關測試的數據；有些可能需要 經過UAT(User acceptance Test)，使用者同意後才可以驗收….等相關需求。要先行瞭解到這些驗收需求，關鍵人物是誰，因為這些都是有關專案結束的重點作業。

以上雖然我分別對三個階段分別敘述了一些，需要注意的事項，但是這些不是只有在那個時階段才需要注意的通常是每個階段都要注意但是就是比重不同 

風險的管控：這時候風險的管控就顯得非常的重要，雖然我在期中就已經在注意風險的管控，但是有些東西會出現在系統整合的時候會發現問題，或是交付文件中他忽然注意要作異地備援，然後又發現他竟然是銀行機構必須要間隔三十公里，就算前面做的再好後面這裡出了一點點小小的錯誤就毀於一旦。