寫得非常好,,前面的專案就是這麼被人給搞壞的,
老闆bb:今天是1.3日,到10.1我們必須完成aix新產品的開發,這個產品對公司很重要,具有最高的優先順序,這是最後的期限。
老闆bb:我們分析階段要用多少時間?
專案成員:可是我們還不知道使用者的需求,無法確定分析需要時間
老闆bb:假設需求就在你面前,你需要多少時間分析
專案成員:如果分析超過4.1日,我們是不可能完成後續任務的
專案lead:我們會找到方法在4.1日完成所有分析
老闆bb:那我們設計需要花多少時間?
專案成員:沒有分析需要時間估計,很難清楚設計需要時間
老闆bb:假如你已經做過了分析?
專案lead:只剩下6個月的時間,設計最好不要超過3個月
老闆bb:大家能夠同意這個時間,我很高興,好，4月1號前完成分析，7月1號前完成設計，那麼你們有3個月的時間實現專案。這次會議是乙個榜樣，它表明了我們新的協商和授權程式工作的有多麼好。現在，大家可以離開，開始工作了。我期望在下週前，可以在我的辦公桌上看到 tqm(全面質量管理)計畫以及 qit(質量改進團隊)任命情況。
老闆bb:記住，sei下週要過來做一次評估。這是評估指南。你要把它讀一遍，記住它，然後把它撕碎。它告訴你如何回答 sei 審計師問你的任何問題。它還告訴你在構建過程中可以使用哪些部分內容以及避免使用哪些部分內容。到 6 月份時，我們會被確定為 cmm3 級機構。
案例分析:
倒排進度有時在受資源約束的時候是有效的進度安排方法,當在使用者需求無法明確的情況下卻下明確了產品交付時間,這樣倒排的進度沒有任何意義,唯一的是給高層管理的心理安慰.倒排進度好比用結論本身在證明著結論的正確性,它給我們帶來的最大迷惑就是已經假設了結論的正確性,然後我們樂此不疲的在用這種未知的假設做著讓高層滿意的推論.
盲目樂觀,空乏的估算,不切實際的進度,很多專案一開始就注定是死亡之旅.專案經理不能領導專案成功,就只能成為專案失敗的替罪羊.專案經理一開始對高層領導的盲目迎合和缺乏風險意識,最終將使專案和自己受到沉重的代價.任何專案都有風險,但對於耗無勝算的專案(按目標完成概率<40%),最好的方法就是選擇離開,而不是專案失敗後再來找藉口,請記住選擇和方向很重要,我們在選擇前可以深思熟慮,選擇後則只有勇往直前.
過程很重要,好的過程有助於我們開發出好的產品.但在不切實際的進度面前過程更加顯得蒼白無力.對進度的恐慌迫使我們有強烈的意願去達到各階段的目標和里程碑,因為你和高層領導都清楚這樣乙個事實,如果里程碑無法達到,你去告訴你的領導你嚴格的遵守了各個過程是多麼沒有說服力的話語.而實際上你完全遵守過程執行,往往減少後期大量的返工時間,更容易達成專案目標.不是過程不好,而是我們不夠成熟,我們需要的是盡可能早的暴露風險和未知,這樣你才能安下心來長舒口氣.
重要片斷:
令你大為驚奇的是，現在要回答「當使用者敲擊回車鍵時，系統應該做什麼？」這個問題，需要填寫15頁的**和問答題。（華麗而無效的過程）
3.27號，距離分析完成還有一周時間，你們已經產生了大量的文件和圖示，但是你們對問題的分析卻和1 月3號時一樣的淺薄。(交付物代表了什麼？)
4.1日,奇蹟發生了,你的上司給高層發郵件說明你們已經成功的完成了分析階段.老闆團隊所表現出的不可思議的團結和團隊協作(盲目的樂觀)
有傳言說，一旦被 sei 授予 cmm3 級，和bb同層以及更高層的管理者就可以得到豐厚的獎金.(權力和政治)
"如果我們要將設計詳細到**級的程度,我們為何不直接去編寫**呢?"
"因為那樣的話，你當然就不是在設計了。而設計階段惟一允許做的事情就是設計."
評審會議很快就變成有關物件導向的意義、分析和設計的定義以及何時使用聚合和關聯的爭論。(偏離主題的評審)
你告訴你的上司，這些變更意味著你需要對系統的大部分內容進行重新分析和重新設計,但是他卻說，「分析階段已經結束。惟一允許做的事情是設計。現在回去設計吧。」（死板的規程）
7月1號，另乙個奇蹟發生了！你完成了設計！乙份無法反映真實需求的設計文件.充斥著大量的類圖,模型和序列圖.(複雜而無用的模型)
你的上司僱傭了乙個顧問來構建乙個計算所編寫的**行數的工具。他把一張很大的座標紙貼在牆上，在頂部標出了數字1000000。每天他都會延長紅線來顯示增加了多少行**。（毫無意義的度量）
接著，他立刻閃現出了管理方面的洞察力，說，「我知道了！，任何一行**都不能超過 20 個字元。任何超過 20 個字元的**行必須得分成兩行或者更多的行——越多越好。現有的所有**都必須按這個標準改寫。這會使我們的**行增加！」
拼湊、拼湊、拼湊還是拼湊。你和你的團隊瘋狂地編碼。到8月1號，你的上司皺著眉頭看著牆上的座標紙，制定出了強制性的每週要工作 50小時。（加班已不能解決問題）
最後，到3月份。經過了大量的 65 小時工作週後。乙個非常不可靠的版本完成了。實地使用時，錯誤的出現率非常高，技術支援人員對於發怒的客戶的抱怨和要求束手無策。所有人都不高興。(為時已晚)
4月，高層決定通過購買的方式來解決問題，他購買了由 rupert工業公司開發的產品的使用授權並重新銷售。客戶的怒火被平息了，市場人員沾沾自喜，而你被解雇了。（替罪羊產生）
軟體專案管理學習（一）
首先軟體專案管理，什麼是專案？什麼是軟體專案？專案是唯一的，臨時的，即在一定的時間內完成。具體定義 專案是為了創造乙個唯一的產品或提供乙個唯一的服務而進行的臨時性的努力。專案的特徵 專案有明確的目標 專案之間的活動具有相關性 限定的週期 有獨特性 資源成本的約束性 預算 專案的不確定性 需求變更 人...
軟體專案管理學習（三）
上次講完了專案初始部分，包括立項 招投標 授權 在進入第二部分，專案計畫 前我們要先了解軟體的需求以及任務的分解 軟體需求管理 軟體需求定義 使用者對軟體功能和效能的要求 軟體需求管理過程 需求獲取 需求分析 需求規格編寫 需求驗證 需求變更 變更管理 確定需求變更控制過程 確立變更控制委員會 sc...
軟體專案管理學習（五）
在get到成本計畫後，我們便要著手開始對專案的進度進行計畫，即這次的核心計畫之一進度計畫。進度計畫的重要性 按時完成專案是專案經理最大的挑戰之一，時間是專案規劃中靈活性最小的因素，進度問題是專案衝突的主要原因。1.進度的定義 進度是對執行的活動和里程碑制定的工作計畫日期表。2.我們知道wbs是面向交...