您的位置:軟件測試 > 軟件項目管理 > 進度管理 >
進度管理:死亡之旅-后期限
作者:網絡轉載 發(fā)布時間:[ 2013/7/5 16:49:05 ] 推薦標簽:

摘錄的案例:

老板BB:是1.3日,到10.1我們必須完成AIX新產品的開發(fā),這個產品對公司很重要,具有高的優(yōu)先級,這是后的期限。

老板BB:我們分析階段要用多少時間?

項目成員:可是我們還不知道用戶的需求,無法確定分析需要時間

老板BB:假設需求在你面前,你需要多少時間分析

項目成員:如果分析超過4.1日,我們是不可能完成后續(xù)任務的

項目Lead:我們會找到方法在4.1日完成所有分析

老板BB:那我們設計需要花多少時間?

項目成員:沒有分析需要時間估計,很難清楚設計需要時間

老板BB:假如你已經做過了分析?

項目Lead:只剩下6個月的時間,設計好不要超過3個月

老板BB:大家能夠同意這個時間,我很高興,好,4月1號前完成分析,7月1號前完成設計,那么你們有3個月的時間實現項目。這次會議是一個榜樣,它表明了我們新的協商和授權程序工作的有多么好,F在,大家可以離開,開始工作了。我期望在下周前,可以在我的辦公桌上看到 TQM(全面質量管理)計劃以及 QIT(質量改進團隊)任命情況。

老板BB:記住,SEI下周要過來做一次評估。這是評估指南。你要把它讀一遍,記住它,然后把它撕碎。它告訴你如何回答 SEI 審計師問你的任何問題。它還告訴你在構建過程中可以使用哪些部分內容以及避免使用哪些部分內容。到 6 月份時,我們會被確定為 CMM3 級機構。

案例分析:

倒排進度有時在受資源約束的時候是有效的進度安排方法,當在用戶需求無法明確的情況下卻下明確了產品交付時間,這樣倒排的進度沒有任何意義,的是給高層管理的心理安慰.倒排進度好比用結論本身在證明著結論的正確性,它給我們帶來的大迷惑是已經假設了結論的正確性,然后我們樂此不疲的在用這種未知的假設做著讓高層滿意的推論.

盲目樂觀,空乏的估算,不切實際的進度,很多項目一開始注定是死亡之旅.項目經理不能領導項目成功,只能成為項目失敗的替罪羊.項目經理一開始對高層領導的盲目迎合和缺乏風險意識,終將使項目和自己受到沉重的代價.任何項目都有風險,但對于耗無勝算的項目(按目標完成概率<40%),好的方法是選擇離開,而不是項目失敗后再來找藉口,請記住選擇和方向很重要,我們在選擇前可以深思熟慮,選擇后則只有勇往直前.

過程很重要,好的過程有助于我們開發(fā)出好的產品.但在不切實際的進度面前過程更加顯得蒼白無力.對進度的恐慌迫使我們有強烈的意愿去達到各階段的目標和里程碑,因為你和高層領導都清楚這樣一個事實,如果里程碑無法達到,你去告訴你的領導你嚴格的遵守了各個過程是多么沒有說服力的話語.而實際上你完全遵守過程執(zhí)行,往往減少后期大量的返工時間,更容易達成項目目標.不是過程不好,而是我們不夠成熟,我們需要的是盡可能早的暴露風險和未知,這樣你才能安下心來長舒口氣.

重要片斷:

令你大為驚奇的是,現在要回答“當用戶敲擊回車鍵時,系統(tǒng)應該做什么?”這個問題,需要填寫15頁的表格和問答題。(華麗而無效的過程)

3.27號,距離分析完成還有一周時間,你們已經產生了大量的文檔和圖示,但是你們對問題的分析卻和1 月3號時一樣的淺薄。(交付物代表了什么?)

4.1日,奇跡發(fā)生了,你的上司給高層發(fā)郵件說明你們已經成功的完成了分析階段.老板團隊所表現出的不可思議的團結和團隊協作(盲目的樂觀)

有傳言說,一旦被 SEI 授予 CMM3 級,和BB同層以及更高層的管理者可以得到豐厚的獎金.(權力和政治)

"如果我們要將設計詳細到代碼級的程度,我們?yōu)楹尾恢苯尤ゾ帉懘a呢?"

"因為那樣的話,你當然不是在設計了。而設計階段惟一允許做的事情是設計."

評審會議很快變成有關面向對象的意義、分析和設計的定義以及何時使用聚合和關聯的爭論。(偏離主題的評審)

你告訴你的上司,這些變更意味著你需要對系統(tǒng)的大部分內容進行重新分析和重新設計,但是他卻說,“分析階段已經結束。惟一允許做的事情是設計,F在回去設計吧。”(死板的規(guī)程)

7月1號,另一個奇跡發(fā)生了!你完成了設計!一份無法反映真實需求的設計文檔.充斥著大量的類圖,模型和序列圖.(復雜而無用的模型)

你的上司雇傭了一個顧問來構建一個計算所編寫的代碼行數的工具。他把一張很大的坐標紙貼在墻上,在頂部標出了數字1000000。每天他都會延長紅線來顯示增加了多少行代碼。(毫無意義的度量)

接著,他立刻閃現出了管理方面的洞察力,說,“我知道了!,任何一行代碼都不能超過 20 個字符。任何超過 20 個字符的代碼行必須得分成兩行或者更多的行——越多越好,F有的所有代碼都必須按這個標準改寫。這會使我們的代碼行增加!”

拼湊、拼湊、拼湊還是拼湊。你和你的團隊瘋狂地編碼。到8月1號,你的上司皺著眉頭看著墻上的坐標紙,制定出了強制性的每周要工作 50小時。(加班已不能解決問題)

后,到3月份。經過了大量的 65 小時工作周后。一個非常不可靠的版本完成了。實地使用時,錯誤的出現率非常高,技術支持人員對于發(fā)怒的客戶的抱怨和要求束手無策。所有人都不高興。(為時已晚)

4月,高層決定通過購買的方式來解決問題,他購買了由 Rupert工業(yè)公司開發(fā)的產品的使用授權并重新銷售?蛻舻呐鸨黄较⒘,市場人員沾沾自喜,而你被解雇了。(替罪羊產生)

軟件測試工具 | 聯系我們 | 投訴建議 | 誠聘英才 | 申請使用列表 | 網站地圖
滬ICP備07036474 2003-2017 版權所有 上海澤眾軟件科技有限公司 Shanghai ZeZhong Software Co.,Ltd