0. 寫在前面

剛重置了"中文部落格"，發現空空的，這很不好；正好現在換工作，就寫一點專案管理的東西。

本篇主要有哪些內容呢？(後續可能有一些微調)

• 正兒八經的專案管理全貌
• 小團隊管理的一般流程(excel展示)
• 一個完整的案例展示(Merlin Project)
• 專案經理的主要工具，我的替代工具
• Excel放飛自我(用Excel來排進度)
• 從技術到管理後的變化(逢人讓三分，應對突發事件)

1. 正規軍的專案管理理論

理論來自於實踐，而又指導實踐，但最初可能總結於一些高手團隊的實踐，然後用於非正規的專案。

我聽到的最多的，關於這些指導理論的評價是: 學院派，過於理論，不切實際，無法實施。

不做評論，只講一句: 存在即合理。

正規軍的理論大致來自於 PMP 以及 IPMP 兩大派系(美國的 PMP 大致相當於歐洲的IPMP Level D)，但國內以及國際多認可 PMP。(您可以參見一下 暴雪 的高階專案經理招聘要求看看)

PMBOK 總共包括 10大知識領域，5大管理過程，47或者49過程矩陣，我直接這裡貼一個圖吧:

圖片知識來源於 PMBOK，圖片本身來源於這裡。

• 僅僅通過我這裡列舉的也就算有了個概念，具體還需要系統學習 --- 對於 newbee 而言

該有的都有了，就不展開了。

哎呀，我超趕時間的。

2. 小團隊的專案管理工作

小團隊的專案管理工作一般是比較累的。

怎麼講？

如果你只是純粹的做專案管理的話，其實比起一線編碼的技術工程師，活少一些，但壓力明顯大一些。然而小團隊&創業團隊&startup，最嚴重的問題就是缺人，人員流動性太大，而且普遍的情況是，人員的編碼素質&效率偏低(如果你在大廠待過的話，就會發現大廠的人專門負責某個模組，編碼以及解決問題能力要強的多)。

• 老闆或者總監心裡大概也知道，但也無奈，既要盈利，人員也要生存。--- 人招多了也不好，利潤被壓沒了

故而做專案管理的工作，時不時的還要去補缺。且資源也不足，導致可用於建設完善專案管理的精力又被進一步擠壓。

同時，有時候專案多了，可能一個人就需要管3，4個小專案的進度以及溝通交涉。(我這裡還沒有談組織團建什麼的)

但麻雀雖小，五臟俱全。越是有挑戰，越讓人懂得集中精力完成優先任務。

2.0 整理流程概覽

一般為了減少後續返工的概率，也還是會遵循一定的規章制度&計劃流程。

當然肯定不可能是完整的 軟體工程 那樣步步到位啦，但小團隊的流程(SOP)該有的還是有的，大致上就這麼個流程: (草圖)

當然實際專案肯定不能是草圖，我只是說明一下意思。一個簡單的專案所需 文件集合 大概如下:

這裡我還沒有給出使用者手冊呢。

2.1 詳細展開說明

上面的文件不能都展開，單挑一兩個出來展開吧，主要給那些沒有相關閱讀許可權的工程師當過過眼課:

比如測試用例:

比如需求進度管理:

等等，按照上面那個草圖，專案經理一般做好專案整體流程把控，但這個表一般給自己用以及彙報用，示例如下:

如果有時間，除了進行 單體測試(UT)，可能還需要進行 系統測試(ST)。

基本形式差不多就是這樣。(但很多小團隊連這個基本都做不到 --- 技術負責人&總工沒有把好關)

2.2 我經歷的大廠專案管理

大廠怎麼搞？ --- 如果是專案型組織，比如一些諮詢公司(先確定是哪類的諮詢，然後Case分到各個專案經理)，他們會更加規範規劃。

我經歷過的硬體大廠，除了有 專案部 的專案經理，還有具體事業部子部門下面的軟體經理，做類似的全職監督和負責某個大專案的具體某個版本的工作。

具體您還是參考 PMBOK 吧。

3 完整案例演示(Merlin Project)

"來，說幹就幹"。(好汙的臺詞啊)

這裡我先用專業的軟體 Merlin Project 弄吧，後面再說 Excel 怎麼搞。 (業內大佬，讓您見笑了)

我為什麼不用巨硬(Microsoft)的 Project 2019/2016？ 因為用不起，感覺訂閱太貴了！(盜版？祝你永遠不會踩到高壓線)

實際上 Merlin Project 我也不是主用，現在主要用 Excel。

由於是演示專案，工時就用天代替，專案週期姑且算作一個月吧，來先啟動專案(kick off)。

然後為了簡便，這裡就直接啟動了 -- 直接認定要做這個專案(賺這個鈔票):

一般設定時間最好還是隻設定最早和最晚(而非精確設定)，給與一定的靈活度:

然後就是通用的，需求調研，概要設計，詳細設計等:

