某公司項目管理內(nèi)訓培訓教材(PPT 67頁).ppt

1、,項目管理內(nèi)訓（PM）,員工平臺中心,宛宗偉,培訓主題系列 項目管理基礎 復雜項目管理 人人都是項目經(jīng)理 人人都是產(chǎn)品經(jīng)理 PMO與PM 探討敏捷 項目集管理,培訓內(nèi)容包括，但不僅限于： 一、項目管理基礎 二、項目管理核心流程解析 三、項目管理微創(chuàng)新 四、IT行業(yè)基準介紹 五、數(shù)據(jù)分析在項目管理中的應用 六、項目績效評分新規(guī)則解析 注：本次培訓針對主要面向員工平臺研發(fā)中心所有員工，不僅限于產(chǎn)品經(jīng)理,項目和產(chǎn)品的區(qū)別,什么是項目經(jīng)理,2020/8/9,軟件開發(fā)工程師,實施顧問,產(chǎn)品顧問,技術(shù)總監(jiān),產(chǎn)品總監(jiān),售前顧問,軟件開發(fā)項目經(jīng)理,項目總監(jiān),產(chǎn)品經(jīng)理,架構(gòu)師,項目經(jīng)理,銷售,BOSS,測試 工

2、程師,測試經(jīng)理,7,專職的項目經(jīng)理 兼職的項目經(jīng)理，來源于某一個技術(shù)部門，如開發(fā)部或事業(yè)部，同時可以兼任其他崗位。 對于第二種方式，往往項目經(jīng)理只會對他熟悉的作業(yè)內(nèi)容、熟悉的人員進行管理，名義上是項目經(jīng)理，實際是個局部經(jīng)理。 爭議 項目經(jīng)理要懂技術(shù)。 配備專職的項目經(jīng)理。,2020/8/9,8,項目經(jīng)理的三種內(nèi)在類型,以自我為中心,以公司為中心,以客戶為中心,以自我為中心者寡； 以公司為中心者生； 以客戶為中心者王；,三者達兼則天下無不可去也,9,開發(fā)式項目經(jīng)理,產(chǎn)品式項目經(jīng)理,外包式項目經(jīng)理,按照不同公司主營業(yè)務不同區(qū)分,無成熟軟件產(chǎn)品，新開發(fā)項目； 主要工作在產(chǎn)品規(guī)劃與研發(fā)； 項目管理偏重

3、于進度，質(zhì)量；,軟件產(chǎn)品成熟，定價銷售； 主要工作是實施，BPR； 項目管理偏重于干系人，成本，范圍；,新開發(fā)和產(chǎn)品化實施都存在； 項目管理偏重于成本，進度；,項目經(jīng)理的三種外在類型,你心目中的項目經(jīng)理應該是個怎樣的人？,項目管理問心,項目經(jīng)理具備的基礎能力,PMP的九大知識領域是什么？ CMMI、ISO對項目流程控制的各項要求了解嗎？,理論基礎20%,協(xié)調(diào)能力40%,文檔能力20%,溝通能力10%,對項目成員協(xié)調(diào) 對領導協(xié)調(diào) 對客戶協(xié)調(diào),什么情況出什么文檔 什么人看什么文檔 文檔積累 為什么出文檔,察言觀色 反應迅速 清晰表達 知識面廣,項目管理問心,項目經(jīng)理具備的能力,抗壓能力10%,喜怒

4、不行于色 能忍所不能忍 清楚壓力臨界點 有解壓方法,12,產(chǎn)品經(jīng)理必備技能 1、一個成功的產(chǎn)品經(jīng)理的能力中應該有35%的項目管理能力。2、個人的能力占15%。3、產(chǎn)品經(jīng)理的業(yè)務能力占全部的20%。4、產(chǎn)品經(jīng)理的技術(shù)能力占全部的15%。5、產(chǎn)品經(jīng)理的溝通和處理沖突的能力占全部的15%。 產(chǎn)品經(jīng)理應該領導項目組，指導產(chǎn)品從概念設計到市場接受，保證實現(xiàn)設計、收益、市場份額和利潤目標，解決項目組的沖突； 同時產(chǎn)品經(jīng)理還應該管理項目，制定項目的計劃和預算，確定和管理參與項目的人員和資源，同職能部門之間相協(xié)調(diào)，跟蹤相對于項目基線的進展； 產(chǎn)品經(jīng)理還要負責和管理層進行溝通，提供項目進展狀況的報告，準備并且確

