帕金森原則原是用于反映政府部門機構臃腫，效率低下的代名詞。不過它在軟件開發中一樣適用。沒有時限限制的話，工作可能無限延期。在軟件開發中，如果沒有嚴格的時間限制，開發人員往往比較懈怠。這是人的天性所決定的。千萬不要指望奇跡的發生――“所有員工的思想覺悟異常崇高”。作為項目管理者而言，此時應充分考慮到員工的工作效率和項目變更帶來的負面影響，制定合理的項目工期并鼓動開發人員盡快完成。
七、時間分配原則
在項目計劃編制過程中，我們常常將資源可用率（人、設備）等設置為100％，殊不知你曾想過，由于開發人員需要休息、吃飯、開會等，根本不可能把所有的時間放在項目開發工作上，而且這還不考慮到開發人員的工作效率是否保持在一恒定水平上。所謂一天8小時工時制實際上是徒有虛名。由于項目管理人員的“無知”，不少開發人員被迫拼命加班。結果依舊出現Brooks原則所出現問題。在實際開發中，開發員工的時間利用率能夠達到80％就已經時很不錯的了，我個人比較傾向于60％左右（黃金分割點）。一個常用的經驗是如果項目人員不懂技術的話，項目時間可能是原計劃（該計劃沒有考慮到資源可用率）的4/3－5/3。如果項目人員不懂技術、管理人員不懂管理的話，這個數字可能是2倍到3倍�，F實就是這么嚴酷。這很大范圍內“歸功于項目管理人員。是的，我們的確沒有必要責備開發人員，因為我們對資源可用率的判斷完全違反常識。
八、變化原則
也許有人問過你，在項目管理中唯一不變的東西是什么？我可以告訴你，項目中唯一不變的就是“變化”。在項目中不考慮可能發生的變化是不可思議的。不過在面對項目可能發生變化而帶來的項目風險時，我們的項目管理人員往往會懷有逃避的態度。經濟學里大名鼎鼎的風險規避原則便是項目管理人員心理的有效描述。作為項目管理人員來說，應該及早預測可能出現的風險，做好風險儲備。雖然風險儲備不能解決所有的問題，但是“預防勝于治療”�？上У氖俏覀兘^大多數人沒有這方面的意識，否則醫院的生意未必如此紅火，項目開發之途未必如此坎坷。
九、作業標準原則
一個團隊要完成項目的開發需要有一定的章法。很可惜，在國內目前仍然以“作坊式”為主，高舉“我們符合國際CMM X規范（ISO某某規范）”的環境下，未必有多少項目團隊注意到這一點。我們曾經驚嘆印度的高中生都能編程序，而國內卻非本科、碩士不收眼簾。究其原因，在于沒有開發章法或是章法粗糙，猶如牛皮圣旨一般。一個好的代碼模板和代碼規范能夠解決大多數人編寫程序隨心所欲的問題，很可惜，沒有多少項目管理人員有此意識，也沒有多少人愿意去做這項基礎任務。業務軟件開發需要高超的開發技巧嗎？不需要，那是故弄玄虛的開發人員的伎倆。軟件開發的美在于其簡潔性和規范性，不在于奇技淫巧。因為缺乏作業標準，我們付出的代價是客戶的抱怨和無休止的返工。此外，對于那些以形式主意蒙人的項目團隊來說，如果你實質如同你口頭所說那樣，也許你就不會是今天的這副狼狽相。
十、 復用和組織變革原則－解決項目問題的未來之路
如何解決日益突出的項目工期、成本、質量等問題，這是大多數項目管理者最為關心的問題。從實踐來看加強復用的力度，建立項目復用體系和實施組織變革是效果較好的途徑之一。復用能夠提高項目的生產率，降低項目風險。通過復用，項目管理者能夠快速的進入項目問題定義之中，減少項目開發人員的工作量，從而盡可能的解決項目在時間、資源方面的過載問題。另外一條途徑是實施項目團隊的組織變革（Moc），精簡項目管理機構、重新定義工作職責，制定柔性的項目工作流程，改善項目開發人員的溝通狀況，提高項目人員的開發效率，努力營造一個良好的項目開發環境。這樣才能從根本上解決項目開發的種種棘手問題。
結論：作為一個項目管理者來說，了解和運用上述原則是不夠的，若要深入的掌握項目管理知識和技巧，還必須深入學習項目管理（建議參看PMI《PMBOK》）、管理心理學、質量管理學、組織變革、系統論等方面的知識，并在工作中不斷的總結和實踐。唯有如此，我們的項目管理人員看自己個人簡歷時方不會覺得臉紅，才能在公司中樹立自己的管理權威性，同樣也才會有一個良好的職業經理生涯的開端。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