而且就我的開發經驗而言，在這裡就要完全確定好資料的流向，格式，模組協作的媒介(一般要 解耦 的話不會直接通訊的)

• 插曲: 有一次聽到有人翻譯的 概要設計 這個詞彙時，用的是 gerneral，怎麼說呢，其實更加準確的說是 PD，preliminary design phase 概要設計階段。

詳細設計編碼以及測試:

最後評審，交付，總結，歸檔:

難麼？真的沒有 --- 我說的是用這些工具。困難點可能來自於各種突發事件的應對以及抗壓能力。

(見下文)

4. 專案經理的主要工具

我是說硬工具，而不是 soft skills。

就我用過的來說，沒有別的，就是 office套件，外加專案管理工具。(如果專案經理還幹研發，還幹需求，那就不止了 --- 還需要 IDE，原型工具等)

而專案管理工具，根據專案的不同&公司投入資金的不同，選擇的工具的也不同。除開各領域的整合工具，比如IT研發領域比較常用的有zen(缺陷管理)，jira，IBM研發供大公司使用的蓮花等，然後就是通用領域的專案管理工具，常見的Microsof 的 Project，macOS平臺的 Merlin Project。

當然我們一般為了省錢都會用 Excel 這種萬能工具來折騰。

您還別說，挺好用的。

5. 我的替代工具

如果公司能有錢訂閱 MS Project，那我肯定用專業的啦，如果沒有呢？

那我就用 Excel，主要是記錄專案開發計劃(就像上面的)。

其實如果是甘特圖，扇形圖等等，圖形 plus 資料相關的，一律都是 Excel。

沒辦法，能省就省。節約不見得是美德，但日子能過下去。

其次我也用資料庫，SQLite，Access 等這類單機小體積的(mysql, meriadb以及nosql, new sql就算了)，畢竟技術出身嘛。

(其他非專案經理專屬的，我就不列舉了)

6. Excel來秀一波

我不算是 Excel 大佬(大佬都是拿 Excel 來分析股票的吧)，只是在用而已。

或許我玩 IDE 的時間都比 Excel 長 --- 這並不表示 Excel 可玩性差。

• 插曲: 很長一段時間裡，我都沒有意識到 Excel 的強大 --- 認為那只是非 Pro 人士的選擇，我們能 Coding 的直接用 指令碼語言了(比如 shell, python --- 主要是 python)

OK，回到正題。

(開一罐薯片)

新建一個 Excel 文件，然後準備一些基礎資料，大致如下:

然後製作甘特圖只需要 開始時間 和 持續時間 就夠了。

然後需要先選中資料，再插入相關圖形圖形:

1. 選中 任務名稱 和 開始日期 兩列
2. 插入 -- 圖表 -- 柱狀圖 --- 條形圖 --- 堆積條形圖

你會看到條狀堆積圖。

其實只有橫縱座標是我們需要的，藍色的條形圖其實不需要。後面在通過設定格式來把它消除掉吧。

接著再來新增 持續時間，選擇藍色的條形圖，選擇資料:

• 點選右鍵，也會出現 選擇資料 的選項。

然後此時注意一下這裡的設定，先選擇新增一組資料才行 --- 點那個 + :

然後對應的資料選擇 持續時間 那一列，操作如下:

最終效果:

藍色的條形圖還是消除了吧，選中藍色條形圖，然後設定格式:

大概就是這個樣子了:

OK 有點意思了，但橫座標的時間貌似和想象中的有點兒差距啊，調一下橫座標的顯示:

看來需要計算一下了，怎麼算？你是不是第一時間想到了 Google 一下？其實不必要，觀察一下圖形即可:

• 最大值跟最小值之間，相差多少天？120 天，對應了最大值和最小值是多少: 44200，44080。此時可以計算單位天對應的距離是: (44200-44080)/120=1
• 44080 對應的是 2020/10/13，而現在橫縱表的起點是 2020/09/06，中間相差了38天。相差多少距離呢？ 38*1=38，也就是說最小值擴大一下設定為 44080+38=44118

最大值也是響應的計算方式，但要縮小最大邊界值而已。(別算了，我算好了，直接直接設定為44190吧)

順便把 數字格式 設定一下:

還能再好麼？OK，是時候根據自己需要來繪製更多功能的圖了。

就點到為止吧。

簡單吧？簡單麼？您做做看看就知道了。

7. 從技術到管理的變化

7.0 技術榜身

除非是高階專案經理或者有專門專案管理團隊PMO，一般而言，技術大概率還是要榜在身上的。

不同的是:

• 做工程師時，你要熟悉模組&領域的每個細節，技巧，常見問題及其一般解決方案，注意並沒有講"僅僅是解決思路即可"，而是應該具體到提供解決方案，快捷解決手段。
• 做專案管理時，也要熟悉技術，但此時要熟悉和記憶的，並非具體的知識細節了，而是要記住大致的技術選型，一般的解決思路。為的是，在必要時可以拼接、搜尋資料彌補相關一線人員的空缺&或者在排工期的時候不被其矇騙