5、定狀態(tài)評審點，作為產(chǎn)品的領導同管理層溝通，提供對項目組 成員的工作績效評審的輸入材料。 一個成功的產(chǎn)品經(jīng)理通常在一個或多個職能部門從事過管理和操作方面的工作經(jīng)驗，并有管理項目開發(fā)的經(jīng)歷。產(chǎn)品經(jīng)理可以來自財務、R&D、市場等任何部門。 產(chǎn)品經(jīng)理富有項目管理經(jīng)驗很重要，產(chǎn)品經(jīng)理最好具備項目經(jīng)理的任職資格證書。,項目管理問心,13,我的總結(jié)： 1. 業(yè)務知識，產(chǎn)品，項目管理，開發(fā)測試不求都精通，但都要學習； 2.會哭會鬧會上吊 3. 對內(nèi)定海神針，對外李鴻章 4.既得利益前，不計較個人得失，會做人 5.堅持原則 以身作則 謙虛且勇于擔當 讓人信服 6.熟悉心理學，厚黑學的謀略家 7.永遠不會說”我不

6、知道，不可能，不關我的事” 8.永遠首先站在客戶立場思考，解決問題 9.深諳職場之道 職業(yè)素養(yǎng)優(yōu)秀 10. 三教九流能喝酒，四海之內(nèi)皆朋友,項目管理問心,14,項目管理的分類： 項目管理 中國式項目管理,中國式項目管理的特點：多 快 好 省,15,項目管理矩陣,影響力的來源梳理 1.職位影響力 短期可執(zhí)行性：效果： 2.專業(yè)影響力 短期可執(zhí)行性：效果： 3.資歷影響力 短期可執(zhí)行性：效果： 4.情感影響力 短期可執(zhí)行性：效果： 5.品格影響力 短期可執(zhí)行性：效果：,評估項目成功的指標是什么?,項目成功評價指標,時間,成本,企業(yè)的榮譽,項目目標,項目影響者的滿意度,高層領導的滿意,社會責任,項目

7、實施者成就感,項目管理3要素（3重制約）,質(zhì)量Quality,時間Time,成本Cost,范圍Scope,人 People,項目管理魔鬼三角,時間,成本,范圍,項目管理魔鬼三角,成本,時間,范圍,質(zhì)量,Time 時間限制,Quality&Quantity 質(zhì)量&數(shù)量限制,Resource 資源限制,核心利益 干系人,事實是這樣嗎,到底什么才是成功的項目,2020/8/9,利益均沾 團隊成型 王者誕生,保證能生存下去 （進度，成本）,解決痛點 滿足需求 獲得認可 （范圍，進度，質(zhì)量）,直接受益 品牌建立,到底什么才是成功的項目,項目管理的5大過程,項目管理過程可被分成5個過程組，每個過程組有一個

8、或多個管理過程： 初始過程：識別一個項目或階段應當開始并提交去完成； 計劃過程：設計和維護一個可以工作的規(guī)劃方案去實現(xiàn)項目所要達到的商務需要； 執(zhí)行過程：協(xié)調(diào)人員和其他資源完成計劃； 控制過程：通過監(jiān)督和測量進展，并在必要時采取正確的動作保障項目目標的實現(xiàn)； 收尾過程：定型為認可形式，并清晰地結(jié)束該階段。,項目管理過程組間的交互,項目管理的5大過程,項目管理PMP 47過程組與10大知識領域,項目管理軟件生命周期模型,噴泉模型,噴泉模型是一種以用戶需求為動力，以對象為驅(qū)動的模型，主要用于采用對象技術(shù)的軟件開發(fā)項目。 優(yōu)點：該模型各個階段沒有明顯的界限，開發(fā)人員可以同步進行開發(fā)。 缺點：由于可重

