專案管理重要原則(轉)

ger8發表於2007-08-11
優質管理的四大要素:選擇正確的人。為他們分配正確的工作。保持他們的積極性。幫助團隊凝聚起來並保持團隊的凝聚力。 (其他一切都只是"文案"。) 安全和變化除非感到安全,否則人們就不能去迎接變化。? 在所有成功的工程中(以及在絕大多數其他有價值的工作中),變化都是基本的要素之一。? 安全感的缺乏會讓人們反對變化。? 逃避風險是致命的,因為這會讓你也得不到與風險同在的利益。? 人們可能會因為來自客觀世界的直接的恐嚇而覺得沒有安全感,但是如果察覺到管理者可能濫用權力來懲罰自己,他們也會覺得沒有安全感。 負面效應威脅不是提高業績最好的方法。如果分配的時間一開始就不夠,不管威脅有多麼嚇人,工作也無法按時完成。更糟糕的是,如果目標沒有實現,你就必須兌現你的威脅。 管理者必需的身體部位管理涉及到心、腸胃、靈魂和鼻子。因此……用心來領導,相信你的腸胃(相信你的預感),構築團隊的靈魂,訓練一個能嗅出謊言的鼻子。 用指揮戰爭來作為管理的一個比喻在戰役開始的時候,管理者真正的工作已經完成了。 面試和招聘招聘涉及到所有與管理相關的身體部位:心、靈魂、鼻子和腸胃(但是主要是腸胃)。不要試圖單獨去招聘——兩副腸胃遠比一副腸胃的兩倍要好。對於新的僱員,讓他們承擔與以前曾經成功過的同樣難度的專案,把有挑戰性的目標推遲到下一次。徵求提示:你最希望僱的那個人可能還知道其他很好的人選。多聽,少說。如果先把材料整理好,那麼所有的事情都會進行得更好。 生產力的提高沒有"短期生產力提高"這樣的東西。生產力的提高是來自長期投資的。任何承諾立刻見效的東西都很可能是江湖遊醫所賣的萬靈油。 風險控制透過控制風險來管理專案。為每個專案建立並維護風險統計表。跟蹤根源性的風險,而不只是最後那討厭的結果。評估每種風險具體化的機率和可能造成的開銷。對於每種風險,預測標誌其具體化的早期徵兆。任命一個風險控制官,這個人不應該維護組織內部"我能行"的態度。建立簡單的(可能是匿名的)通道,讓壞訊息能傳遞到高層。 防止失敗  壯士斷腕。  控制住失敗比最佳化成功更能提高你全面的成績。  要有闖勁,儘早取消失敗的工作。  除非必要,否則就不要自己去凝聚一個團隊:出去找一個已經成型的團隊來用。  保持好的團隊在一起(只要他們自己願意),以幫助你的繼任者避免團隊凝聚得慢或者不能凝聚的問題。  把凝聚在一起的團隊--準備好、並且也願意接受新的工作--作為專案的收穫之一。  專案開始時浪費的一天和最後階段浪費的一天對專案造成的傷害是同等的。有無數種方法可以浪費一天的時間……但是沒有任何一種方法可以拿回一天的時間。 開發過程的建模和模擬  將你關於完成工作過程的直覺建模。  在同事的交流中使用這些模型,以便交流、提煉關於專案運轉的思想。  用模型來模擬專案的結果。  根據實際的結果來調整模型。 "病態的政治" 每一天,你都必須準確度拿自已的工作去打賭...... ......但是這也不能保證"病態的政治"不會影響你。 "病態的政治"可能在任何地方出現,哪怕是在最健康的組織裡面。 "病態的政治"的特徵:對個人權勢的渴望超過了組織本身的目標。即使這種不合理的目標與組織的目標背道而馳,它也可能出現。 "病態的政治"的副作用:它使精簡的專案變得危險。 度量度量每個產品的規模。不要執著於單位——在等待客觀度量的時候,先用你自己的主觀單位。從所有能得到的原始資料(可計算的軟體特徵)自己構造度量單位。不斷完善你的度量方程式,直到它的計算結果與原始資料庫中的專案工作量有最好的對應關係。藉助資料庫畫一條趨勢線,把預期的工作量作為人造度量單位值的函式顯示出來。現在,針對每個要度量的專案,計算出人造度量單位值,並根據這個值在趨勢線上找到預期工作量值。用生產力趨勢周圍的干擾水平作為對映的公差指示。 過程和過程改進好的過程和持續的過程是絕好的目標。它們也是非常自然的目標:優秀的技術工作者一定會關注它們,而不管你是否告訴他們。正式的過程改程式序需要花錢、花時間;特定的過程改進工作還會延緩專案進度。儘管最終體現出生產力上的收穫,它們也不可能抵消花在過程改進上的時間。但是專案有希望從單個的、正確選擇的方法改進中得到足夠的收益,並贏回為這次改變付出的時間和金錢。在專案進行過程中,不要希望在超過一個地方的範圍內實施必改進。多種技術的改程式序(比如說提高整整一個CMM等級)很可能讓專案比不實施這些程式完成得更晚。標準過程的危險就在於人們可能失去重要的走捷徑的機會。特別是對於人員超編的專案,標準的過程看去會很嚴謹,因為它們製造出了足夠的工作(有用的和無用的),讓所有人都忙於不停。 改變完成工作的方式如果不大幅減少除錯時間,就沒有辦法讓專案大幅度提前完成。高速完成的專案用在除錯上的時間成比例地少得多。高速完成的專案用在設計上的時間也成比例地多得多。如果你不關心別人, 不照顧別人,就別想讓他們做一些不同尋常的事情。如果要讓他們改變,就必須去了解(並讚賞)他們的過去。 壓力的效果壓力之下的人無法更快的思考。增加加班時間只會降低生產力。短期的壓力乃至於加班可能是有用的策略,因為它們能使員工集中精力,並且讓他們感到工作的重要性。但是長期的壓力肯定是錯誤的。經理們之所以會施加那麼多壓力,也許是因為他們不知道該做什麼,或者因為其他辦法的困難而感到氣餒。最壞的猜想:使用壓力和加班的真正原因是為了在專案失敗的時候讓所有人看上去能好一點。 憤怒的經理管理中的憤怒和羞辱是會傳染的。如果高階管理者喜歡罵人,低階管理者也會有樣學樣(就象經常被罵的小孩很容易變成愛罵人的父母)。管理中的辱罵常被認為是一種刺激,可以讓員工提高效率。在" 胡蘿蔔加大棒"的管理策略中,辱罵是最常見的"大棒"。但是,哪有人被辱罵之後還能做得更好的?如果經理使用辱罵的方法來刺激員工,這就表現經理的無能,而不是員工的無能。 含糊的規格文件規格文件中的含糊標誌著不同的系統參與者之間存在未解決的衝突。如果一份規格文件不包含完整的輸入輸出列表,那麼它就是毫無希望的:它根本就沒有開始說明任何東西。沒有人會告訴你一份規格文件是不是糟糕。人們往往傾向於責備自己,而不責備文件。 衝突只要在開發過程中有多個參與者,就一定會有衝突存在。建立、安裝系統的業務中特別容易出現衝突。絕大多數系統開發團隊都缺乏解決衝突的能力。衝突應當引起重視。衝突並不是缺乏職業道德的行為。應當提前宣告:所有人的"贏"都是受重視的。確保每個級別的人都能贏。談判困難,調解容易。如果兩個人的利益是完全或者部分相斥的,預先做好安排,準備好請雙方透過調解來解決衝突。記住:我們都站在同一邊;跟我們對立的,是我們要解決的問題。 催化劑的角色有這樣一種催化劑式的人格。這樣的人會幫助團隊成型並凝聚,保持團隊的健康和生產力,從而對專案作出貢獻。就算"催化劑"別的什麼都不幹(其實,通常他們還會幹很多別的事),這種催化劑的角色也是重要而有價值的。調解是"催化劑"的一項特殊工作。調解是可以學的,而且只需要很小的投資就能學會。調解應該從一個小小的儀式開始。"我能幫你們調解一下嗎?"在解決衝突的時候,這是必要的第一個步驟。 人類的錯誤將你置於死的,不是你不知道的東西……而正是你"知道"絕不會置你於死地的東西。 人員安排在早期,人員超編會迫使專案跨過關鍵的設計階段(這是為了讓所有的人都有事可做)。如果在設計完成之前, 工作先被分給了許多人,那麼人與人之間、工作與工作之間的介面就會很複雜。這會使團隊內部耦合度提高,會議時間、重複勞動和無效的工作都會增加。理想的人員安排是這樣的:在專案的大部分時間內由小型核心團隊來做設計工作,在開發的最後階段(時間安排的最後1/6)加入大量的人手。可怕的猜想:時間安排緊迫的專案,與時間安排比較合理的專案比起來,完成的時間反而會更長。 專案社會學讓不必與會的人可以放心離開,從而保持會議的精簡。有一份公開的議程,並嚴格執行,這是最簡單的辦法。專案需要儀式。用小小的儀式來使人們注意專案的目標的理想狀態:小規模會議、零缺陷工作等等。採取行動,防止人們隨便發怒。記住:憤怒=恐懼。隨便對下級發怒的經理一定是因為恐懼才會這樣做的。意見:如果所有人都懂得"憤怒=恐懼"這個道理,就能明顯看出發怒的人是在害怕。由於無法隱瞞自己的恐懼,他也就不會再生氣了。(這不能解決這些生氣的人的問題,但是肯定可以讓其他人好受一些。) "病態的政治"(舊話重提) 別想根治一個病態的人。不要浪費時間,也不要因為嘗試治療上司的病態而使自己受到威脅。有時候,你唯一的的選擇就是等待,等問題自己解決,或者等一個讓你繼續前進的機會。奇蹟是有可能發生的(但是千萬別去指望它)。 精兵簡政精兵簡政是失敗公司使用的辦法,它使員工負但失敗的責任。公司的目標應該正好相反:興旺而人性化。當你聽到"精兵簡政"這個詞的時候,請記住它的弦外之音:失敗和恐嚇。 基本常識專案既需要目標,也需要計劃。而且這兩者應該不同。[@more@]

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-944913/,如需轉載,請註明出處,否則將追究法律責任。

相關文章