一、與領導有效溝通

一般情況下技術人員的弱點是過於注重技術而忽視了溝通。做好工作是必須的，同樣重要的是需要得到領導的認可，能幹還要能說，關鍵是要提升自身的溝通能力。

a.與領導良好溝通的前提是能理解領導的意圖、習慣、風格，與領導使用共同的語言。領導使用的語言較多是概括性、本質性、結果性的語言，便於快速抓住事物的關鍵，因此要注意與領導的對話要保持在同一層次上，這需要在平時不斷積累，不斷提升自己看問題的層次。

b. 使用簡明扼要的語言與領導有效溝通，儘可能在較短的時間裡把我們的意思表達清楚。尤其是專案經理，一定要與領導主動、經常性地溝通，讓領導瞭解到專案的進展，遇到的問題，對於一些難以處理的問題如果能同時提出一些解決方案就更好了，這樣也便於領導瞭解到我們為工作付出的努力。

c. 如果領導暫時沒有認可我們的意見或觀點，說明我們還沒有提供充分的理由，或者領導的觀點受到他本人個性、風格和價值觀的影響，或者領導的思想轉變需要一個過程，還可能是領導看到了一些我們沒有看到的風險等等，這時我們應該仍然按照領導的意見行事，因為領導是一個組織的負責人，他需要對組織負責，因而應擁有最終的決策權，這是與領導在某些問題上發生不同意見時需要注意的。

二、調動下屬的積極性

專案經理處於一個承上啟下的中間層，在管理下屬時要分清自己該做什麼，不該做什麼。當專案經理管理一個規模較小的專案時，如果分不清可能對工作影響還不大，但如果要同時管理多個大型複雜的專案，就必須判斷哪些是該做的，哪些應該分給下屬。只有其他人做不了而必須由專案經理做的才可以做，而大多數事情下屬都是可以做的，領導只需要進行培訓、指導和監控，要相信下屬的能力，充分的信任和授權會激發下屬完成工作的願望。

技術背景較強的專案經理容易陷入事必躬親的誤區，因此有必要在思想上有一個比較大的轉變，專案經理不是要自己當技術骨幹，而是要努力把別人培養成技術骨幹。

三、勇於承擔責任，為他人的錯誤負責

勇於承擔責任的心態是自信的源泉。在專案的實施過程中，不可避免地會遇到很多棘手的問題，包括技術、客戶關係、合作伙伴的管理，還會面臨各種風險和衝突，一個合格的專案經理應該能夠勇敢地站出來有所擔當，積極解決問題，不推卸、不埋怨、不辯解，面對內部和外部的質疑、不理解，堅持不卑不亢，用事實說話，想方設法去溝通和協調，最終圓滿解決問題，而回避責任、繞道困難會造成自我認識的模糊和自我懷疑，不可能產生真正的自信心。

由於專案經理要對整個專案負責，因此就不可避免地要為團隊成員的工作包括所犯的錯誤負責，在解決問題和承擔責任的過程，專案經理才能不斷成熟。

文憑，考證，加專案經驗。提升自己是非常有必要的。比如說考PMP專案管理資格證，除了證是能學到很多專案管理方面的知識體系的。在結合自己的實際參與專案的經歷。文武結合一定能行。

首先，想要從技術轉型做專案經理，必須擴大一下自身在管理方面的知識。最基礎的，是學習PMP專案管理課程，學習專案管理方法。業餘時間可以在培訓機構上課或者線上課程也可以。如果想要增加更多作為專案經理職業的機會，最好拿到PMP專案管理資格認證。證書不是一時之用，而是有備無患。

其次，作為技術，習慣從技術的角度看待問題。但是作為專案管理，需要在更高宏觀的角度看待問題，同時也要具備發展的眼光和戰略性思維。更要懂得換位思考，才能在專案中掌好舵。

最後，作為技術人員很多並不擅長溝通，而作為專案管理在溝通方面的能力是非常重要的。如果作為專案管理者，沒有好的溝通能力是沒有辦法很好的協調相關方以及各方資源，也沒有辦法使專案順利的完工。

一個是做實事的崗位，一個是做管理的崗位。

技術人員走專案經理的發展路線，是一條目前大多數人都會走的一條路線。

那麼，如何從一名技術人員成為一名合格的專案經理呢？

