網路城邦
上一篇 回創作列表 下一篇  字體:
專案管理心得 from The Deadline by Tom DeMarco
2007/05/10 16:43:47瀏覽1358|回應0|推薦0

除非感到安全
否則人們不可能去接受改變

暴燥的經理
抱著不打不成器的封建思想
濫用權力的懲罰部屬
將造成部屬普遍的不安全感
而拒絕接受變化

威脅能提高績效的效果是  極短期表面性的
目前暫時的績效
是以未來的損失來堆砌的

在威脅下所設定的目標
如果沒有達成
威脅就必須被兌現
傷害比目標沒被達成更大

用心來領導
相信直覺
建立團隊的信仰
不要對團隊說謊
並能嗅出謊言

把資料準備好
事情會做得更好

專案風險不是來自天翻地覆的大風險因素
而是一堆不起眼的根源性小風險
累積與逐步放大而成
管理專案就是在控制還在根源階段的小風險

評估每一個小風險的機率與損失
發掘其早期徵兆現象
建立匿名的壞消息揭露管道
讓壞消息早點曝光

因為沒有短期生產力提高這回事
也就沒有 Quick Win  這回事
任何承諾速效的處方
都是江湖術士的膏藥

所有有效的生產力提高
都是長期投資的結果

短期的生產力提高
一定是挖東補西的結果

如非不得已
不要建立自己的全新團隊
不如找一個有績效證明的團隊來用

無數種方法可以浪費一天
沒有任何方法可以拿回這一天

把專案中的行為與其影響
以直覺方式描述出來
再一步一步釐清成一個模型
利用模型
洞察已發生事件的根源因素
及其可能解決方案
並及早預見下一個可能的事件

用模型預測結果
用實際結果來調整模型

病態的政治無賴會在任何一個組織中存在
因為其無賴個性與政治手段
這種無賴會被其他已處高層的無賴
一起拱往高層

政治無賴個人的權勢慾望遠高於組織目標
就算個人慾望與組織目標完全相反也不奇怪

別想改變一個病態的政治無賴
別使自己受到威脅
等待是唯一方案

找出一種衡量產品開發案規模 的 衡量指標
別拘泥於指標的客觀計算單位

從所有可得的數據中
找出一套可以計算得出意義的指標

以指標的歷史值
推測專案生產力的趨勢線
修正計算定義與方式
讓指標的預測線與歷史數據的真正結果盡量接近

用此指標的預測線來估計專案的資源需求與績效預估

必須遵循標準流程的僵硬
會讓走捷徑的機會與利益消失

如果不減少除錯矯正的時間
就沒辦法讓專案時間大幅縮短

快速完成的專案花在謹慎設計的時間
遠高於除錯矯正的時間

給予壓力
不會讓人的思考變快或變好
壓力下的人
只有扭曲應變

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

短期壓力可能會使員工精神集中
長期壓力則肯定是只有負面效果

管理階層之所以只知道施予壓力
是因為他們不知道其他的解決方式是什麼
或是因其他方法的困難度而便宜行事
(參考病態政治無賴)

管理階層
使用壓力與要求加班的真正原因
是在專案失敗時
證明大家有在幹活

管理階層的憤怒與的怕被羞辱的拉不下臉
會傳染給所有的專案成員
經常被罵的員工會成為愛罵人的主管

辱罵是一種機械化管理科學思想下的過時概念
數十年來的事實證明
有誰在被辱罵之後
會表現得更好了??

以辱罵來管理部屬的管理團隊
在一事無成之前
立即證明了自己的無能

一份規格文件內容
絕對應該包括完整的輸入輸出項目
但清楚的輸出入項目
因為參與者間想法的衝突
因此刻意的不能清楚的被寫下來

規格文件之中的含糊不清
代表著不同的專案參與者的衝突點

釐訂規格書
其實是在折衝參與者之間的衝突

絕大多數的系統導入商團隊或軟體設計團隊
都沒有解決衝突的能力

衝突不是非道德的
談判困難
調解容易
衝突雙方不應知道對方底線
但第三方應知道雙方的底牌

我們是站在一起的
與我們對立的是"要解決的問題"

調解開始於第一小步
我能幫什麼忙嗎?

置你於死地的
不是你不知道的東西
而是
你知道絕不會置你於死的東西

理想的專案人力安排
是在設計啟始階段
讓所有人參與發聲與構想

接著讓核心小團隊執行設計

在設計實現階段時
再大量投入所有領域的人
讓事物實現

時間緩衝少的專案
最後會比有合理緩衝的專案
用掉更多的時間

讓不必與會的人
光明正大的放心離開
保持會議成員與會議內容的相關性與必需性

一份公開的會議議程
嚴格執行

小規模會議是一種專案儀式

人員精簡是失敗公司找藉口的法寶
精簡的真正意義是
失敗
恐嚇
由員工承擔責任

( 知識學習商業管理 )
回應 推薦文章 列印 加入我的文摘
上一篇 回創作列表 下一篇