優秀的項目管理與糟糕的項目管理

01-26

軟體工程裡面很重要的一環就是項目管理。理想狀態下的項目管理可以參見各種教科書，然而在真實工程中永遠無法達到教科書中的理想環境，因為管理的核心是人，所以照本宣科談管理都是紙上談兵。下面就從項目管理實施的每個環節上入手，描述一下我在從業過程中遇到的優秀與糟糕的項目管理場景。

首先從需求管理談起。

我想每一個軟體從業者都見過以下這張圖：

這是教科書裡面的圖，以前我每次對學生們講，學生們都不以為然，對內部員工講，員工更是早已麻木（員工內心ps：「老子上學的時候就見過這張圖，你還講個毛線！」）。然而幾乎所有失敗的項目都是因為-----需求失控！

需求失控有兩種可能：1：對用戶需求完成理解錯誤。 2：用戶想要整個世界，但需求人員無法引導用戶。

需求是軟體企業與外部客戶之間的交流，如果這一關做不好，後續就等著扯皮吧：需求人員一肚子火（我明明很累，我做了很多，該交流的都交流的，是客戶沒說明白，是開發沒聽明白）；開發人員一肚子火（領導直接開罵，明明不是我的原因，我加班加點做了很多東西，到最後告訴我需求變了？）；客戶一肚子火（什麼玩意，什麼公司，都是坑我錢）。更可怕的是責任說不清是誰的，相互扯皮，永遠沒完沒了，所有的能量全部消耗到了扯皮中，每個人都苦不堪言。

需求管理的方式有很多，教科書式的理想案例不表，貼一個優秀的圖：

axure 原型圖：

生成的html靜態頁面

與用戶確認的需求

需求做到了這種程度，項目想要爛都難！這是優秀的需求管理。

與之相對的極端糟糕的需求管理就是沒有用戶交流，關起門來自己做，閉門造車，這種情況下想要得到認可簡直是天方夜譚。一般決策領導層把所有的精力放到了商務運作或者自認為簡單沒有與用戶確認需求，就會導致需求混亂。

第二個要來看的是項目規劃：

項目規劃是很有意思的一個環節，有的公司壓根沒有規劃，走哪算哪；有的公司老馬識途，胸有成竹；有的公司東施效顰，規划了各個節點各個裡程碑，結果根本執行不下去，無疾而終。

第一種走哪算哪的公司一般屬於初創型公司，成本制約、公司還沒有形成經驗知識庫。

第二種老馬識途的公司早已專業化、流程化、制度化。

第三種處在第一種與第二種之間，是極其糾結的一類，也是最常見的一類。造成無法執行計劃的原因很重要的一條就是：沒有考慮技術因素、人員因素、客戶因素的情況下使用了理想狀態下的配置對項目進行了規劃，更有甚者一拍腦袋：就這麼定！並且這麼安慰自己：「現在先公布執行下去，到時候執行不下去在改動，不會有沒有完美的計劃」。可知狼來了喊多了，大家也就麻木懈怠了，也就么人拿規劃當正兒八經的事了。

07年我開始做的第一個項目「****CRM系統」，100多個開發人員，project畫的滿天飛，只用了不到2個月project就徹底廢棄了，對客戶一套進度彙報，對內一套真實進度。後來項目經理切入到了每天的開發、每天工作量後才好轉。

顯然假大空的項目規劃，只能感動自己的項目規劃沒有任何意義，項目規劃執行落地才是規劃的真正目的，說道落地就要說第三個具體的開發流程監控了。

三：任務開發跟蹤監控。

項目的管理的主要內容是成本、進度、質量。拋開三者談項目管理都是耍流氓。

糟糕的項目監控大體有三類：1：「老油條」型；2：勞模領導型；3：把自己當「領導」型。

「老油條」型的項目監控人找各種理由推卸責任，常見的有：開發人員水平不行，要招大牛才行；任務我都分配了，開發人員做不出來怎麼辦；我都跟開發人員講清楚了，這有什麼辦法呢；一般在一個環境中工作久了，個人滿足現狀，公司如同一潭死水，就會有這樣老油條的人。

勞模型是項目監管人負責了幾乎能負責的所有工作，而下面的員工卻很清閑。一般一線勞模新晉項目監管人的時候喜歡做這樣的事，這是把一線的勞模成功經驗錯誤的複製到了管理上。

把自己當領導型的更可怕，認為自己是領導，甚至擺擺官架子，這種情況在軟體這個行業中比較少，屬於奇葩型。

14年我帶了一個比較有特點的項目：我半場加入項目管理，工期特別緊張，而人員都是新手，沒有太多經驗，需求多變，計劃不能落地。經過交流基本得出的結論是：成本不能再繼續增加（無法提供更多的人加入，這是我加入項目的先決條件），進度要求在3個月內必須完成，最遲3個月交給客戶上線使用。

在這種情況下我做了個艱難的決定：每天監控、協助開發人員完成每天的工作；不編寫任何業務代碼，全身投入開發管理；對每個人每天的工作及代碼進行審查，所有優劣問題暴露給工資體現。

當時還做了一個表格：

計劃不能落實->開發人員水平不高->有問題無法解決->交流佔用太多時間：那麼我來負責解決技術上的疑難雜症。

計劃不能落實->客戶反覆交流->需求多變：具體需求人員聯繫客戶，不怕需求多變，但要求移交給開發的需求必須是確認的、甚至是簽字的、有人對此負責的。

計劃不能落實->開發過的功能反覆出錯->程序代碼有錯誤：每人沒做完一個功能，立刻審查代碼，代碼審查不通過的，今夜不下班。

計劃不能落實->我完成不了這個功能：每天任務分配讓開發人員確認是否能夠完成，每天至少監控3-4次，在監控到第二次的時候基本就可以判斷能否完成及存在的問題。等等。

管理的工作看似很繁重，其實萬事開頭難，只要人員有了慣性，管理是一件越來越輕鬆的事情。

越是工期緊張，越是容易混亂，對混亂的控制、對資源的把控是管理的價值。

最後簡單說一下測試管理：

測試管理主要分為：功能性測試、系統性測試。系統性測試又包括了：性能測試、安全測試等。兩者都需要有回歸測試。

一般項目型軟體產品功能性測試是重中之重，直接關係到用戶使用。性能與安全測試由於目前大部分軟體架構都比較成熟，相比較功能測試來講並不是重點，有很多企業把性能測試與安全測試外包給各個質保中心進行測試並出具項目測試報告，當然如果項目特殊，對性能與安全提出了很高的要求，這個要求到了另一個維度，這自然要另當別論。

功能性測試一般與需求密不可分，想像一下一個不了解需求的人去做測試，他測什麼？

測試管理的工具有很多，開源的也很多，最早我用的TestDirector，目前國產的開源工具也有很多，不在贅述。

寫著寫著沒想到已經很晚了，最後的最後做個簡單總結。

一個成功的項目背後必然是一個優秀的項目管理支撐，必然是依據其個性化的環境量身打造，換一個環境未必能夠照搬，但只要想著避免失敗的關鍵坑點，落實到具體細節上，那麼總有一天能夠撥亂反正，回歸正軌。

冰凍三尺非一日之寒，立竿見影的效果我們很難做到，但是坑再多，只要有恆心，總能填滿。

真正正確的事可能會遲到，但永遠不會缺席。