1）擺正心態，重新定位自已。從做實事到做管理，這意味著權利多了，責任多了。在一家公司裡，不要認為自身比其它做實事的同事高人一等，其實只不過是比其它下屬同事多了一些經驗，多了一些工作內容。大家都是平等的，只是在工作上，有些事情需要你這個崗位來做決策。所以心態一定要正，重新認識自己，定位自己。

2）理解崗位職責，重新學習。新崗位，崗位職責有所不同，技術人員只對程式碼負責，只對實現功能負責。而專案經理，對事對人對專案都要負責，它要全面把控整個專案的進度、人員安排，計劃安排等。這個時候需要你多點學習，查閱一些專案管理的書籍，案例。

3）提升自我。除了專案方面的學習，橫向學習也十分有必要，在口才方面、待人處理方面等同樣是這個崗位必學技能。

4）報學習班。可以上網報一些學習班，加速上手。

5）每天不斷總結，反省自身。吾日三省吾身，彌補不足。從錯誤中進步。

技術轉管理最難的就是思維的轉變，很多技術都覺得自己很牛，別人不懂，用一些別人聽不懂的專業術語溝通，好像只有別人聽不懂才能顯示自己的能力，其實死就死在這裡。

所以技術轉管理第一關要過的就是思維的轉變，從產品打交道轉變與人打交道，從點性思維像系統思維轉變。

第二關要過的就是"讓我來"，當你看到團隊中有人做事不行，就忍不住自己動手，這是雙輸的事，一定要忍住。只給方向把我原則，堅決不動手。

一點建議如果有幫助給個贊吧！

想要晉升，先轉變思維。

技術型人員

技術型人員是做什麼的？他是具體執行者，去執行管理者的命令。

專案經理

專案經理是做什麼的？他是命令釋出者，監督技術型人員完成命令的進度及質量。

專案經理的必備技能

專案經理不需要在技術上鑽研，他需要的是如何安排工作，如何保質保量的完成上級交給他的生產任務，在這個過程中去把控成本、效益等因素。

好比將軍與士兵，將軍負責佈陣，士兵負責練好殺敵本領。你讓諸葛亮上陣殺敵可能還不如一個火頭軍厲害，但是你讓火頭軍來出“空城計”，可能嗎？

熟悉我的粉絲都知道，我曾經在機械廠做過學徒。學的就是電氣焊，技能考核，我在三百多人裡面是倒數第二名。不到一年時間，我從這三百多人裡，脫穎而出，走向了管理層。之所以我能勝出，我有個最大的優勢就是，我們車間乾的這些裝置，我知道生產流程、各種尺寸、引數。甚至不用看圖紙，都能如數家珍。其他人也知道，但是不全面，他們也不關心，只關心電焊焊縫是否光滑，氣割的線條是否筆直。

機會是留給有準備的人的。班長受工傷，我作為班長也是師父的大徒弟，暫代管理班組，剛巧有批裝置很緊急，需要加班加點趕出來。上級領導擔心我能不能如期完工，我信誓旦旦立下軍令狀。做好工作計劃，加班安排，人盡其才。十多天後，還提前半天完成了任務，就等裝車了。從那以後，上級領導就認定我有管理才能，再後來我也如願以償。

說這麼多，歸納下中心：做管理層，你要會分配工作，什麼崗位就讓什麼樣的人去做。管理層是讓你激發員工的潛能，而不是讓你跟員工比誰技術好，誰的力氣大。

此問題特邀資深專案經理回答的。

學會使用專案管理工具

專案管理上出了問題，管理者總是喜歡從流程規範的角度去想辦法，於是為此設定了不少流程規範，例如每天要寫日報，根據日報更新專案進度，每週要開周例會，看看專案有沒有執行上的問題。

對任務進度的量化也是個很困擾專案經理的事情，需要頻繁的去問程式設計師：“你這個任務進展如何，大概完成比例多少？”，從程式設計師那得到的答覆通常都是個很樂觀的數字，例如 80%。第二天以為他能做完，結果一問是 90%，就這樣要持續好多天才真的算做完。

所以後來我得出來一個結論：一個任務，只有 0% 和 100% 兩種狀態是準確的，中間狀態都是不靠譜的。

