軟件工程里面很重要的一環(huán)就是項目管理。理想狀態(tài)下的項目管理可以參見各種教科書，然而在真實工程中永遠無法達到教科書中的理想環(huán)境，因為管理的核心是人，所以照本宣科談管理都是紙上談兵。下面就從項目管理實施的每個環(huán)節(jié)上入手，描述一下我在從業(yè)過程中遇到的優(yōu)秀與糟糕的項目管理場景。
首先從需求管理談起。
需求失控有兩種可能：1：對用戶需求完成理解錯誤。 2：用戶想要整個世界，但需求人員無法引導(dǎo)用戶。
需求是軟件企業(yè)與外部客戶之間的交流，如果這一關(guān)做不好，后續(xù)就等著扯皮吧：需求人員一肚子火（我明明很累，我做了很多，該交流的都交流的，是客戶沒說明白，是開發(fā)沒聽明白）；開發(fā)人員一肚子火（領(lǐng)導(dǎo)直接開罵，明明不是我的原因，我加班加點做了很多東西，到最后告訴我需求變了？）；客戶一肚子火（什么玩意，什么公司，都是坑我錢）。更可怕的是責(zé)任說不清是誰的，相互扯皮，永遠沒完沒了，所有的能量全部消耗到了扯皮中，每個人都苦不堪言。
需求管理的方式有很多，教科書式的理想案例不表，貼一個優(yōu)秀的圖：
axure 原型圖：
生成的html靜態(tài)頁面
與用戶確認(rèn)的需求
需求做到了這種程度，項目想要爛都難！這是優(yōu)秀的需求管理。
與之相對的極端糟糕的需求管理就是沒有用戶交流，關(guān)起門來自己做，閉門造車，這種情況下想要得到認(rèn)可簡直是天方夜譚。一般決策領(lǐng)導(dǎo)層把所有的精力放到了商務(wù)運作或者自認(rèn)為簡單沒有與用戶確認(rèn)需求，就會導(dǎo)致需求混亂。
第二個要來看的是項目規(guī)劃：
項目規(guī)劃是很有意思的一個環(huán)節(jié)，有的公司壓根沒有規(guī)劃，走哪算哪；有的公司老馬識途，胸有成竹；有的公司東施效顰，規(guī)劃了各個節(jié)點各個里程碑，結(jié)果根本執(zhí)行不下去，無疾而終。
第一種走哪算哪的公司一般屬于初創(chuàng)型公司，成本制約、公司還沒有形成經(jīng)驗知識庫。
第二種老馬識途的公司早已專業(yè)化、流程化、制度化。
第三種處在第一種與第二種之間，是極其糾結(jié)的一類，也是最常見的一類。造成無法執(zhí)行計劃的原因很重要的一條就是：沒有考慮技術(shù)因素、人員因素、客戶因素的情況下使用了理想狀態(tài)下的配置對項目進行了規(guī)劃，更有甚者一拍腦袋：就這么定！并且這么安慰自己：“現(xiàn)在先公布執(zhí)行下去，到時候執(zhí)行不下去在改動，不會有沒有完美的計劃”。可知狼來了喊多了，大家也就麻木懈怠了，也就么人拿規(guī)劃當(dāng)正兒八經(jīng)的事了。
07年我開始做的第一個項目“****CRM系統(tǒng)”，100多個開發(fā)人員，project畫的滿天飛，只用了不到2個月project就徹底廢棄了，對客戶一套進度匯報，對內(nèi)一套真實進度。后來項目經(jīng)理切入到了每天的開發(fā)、每天工作量后才好轉(zhuǎn)。
顯然假大空的項目規(guī)劃，只能感動自己的項目規(guī)劃沒有任何意義，項目規(guī)劃執(zhí)行落地才是規(guī)劃的真正目的，說道落地就要說第三個具體的開發(fā)流程監(jiān)控了。
三：任務(wù)開發(fā)跟蹤監(jiān)控。
項目的管理的主要內(nèi)容是成本、進度、質(zhì)量。拋開三者談項目管理都是耍流氓。
糟糕的項目監(jiān)控大體有三類：1：“老油條”型；2：勞模領(lǐng)導(dǎo)型；3：把自己當(dāng)“領(lǐng)導(dǎo)”型。
“老油條”型的項目監(jiān)控人找各種理由推卸責(zé)任，常見的有：開發(fā)人員水平不行，要招大牛才行；任務(wù)我都分配了，開發(fā)人員做不出來怎么辦；我都跟開發(fā)人員講清楚了，這有什么辦法呢；一般在一個環(huán)境中工作久了，個人滿足現(xiàn)狀，公司如同一潭死水，就會有這樣老油條的人。
勞模型是項目監(jiān)管人負(fù)責(zé)了幾乎能負(fù)責(zé)的所有工作，而下面的員工卻很清閑。一般一線勞模新晉項目監(jiān)管人的時候喜歡做這樣的事，這是把一線的勞模成功經(jīng)驗錯誤的 ** 到了管理上。
把自己當(dāng)領(lǐng)導(dǎo)型的更可怕，認(rèn)為自己是領(lǐng)導(dǎo)，甚至擺擺官架子，這種情況在軟件這個行業(yè)中比較少，屬于奇葩型。
14年我?guī)Я艘粋€比較有特點的項目：我半場加入項目管理，工期特別緊張，而人員都是新手，沒有太多經(jīng)驗，需求多變，計劃不能落地。經(jīng)過交流基本得出的結(jié)論是：成本不能再繼續(xù)增加（無法提供更多的人加入，這是我加入項目的先決條件），進度要求在3個月內(nèi)必須完成，最遲3個月交給客戶上線使用。
在這種情況下我做了個艱難的決定：每天監(jiān)控、協(xié)助開發(fā)人員完成每天的工作；不編寫任何業(yè)務(wù)代碼，全身投入開發(fā)管理；對每個人每天的工作及代碼進行審查，所有優(yōu)劣問題暴露給工資體現(xiàn)。
當(dāng)時還做了一個表格：
計劃不能落實->開發(fā)人員水平不高->有問題無法解決->交流占用太多時間：那么我來負(fù)責(zé)解決技術(shù)上的疑難雜癥。
計劃不能落實->客戶反復(fù)交流->需求多變：具體需求人員聯(lián)系客戶，不怕需求多變，但要求移交給開發(fā)的需求必須是確認(rèn)的、甚至是簽字的、有人對此負(fù)責(zé)的。
計劃不能落實->開發(fā)過的功能反復(fù)出錯->程序代碼有錯誤：每人沒做完一個功能，立刻審查代碼，代碼審查不通過的，今夜不下班。
計劃不能落實->我完成不了這個功能：每天任務(wù)分配讓開發(fā)人員確認(rèn)是否能夠完成，每天至少監(jiān)控3-4次，在監(jiān)控到第二次的時候基本就可以判斷能否完成及存在的問題。等等。
管理的工作看似很繁重，其實萬事開頭難，只要人員有了慣性，管理是一件越來越輕松的事情。
越是工期緊張，越是容易混亂，對混亂的控制、對資源的把控是管理的價值。
最后簡單說一下測試管理：
測試管理主要分為：功能性測試、系統(tǒng)性測試。系統(tǒng)性測試又包括了：性能測試、安全測試等。兩者都需要有回歸測試。
一般項目型軟件產(chǎn)品功能性測試是重中之重，直接關(guān)系到用戶使用。性能與安全測試由于目前大部分軟件架構(gòu)都比較成熟，相比較功能測試來講并不是重點，有很多企業(yè)把性能測試與安全測試外包給各個質(zhì)保中心進行測試并出具項目測試報告，當(dāng)然如果項目特殊，對性能與安全提出了很高的要求，這個要求到了另一個維度，這自然要另當(dāng)別論。
功能性測試一般與需求密不可分，想象一下一個不了解需求的人去做測試，他測什么？
測試管理的工具有很多，開源的也很多，最早我用的TestDirector，目前國產(chǎn)的開源工具也有很多，不在贅述。
寫著寫著沒想到已經(jīng)很晚了，最后的最后做個簡單總結(jié)。
一個成功的項目背后必然是一個優(yōu)秀的項目管理支撐，必然是依據(jù)其個性化的環(huán)境量身打造，換一個環(huán)境未必能夠照搬，但只要想著避免失敗的關(guān)鍵坑點，落實到具體細節(jié)上，那么總有一天能夠撥亂反正，回歸正軌。
冰凍三尺非一日之寒，立竿見影的效果我們很難做到，但是坑再多，只要有恒心，總能填滿。
真正正確的事可能會遲到，但永遠不會缺席。
