項目管理內(nèi)訓ppt課件

1、工程管理內(nèi)訓PM員工平臺中心宛宗偉培訓主題系列工程管理根底復(fù)雜工程管理人人都是工程經(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)理2022/7/19軟件開發(fā)工程師實施顧問產(chǎn)品顧問技術(shù)總監(jiān)產(chǎn)品總監(jiān)售前顧問軟件開發(fā)工程經(jīng)理工程總監(jiān)產(chǎn)品經(jīng)理架構(gòu)師工程經(jīng)理銷售BOSS測試工程師測試經(jīng)理7專職的工程經(jīng)理兼職的工程經(jīng)理，來源于某一個技術(shù)部門，如開發(fā)部

2、或事業(yè)部，同時可以兼任其他崗位。 對于第二種方式，往往工程經(jīng)理只會對他熟習的作業(yè)內(nèi)容、熟習的人員進展管理，名義上是工程經(jīng)理，實踐是個部分經(jīng)理。爭議工程經(jīng)理要懂技術(shù)。配備專職的工程經(jīng)理。2022/7/198工程經(jīng)理的三種內(nèi)在類型以自我為中心以公司為中心以客戶為中心以自我為中心者寡；以公司為中心者生；以客戶為中心者王；三者達兼那么天下無不可去也9 開發(fā)式工程經(jīng)理產(chǎn)品式工程經(jīng)理外包式工程經(jīng)理按照不同公司主營業(yè)務(wù)不同區(qū)分無成熟軟件產(chǎn)品，新開發(fā)工程；主要任務(wù)在產(chǎn)品規(guī)劃與研發(fā)；工程管理偏重于進度，質(zhì)量；軟件產(chǎn)品成熟，定價銷售；主要任務(wù)是實施，BPR；工程管理偏重于干系人，本錢，范圍；新開發(fā)和產(chǎn)品化實施都存

3、在；工程管理偏重于本錢，進度；工程經(jīng)理的三種外在類型他心目中的工程經(jīng)理應(yīng)該是個怎樣的人？工程管理問心工程經(jīng)理具備的根底才干PMP的九大知識領(lǐng)域是什么？CMMI、ISO對工程流程控制的各項要求了解嗎？實際根底20%協(xié)調(diào)才干40%文檔才干20%溝通才干10%對工程成員協(xié)調(diào)對指點協(xié)調(diào)對客戶協(xié)調(diào)什么情況出什么文檔什么人看什么文檔文檔積累為什么出文檔察言觀色反響迅速明晰表達知識面廣工程管理問心工程經(jīng)理具備的才干抗壓才干10%喜怒不行于色能忍所不能忍清楚壓力臨界點有解壓方法12產(chǎn)品經(jīng)理必備技藝1、一個勝利的產(chǎn)品經(jīng)理的才干中應(yīng)該有35%的工程管理才干。2、個人的才干占15%。3、產(chǎn)品經(jīng)理的業(yè)務(wù)才干占全部的2

4、0%。4、產(chǎn)品經(jīng)理的技術(shù)才干占全部的15%。5、產(chǎn)品經(jīng)理的溝通和處置沖突的才干占全部的15%。產(chǎn)品經(jīng)理應(yīng)該指點工程組，指點產(chǎn)品從概念設(shè)計到市場接受，保證明現(xiàn)設(shè)計、收益、市場份額和利潤目的，處理工程組的沖突；同時產(chǎn)品經(jīng)理還應(yīng)該管理工程，制定工程的方案和預(yù)算，確定和管理參與工程的人員和資源，同職能部門之間相協(xié)調(diào)，跟蹤相對于工程基線的進展；產(chǎn)品經(jīng)理還要擔任和管理層進展溝通，提供工程進展情況的報告，預(yù)備并且確定形狀評審點，作為產(chǎn)品的指點同管理層溝通，提供對工程組 成員的任務(wù)績效評審的輸入資料。一個勝利的產(chǎn)品經(jīng)理通常在一個或多個職能部門從事過管理和操作方面的任務(wù)閱歷，并有管理工程開發(fā)的閱歷。產(chǎn)品經(jīng)理可以