除此之外，還有個問題就是，專案的進展並不太直觀，除了專案經理每天看計劃表，對計劃有一個大概瞭解以外，其他人可能只有在到了計劃設定的“里程碑”時，才對進度有比較直觀的感覺。

專案成員手頭事情做完，如果和計劃有出入，也不知道自己接下來該幹嘛，都要跑去問專案經理，所以專案經理對於很多事情都要從中協調，日常有很多繁重的任務管理工作。

後來我發現其實很多管理者都有類似的困惑：任務不好量化難以估算，專案成員對當前專案進度缺少直觀感受，管理者要花大量時間在任務管理上。

這些年，隨著軟體專案管理工具的發展進化，發現當年困擾我的這些問題已經不再是一個主要問題，因為透過工具就能很好的解決這些問題。

這也是我這些年專案管理和技術管理的一點感悟：

一切管理問題，都應思考能否透過工具或技術解決，如果當前工具或技術無法解決，暫時由流程規範代替，同時不停止尋找工具和技術。 專案管理工具軟體發展史

在沒有專案管理工具的年代，都是怎麼管理專案的？

早些年，我除了好奇過大廠是怎麼開發大型軟體專案以外，還好奇過像登月這種超大型專案是如何做專案管理的。正好前不久看了餘晟老師寫的一篇文章《“阿波羅“登月中的工程管理一瞥》，讓我有機會一窺究竟。

其實這種大專案的專案管理並不神秘，就是像我們專欄《11 | 專案計劃：程式碼未動，計劃先行》那一篇講的，這種大專案也是採用 WBS（工作分解結構）把所有任務一級級分解，再排成計劃，按照計劃有序進行。

但阿波羅專案是個超大型專案，所有的任務分成了 A、B、C 三級，到 C 級已經有超過 4 萬個任務。要給這四萬多工排出專案計劃就太不容易了，一共要幾十名分析人員來協調和跟蹤所有的任務。最終列計劃的圖表貼在牆上超過 100 平米。

在沒有專案管理工具的年代，要制訂一個專案計劃非常之不容易，需要專業人士花大量時間，而且每次修改調整，都要再花費大量時間精力。

最初的專案管理軟體：專案計劃工具

直到後來像微軟的 MS Project 這樣的專案計劃工具軟體普及，才讓制訂計劃變成了一個相對容易的事情，可以方便的對分解好的任務排出計劃。

早些年軟體專案的開發以瀑布模型為主，瀑布模型的這種按階段劃分的開發模式，和 WBS （工作分解結構）這種將任務層層分解的理念不謀而合，MS Project 這種軟體可以非常好的將所有任務分解、制訂計劃，按照計劃跟蹤執行。所以那時候會使用 MS Project 就是專案經理的標配。

MS Projec 雖然解決了計劃制訂的問題，但還是有些不足之處。例如不方便跟蹤任務進度，進度不直觀等。

再加上後來敏捷開發開始興起，很多專案都開始採用 Scrum 的方式來進行專案管理，開發變成了迭代的方式，以前單純的專案計劃工具，就不能很好的滿足專案管理需要了。

基於 Ticket 的任務跟蹤系統

傳統的專案計劃軟體還有很多問題無法解決。比如，很多人都有過以下類似的專案經歷：

產品經理口頭讓開發對產品做一點小改動，開發也答應了，後來就把這事忘了，或者測試都不知道還有這事，也不記得要測試這個模組；

程式碼審查的時候，發現組內某個同事的程式碼沒有寫單元測試，但是因為任務緊，只能先上線，於是叮囑他後面一定要把單元測試程式碼補上，結果還是忘了。

日常專案中像這樣的小事情不少，如果不記下來很容易忘記，如果用傳統的專案計劃軟體排進去又很麻煩，直到後面有了基於 Ticket 的任務跟蹤系統，才很好的解決了這個問題。

Ticket 跟蹤最早源於客服的工單（Ticket）系統，每次客戶接到一個問題，就建立一個工單，後續和客戶的每一次交流和處理，都要更新工單內容和狀態，直到結束。

