沒有計畫，你無從知道什麼時候控制和變更。制定乙個詳盡的計畫，以詳細到開發人員可以理解的程度為宜。計畫能夠告訴你什麼時候應該做什麼。沒有計畫，你無從知道自己需要做什麼。不少專案經理告訴組員需要做什麼東西後揚長而去，絲毫沒有乙個相關任務（活動）之間的說明。由於沒有計畫或是計畫太粗糙、不切實際，很多專案1/3甚至1/2的時間花在返工上面。因為計畫中遺漏了某一項關鍵任務，專案就有可能宣告失敗。試想一下，制定乙個周密合理的計畫需要耗費這麼多的時間嗎？需要付出專案失敗的代價嗎？還有很多專案管理人員常常錯誤認為"變化比計畫快"，但實際的情況是，由於沒有計畫，你無法**和估量變化給你的專案所帶來影響，你所面臨的將會是比麵條還難以理清?混沌"狀態。此外，對於開發人員來說，"目標導向（objective oriented）"是充分調動其工作積極性的最佳方法，每乙個任務階段的成果能夠將員工的工作效率維持在乙個較高的水平。因為近期目標總是比遠期目標來說更容易看到和達到。為此，制定乙個計畫吧，讓它符合目標導向（通過各個具體任務計畫促使專案總計畫的達成）。
二、 brooks原則
向乙個已經滯後的專案新增人員，可能會使專案更加滯後。因為作為新加入的員工來說，相關培訓、環境熟悉和人員之間的溝通通路的增加，迫使專案的工作效率急劇**。工作效率下降需要加班來進行彌補，但加班造成的疲勞會再次使工作效率降低。同時工作成本卻不斷的向上攀公升。不過就目前來說，專案管理人員絲毫不會理會這一點，"人多力量大"也許更能引人入勝。不少專案管理人員抱怨到時間的急迫性，須知很多專案內時間的急迫性來自於專案管理人員不假思索和不基於常理的邀功表現，沒有充分考慮的開發人員能力的多樣性
所致。為此，正規的企業不得不耗費大量的加班費用於加班人員的津貼，同時亦要承擔違反《勞動法》的潛在法律危險。現在一種萬不得已的做法是，假設專案開發人員之間的任務的關聯性不是太大的情況下，採取兩班倒或是三班倒的方法來保證時間的延續性和相關開發人員的工作高效性。
三、 驗收標準原則
我們在進行某項任務，往往會為以何種結果為宜而感到困惑。不求質量的開發人員往往憑據經驗草草了事，追求完美的開發人員則在該項任務上耗費太多的精力，但此番耗費未必針對該項任務，因而常常吃力不討好。這是由於沒有驗收標準而導致的情景。因為沒有驗收標準，你無法知道你要進行的任務需要乙個什麼樣的結果，需要達到什麼樣的質量標準。在很多情況下，你的活動會與期望結果背道而馳，而此時的你還在沉醉於自己的辛勤耕耘之中。作為專案經理來說，只有制定好每個任務的驗收標準，才能夠嚴格把好每乙個質量關、同時了解專案的進度情況。
四、 預設無效原則
你的專案成員理解和贊成專案的範圍、目標和你所制定的專案策略嗎？不少專案管理人員認為"沉默意味著同意"。實際上我們或多或少都會陷入這樣的乙個思維誤區。試想一下，你作為職員或專案開發人員時的沉默完全代表你贊成你的領導的意見嗎？不見得，這就是答案。這一點在專案溝通中極為重要，專案管理者切不可為沉預設為是同意，沉默在很大的程度上說明專案開發人員還尚未弄清楚專案的範圍、任務和目標。為此專案管理者還需要同開發人員進行充分溝通，了解開發人員的想法。在對專案沒有乙個共同的一致的理解的前提下，乙個團隊是不可能成功的。
五、 80-20原則
80-20原則在軟體開發和專案管理方面有許多"例項"。其一便是我們在20％的專案要求上耗費了80％的時間。仔細分析一下，這些專案要求分為必須的非必須的，因此我們建議是壓縮非必須的部分或是暫時將其放在一邊不必太重視。軟體專案開發事實告訴我們，開發人員在非必須的專案要求上耗費了太多的精力，使用者的需求變更的大部分出現在"最好有"這一部分，實際上使用者並不看重這些需求（即使去除這些需求），而我們所做的，往往是捨本求末。
80-20原則的另外乙個例項是我們專案中的20％的人員擔當了80％的專案任務（這樣講在實際實施中一點都不過分）。考慮到開發人員能力的多樣性，聰明的專案管理人員決不會採取任務均分的愚蠢做法，因為就系統論的觀點來看，互補結構比對等結構要更穩定一些。此外作為專案管理人員來說，了解屬下員工的能力特點，將其放在合適的位置上，會更有利於專案的順利進行。很多管理人員常常抱怨屬下能力問題，究其實質，往往是這些專案管理人員未能發現開發人員潛能所在之處。她們看待問題往往以"經驗"這樣的思維定勢來做決定。導致的結果如系統論所言：由於"抱怨"的作用和反作用迴圈，結果是大家都不歡而散。
六、 帕金森原則
帕金森原則原是用於反映**部門機構臃腫，效率低下的代名詞。不過它在軟體開發中一樣適用。沒有時限限制的話，工作可能無限延期。在軟體開發中，如果沒有嚴格的時間限制，開發人員往往比較懈怠。這是人的天性所決定的。千萬不要指望奇蹟的發生――"所有員工的思想覺悟異常崇高"。作為專案管理者而言，此時應充分考慮到員工的工作效率和專案變更帶來的負面影響，制定合理的專案工期並鼓動開發人員盡快完成。
七、時間分配原則
在專案計畫編制過程中，我們常常將資源可用率（人、裝置）等設定為100％，殊不知你曾想過，由於開發人員需要休息、吃飯、開會等，根本不可能把所有的時間放在專案開發工作上，而且這還不考慮到開發人員的工作效率是否保持在一恆定水平上。所謂一天8小時工時制實際上是徒有虛名。由於專案管理人員的"無知"，不少開發人員被迫拼命加班。結果依舊出現brooks原則所出現問題。在實際開發中，開發員工的時間利用率能夠達到80％就已經時很不錯的了，我個人比較傾向於60％左右（**分割點）。乙個常用的經驗是如果專案人員不懂技術的話，專案時間可能是原計畫（該計畫沒有考慮到資源可用率）的4/3－5/3。如果專案人員不懂技術、管理人員不懂管理的話，這個數字可能是2倍到3倍。現實就是這麼嚴酷。這很大範圍內"歸功於專案管理人員。是的，我們的確沒有必要責備開發人員，因為我們對資源可用率的判斷完全違反常識。
八、變化原則
也許有人問過你，在專案管理中唯一不變的東西是什麼？我可以告訴你，專案中唯一不變的就是"變化"。在專案中不考慮可能發生的變化是不可思議的。不過在面對專案可能發生變化而帶來的專案風險時，我們的專案管理人員往往會懷有逃避的態度。經濟學裡大名鼎鼎的風險規避原則便是專案管理人員心理的有效描述。作為專案管理人員來說，應該及早**可能出現的風險，做好風險儲備。雖然風險儲備不能解決所有的問題，但預防勝於**"。可惜的是我們絕大多數人沒有這方面的意識，否則醫院的生意未必如此紅火，專案開發之途未必如此坎坷。
九、作業標準原則
乙個團隊要完成專案的開發需要有一定的章法。很可惜，在國內目前仍然以"作坊式"為主，高舉"我們符合國際cmm x規範（iso某某規範）"的環境下，未必有多少專案團隊注意到這一點。我們曾經驚嘆印度的高中生都能程式設計序，而國內卻非本科、碩士不收眼簾。究其原因，在於沒有開發章法或是章法粗糙，猶如牛皮聖旨一般。乙個好的**模板和**規範能夠解決大多數人編寫程式隨心所欲的問題，很可惜，沒有多少專案管理人員有此意識，也沒有多少人願意去做這項基礎任務。業務軟體開發需要高超的開發技巧嗎？不需要，那是故弄玄虛的開發人員的伎倆。軟體開發的美在於其簡潔性和規範性，不在於奇技淫巧。因為缺乏作業標準，我們付出的代價是客戶的抱怨和無休止的返工。此外，對於那些以形式主意蒙人的專案團隊來說，如果你實質如同你口頭所說那樣，也許你就不會是今天的這副狼狽相。
十、復用和組織變革原則－解決專案問題的未來之路
如何解決日益突出的專案工期、成本、質量等問題，這是大多數專案管理者最為關心的問題。從實踐來看加強復用的力度，建立專案復用體系和實施組織變革是效果較好的途徑之一。復用能夠提高專案的生產率，降低專案風險。通過復用，專案管理者能夠快速的進入專案問題定義之中，減少專案開發人員的工作量，從而盡可能的解決專案在時間、資源方面的過載問題。另外一條途徑是實施專案團隊的組織變革（moc），精簡專案管理機構、重新定義工作職責，制定柔性的專案工作流程，改善專案開發人員的溝通狀況，提高專案人員的開發效率，努力營造乙個良好的專案開發環境。這樣才能從根本上解決專案開發的種種棘手問題。
結論作為乙個專案管理者來說，了解和運用上述原則是不夠的，若要深入的掌握專案管理知識和技巧，還必須深入學習專案管理（建議參看pmi《pmbok》）、管理心理學、質量管理學、組織變革、系統論等方面的知識，並在工作中不斷的總結和實踐。唯有如此，我們的專案管理人員看自己個人簡歷時方不會覺得臉紅，才能在公司中樹立自己的管理權威性，同樣也才會有乙個良好的職業經理生涯的開端。
(**csdn)
揭秘鮮為人知的酒店管理「黑洞」
揭秘鮮為人知的 酒店管理 黑洞 一款好的酒店管理軟體的優劣，能否真正做到防漏是關鍵。那麼一款好的酒店管理軟體究竟從哪些方面做到100 防止酒店管理漏洞呢？金天鵝酒店管理學院資深實戰專家鄧友富認為，應該從許可權控制 單據控制 門鎖控制以及管理提公升四個方面著手，從而徹底 酒店管理漏洞。四維金盾防漏體系...
鮮為人知的 Python 語法
所有人 好吧，不是所有人 都知道 python 是一門用途廣泛 易讀 而且容易入門的程式語言。但同時 python 語法也允許我們做一些很奇怪的事情。眾所周知 python 的 lambda 表示式不支援多行 但是可以模擬出多行 的效果。def f x string if x.endswith g ...
C 鮮為人知的符號
目錄 1 1.引言 1 2.少為人知的符號表1 1 2.1.符號表 1 2.2.示例 2 3.少為人知的符號表2 2 3.1.符號表 2 3.2.示例 3 這些鮮為人知的c 符號，可直接在 中使用，但實踐中不推薦這麼做，可作為茶餘飯後的樂趣了解c 的另一面。雖然它們鮮為人知，但卻不是gnu g 獨有...