5、來自財務(wù)、R&D、市場等任何部門。產(chǎn)品經(jīng)理富有工程管理閱歷很重要，產(chǎn)品經(jīng)理最好具備工程經(jīng)理的任職資歷證書。工程管理問心13我的總結(jié)：1. 業(yè)務(wù)知識，產(chǎn)品，工程管理，開發(fā)測試不求都知曉，但都要學習；2.會哭會鬧會上吊 3. 對內(nèi)定海神針，對外李鴻章4.既得利益前，不計較個人得失，會做人5.堅持原那么 以身作那么 謙虛且勇于擔當 讓人服氣 6.熟習心思學，厚黑學的謀略家7.永遠不會說我不知道，不能夠，不關(guān)我的事8.永遠首先站在客戶立場思索，處理問題9.深諳職場之道 職業(yè)素養(yǎng)優(yōu)秀10. 三教九流能喝酒，四海之內(nèi)皆朋友工程管理問心14工程管理的分類：工程管理中國式工程管理中國式工程管理的特點：多 快

6、好 省15工程管理矩陣組織結(jié)構(gòu)項目特點職能型矩陣型項目型弱矩陣平衡矩陣強矩陣項目經(jīng)理權(quán)威很少或沒有有限從低到中從中到高從高到全權(quán)資源可用性很少或沒有有限從低到中從中到高從高到全部誰控制項目預(yù)算職能經(jīng)理職能經(jīng)理混合項目經(jīng)理項目經(jīng)理項目經(jīng)理的作用部分時間部分時間全部時間全部時間全部時間項目管理人員部分時間部分時間部分時間全部時間全部時間影響力的來源梳理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 資源限制中心利益 干系人現(xiàn)實是這樣嗎究竟什么才是勝利的工程2022/7/19利益均沾 團隊成型 王者誕生團隊稱心自我稱心用戶稱心指點稱心保證能生存下去進度，本錢處理痛點 滿足需求 獲得認可范圍，進度，質(zhì)量直接受害 品牌建立究竟什么才是勝利的工程工程管理的5大過程工程管理過程可被分成5個過程組，每個過程組有一個或

8、多個管理過程：初始過程：識別一個工程或階段該當開場并提交去完成；方案過程：設(shè)計和維護一個可以任務(wù)的規(guī)劃方案去實現(xiàn)工程所要到達的商務(wù)需求；執(zhí)行過程：協(xié)調(diào)人員和其他資源完成方案；控制過程：經(jīng)過監(jiān)視和丈量進展，并在必要時采取正確的動作保證工程目的的實現(xiàn)；收尾過程：定型為認可方式，并明晰地終了該階段。工程管理過程組間的交互啟動過程組規(guī)劃過程組執(zhí)行過程組監(jiān)控過程組收尾過程組過程相互作用的程度開場完成工程進度工程管理的5大過程工程管理PMP 47過程組與10大知識領(lǐng)域 不同軟件生命周期模型優(yōu)缺陷把每個階段當成瀑布中的一個階梯，強調(diào)由上而下，相互銜接、逐級下落，固定次序。優(yōu)點：開發(fā)階段明晰，便于評審、審計、

9、跟蹤、管理和控制缺陷：不可逆或很難可逆問題會積累，錯誤解傳送發(fā)散擴展，導(dǎo)致本錢和質(zhì)量失控快速原型模型的第一步是快速建立一個能反映用戶主要需求的原型系統(tǒng)，讓用戶在計算機上試用它，經(jīng)過實際來了解目的系統(tǒng)的概貌。優(yōu)點：抑制瀑布模型的缺陷，減少由于軟件需求不明確帶來的開發(fā)風險缺陷：所選用的開發(fā)技術(shù)和工具不一定符合主流的開展，快速建立起來的系統(tǒng)構(gòu)造加上延續(xù)的修正能夠會導(dǎo)致產(chǎn)質(zhì)量量低下。增量模型交融了瀑布模型的根本成分和原型實現(xiàn)的迭代特征。優(yōu)點：人員分配靈敏，增量可以有方案的管理技術(shù)風險。缺陷：軟件具備開放式的體系構(gòu)造。很容易退化為邊做邊改的模型，從而使軟件過程的控制失去整體性。這種模型將功能細化后分別開