9、疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項目的管理。此外這種模型要求嚴格管理文檔，審核的難度加大,項目管理CMMI,ISO9001與CMMI有哪些區(qū)別和聯(lián)系？,CMMI與PMBOK有沒有直接的關系？,項目管理PDCA,ISO9000就是采用PDCA精神循環(huán)實行的,天津漢邦企業(yè)管理咨詢有限公司,循環(huán)主要包括四個階段：計劃、實施、檢查和處理，及八個步驟,問 題,有時候你是不是覺得憑借自己的直覺和積累的管理知識，就可以把事情辦好？ 有時候你是不是覺得自己解決問題的辦法已經(jīng)很科學、很有效率了？,你的解決方案有多好？,1、你是皇帝的俘虜。他要給自己的城堡增加三個新地牢，讓你做一個規(guī)劃。干得好

10、就釋放，干不好就終生監(jiān)禁。 2、小地牢很難設計，要12周，但容易建成，1周即可；中地牢設計要5周，施工要6周；大地牢設計只要1周，但建造要用9周。 3、你有一個設計師和一個建筑師，設計師不會建造而建筑師不會設計。 4、要建好這三個地牢，你規(guī)劃的工期是幾周？,Q、R、T分析,Q：三個地牢 （最不靈活因素）,T：時間最短 （依你的設計而定，靈活因素）,R：一個設計師、 一個建筑師 （人員固定，但在開展具體工作的順序上有變動余地，較不靈活因素）,質(zhì)量或數(shù)量,資源,時間,規(guī)劃時不同的思路,思路一,思路二,理性的選擇,思路一的缺點： 從一開始就關注單個產(chǎn)品這樣的細節(jié)。容易造成只見樹木，不見森林. 思路二

11、的關鍵： 建造可以根據(jù)設計的整體安排進行調(diào)整。要取得最佳效果必須安排好工作的起點與排序.,思路二指導下的工作安排,1、先設計小地牢 2、先設計中地牢 3、先設計大地牢,最后工期太長,真的很遺憾,設計建造地牢的任務中，按照你的規(guī)劃，雖然工期是最短的，但有兩周建筑師沒有活干，成天睡覺或出去游玩。不巧的是國王就在這兩周里的某一天來視察了，發(fā)現(xiàn)建筑師在睡大覺，認為你的方案工期雖短，但讓他多浪費了糧食和工錢，不是最佳方案。所以他下令：,判你終生監(jiān)禁！,意外的結(jié)果,項目管理誰的責任,項目管理-案例1,1）階段：立項 非訂單軟件 訂單軟件,領導緊急安排,原始需求（市場需要，業(yè)務需要，功能優(yōu)化，BUG修復）,

12、自提自解決（創(chuàng)新，整合，性能提升，彌補從前的錯誤）,員工平臺中心項目來源,立項申請書,項目背景，項目目標，項目等級，變革點， 團隊介紹，資源計劃，里程碑計劃， 技術(shù)路線，驗收標準，風險分析,項目可行性分析,產(chǎn)品定義說明書,項目可能性,客戶群&潛在客戶群,投入產(chǎn)出分析（ROI）,業(yè)務需求分析,產(chǎn)品設計，藍圖,運營分析,立項,現(xiàn)階段主要問題： 1。目標不明確，可量化程度低； 2。變革點中對現(xiàn)有流程，系統(tǒng)的影響范圍缺乏描述； 3。項目團隊及資源計劃在立項評審時仍不能完全確定； 4。里程碑計劃形同虛設； 5。驗收標準含混不清； 6。溝通不暢； 7。項目等級確定有疑問； 8。整體概念感差，缺乏營運視角；

13、 9?；谛枨蟊旧?，而很少考慮用戶感受； 10。項目例會制度沒有建立； 11。對于評審未通過的原因沒有記錄和總結(jié)； 12。通過不通過，無法量化，目前領導說的算；,立項,反面教材：,正面教材：,立項,立項評審指標,產(chǎn)品項目從需求到上線流程,Diagram,針對現(xiàn)在的企業(yè)現(xiàn)狀和行業(yè)趨勢， 戰(zhàn)略需求文檔， 可以是商業(yè)可行性分析,重點放在為一個被提議的新產(chǎn)品或者 現(xiàn)有產(chǎn)品的改進定義市場需求 側(cè)重于從產(chǎn)品本身角度看待需求,區(qū)別-BRD關鍵說明產(chǎn)品的方向， MRD關鍵說明產(chǎn)品的定位,開始銜接開發(fā) 定義產(chǎn)品功能需求的全部細節(jié),現(xiàn)在我們生產(chǎn)車最有賺頭,現(xiàn)在我們生產(chǎn)小汽車才真有賺頭,產(chǎn)品定義說明書 業(yè)務需求說明

