前言1：

我本是一個創業失敗者，放下曾經所有的不切實際。告別深圳，來到惠州從最底層的程式設計師開始，效仿自己10多年前從頭來過，

入職在這一個八千人的製造業公司中，發現這裡的同事關係都是清淡的，甚至直接領導和下屬也是清淡的。

回想剛入職那會我就默默在那寫程式碼，哪怕這只是一個三十人規模的技術部，我入職2個月了總監都沒跟我單聊過一次，這就是大公司吧。

記得有一次，晚上9點了。由於專案第二天要上線，我還在那加班，總監剛開完會出來，看到我一個人在那。我以為他回過來體面的問候我一下，比如說一句：“怎麼還在加班，遇到什麼困難了？”

然後只是瞅了一眼，就回自己辦公室了。背上包從辦公室出來，直接走了。那一刻我怒了！

我覺得領導看不見我，心裡默想：“你不是看不見我嗎？我就讓你看見一下”。

雖然說從頭開始，可是打心裡還是有那一股子傲氣。工作十年，五年開發，四年管理，一年創業。十年工作經驗的我哪怕是從頭來過，再爬上去我也不可能又要花10年。

後來就有了《手把手擼套框架》這個系列的部落格。在部門內部組織了一次非常成功的培訓，Victory框架被部門稱“開發框架1.0”。

這也是製造業不像網際網路那樣重視技術部門，導致技術部門同樣不重視開發。讓我抓住機會好好秀了一把，在培訓會上我直接說我覺得我可以擔任架構師。

後來，領導經常叫我去辦公室，談各種話題。有技術的，有管理的，也有指導我很多。 最後他沒讓我當架構師，卻讓我當了“專案經理”。

確實，比起開發技能，部門的專案管理幾乎是一塌糊塗。畢竟七分業務，三分技術。隨後我從專案經理，一直往專案集經理的路線發展。這就是我想寫《專案經理指導手冊》的原因，等同於制定一份專案經理的“開發框架”。

前言2：PMP只是一本字典

我是2015年考的PMP，在我剛做管理的時候，那會沒人教我技術部應該怎麼管，我經常逛部落格園看文章，有看到一個作者寫的《從程式設計師到專案經理》的系列文章（這哥們還出了書），其實這個系列對我幫助沒多大，只是讓我知道了有PMP

這個東西，去培訓了，也考證了。PMP似乎是所有專案經理，必考一個證，在很長一段時間裡 我覺得PMP 沒什麼卵用。 PMP是把所有的活動都去理解成一個專案進行管理。也就是說無論你造橋，修路，蓋房子。讀可以去套用PMP。都是啟動，規劃，

執行，監控，收尾，這個五個基礎過程。 都是“範圍管理、整合管理、進度管理、成本管理、資源管理、風險管理、質量管理、溝通管理、採購管理、相關方管理。” 這就活脫脫的一本字典，沒人照著字典寫作文吧。 真按PMP去做專案一會完蛋。。

很可悲的事情是，軟體行業很長一段時間的管理模式都是平移自建築業、製造業。軟體行業有他的特殊性，就拿需求變更來說，造橋，修路不可能造到一半突然改方案，軟體行業就會，而且很頻繁。造橋修路來不得一點質量問題，否則就是一場人禍，

但軟體行業可以不斷升級，甚至重構。

　所以，一次成型，資源無限很多情況只存在理論當中。當然我的理解也會有一定的片面，這個我必須承認。因此，我也認為認為 自研專案的話，採用“瀑布模式” 的適用場景同樣非常少。

前言3：瀑布與敏捷

瀑布與敏捷，本身沒有孰優孰略。 也不想網上說的敏捷比瀑布快， 這個本身不存在的。只是兩者在理念上有所不同，瀑布要求的是 “全量交付”。而敏捷是“增量交付"。 而且，敏捷佔用資源更多，還要求是優質資源。

對於人員的管理要求也不一樣，瀑布的管理模式 專案經理指導，而敏捷是要求員工有自驅力，能自管理。 這個難度上其實比瀑布難多了。

為此，我特地去考了一下《Scrum敏捷專案管理》 也拿到了 “Scrum Master” 的證書。 總體感覺就比實行PMP 或者 瀑布，自在多了。

===============================華麗的分割線==============================================

以下內容是我 在這現在任職公司 做專案經理之後，對部門軟體專案管理改善後的指導內容。90%的思想是基於“Scrum” 的基礎，結合了一點 “OKR” 的理念演化而來。。

所以，不具備 “通用性”，在這裡寫成部落格除了把自己的 想法做一個記錄以外，也是為了將規範化，後期在新人培訓上能減少一些溝通成本。

另外，也是一種經驗積累，持續維護這份文件的話，這能成為我行走江湖的一招半式。