最早在軟體專案中，應用 Ticket 跟蹤系統的領域是測試領域，用來追蹤 Bug，後來逐步衍生到整個專案管理領域，不僅跟蹤 Bug，還用來跟蹤需求、開發任務等。 也有很多系統用 Issue 來表示 Ticket 的概念，無論 Ticket 還是 Issue，表示的都是一個工作任務，可以包括軟體的 Bug、功能需求、某個模組的開發、系統的重構任務等。

那一個 Ticket 應該包含哪些主要資訊呢？

一個 Ticket，應該包含：

標題：摘要性的描述 Ticket 內容；

型別：屬於什麼型別的 Ticket：Bug、需求、任務；

內容：Ticket 的詳細內容，例如，如果是 Bug 的話，除了要寫清楚 Bug 內容，還需要重現步驟。如果是需求的話，要有需求的描述，可能還需要額外的文件連結輔助說明；

建立人：誰建立的這條 Ticket；

優先順序：這個 Ticket 的優先順序高還是低；

狀態：Ticket 的狀態，例如：未開始、處理中、已解決、重新開啟、關閉等；

指派給誰：這個 Ticket 被指派給誰了，誰來負責；

歷史記錄：整個 Ticket 改變的歷史資訊，用以跟蹤；

當然除了這些外，還有一些其他資訊，例如建立時間、附件、標籤、版本等。另外現在的 Ticket 跟蹤軟體都有強大的定製功能，可以增加額外的輔助資訊，例如你是基於敏捷開發，還可以加上 Sprint、故事分數等資訊。

Ticket 的這些內容，基本上可以包含一個工作任務所需要的所有內容。有了 Ticket 之後，無論大到一個功能需求，還是小到一個 Bug，從它建立，一直到完成，整個過程都可以方便的被跟蹤起來了。再也不擔心像任務被忘記等前面提到的這些情況了。

基於 Ticket 去跟蹤任務，不再需要透過日報、一對一會議的方式來收集任務執行情況，負責 Ticket 的專案成員在完成任務後，會直接修改 Ticket 的狀態，這樣其他人就可以看到 Ticket 是否已經完成。

Ticket 透過各種不同狀態，例如未開始、開發中、完成等，可以很直觀的瞭解任務的進展，這就避免了任務難以量化的問題。

Ticket 跟蹤系統和敏捷開發也是很好的搭檔。在敏捷開發中，產品 Backlog（產品待辦任務列表）是一個用來放所有產品的待辦任務的清單，在每個 Sprint 開始前的迭代計劃會議上，從產品待辦任務清單裡面選取一部分任務到 Sprint 的待辦任務清單（Sprint Backlog）中。

當使用 Ticket 跟蹤系統後，就可以把所有產品的待辦任務用 Ticket 都記錄起來，當我們在迭代計劃會議上選取好任務後，就標記為要在當前 Sprint 完成，這樣後面就可以方便的篩選出屬於當前 Sprint 的所有 Ticket，這樣大家就可以從 Ticket 跟蹤系統知道我們這個 Sprint 有哪些 Ticket 需要完成、進展如何。

如果將當前 Sprint 中，從開始到結束，每天記錄一下 Sprint Backlog 中未完成 Ticket 的數量，繪製成一張圖表，橫軸表示時間，縱軸表示剩餘 Ticket 數量，就可以透過圖表直觀地看到還剩下多少工作。

這種用於表示剩餘工作量的工作圖表也叫燃盡圖（burn down chart），可以直觀的預測工作將在何時全部完成。

基於 Ticket 的任務跟蹤系統，很好的彌補了專案計劃工具的不足，讓專案中大大小小的各種開發任務都可以方便的記錄跟蹤起來。燃盡圖也可以直觀的瞭解剩餘工作情況。

如果說美中不足的話，就是整體的 Ticket 狀態還不是很直觀，例如不能清楚的看到哪些任務在進行中，哪些任務待領取。

基於看板的視覺化任務管理

看板本來是在 1940 年由“豐田汽車”發明的生產管理系統，其中一些理念被借鑑到軟體開發中，尤其是其視覺化的任務管理方式，很好地解決了早期 Ticket 跟蹤系統不直觀的問題。

所以現在的 Ticket 任務跟蹤系統幾乎都會有看板檢視，透過看板可以很直觀的看到當前任務進展情況。

參考上圖，可以看出，在看板檢視上的所有 Ticket，可以很直觀的看出哪些還沒開始，哪些進行中，哪些已經完成。

