專案管理-7-降妖除魔
引言 前面說到『唐玄奘披上袈裟，領的禪杖，手捧金缽，辭別唐王』，從此上路了。取經路上，各路妖魔鬼怪，魑魅魍魎，凶神惡煞，無不想吃掉唐僧，以得永生。幸虧收得悟空，悟能，悟靜三位高徒，才保得唐曾，不辭艱險，一去西天，取得真經，修得正果。
對於專案管理，前面的制定章程，規劃，估算，日程安排，建立團隊，算是專案的前期準備的話，那麼現在就該正式執行了，專案管理，就是風險的管理，而整個專案過程中風險迭出，層出不窮，如何才能發現風險，分析風險，消除風險呢。本節就說一下一些具體的管理實踐。
需要注意的是，這些實踐有很多，他們之間沒有特定的順序，但是有彼此的聯絡，要融匯貫通，多管齊下，才能達到你想要的目的，即，專案的成功。就像三徒弟一樣，法力不同，性格迥異，但只有同心協力，才歷盡磨難，保得唐僧，功德圓滿。
下面就一一說一下這些為專案保駕護航的管理實踐。
7.1緊握船舵
7.1.1發現影響專案節奏的情況
1》不知道先要完成哪些需求
如果有人問你『老大，咱們先幹什麼呀，先弄哪個功能啊』，這就有問題了。
2》需求相關的工作花費了較長的時間
如果都過去好幾周了，還在有人問你『老大，你看，現在還有哪些需求啊，是不是該進行需求分析了』，趕緊的，別收集需求了，趕緊組織，找到最重要的那個需求，進行分析，不要再召集所有人，對所有需求進行分析了。
3》gui人員不知下一步幹嘛
如果前期一直在做底層的功能模組，gui的人員一直閒著，整天上網，聊qq，那麼記住『按功能實現，而不是按架構』。乙個功能的實現，一般會涉及到gui。
4》沒有對架構的整體描述
如果大部分的人對這個專案的整體還不了解，只知道自己的『一畝三分地』，不行！趕緊的，召集到一塊，整體介紹一下。
5》要完成某個功能，需要增加相應的技術人員，但是領導不給人。
沒人什麼也幹不了。並且盡量不要外包，尤其是對於一些嵌入式的專案。環環相扣，外包來填補空擋，難度很大。
7.1.2舉行中途回顧會議
抽空，大概每兩周舉行一次，召集大夥，談談心，聊聊他們對專案的感覺，看法，建議。開完以後，給人家乙個回應，這個很必要。
7.1.3給需求排序
不要乙個word文件，從頭到尾，一行行寫著需求，除了乙個序號，沒有其他的標誌。要給需求排序。按價值，給需求排序。排序，程式設計師一定不陌生，採用『冒泡法』就行。當然，需要考慮一下幾方面的因素：對架構的影響，完成計畫所用的時間，對於客戶的重要性，實施的技術可行性。
防止出現『這些需求都很重要』的情況。
7.1.4制定productbacklog
上面排完序，寫到excel裡，指分析前面幾個需求，並分解成小任務，完成後，依此類推。各個擊破。
7.1.5用時間盒限制需求相關的工作
如上所敘，對於需要，當斷則斷，不斷則亂。
7.1.6使用顯式或隱式的迭代
千萬不要把整個專案作為乙個迭代，不行，要把功能分解成小功能，用一定的時間完成，然後測試，整合。即，持續整合。如果公司不允許什麼『迭代』的概念產生，低調點也行，直接這麼做就行了，別給他起個名稱，實在不行，就起個外號。也成。
7.1.7波浪式的規劃專案，安排日程
不要試圖，一口吃個胖子。要按經過排序的需求列表，化大為小，循序漸進，各個突破，持續整合。
7.1.8建立跨職能團隊
盡量使自己的專案團隊的角色多一些，包括，做架構的，編碼的，測試的，gui的。這樣會有好處的。技術越全面，做出來的產品越完美。
7.1.9選用合適的生命週期模型
前面已經說過了，適合自己的最重要。
7.1.10保持合理的加班時間
一般一周不要超過兩天在加班。要不然團隊會抱怨的嚴重。產生抵制，效果會適得其反。如果出現了，就修改日程安排或調整資源配備。
7.1.11化整為零
把大任務，分解成小任務。一般不要超過1個人日。
7.1.12應對干擾
人是社會的人，總會跟別人打交道，要打交道，就會有干擾。一般干擾分為兩種，其他專案的干擾，其他人的干擾。
對於其他專案的干擾，要盡量推遲，最少要推遲到下個迭代。並且把這些干擾都記錄下來，然後呈獻給領導和其他人看，讓他們明白，干擾帶來的影響。
對於來自其他人的干擾，要結對程式設計（別先假設團隊不願意，要先允許結對），對於討論問題，讓他們到封閉空間，別影響其他人。
7.1.13從專案開始就管理缺陷
在專案開始之前，就準備好bug列表，發現乙個，記錄乙個，解決乙個，更新乙個。不要認為，bug是從專案後期才會出現的。而這就要求在一開始就有測試人員介入。如果沒有測試人員，就把單元測試的結果填寫進去，並時刻提醒成員，現在就有bug。
7.1.14多幾隻眼盯著專案
尋找機會，讓更多的人來了解專案，了解已經實現的功能，並進行試用。對於團隊內部，要嘗試結對，同伴互查，走查，正式檢查等方式來發現bug，增強健壯性。
7.1.15用故事來描述需求
對於需求，不要用很深奧的術語來描述，沒幾個人仔細看。要假設一種情景，把需求入其中。
7.1.16選擇簡單的工具來進行專案管理工作
別整好多專業的軟體，雲裡霧裡，效果不一定會好，還要花很多時間來學習，還要培訓團隊。一般情況下，簡單的excel就能辦到。
7.1.17不要開那些費時費力，沒有多少效果的會議
首先要從自己做起，別動不動就把某某叫到自己的辦公室。沒什麼事的話，就通過郵件溝通就夠了。如果真有事，一般別超過15分鐘。要不人別人會煩『我剛要幹活，你就把我叫過去了，結果今天什麼也沒乾成』。
當然有些會是一定要開的，比如，專案啟動會議，發布版本規劃會議，迭代回顧會議，等。還需注意的是，會議之前要準備好，通知到。把會議目的，日程，講義，要提前發給大家。這樣會省好多時間，效果還好。要有會議記錄，會後要有跟蹤落實。要『責任到人』。除此之外，每週要有乙個進度報告，通過郵件的形式就行了，並且要讓所有人知道當前專案的進度情況，以及別人的進度情況。即，敏捷裡面的『透明性』，這個真的非常重要。
7.1.18向領導和客戶展現風險和已完成的功能
要定期的想老闆和客戶報告專案的風險，當然還要給他們信心，就是展示團隊已經完成的功能。讓他們看到，這個專案在一天一天的有所進步。
7.2張榜公示
通過上面的實踐，是不是起到作用了呢，專案的進度是否合適呢，就需要反饋機制，這些反饋最好以圖表的形式展現。下面就說幾種，供選擇。
說明，其實這些變數之間是存在關係的，為了方便，沒有嚴格描繪，請見諒。
7.2.1功能數目圖
全部數目
已完成數目
剩餘數目
————日期
7.2.2結束日期圖
估算結束日期
————日期
7.2.3日程對比圖
計畫完成時間
實際完成時間
————啟動，規劃，架構，編碼，測試
7.2.4人員數目圖
計畫人員數目
實際人員數目
————日期
7.2.5變更數目圖
重要變更數
小變更數
————日期
7.2.6缺陷數目圖
總缺陷數
完成缺陷數
剩餘缺陷數
拒絕缺陷數
————日期
7.2.7測試效果圖
計畫測試數
實際測試數
通過數————日期
7.2.8實踐雷達圖
夥伴複查
自動測試
波浪式規劃
按功能實現
持續整合
7.3小結
融匯貫通，多管齊下。
軟體專案管理（7）
軟體專案管理 7 1 需求分析 1 也稱為需求建模，是為終端使用者所看到的系統建立乙個概念模型，是對需求的抽象描述，並盡可能多地捕獲現實世界的語義。2 需求分析的任務就是借助於當前系統的邏輯模型匯出目標系統的邏輯模型，解決目標系統的 做什麼 的問題。3 分析使用者需求應執行下列活動 1 以圖形表示的...
IT專案管理作業7
題一 題目內容 準備和列印一頁類似於圖7 2的成本模型 題二使用你上面製作的成本模型，通過按wbs分配成本，為這個專案每個月指定成本基線 題三假設專案已經做了三個月，而這個為期6個月的專案的bca是20 000美元，並且 pv 120 000美元 ev 100 000美元 ac 90 000美元 a...
PMP專案管理 專案風險管理（7）
專案風險管理包括規劃風險管理 識別風險 實施風險分析 規劃風險應對和控制風險 等各個過程。專案風險管理的目標在於提高專案中積極事件的概率和影響，降低專案中消極 事件的概率和影響。7.1 規劃風險管理 定義如何實施專案風險管理活動的過程。7.2 識別風險 判斷哪些風險可能影響專案並記錄其特徵的過程。7...