14、書 系統(tǒng)需求說明書 系統(tǒng)概要設計 系統(tǒng)詳細設計,文檔困惑,What Why Who When How,系統(tǒng)評審,需求評審,立項評審,立項準備,需求調(diào)研,開發(fā),測試,上線 驗收,產(chǎn)品定義說明書 業(yè)務需求說明書 系統(tǒng)需求說明書 系統(tǒng)概要設計 系統(tǒng)詳細設計,文檔困惑,What Why Who When How,系統(tǒng)評審,需求評審,立項評審,立項準備,需求調(diào)研,開發(fā),測試,上線 驗收,產(chǎn)品定義說明書 業(yè)務需求說明書 系統(tǒng)需求說明書 系統(tǒng)概要設計 系統(tǒng)詳細設計,文檔困惑,What Why Who When How,系統(tǒng)評審,需求評審,立項評審,立項準備,需求調(diào)研,開發(fā),測試,上線 驗收,產(chǎn)品定義說明書

15、業(yè)務需求說明書 系統(tǒng)需求說明書 系統(tǒng)概要設計 系統(tǒng)詳細設計,文檔困惑,What Why Who When How,系統(tǒng)評審,需求評審,立項評審,立項準備,需求調(diào)研,開發(fā),測試,上線 驗收,產(chǎn)品定義說明書 業(yè)務需求說明書 系統(tǒng)需求說明書 系統(tǒng)概要設計 系統(tǒng)詳細設計,文檔困惑,What Why Who When How,系統(tǒng)評審,需求評審,立項評審,立項準備,需求調(diào)研,開發(fā),測試,上線 驗收,階段2：需求評審,項目管理-案例2,3.2.1業(yè)務簡單描述,字段解釋 3.2.4 業(yè)務規(guī)則；,3.2.6 設計細節(jié)； 3.2.7備注；,3.2.2 業(yè)務流程圖及說明,階段3：系統(tǒng)評審,項目管理-案例3,簡要說

16、明 前置條件 后置條件,業(yè)務規(guī)則 補充說明,表單數(shù)據(jù)說明,主流程,PRD,該文檔是產(chǎn)品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔，其作用就是“對MRD中的內(nèi)容進行指標化和技術(shù)化”，這個文檔的質(zhì)量好壞直接影響到研發(fā)部門是否能夠明確產(chǎn)品的功能和性能。,產(chǎn)品需求文檔：,階段4：項目計劃,項目管理-案例4,項目計劃：凡事預則立，不預則廢。 項目計劃一定要包括這幾方面的內(nèi)容：各階段里程碑時間點，各個里程碑的輸出結(jié)果，風險預測，意外應對。計劃一定要提前于交貨時間計劃，風險意外是否留下時間和應對處理方案？,介紹重點：項目計劃(plan)，進度監(jiān)控(progress control)，質(zhì)量監(jiān)控

17、(quality control)，風險預測(exposure rating),不要說項目的失敗是因為新需求引起的,一個沒有新增需求和風險的項目是不存在的。,項目的誤區(qū)：,三邊行動 邊計劃 邊實施 邊修改,壞了壞了，期限到了，忙不完了！,不行啊，情況變化，我們的項目進程恐怕也要變動了！,下一步該干什么?還沒想好，正在作新計劃呢。,造成“三邊行動”的根本原因是在目標未清、職責未明的情況下就倉促開始往下做細節(jié)，結(jié)果常會因為在一些小事上扯皮導致項目被不斷地延期。即時最后勉強完成了，也與最初的目標相去甚遠。,計劃之痛,已結(jié)項項目數(shù)據(jù),已上線項目數(shù)據(jù),計劃之鑰,WBS的重要性：,一般情況：4-6級 工作

