1. 程式人生 > >一位副總給我啟示(最後期限)

一位副總給我啟示(最後期限)

最簡 部分 身體部位 兩個 嚴格 匿名 別人 投資 並不是

★優質管理的四大要素:

■選擇正確的人。

■為他們分配正確的工作。

■保持他們的積極性。

■幫助團隊凝聚起來並保持團隊的凝聚力。(其他一切都只是“文案”。)

★安全和變化:

■除非感到安全,否則人們就不能去迎接變化。

■在所有成功的工程中(以及在絕大多數其他有價值的工作中),變化都是基本的要素之一。

■安全感的缺乏會讓人們反對變化。

■逃避風險是致命的,因為這會讓你也得不到與風險同在的利益。

■人們可能會因為來自客觀世界的直接的恐嚇而覺得沒有安全感,但是如果察覺到管理者可能濫用權力來懲罰自己,他們也會覺得沒有安全感。

負面效應:

■威脅不是提高業績最好的方法。

■如果分配的時間一開始就不夠,不管威脅有多麽嚇人,工作也無法按時完成。 更糟糕的是,如果目標沒有實現,你就必須兌現你的威脅。

★管理者必需的身體部位:

■管理涉及到心、腸胃、靈魂和鼻子。

■因此... 用心來領導, 相信你的腸胃(相信你的預感),構築團隊的靈魂,訓練一個能嗅出謊言的鼻子。

★用指揮戰爭來作為管理的一個比喻:

■在戰役開始的時候,管理者真正的工作已經完成了。

面試和招聘:

■招聘涉及到所有與管理相關的身體部位:心、靈魂、鼻子和腸胃(但是主要是腸胃)。

■不要試圖單獨去招聘 —— 兩副腸胃遠比一副腸胃的兩倍要好。

■對於新的雇員,讓他們承擔與以前曾經成功過的同樣難度的項目,把有挑戰性的目標推遲到下一次。

■征求提示:你最希望雇的那個人可能還知道其他很好的人選。

■多聽,少說。

■如果先把材料整理好,那麽所有的事情都會進行得更好。

防止失敗:

■壯士斷腕。

■控制住失敗比優化成功更能提高你全面的成績。

■要有闖勁,盡早取消失敗的工作。

■除非必要,否則就不要自己去凝聚一個團隊:出去找一個已經成型的團隊來用。

■保持好的團隊在一起(只要他們自己願意),以幫助你的繼任者避免團隊凝聚得慢或者不能凝聚的問題。

■把凝聚在一起的團隊 ——準備好、並且也願意接受新的工作,作為項目的收獲之一。

■項目開始時浪費的一天和最後階段浪費的一天對項目造成的傷害是同等的。

★生產力的提高:

■沒有“短期生產力提高”這樣的東西。

■生產力的提高是來自長期投資的。

■任何承諾立刻見效的東西都很可能是江湖遊醫所賣的萬靈油。

風險控制:

■通過控制風險來管理項目。

■為每個項目創建並維護風險統計表。

■跟蹤根源性的風險,而不只是最後那討厭的結果。

■評估每種風險具體化的概率和可能造成的開銷。

■對於每種風險,預測標誌其具體化的早期征兆。

■任命一個風險控制官,這個人不應該維護組織內部“我能行”的態度。

■建立簡單的(可能是匿名的)通道,讓壞消息能傳遞到高層。

★開發過程的建模和模擬:

■將你關於完成工作過程的直覺建模。

■在同事的交流中使用這些模型,以便交流、提煉關於項目運轉的思想。

■用模型來模擬項目的結果。

■根據實際的結果來調整模型。

★病態的政治:

■每一天,你都必須準備拿自己的工作打賭.......

■ ......但是這也不能保證“病態的政治”影響你。

■“病態的政治”可能在任何地方出現,哪怕是在最健康的組織裏面。

■“病態的政治”的特征:對個人權勢的渴望超過了組織本身的目標。

■ 即使這種不合理的目標與組織目標背道而馳,它也可能出現。

■“病態的政治”最惡劣的副作用:它精簡項目變得危險。

★度量:

■ 度量每個產品的規模

■ 不要執著於單位 – 在等待客觀度量的時候,先用你自己的主觀單位

■ 從所有能得到的原始數據(可計算得軟件特性)自己構造度量單位

■ 從已經完成得項目中收集原始數據,以推導出生產力趨向

■ 借助數據庫畫一條趨勢線,把預期工作量作為人造度量值的函數顯示出來

■ 現在,針對每個要評估的項目,計算出人造度量單位值,並根據這個值在趨勢線上找到預期工作量值

■ 用生產力趨勢周圍的幹擾水平作為映射的標示

★過程和過程改進:

■ 好的過程和持續的過程改進是絕好的目標

■ 它們也是非常自然的目標:優秀的技術工作者一定會關註它們,不管你是否告訴他們

■ 正式的過程改進程序常需要花錢、花時間;特定的過程改進工作拖延項目進度。盡管最終會體現出生產力上的收獲,它們也不可能抵消花在過程改進上的時間。

■ 但是,項目有希望從單個的、正確選擇的方法改進中得到足夠的收益,並贏回為這次改變付出的時間和金錢。

■ 在項目進行的過程中,不要希望在超過一個方法的範圍內實施改進。多種技術的改進程序(比如說提高整整一個CMM等級)很可能讓項目比不實施這些程序完成得更晚。

■ 標準過程的危險就在於人們可能失去重要的走捷徑的機會

■ 特別是對於人員超編的項目,標準過程看上去會很嚴謹,因為它們制造出了足夠的工作(有用的和無用的),讓所有人都忙碌不停。

