專案管理實務入門
專案管理實務入門 梅田弘之 博碩文化
引導專案成功的52條準則
讀後感想:
過年時間 回鄉下時 隨手帶回去看的。淺顯易懂，基礎書籍
看了本書，就能體會專案管理的難題是全國共通的
尤其在軟體業，不定之因素太多了，如何有效控管及讓客戶滿意呢?
這個每個人都有很多想法及建議的，也有很多人覺得專案管理是靠個人魅力及從失敗中找尋經驗
不過唯有基礎觀念打好，還有基本控管動作要紮實，才能在關鍵時刻，把風險降低
本書中有提到，軟體業於專案管理上還有很大的進步空間，如何師法建築業那種控管及預估精準(CMMI Level 5 的目標)
我想這也是未來能否在軟體業生存的一大課題
而最後二章的工具篇，可惜了~只是工具操作篇 並非我想像中教導遇到問題時如何排除篇
more..
書摘：
Chapter 1 馬上建立專案計劃書吧!!
Chapter 1 馬上建立專案計劃書吧!!
首先要設定明確的目標: 要使全體成員有共目標，專案的目標，往往不是很清楚，儘可能將專案的目標作成具體而可以對照的數值，ex:例如以低採購成本為專案目標的話，就要決定年度預定低的成本要從多少降低到多少
可以成功地領導專案的專案負責人通常有 判斷力 決策力 領導能力 溝通能力 專業技術 毅力
確實執行專案管理技巧 方法 就算不是最頂尖的人也可以成功地領導專案的進行
要使專案成功 經驗很有價值，有經驗豐富的專案負責人在心中有很清楚明確的遠景可以達成專案的目標
在腦中要清楚成功是怎樣，失敗又是怎樣
專案的目標應該儘量集中成一個，如果同時達兩個以上目標就可能陷入 同時追兩隻免子的高度風險
在同時列出要達成的目標時，應儘可能設定具體的目標，如果有需要的話，也可建立階段性進行的計畫目標
專案管理三要素 schedule,cost,quality
waterfall & spiral(螺旋式)
受託專案，很難適用螺線模式? 因為該模式和waterfall 相比在最初階段要確實計算預算是較為困難的，但如果善用在剛開始時能預估好螺線的圈數或是以專案完成的程度來衡量之技巧是很重要的
儘早下筆定出計劃書 是建立專案計劃最重要的一點，並且要多加使用範本
Chapter 2 製作排程及運用範本
學習過去的失敗不要再犯同樣的錯誤
檢查超出期限的風險
運用checkList來認識失敗的風險(當有超過五個以上的風險成立)應該停下檢討一下 找出對策
建立排程需隨時更新
一個好的專案負責人應做到 1.建立適當的排程 2.確實管理專案成員的進度 3.如果delay 要做出適當的指示
(使用範本也是一種義務)
為了達成組織的效率化，必須要準備排程表的統一範本，並統一所有專案的填寫及管理方法
綜合排程，用一表格規劃整體專案的排程，儘可能注意到專案的整體性。如作業時間沒有相距很遠，應該列在同一表格裡
詳細排程，用在作業內容的詳細設定及進度管理的話需建立詳細排程
以功能區分的排程為基礎來跟催進度及管理，以具體實行日程管理，用百分比來管理進度
外包管理比較會出狀況的是事先沒有明確的進度管理指標
綜合排程，需要在需求分析階段的最後階段完成，它是判斷所企劃的系統是否可行的一個要素
如果要執行詳細設計進度管理的話，在基本設計的最後就要具體的配置開發成員
排程修正的頻率，通常選定每週固定一天來執行排程修正
Chapter 3 螺線型模式的專案管理和專案組織圖
首先，試著做看看 是螺線型模式的特徵
但該模式也需要製作專案計劃與排程表，必須要依照「原型計劃書」來決定製作怎樣的原型
使用該模式，並非所有階段的工作都是依照這種方式進行，通常會在waterfall模式上的細部設計、程式設計、程式開發、單元測式的階段會置換成螺線型模式的工程再來建立排程
也有兩種方式並行的分類法，一般用程式開發是以螺線型模式，而在資料庫設計或資料轉移及系統架設則是採用waterfall
需採用專案組織圖以清楚分配角色，而且需注意不要有黑暗的角落及幽靈成員 並找出那些是利害關係人
可運用WBS(work breakdown structure 工作展開)進行切割功能作業，這種技巧就是將原型專案必要的工程或工作由上而下分析，以階層造來表現的方法
Chatper 4 外包管理是成人間的相互配合
有配合良的協力廠商也可以算是個資訊企業的競爭力
為了和協力廠商能配合良好，所以需要有清楚的作業分工，用文件的方式來保存和協力廠商的會議紀錄內容及問答，共同商定品質管理的標準
基本契約有個重點就是要詳述完成作品的著作權歸屬，目前著作權法除非基本契約中有載明，鴀然著作權並不是歸屬於包商，而是歸屬於創作者
與協力廠商要互動良好，最重要的一點就是要 確保溝通無障礙
會議紀錄，其目的就下要透過文字紀錄「會議的紀錄」，避免日後發生類似像「有說過，沒有說過」這樣的爭議 ，而確實地將會議中所決定的事項紀錄下來。會記錄另一個一樣重要的目的就是挑出保留的項目，在議程上沒有決定的議題有很多變成「要調，要檢討」的項目，什麼時候、誰去執行? 都要記下
於下次會議上，先確認前次會議所保留的項目再繼續會議的進行
在與新的協力廠商合作前，最好要先調查合作夥伴的八是否可以信賴，因此首先「拜訪一下合作的廠商」去感受合作廠商的氣氛 是不錯的方法
在確認功能時，常常進度報告 回報進度已達90% 但有很多案例卻還是久久無法完成，所以最好的進度報告就是親自 確認輸出，並且一定不能有「100% 相信包商一直在那裡等待」，藉由加入檢查，將可使協力廠商確實執行本身的管理制度
和協力廠商平常的溝通主要就是規格變更及Q&A，一般都會沒有留下證據，故容易衍生問題，所以可以使用web or 使用「變更聯絡單」及「問題管理單」進行溝通
進度管理 和 品質管理 是管理協力廠商的兩大要素，巷所有要有產芔品質優良的結果，就要確實的管理，不要使用委託後一切麻煩了，而是要 這裡也要好好的檢查，請配合一下
品質管理 為了釐清責任所在，有必要以書面方式確實事說清楚資料處理量及可容許的反應時間
以減少產出後的問題。
品質是一起思考共同的問題
事先預定測試的日期與預留測試的成員
會議紀錄一般由承包商製作，由發包商確認(下對上)為了能以保留事項的確認目的來用會議紀錄，最理想的狀態是在會議中就做成會議紀錄，會議結束時就能確認完成。如果不能如此的話，至少會議完的隔天就要完成
公司的規定就是這麼囉唆，用公司主管或上司扮黑臉
Chapter 5 自覺品質管理是擅長的領域
軟體業是服務業嗎? 有很多軟體公司有固定和派人力的區分，所以可以稱為是服務業。
但軟體業有製造軟體的意味 ，所以也可以稱為製造業
但軟體業比生產線更有創造性，用建築業來稱呼更恰當
在系統開發上 QC圈相當於專案小組。專案小組不不號以TQC的想法致力提昇個別的專案，而是全公司規模的品質，以TQM的想法確立全公司的品質管理系統。
怎樣才是品質好的軟體 = 使用者的滿意度 非 程式沒有錯誤
以這個定義為前提，設計上的錯誤也需被當成是疏失成為要改善的對象
在品質上需想像使用者使用的情況來製作軟體
ISO9126品質的特性 在開發專案中實現高品，有必要提高每個成員的品質意識
ISO9001是訂定 最碼要求事項的標準 ；而相對的ISO9126則是適合全體成員「人人有獎的要求事項」
定訂品質基準書，使全體成員都徹底了解是很重要的事並且達成共識
品質的精進要點~熱誠
和使用者確認最後的規格前，需檢討設計以消除設計的錯誤
最後強制執行使用者確認計劃書以消除設計的錯誤
單元測試時，使用 marker 來檢查全部過程的資料是無誤的 是件重要的事 尤其是報表
測試時應要有「應該有錯誤」的認知(就像有疑心病的老婆婆一樣)
單元層面的錯誤在單元測試時就要完全清除。如果等到結合層面才發現單元層面的錯的話，就要花很多功夫來解決。結合測試的目的就是要發現程式間的整合性等頭到尾結合層面的缺點
在程式寫完後就單元測試好處是測試起來會較有效率
Chapter 6 徹底管理預算和成本
對SIer(system integrator)而言，「提昇開發成本預算的正確度」是永遠要面對的課
開發成本的預估技巧
LOC(lines of code) 這是使用cobol or PL/1,FORTRAND 常被使用的方法，但web design 和OO design 就不怎麼有效
類推法(排程表) 以過去類似的系統開發的經驗為基礎的預估方法
標準值法 以過去開發經驗值為基礎，使用生產性的標準值，累積每個次系統之工數的方法
Function point 法 在每個功能乘上處理難易度來推定開發規模的方法
COCOMOII 考慮開發規模、難易度、開發特性等因子的預估模型，由生成應用、初期設計、後段架構三種模型所構成
KDD法 即以「經驗、直覺、膽識」來預估，是以負責人主觀的想法為基礎的估算方法，因為沒有客觀的指標，受到學術派的批判 ；類推法、標準值法就是KDD的一種
標準值法 根據過去的開發經驗值為基礎，以生產性標準值來累積每個系統的工數，然後計算開發工數的方法，因為在計算基準時使用數值，也可以說是FP的簡易版
因為KDD法是很主觀性的技巧，所以儘量不要讓一個人來預估
標準法和FP法的不同：FP法要以FP數值指標來表示開發的規模，不 因為對一般的使用者來說，這是不太熟悉的指標，所以常會得到「用FP法也有點困難」的回應 在標準值法中，可利用使用者也可以理解認識的畫面和表單功能為共同的指標
在執行專案時，整體專案成員需共享成本資訊 並且於專案完成時評估預算和實際成效
Chapter 7 在現場管理風險或問題
風險管理的基本方針,明確說明風險和定性化,風險的定量化,風險對策,風險的監視和管理
處理風險的方法中有個就是準備備份，將文件及程式定期備份是基本面對風險的對策
另一個是要有某人不在也不會發生問題的人力備份；而專案成員的情緒管理 要成員不要熬夜 加班
就是另一種程度的預防備份(定期檢查)
追蹤和掌握=把握問題點，解決這些問題
一般追蹤 不外乎 排程的追蹤,品質的追蹤,成本的追蹤,風險的追蹤
常使用當場進行確認作業，能營造嚴格自我要求的氣氛，這種效果很大
時時傾聽問題點，如發現問題應要有別處還有的想法
從Team member的平時言談及臉色也可以看出該專案的風險控管是否出了問題
Chapter 8 了解PMBOK和CMM
學習PMBOK了解組織性的管理方法
PMBOK 五大程序(開始、計劃、執行、控管、結案)及九大知識領域 和三個部份(輸入、工具及實務技巧、輸出)
CMM 五階段的成熟度級別(初始、可重覆、定義、管理、最佳化
PDCA Plan Do Check Action =PMBOK五大程序
強化專案管理的方法
1.有系統地整理、了解專案管理項目(理解PMBOK等)
2.具體符合自己公司狀況的管理技巧(相當於CMM 2,3級)
3.授權技巧，強迫專案成員實踐(相當於CMM 3級）
4.監視、管理的執行，並貫徹執行力(CMM 4級)
5.評估結果，改善管理技巧的缺失，並套用到往後的專案(CMM 5 級)
近期留言