18、包1天，不超過2周 須分解到個人 獨立可交付,進度監(jiān)控,進度監(jiān)控：對每個階段把握好，每個階段要完成的任務一定要完成，如果完不成，是什么原因?qū)е碌?？我們的應對策略是什么？我們要信任別人，但是不要忘記鎖門。,進度監(jiān)控數(shù)據(jù)分析,垂直偏差：實際與計劃之差；橫向偏差：實際自然天與計劃自然天數(shù)之差；橫向偏差率： （實際消耗自然天數(shù)-計劃實際消耗自然天數(shù)）/計劃實際消耗自然天數(shù) 整體橫向偏差率：橫向偏差天數(shù)/（計劃總自然天-橫向偏差天數(shù)）,2020/8/9,55,進度監(jiān)控案例：,2020/8/9,質(zhì)量監(jiān)控,國際標準組織ISO9000對質(zhì)量的定義就是:質(zhì)量是產(chǎn)品或服務用于滿足人們潛在或明示的需求的所有特征和性

19、能的總和,2020/8/9,57,質(zhì)量監(jiān)控,質(zhì)量監(jiān)控：也應該是分階段進行的，每一個階段的質(zhì)量監(jiān)控內(nèi)容有所不同。 需求分析階段：完整而又正確的理解用戶需求，需求是否清楚可懂，寫用例的測試人員是否明白需求？ 分析設計階段：設計是否完全滿足需求？這個設計方案是否滿足以后新功能的擴展？以及是否有考慮到新功能的意外和設備環(huán)境，運行平臺的變化？ 編碼階段：變量命名是否規(guī)范？代碼是否可讀？是否有詳細的注釋？是否有重復代碼？要知道重復代碼是必然會造成系統(tǒng)不穩(wěn)定，bug成群的。做code review代碼公開評審。 項目經(jīng)理設立檢查點的基本原則是:,2020/8/9,58,質(zhì)量監(jiān)控數(shù)據(jù)分析,不正確的系統(tǒng)需求、過

20、度的進度壓力、團隊缺乏溝通、產(chǎn)品功能復雜度高、產(chǎn)品設計不好、關鍵崗位人員離職、人員經(jīng)驗不足、系統(tǒng)需求識別不充分、需求頻繁變動、測試覆蓋度不足10個因素對項目的質(zhì)量影響最嚴重。 系統(tǒng)需求頻繁變動、對系統(tǒng)需求識別不完整、關鍵崗位人員離職、缺乏有效的開發(fā)方法、團隊成員缺乏溝通、不正確的系統(tǒng)需求、過程監(jiān)控的不足、過度的進度壓力、人員缺乏責任心、人員缺乏類似項目經(jīng)驗、不清晰的系統(tǒng)需求、采用不成熟的技術(shù)、團隊人員短缺、人員結(jié)構(gòu)缺陷等因素與項目的質(zhì)量問題存在著正相關性。,2020/8/9,59,質(zhì)量監(jiān)控,增加加班時間只會降低生產(chǎn)力？ 短期的壓力乃至于加班可能是有用的策略，因為他們能使員工集中精力，并且讓他們

21、感到工作的重要性，但是長期的壓力肯定是錯誤的； 經(jīng)理之所以會施加那么多的壓力，也許是因為他們不知道該做什么，或者因為其他辦法的困難而感到氣餒； 最壞的猜測：使用壓力和加班的真正原因是為了在項目失敗的時候讓所有人看上去能好過一點。 在早期，人員超編會迫使項目跨過關鍵的設計階段（這是為了讓所有的人都有事可做）； 如果在設計完成之前，工作先被分給了許多人，那么人與人之間，工作組之間的接口就會很復雜； 這會使團隊內(nèi)部耦合度提高，會議期間，重復勞動和無效工作都會增加； 理想的人員安排是這樣：在項目的大部分時間是由小型核心團隊來做設計工作，在開發(fā)的最后階段（時間安排的最后1/6）加入大量的人手；,2020/8/9,問題不應該依賴由測試人員來發(fā)現(xiàn)，而應該由開發(fā)人員來發(fā)現(xiàn)。 軟件的質(zhì)量應該由程序員來保證的，而不是測試人員。 問題不應該由測試人員來發(fā)現(xiàn)，而應該由開發(fā)人員來發(fā)現(xiàn)。也就是說，我們盡量不要讓測試人員來發(fā)現(xiàn)問題。如果第一次測試有至少25%以上的用例通不過，那說明質(zhì)量監(jiān)控出了問題。這