10、發(fā)的方法較順應(yīng)于需求經(jīng)常改動的軟件開發(fā)過程。螺旋模型采用周期性的方法來進展系統(tǒng)開發(fā)。優(yōu)點：設(shè)計上的靈敏，可以在工程的各個階段進展變卦。以小的分段來構(gòu)建大型系統(tǒng)，使本錢計算變得簡單容易?？蛻粢恢眳⑴c每個階段的開發(fā)，保證了工程部偏離正確方向以及工程的可控性。缺陷：建立周期長，經(jīng)常出現(xiàn)軟件開發(fā)終了后，和當前的技術(shù)程度有了較大的差距，無法滿足當前用戶需求。瀑布模型快速原型模型原型模型增量模型螺旋模型工程管理軟件生命周期模型噴泉模型噴泉模型是一種以用戶需求為動力，以對象為驅(qū)動的模型，主要用于采用對象技術(shù)的軟件開發(fā)工程。優(yōu)點：該模型各個階段沒有明顯的界限，開發(fā)人員可以同步進展開發(fā)。缺陷：由于可重疊的，因此

11、在開發(fā)過程中需求大量的開發(fā)人員，因此不利于工程的管理。此外這種模型要求嚴厲管理文檔，審核的難度加大工程管理CMMIISO9001與CMMI有哪些區(qū)別和聯(lián)絡(luò)？CMMI與PMBOK有沒有直接的關(guān)系？工程管理PDCAISO9000就是采用PDCA精神循環(huán)實行的天津漢邦企業(yè)管理咨詢循環(huán)主要包括四個階段：方案、實施、檢查和處置，及八個步驟問 題有時候他是不是覺得憑仗本人的直覺和積累的管理知識，就可以把事情辦好？有時候他是不是覺得本人處理問題的方法曾經(jīng)很科學、很有效率了？他的處理方案有多好？1、他是皇帝的俘虜。他要給本人的城堡添加三個新地牢，讓他做一個規(guī)劃。干得好就釋放，干不好就終生監(jiān)禁。 2、小地牢很難

12、設(shè)計，要12周，但容易建成，1周即可；中地牢設(shè)計要5周，施工要6周；大地牢設(shè)計只需1周，但建造要用9周。 3、他有一個設(shè)計師和一個建筑師，設(shè)計師不會建造而建筑師不會設(shè)計。 4、要建好這三個地牢，他規(guī)劃的工期是幾周？Q、R、T分析 Q：三個地牢 最不靈敏要素T：時間最短依他的設(shè)計而定，靈敏要素R：一個設(shè)計師、 一個建筑師人員固定，但在開展詳細任務(wù)的順序上有變動余地，較不靈敏要素質(zhì)量或數(shù)量資源時間規(guī)劃時不同的思緒設(shè)計建造地牢設(shè)計小地牢中地牢大地牢建造小地牢中地牢大地牢設(shè)計建造地牢設(shè)計建造小地牢設(shè)計建造設(shè)計建造中地牢設(shè)計建造設(shè)計建造大地牢設(shè)計建造思緒一思緒二理性的選擇思緒一的缺陷： 從一開場就關(guān)注單

13、個產(chǎn)品這樣的細節(jié)。容易呵斥只見樹木，不見森林.思緒二的關(guān)鍵： 建造可以根據(jù)設(shè)計的整體安排進展調(diào)整。要獲得最正確效果必需安排好任務(wù)的起點與排序.思緒二指點下的任務(wù)安排1、先設(shè)計小地牢2、先設(shè)計中地牢 3、先設(shè)計大地牢最后工期太長1 2 3 4 5 6 7 8 9 10111213141516 1718192021222324 周設(shè)計大地牢設(shè)計中地牢設(shè)計小地牢建造大地牢建造中地牢建造小地牢義務(wù)真的很遺憾 設(shè)計建造地牢的義務(wù)中，按照他的規(guī)劃，雖然工期是最短的，但有兩周建筑師沒有活干，成天睡覺或出去玩耍。不巧的是國王就在這兩周里的某一天來視察了，發(fā)現(xiàn)建筑師在睡大覺，以為他的方案工期雖短，但讓他多浪費了

