做PM，打雜不可怕，可怕的是3年後你還在打雜
專案管理是什麼？
怎麼樣才能做好專案管理？
為什麼有的人
不是技術專家，沒有同類業務的深入實踐
怎麼看都不覺得他有什麼先天優勢
然而，隨便把一個多麼錯綜複雜的專案交給他
他最終都能做出令人滿意的效果？
而另外一些人
是上下公認的技術專家
無論程式語言還是資料庫
無論系統架構還是網路拓撲
（oh！這段freestyle好有節奏感~~）
說起來頭頭是道
以至於總是讓人滿懷期望的把專案交給他
最終的結果卻往往令人失望
到底是什麼拉開了我們之間的差距？？？
IT專案管理的最終目標：實現、產出
每一個專案都是不同的，所以再多再好的經驗，在另一個專案中都是無法重現的。
因此無論PMP還是CMMI，其實都只能告訴我們一些放之四海皆準的理論，這些理論背的再熟，在專案實踐中的作用還是要看個人發揮。
但並不是說專案管理就無章可循，有的，不僅有，而且很簡單，只有四個字而已：以終為始！
展開來說就是：找準專案目標（這個最重要！）、控制專案範圍，然後圍繞目標，找資源、要政策、控制時間……動用一切合理合法的手段去實現目標！
IT的專案管理要達到一個什麼樣的目標？
只有徹底搞清楚這個問題，我們才能知道要做什麼工作。
1. 專案管理要解決的問題：
2. 研發團隊專案管理的問題：
3. 測試團隊專案管理的問題：
專案測試工作排期，包括編寫測試用例、及黑盒測試工作排期。
測試風險管理，主要包括
然後，專案管理在各個環節最關鍵的工作是計劃和風險。一個計劃是為了給一個有固定需求範圍、人員的專案一個時間目標。
很多的計劃是為了保證在人力資源和時間範圍有限的時候讓需求範圍儘可能的大，也就是高產出。風險則是為了保證專案計劃的目標能成功達到，同時又能保證產出專案的高質量。
IT專案管理的制度目標：透明化
那怎麼落地？客觀上來講，這個目標是包含產品、研發、測試在內的整個團隊的目標，特別是專案管理，在這裡顯得很無力，因為專案管理人員既不能幫產品梳理業務寫PRD；
也不能擼起袖子自己敲程式碼、也不能越俎代庖做測試，當然也沒這個時間。那麼專案管理人員能怎麼去達到這個目標呢？或者能怎麼發現當前團隊的產出是否是高質量、高產出的呢？
似乎這個問題提到了點子上，接下來我需要搞清楚：
怎麼發現當前團隊的產出不是 高質量、高產出的呢？
以下是IT專案研發所涉及的團隊，和各個團隊中會導致不能達到高質量、高產出的一些場景。
1. 研發人員
2. 測試人員
透明化程度越高，產品規劃、專案計劃、人力資源安排、跨團隊協作、延期等風險就能比較快速的展現到整個團隊面前，專案經理就能儘早並且比較充分的時間來協調並將風險造成的影響控制到最小。
流程規範的透明化在於確保產品業務方需求介面人、產品、研發、測試對流程規範有一致的理解，這樣的流程需要各團隊配合專案管理所做的工作要儘可能少，價效比要足夠高。
Value1 = 各團隊在專案管理中投入的時間資源價值。
Value2 = 流程規範推動產品研發產出和質量的提升的價值。
價效比= Value2 – Value1。
給予共贏的局面，參與專案的各個團隊對流程規範有一致的理解並完全接受的。
專案管理過程的透明化
可以基於下面的模板來體現，一些常見的專案管理工具Scrum看板都可以做成包含下面屬性的卡片，也能在計劃時間的不同階段有相應的提示預警。
一個版本迭代的週期控制在1-2周左右，建議最長不要超過1個月。專案週期過長則建議調整產品規劃方案。
【專案名稱V1.0.0】當前迭代核心需求範圍概述：
專案經理
研發成員
研發完成時間
測試成員
測試完成時間
一個包含團隊所有專案的Scrum看板，可以充分的展示團隊處於各個階段的專案，能反映出研發測試進度健康狀態。
能反映出研發中心的現狀和後續計劃，能反映出人力資源的使用情況。從而能暴露出專案存在的問題和風險。
IT專案管理的過程目標：及早暴露問題和風險
一個考過PMP或者一個對專案管理工作有所瞭解的人都知道專案管理需要做的工作內容。但是專案延期始終是各個領域司空見慣的現象。
更多人對延期習以為常，或者覺得不延期不正常。因為專案管理的過程最難把控。
過程的把控是為了把過程中的問題和風險造成的影響透過及早協調解決的方式降到最低，而這及早協調解決的前提則是及早的暴露問題和風險。
所以，專案管理過程中的目標是及早的暴露問題和風險。
總結
專案目標怎麼定義？客戶？專案任務書？合同？
在經歷過深刻的教訓之後，終於領會到：在有的時候，真正的專案目標是由上司來定的；甚至，這個隱含的、真正的“專案目標”，可能與紙面上透過合同或是專案任務書規定的，截然相反！
識別出真正的“專案目標”，並且巧妙的把明示的專案目標與隱含的專案目標結合在一起，在兩者間尋找到共同點。完成一個的同時，也滿足了另一個——這可能就是3年之後是否還在打雜的區別！