===============================華麗的分割線==============================================

　　　　　　　　　　　　　　　　《專案經理指導手冊》

開篇

《專案經理指導手冊》是我根據入職公司以來閱讀的《OKR工作法》、《Scrum實戰指南》兩本書的思想總結，經過多個專案實戰的檢驗和不斷完善，自我感覺可以將其固化下來成為一個

專案經理工作的通用方法。現代軟體行業的高速發展對專案經理的要求越來越高，不僅僅是需要掌握瀑布模型，PMP、敏捷 等等專案管理手段，更需要專案經理以此為基礎結合工作場景做出靈活性管理。

因此，手冊中對針對，調研、工具、角色、會議、需求、任務、測試等多個維度進行規範。

　手冊的願景是，降低專案經理門檻，提高專案交付能力。無規矩不成方圓，無規範難以協同。對於專案經理來說適當的規範和標準不是要去消滅專案經理的創造性，而是要將專案經理的行為標準化，降低

溝通與管理成本。以一種普遍的方式形成共識。 基於共識一起工作，提升協作效率，儘可能的少踩坑，杜絕重複踩坑，切實提升專案管理能力，做出好專案。

一、成員篇

（1）規模，美國CHAOS協會，做過一個調查。得出一個結論。敏捷團隊人員規模，10人範圍內人數和效率是正比上升的，12人以上的效率曲線是下降的。所以在Scrum提出合理人員規模應該在： 7±2 人。

　　　即最小團隊位5 人。 最多為9人。 （敏捷也有大規模支撐方案：SAFe，但是不適用我們這種場景。）

（2）角色，我們在軟體專案中會聽到各種角色：專案經理、需求分析師、產品經理、程式設計師、架構師、測試、UI設計師等等。在Scrum中只有三種角色：

　　　1，Scrum Master 敏捷教練，保障敏捷正常進行。

　　 2，Product Owner 產品經理，驅動產品成功。

　　 3，Developers 開發者，開發軟體，負責交付成果。

　　　這種模式，下沒有專案經理，Scrum Master 職責是保證專案按敏捷模式不偏離方向的進行下去。Scrum Master 沒有權力，更像是一個保姆。

　　　我們在實際專案中，很難在客戶那裡解釋自己是Scrum Master。

　　　所以，在角色分工上，我所處的製造業資訊化專案，角色上進行了一些結合。如下：

　1，專案經理：專案中擁有權力，把握專案方向，負責專案中的管理事務，結合PMP五大過程組，十大領域，對專案進行管理。

　　 2，產品經理：設計產品，規劃產品交付優先順序。擔任業務方和團隊之間的橋樑。結合

　　 3，實施工程師：推進產品落地，負責培訓，指導使用者使用系統。專案一線作戰員，解答使用者問題，收集並反饋使用者需求和問題。

　　　4，測試工程師：保障專案質量，編寫測試用例，執行軟體測試工作，包括不限於，功能、流程、效能、安全測試。 專案質量的守門員。

　　 5，開發工程師：軟體開發，根據設計文件編寫程式碼；根據設計文件編寫單元測試程式碼，按需求交付軟體。

　　 這裡，有一定的侷限性，一般還有UI設計師，但是工業網際網路，都是各種系統型別的專案，所以，幾乎沒有美工方面的設計。

　　　前面說標準團隊的成員是7人正負2人， 這裡就佔了5個角色了。我定義的比例是： 1:1:1:1:3 （開發3人）

　　 在我們公司，由於設定了一個經營管理部的獨立部門，由這個部門負責資訊化戰略規劃。所以，關於企業上線什麼產品，要做什麼功能，其實是他們部門決定了。當然，他們不是業務方，也不能把他們理解成客戶。

　　 這裡，經營管理部，理解為產品經理的職能部門。

（3）複合。敏捷中講究T型人才，一專多能。我們也之為複合型人才。專案中，我們不一定能真的把 專案，產品，實施，測試，開發，按比例給配齊了。往往是“缺胳膊少腿”的, 但是工作和流程卻不會因此減少。

　　　　因此，往往我們需要變通，我覺得幾個角色中，是崗位缺失的情況下，是可以切換或短時間兼任的。

　　　　1,專案經理 <=雙向=> 產品經理

　　　　2.測試工程師 <=雙向=> 實施工程師

　　　　3.開發工程師 =單向=> 測試工程師

4.開發工程師 =單向=> 實施工程師

直接切換或兼任的情況，一定只能短時間應急，規劃的五種角色是專案中必須的角色，沒有哪個角色是可要可不要的，兼任一時可以，長期就會造成兩頭 都做不好。職責分離是團隊協作的基礎。再次強調，不是萬不得已

不要用這種方式去執行專案工作。