14、糧食和工錢，不是最正確方案。所以他下令： 判他終生監(jiān)禁！不測的結(jié)果工程管理誰的責任工程管理-案例11階段：立項非訂單軟件 訂單軟件 指點緊急安排原始需求市場需求，業(yè)務(wù)需求，功能優(yōu)化，BUG修復(fù)自提自處理創(chuàng)新，整合，性能提升，彌補從前的錯誤員工平臺中心工程來源立項懇求書工程背景，工程目的，工程等級，變革點，團隊引見，資源方案，里程碑方案，技術(shù)道路，驗收規(guī)范，風險分析工程必要性工程可行性分析產(chǎn)品定義闡明書工程能夠性客戶群&潛在客戶群投入產(chǎn)出分析ROI業(yè)務(wù)需求分析產(chǎn)品設(shè)計，藍圖運營分析立項現(xiàn)階段主要問題：1。目的不明確，可量化程度低；2。變革點中對現(xiàn)有流程，系統(tǒng)的影響范圍缺乏描畫；3。工程團隊及資源

15、方案在立項評審時仍不能完全確定；4。里程碑方案形同虛設(shè)；5。驗收規(guī)范含混不清；6。溝通不暢；7。工程等級確定有疑問；8。整體概念感差，缺乏營運視角；9?；谛枨蟊旧恚苌偎妓饔脩舾惺?；10。工程例會制度沒有建立；11。對于評審未經(jīng)過的緣由沒有記錄和總結(jié)；12。經(jīng)過不經(jīng)過，無法量化，目前指點說的算；立項反面教材： 正面教材： 立項立項評審目的產(chǎn)品工程從需求到上線流程Diagramthemegallery針對如今的企業(yè)現(xiàn)狀和行業(yè)趨勢，戰(zhàn)略需求文檔，可以是商業(yè)可行性分析重點放在為一個被提議的新產(chǎn)品或者現(xiàn)有產(chǎn)品的改良定義市場需求偏重于從產(chǎn)品本身角度對待需求區(qū)別-BRD關(guān)鍵闡明產(chǎn)品的方向，MRD關(guān)鍵闡

16、明產(chǎn)品的定位開場銜接開發(fā)定義產(chǎn)品功能需求的全部細節(jié)SRS文檔PRD文檔MRD文檔BRD文檔如今我們消費車最有賺頭如今我們消費小汽車才真有賺頭產(chǎn)品定義闡明書 業(yè)務(wù)需求闡明書系統(tǒng)需求闡明書系統(tǒng)概要設(shè)計系統(tǒng)詳細設(shè)計文檔困惑What Why Who When How 系統(tǒng)評審需求評審立項評審立項預(yù)備需求調(diào)研開發(fā)測試上線驗收產(chǎn)品定義闡明書 業(yè)務(wù)需求闡明書系統(tǒng)需求闡明書系統(tǒng)概要設(shè)計系統(tǒng)詳細設(shè)計文檔困惑What Why Who When How 系統(tǒng)評審需求評審立項評審立項預(yù)備需求調(diào)研開發(fā)測試上線驗收產(chǎn)品定義闡明書 業(yè)務(wù)需求闡明書系統(tǒng)需求闡明書系統(tǒng)概要設(shè)計系統(tǒng)詳細設(shè)計文檔困惑What Why Who Whe

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

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

19、control)，風險預(yù)測(exposure rating)不要說工程的失敗是由于新需求引起的,一個沒有新增需求和風險的工程是不存在的。 工程的誤區(qū)： 三邊行動邊方案邊實施邊修正壞了壞了，期限到了，忙不完了！不行啊，情況變化，我們的工程進程恐怕也要變動了！下一步該干什么?還沒想好，正在作新方案呢。呵斥“三邊行動的根本緣由是在目的未清、職責未明的情況下就倉促開場往下做細節(jié)，結(jié)果常會由于在一些小事上扯皮導(dǎo)致工程被不斷地延期。即時最后勉強完成了，也與最初的目的相去甚遠。方案之痛已結(jié)項工程數(shù)據(jù)已上線工程數(shù)據(jù)方案之鑰WBS的重要性：普通情況：4-6級 任務(wù)包1天，不超越2周 須分解到個人 獨立可交付進度