這裡用詞比較靦腆: "必要時刻" --- 因為總是缺人的話，請向上級申請招人，否則自己很容易成為兩個工作領域的半瓶子水，影響自己職業生涯。相對而言，大公司分工明確，一個蘿蔔一個坑，要好的多。

7.1 個人過渡案例

我個人選擇專案管理，大致是三年前，那時候我已經玩技術玩到了kernel層了(BTW，大學時就沒少玩，什麼 arp 攻擊搶室友網路，檢視tcp/ip核心實現，linux系統程式設計，c++ qt, java spring, web service等)，但感覺不到任何滿足(成就感可能還是有，可能就是交大作業的時候吧)，但距離我的人生兩大目標太遠，故而轉型。

然後，其實這裡還有一個最關鍵的因素， 機會和條件。我當時是因為有熟人(自己人)袒護和攜帶，才慢慢走過來的。

• 至於離正規軍(國際水準)有多遠？我猜可能還有點距離 --- 這也是我要回到資源豐富的地方 --- 大平臺發展的原因。

7.2 逢人讓三分

轉型之後，我體會最多的問題不在解決問題上，也不在為客戶創造價值上，更不在完成交付上，在需求理解上！

• (包括後續的需求變更，交付扯皮根源都是這裡；但新增功能，做二、三期工程則不屬於次範疇)

我曾經在需求研討會上發現東西已經做了一陣子了，又發現雙方討論時需求還是有一些大出入，而且問題還比較煩，因為程式設計師很多都很固執，有脾氣，一般都覺得自己牛，然後客戶那邊兒呢我不曉得他是在以前的基礎上改變過需求(這一次會議自己追加的)，還是礙於面子自己沒有理解程式設計師&實施人員的內容(因為多半是程式設計師做了一些東西，然後客戶先確認一下是否偏離了方向，或者階段性成果驗收時，先由程式這邊講解，然後雙方交流)，敷衍過去導致的。

可能兩方面都有。

需求方中途跑來說，做的東西可能有點出入!!! What the xxxx?

你說客戶是需求變更吧，他不承認，他說這邊做跑題了。(當初需求會議上你怎麼親口確認總工的複述的？)

但我敢得罪甲方爸爸麼？？？

當然這也是很久之前的問題了，藉著需求來說明溝通，處理和協調中存在的問題。

雖然問題各不一樣，除開故意埋坑的，多數情況下，我個人總結對於需求的理解問題，還是 智商上的差距，然後需要情商來彌補 (照顧雙方的面子，哪怕有一方你明顯聽出來對方不專業)。

工作中人與人的智商差距，真的有很大的影響。

這一點不管是上學時還是工作後，都很明顯：反應力，接受能力慢的人，再不勤奮一點，註定成為團隊的扶持物件。

回到主題，程式設計師多半比較實在(你看他們的job position&title 也看的出)，然後就是能忍耐(可能也是因為薪水非常高或者非常低吧)；相對的客戶啊，業務員啊，銷售啊，那就有點虛了，你看他們的 title 隨隨便便都是個 consultant(顧問)，然後就是某業務負責人，區域負責人blabla。這裡沒有貶義，可能職業需要，必須要講一些高大上的，陽春白雪的東西吧。

所以，這裡就需要一個種技巧，那就是逢人讓三分，和氣好生財 --- 即便對方確實不專業，確實水的不行。（注意必須先確立個人做人的原則！別跑偏了）

能夠 包容 這些的存在，然後把專案做成，交付。

(但這其實也算不上高手的招，因為我目前也不在高段位，還在不斷接觸高手，學習高手的過程中...)

7.3 突發事件

程式設計師可能也會遇到突發事件，比如莫名其妙的，昨天自測能走的程式碼，今天就不行了。然後仔細查了檢視到了，某個傢伙合入程式碼的時候，沒有考慮公共開關(多模組共用的引數，變數等)，然後自個兒就能解決。

但是專案經理遇到的突發事件能有這麼簡單，自個兒琢磨一下，私底下就解決了麼？不存在的。

往往是涉及到多個干係人，存在多種利益糾紛，然後要解決，就得想辦法溝通。

有時候氣的沒有辦法還要請中間人協調或者摸清其中利益干係後在行動，比如某要用其內部資料測試剛實現的模組，但對方掐著閘道器死活不給你放行，怎麼搞？我哪知道啊，但還是要硬著頭皮，想辦法啊，總歸是要解決的呀。

其次就是程式設計師遇到突發事件絕對沒有專案經理多，因為負責的範疇廣了，時不時的就會來事兒，極其考驗一個人的抗壓能力 --- 因為每次可能都是新鮮的！！！

可能還有其他的，但是我只寫了我經歷的和個人見解。

此篇算是 田篇之作，有不妥之處，萬望斧正，謝謝您的時間。

(始終走 D小調，不釋出到網站首頁了)

YanYueIO Oct 13, 2020 afternoon