★改變完成工作的方式:

■ 如果不大幅度減少調試的時間,就沒辦法讓項目大幅度提前完成。

■ 高速完成的項目用在調試上的時間也成比例地少得多。

■ 高速完成的項目用在設計上的時間也成比例地多得多。

■ 如果你不關心別人,不照顧別人,就別想讓他們為你做一些不同尋常的事情。如果要讓他們改變,就必須去了解(並贊賞)他們的過去。

★壓力的效果:

■ 壓力之下的人無法更快地思考

■ 增加加班時間只會降低生產力

■ 短期的壓力乃至於加班可能是有用的策略,因為它們能使員工集中精力,並且讓他們感到工作的重要性。但是長期的壓力肯定是錯誤的。

■ 經理之所以會施加那麽多的壓力,也許是因為他們不知道該做什麽,或者因為其他辦法的困難而感到氣餒。

■ 最壞的猜測:是用壓力和加班的真正原因是為了在項目失敗的時候讓所有人看上去能好一點。

★憤怒的經理:

■ 管理中的憤怒和恥辱是會傳染的。如果高級管理者喜歡罵人,低級管理者也會有樣學樣(就像經常被罵得小孩很容易變成愛罵人的父母)。

■ 管理中的辱罵常被認為是一種刺激,可以讓員工提高效率。在“胡蘿蔔加大棒”的管理策略中,辱罵是最常見的“大棒”。但是,哪有人被辱罵之後還能做得更好的?

■ 如果經理使用辱罵得方法來刺激員工,這就表現出經理的無能,而不是員工的無能。

★含糊的規格文檔:

■ 規格文檔中的含糊隱含著不同的系統參與者之間存在著未解決的沖突。

■ 如果一份規格文檔不包含完整的輸入輸出列表,那麽它就是毫無希望的,它根本就還沒開始說明任何東西。

■ 沒有人會告訴你一份規格文檔是不是糟糕。人們往往傾向於責備自己,而不是責備文檔。

★沖突:

■ 只要在開式過程中有多個參與者,就一定會有沖突存在。

■ 創建、安裝系統的業務中特別容易出現沖突。

■ 絕大多數系統開發團隊都缺乏解決沖突的能力。

■ 沖突應當引起重視。沖突並不是缺乏職業道德的行為。

■ 應當提前聲明:所有人的‘贏’都是受重視的。確保每個級別的人都能贏。

■ 談判困難;調解容易。

■ 如果兩個人的利益是完全或者部分相斥的,預先做好安排,準備好請雙方通過調解來解決沖突。

■ 記住:我們都站在同一邊;跟我們對立的,是我們要解決的問題。

★催化劑的角色:

■ 有這樣一種催化劑式的人物,這樣的人能幫助團隊成型並凝聚,保持團隊的健康和生產力,從而對項目做出貢獻。就算“催化劑”別的什麽事情都不幹(其實,通常他們還會幹很多別的事),這種催化劑的角色也是重要而有價值的。

■ 調解是“催化劑”的一項特殊工作。調解是可以學的,而且只需要很小的投資就能學會。

■ 調解應該從一個小小的儀式開始。“我能幫你們調解一下嗎?”在解決沖突的時候,這是必要的第一個步驟。

★人類的錯誤:

■ 將你置於死地的,不是你不知道的的東西…而正是你“知道”絕不會置你於死地的東西。

★人員安排:

■ 在早期,人員超編會迫使項目跨過關鍵的設計階段(這是為了讓所有的人有事可做)。

■ 如果在設計完成之前,工作先被分給了很多人,那麽人與人之間、工作組之間的接口就會很亂套。

■ 這會使團隊內部耦合度提高,會議時間、重復勞動和無效工作都會增加。

■ 理想的人員安排是這樣:在項目的的大部分時間裏由小型核心團隊來做設計工作,在開發的最後階段(時間安排的最後1/6)加入大量的人手。

■ 可怕的猜想:時間安排緊迫的項目,與時間安排比較合理的項目比起來,完成的時間發而會更長。

★項目社會學:

■ 讓不必與會的人可以放心離開,從而保證會議的精簡。有一份公開的議程,並嚴格執行,這是最簡單的辦法。

■ 項目需要儀式。

■ 用小小的儀式來使人們註意項目的目標和理想狀態:小規模會議、零缺陷工作等等。

■ 采取行動,防止人們隨便發怒

■ 記住:憤怒=恐懼。隨便對下級發怒的經理一定是因為恐懼才會這樣做的。

■ 意見:如果所有人都懂得“憤怒=恐懼”這個道理,就能明顯地看出發怒的人是在害怕。由於無法再隱瞞自己的恐懼,他也就不會再生氣了。(這不能解決這些生氣的人的問題,但是肯定可以讓其他人好受一些。)

★“病態的政治”(舊話重提):

■ 別想根治一個病態的人

■ 不要浪費時間,也不要因為嘗試治療上司的病態而使自己受到威脅。

■ 有時候,你唯一的選擇就是等待,等問題自己解決,或者等一個讓你繼續前進的機會。

■ 奇跡時有可能發生的(但是千萬別去指望它)。

★精兵簡政:

■ 精兵確政是支敗的公司使用的辦法。它讓員工負擔失敗的責任。

■ 公司的目標應該正好相反:興旺而人性化。

■ 當你聽到“精兵簡政”這個詞的時候,請記住它的弦外之音:失敗和恐嚇。

★基本常識:

■ 項目既需要目標,也需要計劃。

■ 而且這兩者應該不同

出自:http://blog.csdn.net/andymu077/article/details/6924748

一位副總給我啟示(最後期限)