20、監(jiān)控進度監(jiān)控：對每個階段把握好，每個階段要完成的義務(wù)一定要完成，假設(shè)完不成，是什么緣由導(dǎo)致的？我們的應(yīng)對戰(zhàn)略是什么？我們要信任他人，但是不要忘記鎖門。進度監(jiān)控數(shù)據(jù)分析垂直偏向：實踐與方案之差；橫向偏向：實踐自然天與方案自然天數(shù)之差；橫向偏向率： 實踐耗費自然天數(shù)-方案實踐耗費自然天數(shù)/方案實踐耗費自然天數(shù)整體橫向偏向率：橫向偏向天數(shù)/方案總自然天-橫向偏向天數(shù)2022/7/1955進度監(jiān)控案例：2022/7/19質(zhì)量監(jiān)控國際規(guī)范組織ISO9000對質(zhì)量的定義就是:質(zhì)量是產(chǎn)品或效力用于滿足人們潛在或明示的需求的一切特征和性能的總和2022/7/1957質(zhì)量監(jiān)控質(zhì)量監(jiān)控：也應(yīng)該是分階段進展的，每一

21、個階段的質(zhì)量監(jiān)控內(nèi)容有所不同。需求分析階段：完好而又正確的了解用戶需求，需求能否清楚可懂，寫用例的測試人員能否明白需求？分析設(shè)計階段：設(shè)計能否完全滿足需求？這個設(shè)計方案能否滿足以后新功能的擴展？以及能否有思索到新功能的不測和設(shè)備環(huán)境，運轉(zhuǎn)平臺的變化？編碼階段：變量命名能否規(guī)范？代碼能否可讀？能否有詳細的注釋？能否有反復(fù)代碼？要知道反復(fù)代碼是必然會呵斥系統(tǒng)不穩(wěn)定，bug成群的。做code review代碼公開評審。工程經(jīng)理設(shè)立檢查點的根本原那么是:在潛在的損害、破壞能夠發(fā)生前在一個業(yè)務(wù)邏輯特別復(fù)雜的流程開場之前在與其他軟件系統(tǒng)進展對接前在一個模塊功能完成前在責任發(fā)生轉(zhuǎn)移前2022/7/1958質(zhì)

22、量監(jiān)控數(shù)據(jù)分析不正確的系統(tǒng)需求、過度的進度壓力、團隊缺乏溝通、產(chǎn)品功能復(fù)雜度高、產(chǎn)品設(shè)計不好、關(guān)鍵崗位人員離任、人員閱歷缺乏、系統(tǒng)需求識別不充分、需求頻繁變動、測試覆蓋度缺乏10個要素對工程的質(zhì)量影響最嚴重。系統(tǒng)需求頻繁變動、對系統(tǒng)需求識別不完好、關(guān)鍵崗位人員離任、缺乏有效的開發(fā)方法、團隊成員缺乏溝通、不正確的系統(tǒng)需求、過程監(jiān)控的缺乏、過度的進度壓力、人員缺乏責任心、人員缺乏類似工程閱歷、不明晰的系統(tǒng)需求、采用不成熟的技術(shù)、團隊人員短缺、人員構(gòu)造缺陷等要素與工程的質(zhì)量問題存在著正相關(guān)性。2022/7/1959質(zhì)量監(jiān)控添加加班時間只會降低消費力？短期的壓力乃至于加班能夠是有用的戰(zhàn)略，由于他們能使

23、員工集中精神，并且讓他們感到任務(wù)的重要性，但是長期的壓力一定是錯誤的；經(jīng)理之所以會施加那么多的壓力，也許是由于他們不知道該做什么，或者由于其他方法的困難而感到氣餒；最壞的猜測：運用壓力和加班的真正緣由是為了在工程失敗的時候讓一切人看上去能好過一點。在早期，人員超編會迫使工程跨過關(guān)鍵的設(shè)計階段這是為了讓一切的人都有事可做；假設(shè)在設(shè)計完成之前，任務(wù)先被分給了許多人，那么人與人之間，任務(wù)組之間的接口就會很復(fù)雜；這會使團隊內(nèi)部耦合度提高，會議期間，反復(fù)勞動和無效任務(wù)都會添加；理想的人員安排是這樣：在工程的大部分時間是由小型中心團隊來做設(shè)計任務(wù)，在開發(fā)的最后階段時間安排的最后1/6參與大量的人手；2022/7/19問題不應(yīng)該依賴由測試人員來發(fā)現(xiàn)，而應(yīng)該由開發(fā)人員來發(fā)現(xiàn)。軟件的質(zhì)量應(yīng)該由程序員來保證的，而