這種視覺化的任務檢視，不僅是對專案經理，可以很直觀看到進展，對於普通專案成員也是很方便。

從“待選取”欄選擇一個 Ticket，拖動到“開發中”欄，表示這個 Ticket 已經選取，開始開發了。

手頭上的 Ticket 開發完成後，就可以將 Ticket 拖動到下一欄——“測試”欄。

測試人員看到新加入“測試”欄就可以從測試欄選取 Ticket 進行測試。

如果測試沒透過，Ticket 就會被拖動到“待選取”欄。

如果測試透過，Ticket 就會被拖動到下一欄——“待部署”欄。

部署完成後，所有“待部署”欄的 Ticket 就會被拖動到“完成”欄。

整個過程完全不需要專案經理從中協調太多，尤其是結合每日站立會議，可以讓專案成員自發有序地按照看板開展日常工作。

藉助 Ticket 跟蹤和看板視覺化，專案經理可以從繁重的任務管理中解放出來，可以抽出來時間做一些其他更重要的事情。

以上就是專案管理工具的一個演化簡史，可以看到，每一次工具的發展進化，相應的很多專案管理工作就可以得到簡化，很多早期的專案管理問題，也就不再是問題了。

有哪些專案管理軟體可以選擇的？

在瞭解完專案管理工具的發展歷史後，再給你介紹一些目前國內國外主流的專案管理軟體，幫助你根據自己專案需要進行選擇。

如果單純是專案計劃工具，功能最好、最全的應該是微軟的MS Project，但遺憾的是隻能執行在 Window 上，不支援 Mac 平臺。如果要在 Mac 上使用專案計劃工具，可選的有OmniPlan和Merlin Project。

而且這些專案計劃工具，現在也都支援了看板檢視。不過如果只是單機支援的話，意義並沒有那麼大，需要線上版的 Ticket 跟蹤結合看板檢視，才能讓整個團隊可以一起瀏覽操作，發揮其最大效用。

基於 Ticket 的任務跟蹤系統，最有名的應該是Atlassian公司出品的Jira軟體，功能全面，體驗很好。Jira 主要是在海外比較流行，因為訪問速度和使用習慣等原因，國內使用者要相對少一些。

同類產品也很多，微軟的Azure DevOps （以前叫 TFS, Team Foundation Server），和微軟系的產品如 Visual Studio、Azure 可以很好的整合。

程式碼託管平臺GitHub本身也集成了一套 Issue 跟蹤管理系統，雖然沒有 Jira 那麼強大，但是對於普通專案來說，足夠用了。尤其是對於開源專案，完全可以基於 GitHub 的 Issue 進行日常的專案管理。

國內同類的軟體有：

禪道：為數不多提供開源版本可以自己搭建的；

Worktile：集成了即時訊息軟體；

雲效：阿里巴巴出品，可以和阿里的服務很好整合，例如阿里雲和釘釘；

DevCloud：華為出品，和華為雲有很好的整合。

還有一些其他很多產品，這裡就不一一列舉。

那麼該如何選擇適合的工具呢？

從功能上來說，基本上，上面提到的每一款產品都能滿足日常專案管理的基本需求，建議從專案特色、團隊成員和價格服務等因素綜合考慮。

例如說你的專案完全是微軟技術棧，就可以考慮使用 TFS；如果你深度使用阿里雲和釘釘，那麼就可以考慮阿里的雲效；如果你想自己搭建，那麼就可以考慮 Jira 或者禪道。

這些產品都有免費版本，可以先試用，你可以仔細對比後，根據自身的情況再最終決定。

總結

今天我帶你一起了解了軟體專案管理工具的發展歷史：從完全手工方式管理專案，到藉助計劃工具分解安排計劃，到基於 Ticket 跟蹤管理任務，再到基於看板的任務視覺化。每一次工具的升級，都是對專案管理工作的一次簡化。

合理的使用專案管理工具，可以幫你極大提高管理效率，起到事半功倍的效果。我也列舉了一些目前國內外主流的專案管理工具，希望可以幫助你做出選擇。

最後，對於日常專案管理的問題，你也可以多思考是不是可以由工具或者技術手段來解決的。

對於技術轉專案經理，從自己擅長的方向出發，相信你會做得越來越好，加油。