量標準。在很多情況下，你的活動會與期望結果背道而馳，而此時的你還在沉醉于自己的辛勤耕耘之中。作為項目經(jīng)理來說，只有制定好每個任務的驗收標準，才能夠嚴格把好每一個質量關、同時了解項目的進度情況。
四、80-20原則
80-20原則在軟件開發(fā)和項目管理方面有許多“實例”。其一便是我們在20%的項目要求上耗費了80%的時間。仔細分析一下，這些項目要求分為必須的非必須的，因此我們建議是壓縮非必須的部分或是暫時將其放在一邊不必太重視。軟件項目開發(fā)事實告訴我們，開發(fā)人員在非必須的項目要求上耗費了太多的精力，用戶的需求變更的大部分出現(xiàn)在“最好有”這一部分，實際上用戶并不看重這些需求(即使去除這些需求)，而我們所做的，往往是舍本求末。
80-20原則的另外一個實例是我們項目中的20%的人員擔當了80%的項目任務(這樣講在實際實施中一點都不過分)?？紤]到開發(fā)人員能力的多樣性，聰明的項目管理人員決不會采取任務均分的愚蠢做法，因為就系統(tǒng)論的觀點來看，互補結構比對等結構要更穩(wěn)定一些。此外作為項目管理人員來說，了解屬下員工的能力特點，將其放在合適的位置上，會更有利于項目的順利進行。很多管理人員常常抱怨屬下能力問題，究其實質，往往是這些項目管理人員未能發(fā)現(xiàn)開發(fā)人員潛能所在之處。她們看待問題往往以“經(jīng)驗”這樣的思維定勢來做決定。導致的結果如系統(tǒng)論所言：由于“抱怨”的作用和反作用循環(huán)，結果是大家都不歡而散。
帕金森原則原是用于反映政府部門機構臃腫，效率低下的代名詞。不過它在軟件開發(fā)中一樣適用。沒有時限限制的話，工作可能無限延期。在軟件開發(fā)中，如果沒有嚴格的時間限制，開發(fā)人員往往比較懈怠。這是人的天性所決定的。千萬不要指望奇跡的發(fā)生―“所有員工的思想覺悟異常崇高”.作為項目管理者而言，此時應充分考慮到員工的工作效率和項目變更帶來的負面影響，制定合理的項目工期并鼓動開發(fā)人員盡快完成。
五、時間分配原則
在項目計劃編制過程中，我們常常將資源可用率(人、設備)等設置為100%,殊不知你曾想過，由于開發(fā)人員需要休息、吃飯、開會等，根本不可能把所有的時間放在項目開發(fā)工作上，而且這還不考慮到開發(fā)人員的工作效率是否保持在一恒定水平上。所謂一天8小時工時制實際上是徒有虛名。由于項目管理人員的“無知 ”,不少開發(fā)人員被迫拼命加班。結果依舊出現(xiàn)Brooks原則所出現(xiàn)問題。
在實際開發(fā)中，開發(fā)員工的時間利用率能夠達到80%就已經(jīng)時很不錯的了，我個人 比較傾向于60%左右(黃金分割點)。一個常用的經(jīng)驗是如果項目人員不懂技術的話，項目時間可能是原計劃(該計劃沒有考慮到資源可用率)的4/3-5/3.如果項目人員不懂技術、管理人員不懂管理的話，這個數(shù)字可能是2倍到3倍?，F(xiàn)實就是這么嚴酷。這很大范圍內“歸功于項目管理人員。是的，我們的確沒有必要責備開發(fā)人員，因為我們對資源可用率的判斷完全違反常識。
六、默認無效原則
你的項目成員理解和贊成項目的范圍、目標和你所制定的項目策略嗎?不少項目管理人員認為“沉默意味著同意”。實際上我們或多或少都會陷入這樣的一個思維誤區(qū)。試想一下，你作為職員或項目開發(fā)人員時的沉默完全代表你贊成你的領導的意見嗎?不見得，這就是答案。這一點在項目溝通中極為重要，項目管理者切不可為