- 相關(guān)推薦
項目管理總結(jié)ppt
項目管理總結(jié)ppt:項目管理工作總結(jié)
從一個公司小小的業(yè)務(wù)員走到今天公司的項目經(jīng)理,其中的酸甜苦辣,個中滋味也只有自己能夠體會了,不過這些年我一直是通過自己的努力,一步一個腳印慢慢的過來的,這使我慢慢的開始懂得了創(chuàng)業(yè)的艱苦,我走到現(xiàn)在這一部,我更加珍惜我的工作了,我將會在工作中盡自己最大努力的。
回顧20xx年,在公司各級領(lǐng)導(dǎo)的正確指揮及擔(dān)保業(yè)務(wù)部領(lǐng)導(dǎo)的直接帶領(lǐng)之下,本人始終按照公司20xx年工作部署,并根據(jù)本人工作實際,緊緊握住做業(yè)務(wù)和抓營銷兩把鑰匙,在項目經(jīng)理的工作崗位上做到了努力學(xué)習(xí),大膽實踐,轉(zhuǎn)變觀念,很快適應(yīng)了我公司快速發(fā)展的要求,圓滿完成了全年工作任務(wù)。
主要情況匯報如下:
一、端正工作態(tài)度,堅持勤奮敬業(yè)、廉潔自律的職業(yè)操守。
本人熱愛自己的本職工作,熱心為客戶服務(wù),認(rèn)真遵守勞動紀(jì)律,有效利用工作時間,堅守崗位。
需要加班完成工作時,就利用晚上和休息天進(jìn)行調(diào)研和評審報告撰寫,公司下達(dá)的臨時工作任務(wù),都能夠按做到按時按量完成。
在日常工作中嚴(yán)格自律,謝絕客戶多次請客送禮,努力維護(hù)公司在客戶心中的良好的形象,也實際提高了自身的職業(yè)修養(yǎng)。
二、圓滿完成了項目經(jīng)理各項業(yè)務(wù)指標(biāo)。
在20xx年中,本人實際完成擔(dān)保貸款業(yè)務(wù)筆數(shù)7.2筆,完成任務(wù)量的180%,完成業(yè)務(wù)金額為1050萬元,完成任務(wù)量的105%。
其中作為項目經(jīng)理a角完成業(yè)務(wù)5筆,金額688萬元,作為項目經(jīng)理b角完成業(yè)務(wù)2.2筆,金額362萬元,以上本人參與完成的項目共計18筆,業(yè)務(wù)量總額3612萬元。
上述成績的取得得益于公司各級領(lǐng)導(dǎo)的正確領(lǐng)導(dǎo),同事的鼎立支持,再加上本人堅持不懈的努力和花費了大量的加班時間,可以說每一筆貸款,每一分業(yè)務(wù)都包含著心血,留下了刻骨銘心的記憶。
20xx年本人付出了辛勤的汗水,也收獲了成長的喜悅。
三、堅持不懈努力學(xué)習(xí),業(yè)務(wù)理論及實踐經(jīng)驗得到快速提升。
本人在20xx年堅持理論學(xué)習(xí)與實踐操作相結(jié)合,通過公司培訓(xùn)、業(yè)余自學(xué)多種渠道積累業(yè)務(wù)知識,并堅持及時總結(jié)。
年中本人的論文《中小企業(yè)文化建設(shè)的難題及破解之策》在《**擔(dān)保》雜志上發(fā)表,受到不少客戶的好評;本人半年工作總結(jié)也得到了王總的肯定,擔(dān)保項目“人、事、物”原則的思考逐步深入,從單純的“人”、“事”和“物”的三方面擴展到“人”與“事”、“人”與“物”、“事”與“物”的對立統(tǒng)一上。
對該原則的深入思考,使得本人業(yè)務(wù)操作的思路愈加清晰,而不斷的業(yè)務(wù)積累又反過來促進(jìn)了對該原則的深入領(lǐng)會和擴展,感覺收益匪淺。
四、加強貸后管理,努力為公司執(zhí)行力的提高貢獻(xiàn)力量。
在20xx年公司布置重點進(jìn)行的gmis系統(tǒng)流程錄入、檔案歸檔及“回頭看”工作中,本人嚴(yán)格按照公司要求,認(rèn)真完成本人項下的任務(wù),努力做到gmis系統(tǒng)流程與項目流程一致;在項目歸檔工作中,本人也按照公司要求按時按步驟移交了檔案資料,同時也通過該項工作,對貸款資料及時查漏補缺,完善了貸后管理;在回頭看工作中,本人按照公司整體部署和擔(dān)保部具體的安排,對本人負(fù)責(zé)的貸款企業(yè)全部走訪了一遍,其中對重點企業(yè)海南**有限公司走訪了3次,對海南**有限公司存貨質(zhì)押情況不定期抽查9次,較圓滿完成了公司任務(wù),為下一步工作理清了思路。
五、客戶營銷工作取得較大進(jìn)展。
缺乏優(yōu)質(zhì)的客戶資源是新項目經(jīng)理普遍面臨的困難,在20xx年全年的工作中,本人時刻將客戶營銷工作作為自己的核心任務(wù)來抓,全年度推薦企業(yè)加入信用協(xié)會共計6戶,其中已放款的有海南**包裝有限公司一戶60萬元,已通過交通銀行評審但尚未放款的有海南**貿(mào)易有限公司一戶150萬元,其他正在進(jìn)行擔(dān);蛭J業(yè)務(wù)評審的有兩戶,該兩戶計劃發(fā)放貸款約200萬元。
在客戶營銷的實踐中,本人深刻領(lǐng)會并堅決貫徹落實王總多次提出的“向客戶上下游延伸的”思路,在實際著手營銷客戶過程中受到業(yè)務(wù)部潘部長的悉心指導(dǎo),收益匪淺。
最值得稱道的例子是對海南**有限公司的項目操作。
在項目調(diào)查過程中,本人走訪了**公司下游的十余家印刷包裝廠,在核實**公司銷售收入的同時,也向這些印刷包裝廠宣介擔(dān)保公司,了解到了他們的融資需求,解答他們的具體疑問。
通過項目經(jīng)理的言行使他們深切感覺到擔(dān)保公司工作人員敬業(yè)、誠懇、嚴(yán)謹(jǐn)、務(wù)實的工作作風(fēng),不少企業(yè)申請加入了信用協(xié)會,其中海南**包裝有限公司和海南**包裝有限公司還通過我公司擔(dān)保分別獲得了開發(fā)銀行60萬元和50萬元的貸款支持。
今后本人還將會繼續(xù)貫徹王總“向客戶上下游延伸的”的營銷思路,繼續(xù)拓寬客戶來源,深入挖掘發(fā)展?jié)撛诳蛻,將營銷工作向縱深推進(jìn)。
六、通過較長期的實踐,總結(jié)出交行貸款相關(guān)流程。
通過交行貸款,我公司提供擔(dān)保并由開發(fā)行再擔(dān)保的渠道是公司20xx年底開通的新的貸款渠道,但是由于其程序較復(fù)雜,且涉及從交行各支行到分行零貸部、法務(wù)部、主管行長等多個操作環(huán)節(jié),最后還要經(jīng)過開行審批流程,項目經(jīng)理操作過程中需要耗費極大的時間和精力。
本人在20xx年通過海南**有限公司和海南**貿(mào)易有限公司兩戶企業(yè)在上述渠道操作的實踐,同時在*副總、*副總及*部長的直接領(lǐng)導(dǎo)下,總結(jié)出一整套比較成熟和完備的與該渠道相關(guān)的資料、文件及操作流程,一方面為今后公司相關(guān)業(yè)務(wù)的順利開展打下了比較堅實的基礎(chǔ),另一方面使得本人擔(dān)保理論知識和實務(wù)操作水平上了一個新的臺階。
本人認(rèn)為,必須及時總結(jié)工作中的經(jīng)驗教訓(xùn),對指導(dǎo)日后的工作大有裨益,今后本人仍將堅持不懈抓緊。
剛剛過去的20xx年對公司對本人都是收獲的一年,但是也暴露出了不足和缺點,如客戶資源仍然較匱乏,業(yè)務(wù)水平較老項目經(jīng)理存在較大差距,管理細(xì)節(jié)尚不能達(dá)到完善等等。
因此,在今后的工作和學(xué)習(xí)中,本人將繼續(xù)把做業(yè)務(wù)與客戶營銷相結(jié)合、與總結(jié)經(jīng)驗教訓(xùn)相結(jié)合、與個人性格改善相結(jié)合、與鍛煉意志相結(jié)合,努力探索擔(dān)保業(yè)務(wù)與法律業(yè)務(wù)相互促進(jìn)的新途徑,努力將自己鍛造成為一個具有復(fù)合型知識、開發(fā)型性格和堅強意志力的合格的項目經(jīng)理。
只有克服了我的弱點,將我的最大優(yōu)點發(fā)揮出來,那么我這個項目經(jīng)理的工作就可以做到最好了,我也知道我自己的能力還沒有達(dá)到十分強的地步,所以只有不斷的努力和不斷的進(jìn)步才能彌補我的缺憾,我會努力的!
現(xiàn)在的生活就是這樣,競爭的的激烈造就了我的生活中的不斷進(jìn)步,我會將我的工作在大家的幫助下,實現(xiàn)我最好的價值!
項目管理總結(jié)ppt:項目管理流程總結(jié)
一、 風(fēng)險評估
軟件項目風(fēng)險是指在整個項目周期中所涉及的成本預(yù)算、開發(fā)進(jìn)度、技術(shù)難度、經(jīng)濟可行性、安全管理等各方面的問題,以及由這些問題而對項目所產(chǎn)生的影響。
項目的風(fēng)險與其可行性成反比,其可行性越高,風(fēng)險越低。
軟件項目的可行性分為經(jīng)濟可行性、業(yè)務(wù)可行性、技術(shù)可行性、法律可行性等四個方面。
而軟件項目風(fēng)險則分為產(chǎn)品規(guī)模風(fēng)險、需要風(fēng)險、相關(guān)性風(fēng)險、管理風(fēng)險、安全風(fēng)險等六個方面:
1. 產(chǎn)品規(guī)模風(fēng)險
項目的風(fēng)險是與產(chǎn)品的規(guī)模成正比的,一般產(chǎn)品規(guī)模越大,問題就越突出。
尤其是估算產(chǎn)品規(guī)模的方法,復(fù)用軟件的多少,需求變更的多少等因素與產(chǎn)品風(fēng)險息息相關(guān):
(1) 估算產(chǎn)品規(guī)模的方法
(2) 產(chǎn)品規(guī)模估算的信任度
(3) 產(chǎn)品規(guī)模與以前產(chǎn)品規(guī)模平均值的偏差
(4) 產(chǎn)品的用戶數(shù)
(5) 復(fù)用軟件的多少
(6) 產(chǎn)品需求變更的多少
2. 需求風(fēng)險
很多項目在確定需求時都面臨著一些不確定性。
當(dāng)在項目早期容忍了這些不確定性,并且在項目進(jìn)展過程當(dāng)中得不到解決,這些問題就會對項目的成功造成很大威脅。
如果不控制與需求相關(guān)的風(fēng)險因素,那么就很有可能產(chǎn)生錯誤的產(chǎn)品或者拙劣地建造預(yù)期的產(chǎn)品。
每一種情況對產(chǎn)品來講都可能致命的,這些的風(fēng)險因素有:
(1) 對產(chǎn)品缺少清晰的認(rèn)識
(2) 對產(chǎn)品需求缺少認(rèn)同
(3) 在做需求分析過程中客戶參與不夠
(4) 沒有優(yōu)先需求
(5) 由于不確定的需要導(dǎo)致新的市場
(6) 不斷變化需求
(7) 缺少有效的需求變化管理過程
(8) 對需求的變化缺少相關(guān)分析等
3. 相關(guān)性風(fēng)險
許多風(fēng)險都是因為項目的外部環(huán)境或因素的相關(guān)性產(chǎn)生的。
控制外部的相關(guān)性風(fēng)險, 能緩解策略應(yīng)該包括可能性計劃,以便從第二資源或協(xié)同工作資源中取得必要的組成部分,并覺察潛在的問題,與外部環(huán)境相關(guān)的因素有:
(1) 客戶供應(yīng)條目或信息
(2) 交互成員或交互團體依賴性
(3) 內(nèi)部或外部轉(zhuǎn)包商的關(guān)系
(4) 經(jīng)驗豐富人員的可得性
(5) 項目的復(fù)用性
4. 技術(shù)風(fēng)險
軟件技術(shù)的飛速發(fā)展和經(jīng)驗豐富員工的缺乏,意味著項目團隊可能會因為技巧的原因影響項目的成功。
在早期,識別風(fēng)險從而采取合適的預(yù)防措施是解決風(fēng)險領(lǐng)域問題的關(guān)鍵,比如:培訓(xùn)、聘請顧問以及為項目團隊招聘合適的人才等。
關(guān)于技術(shù)主要有下面這些風(fēng)險因素:
(1) 缺乏培訓(xùn)
(2) 對方法、工具和技術(shù)理解的不夠
(3) 應(yīng)用領(lǐng)域的經(jīng)驗不足
(4) 對新的技術(shù)和開發(fā)方法應(yīng)用不熟悉
5. 管理風(fēng)險
盡管管理問題制約了很多項目的成功,但是不要因為風(fēng)險管理計劃中沒有包括所有管理活動而感到驚奇。
在大部分項目里,項目經(jīng)理經(jīng)常是寫項目風(fēng)險管理計劃的人,他們有先天性的不足——不能檢查到自己的錯誤。
因而,使項目的成功變得更加困難。
如果不正視這些棘手的問題,它們就很有可能在項目進(jìn)行的某個階段影響項目本身。
當(dāng)我們定義了項目追蹤過程并且明晰項目角色和責(zé)任,就能處理這些風(fēng)險因素:
(1) 計劃和任務(wù)定義不夠充分
(2) 對實際項目狀態(tài)不了解
(3) 項目所有者和決策者分不清
(4) 不切實際的承諾
(5) 不能與員工之間的進(jìn)行充分地溝通
6. 安全風(fēng)險
軟件產(chǎn)品本身是屬于創(chuàng)造性的產(chǎn)品,產(chǎn)品本身的核心技術(shù)保密非常重要。
但一直以來,我們在軟件這方 面的安全意識比較淡薄,對軟件產(chǎn)品的開發(fā)主要注重技術(shù)本身,而忽略了專利的保護(hù)。
軟件行業(yè)的技術(shù)人員流動是很普遍的現(xiàn)象,隨著技術(shù)人員的流失、變更,很能會導(dǎo)致產(chǎn)品和新技術(shù)的泄密,致使我們的軟件產(chǎn)品被它公司竊取,導(dǎo)致項目失敗。
而且在軟件方面關(guān)于知識產(chǎn)權(quán)的認(rèn)定目前還沒有明確的一個行業(yè)規(guī)范,這也是我們 軟件項目潛在的風(fēng)險。
7. 回避風(fēng)險的方式
(1) 以開發(fā)方誘導(dǎo)能保證需求的完整,使需求與客戶的真實期望高度一致。
再以書面方便形成《用戶需求》這一重要的文檔,避免疏漏造成的損失在軟件系統(tǒng)的后續(xù)階段被逐步地放大。
(2) 設(shè)立監(jiān)督制度,項目開發(fā)中任何較大的決定都必須有客戶參與進(jìn)行的,在該項目中項目監(jiān)督由項目開發(fā)中的質(zhì)量監(jiān)督組來實施。
(3) 需求變更需要經(jīng)過統(tǒng)一的負(fù)責(zé)人提出,并且要用戶需求的審核領(lǐng)導(dǎo)認(rèn)可,需求變更應(yīng)該是定期而不是隨時的提出,而且開發(fā)方應(yīng)該做好詳細(xì)的記錄,讓客戶了解需求變更的實際情況。
(4) 控制系統(tǒng)的復(fù)雜程度,過于簡單的系統(tǒng)結(jié)構(gòu),對用戶來使用比例會有明顯的折扣,甚至造成軟件壽命過短。
反之,軟件結(jié)構(gòu)的過于靈活和通用,必然引起軟件實現(xiàn)的難度增加,系統(tǒng)的復(fù)雜度會上升,這又會在實現(xiàn)和測試階段帶來風(fēng)險。
適當(dāng)控制系統(tǒng)的復(fù)雜程度有利于降低開發(fā)的風(fēng)險。
(5) 從軟件工程的角度看,軟件維護(hù)費用約占總費用的55%~70%,系統(tǒng)越大,該費用越高。
對系統(tǒng)可維護(hù)性的輕視是大型軟件系統(tǒng)的最大風(fēng)險。
在軟件漫長的運營期內(nèi),業(yè)務(wù)規(guī)則肯定會不斷發(fā)展,科學(xué)的解決此問題的做法是不斷對軟件系統(tǒng)進(jìn)行版本升級,在確?删S護(hù)性的前提下逐步擴展系統(tǒng)。
(6) 設(shè)定應(yīng)急計劃,每個開發(fā)計劃都至少應(yīng)該設(shè)定一個應(yīng)急預(yù)案去應(yīng)對出現(xiàn)突發(fā)情況和不可遇知的風(fēng)險。
回到目錄
二、 成本預(yù)算
1. 成本預(yù)算方式
(1) 自上而下的預(yù)算方法
自上而下的預(yù)方法主要是依據(jù)上層、中層項目管理人員的管理經(jīng)驗進(jìn)行判斷,對構(gòu)成項目整體成本的子項目成本進(jìn)行估計,并把這些判斷估計的結(jié)果傳遞給低一層的管理人員,在此基礎(chǔ)上由這一層的管理人員對組成項目的子任務(wù)和子項目的成本進(jìn)行估計,然后繼續(xù)向下一層傳遞他們的成本估計,直到傳遞到最低一層。
使用此預(yù)算方式,在上層的管理人員根據(jù)他們的經(jīng)驗進(jìn)行的費用估計分解到下層時,可能會出現(xiàn)下層人員認(rèn)為上層的估計不足以完成相應(yīng)任務(wù)的情況。
這時,下層人員不一定會表達(dá)出自己的真實觀點,不一定會和上層管理人員進(jìn)行理智地討論,從而得出更為合理的預(yù)算分配方案。
在實際中,他們往往只能沉默地等待上層管理者自行發(fā)現(xiàn)問題并予以糾正,這樣往往會給項目帶來諸多問題。
自上而下更適用于項目啟動的前期,與真實費用相差在30% ~ 70%之間。
Scrum使用自上而下的成本預(yù)算方式,它不會立即精確地確定成本,而是以最大限度容納客戶對未來產(chǎn)品要求所產(chǎn)生的變更。
(2) 自下而上的預(yù)算方法
自下而上方法要求運用WBS(Work Breakdown Structure,工作分解結(jié)構(gòu))對項目的所有工作任務(wù)的時間和預(yù)算進(jìn)行仔細(xì)考察。
最初,預(yù)算是針對資源(團隊成員的工作時間、硬件的配置)進(jìn)行的,項目經(jīng)理在此之上再加上適當(dāng)?shù)拈g接費用(如培訓(xùn)費用、管理費用、不可預(yù)見費等)以及項目要達(dá)到的利潤目標(biāo)就形成了項目的總預(yù)算。
自下而上的預(yù)算方法要求全面考慮所有涉及到的工作任務(wù),更適用于項目的初期與中期,它能準(zhǔn)備地評估項目的成本,與真實費用相差在5% ~ 10%之間。
注解:WBS
WBS是面向提交成果對項目的分解,從提交成果的列表可以確定每個提交成果需要執(zhí)行的活動。
Scrum會對WBS進(jìn)一步細(xì)化,把一個迭代分解為一個或多個的工作包,再把工作包分解為細(xì)小的開發(fā)任務(wù)(一般開發(fā)任務(wù)的開發(fā)周期在15個工作小時以內(nèi))。
2. 確定項目支出
總體成本預(yù)算就是結(jié)合下列多個成本預(yù)算方式綜合計算的開發(fā)成本:
(1) 零基數(shù)預(yù)算
在成本預(yù)算的初期應(yīng)該使用零基數(shù)的計算原則,而不可以使用類似于:以上一年總體費用加上20% 這樣粗略的方式計算項目成本。
(2) 軟硬件成本、物品成本
物品成本是指類似于:服務(wù)器(RAM 硬盤 CPU NIC卡 RAID簇)成本、維護(hù)成本、機房租金、光纖通訊成本、軟件成本等的成本。
計算成本時需要考慮組裝硬盤需時的長短,技術(shù)人員需要具備的質(zhì)素,產(chǎn)品供應(yīng)商能否提供保證質(zhì)量,管理時是否需要額外的管理人員這些多方因素。
(3) 軟件許可證成本
(4) 外包成本
當(dāng)使用類似:視頻、短信、移動電信類服務(wù)、門戶網(wǎng)站等子項目時可以考慮以外包形式完成,以降低開發(fā)成本。
(5) 人力資源成本
計算人力資源成本時應(yīng)該使用以最高和最低的工作效率估算平均效率的方式,計算出人力資源的平均成本。
(6) 維修保養(yǎng)成本
回到目錄
三、 客戶溝通的過程
從客戶溝通的方向出發(fā)來看,軟件項目可分為:需求識別、方案定制、項目實施、項目結(jié)束等4個不同的階段,各個階段都具有不同的溝通重點。
1. 需求識別階段
(1) 文本溝通
在需求識別的前期,應(yīng)該通過問卷、原型展示、界面展示、邏輯處理展示、準(zhǔn)化文檔模板等方式進(jìn)行全方位多角度的分析,隨時將不明確之處反饋給客戶,以期待客戶解答。
并以文本記錄的方式建立需要分析書,并要求客戶審核需求分析書,以達(dá)到需要分析與客戶的真實期望高度一致的結(jié)果。
(2) 業(yè)務(wù)邏輯溝通
在進(jìn)行業(yè)務(wù)溝通時,應(yīng)該了解客戶的行業(yè)語言,以促進(jìn)業(yè)務(wù)分析的過程,越過應(yīng)用需求和開發(fā)之間的鴻溝。
溝通過程提倡以草圖或者可視信息化的方式進(jìn)行, 針對不同層面的企業(yè)用戶提供最適合的操作界面。
以多角度的方式思考問題,要抓住需求重點,尤其是客戶方領(lǐng)導(dǎo)所關(guān)注的創(chuàng)新類和實用類需求。
(3) 需求變更的規(guī)范化管理
需求變更在軟件開發(fā)類項目中是可以理解的,但必須對需求變更做好規(guī)范化的管理,以避免出現(xiàn)需求無止境變更的風(fēng)險。
需求變更必須由統(tǒng)一的負(fù)責(zé)人提出,并且由用戶需求的審核領(lǐng)導(dǎo)者認(rèn)可。
需求變更的提出應(yīng)該是定期而不是隨時的,開發(fā)方應(yīng)該做好詳細(xì)的文本記錄,讓客戶了解需求變更的實際情況和開發(fā)方為之所付出的成本代價。
2. 方案定制階段
該階段項目的主要任務(wù)是與客戶共同制定一個以前期明確的需求、雙方的資源、項目開始的階段、實施的時間約定、項目費用限制等為基礎(chǔ)的具有可操作性的項目計劃,從本階段開始爭取客戶全面參與項目的管理,并以雙方的共同利益考慮項目實施的具體計劃與風(fēng)險規(guī)避。
3. 項目實施階段
在該階段,軟件項目團隊?wèi)?yīng)該與客戶共同領(lǐng)導(dǎo)項目的實施。
同時,項目團隊?wèi)?yīng)實時評估客戶滿意度,并通過持續(xù)改進(jìn)的方式提高客戶滿意度,還應(yīng)要求客戶參加必要的培訓(xùn),以及在必要時檢查項目產(chǎn)品。
在出現(xiàn)客戶的需求變更前,應(yīng)主動與客戶溝通交流,使客戶充分了解項目的每個環(huán)節(jié),以及變更帶來的影響,減少需求變更。
如果出現(xiàn)客戶需求變更,應(yīng)與客戶一起共同解決由變更引起的成本、進(jìn)度、質(zhì)量變化。
4. 結(jié)束階段
該階段主要進(jìn)行項目成果的移交,并把系統(tǒng)交付給維護(hù)人員,幫助客戶實現(xiàn)商務(wù)目標(biāo),結(jié)清各種款項。
完成這些工作后應(yīng)該進(jìn)行項目評估,審核此項目的成果并總結(jié)項目經(jīng)驗。
5. 售前人員注意事項
在產(chǎn)品型項目作為開發(fā)成果時,相關(guān)銷售人員應(yīng)該注意:對產(chǎn)品的推銷不應(yīng)該過分承諾。
如果過分承諾,會給后續(xù)的項目實施帶來困難;一旦承諾沒有兌現(xiàn),也會降低客戶滿意度,影響今后合作。
如果有附加承諾,一定要以文本形式記錄,讓實施項目經(jīng)理知曉并傳達(dá)給項目組成員。
注解:在軟件項目中,需要明確以下四種客戶角色
A. 要明確最終使用部門和用戶,要去了解他們現(xiàn)有的工作方式,要讓他們知道項目的目標(biāo)框架,知道項目要解決他們的哪些困難,但絕對不是全部困難,這樣可以較好的控制項目范圍。
B. 要明確需求的提出者,他或者他們要能夠代表最終客戶群體。
提出產(chǎn)品需求的這類客戶要具有一定的技術(shù)、業(yè)務(wù)能力和權(quán)威,能夠真正代表最終客戶團隊的意愿和想法,最好有IT基礎(chǔ),能夠用IT語言描述問題和需求,以利于雙方的溝通、協(xié)作,避免產(chǎn)生歧義。
C. 要明確做需求確認(rèn)的中層領(lǐng)導(dǎo),他要把握方向。
軟件開發(fā)項目是解決實際生產(chǎn)或者管理問題,同時 也是領(lǐng)導(dǎo)系統(tǒng)建設(shè)的具體實現(xiàn),做需求確認(rèn)的客戶領(lǐng)導(dǎo),既要了解高層領(lǐng)導(dǎo)的系統(tǒng)建設(shè)要點和方向,又要諳熟具體業(yè)務(wù)和生產(chǎn)管理實際。
如果是這樣的客戶領(lǐng)導(dǎo)來把 握和決策,對企業(yè)軟件開發(fā)項目的順利進(jìn)展作用非凡。
D. 要明確誰來對成品提意見,誰來驗收。
項目驗收環(huán)節(jié),是項目的收尾環(huán)節(jié),如果驗收的人對項目初期的需求目標(biāo)不了解,會從態(tài)度和產(chǎn)品實際使用效果上對驗收產(chǎn)生負(fù)面的影響,對提供產(chǎn)品的企業(yè)關(guān)閉項目非常不利。
根據(jù)實踐總結(jié),由需求提出人和確認(rèn)人來做項 目的驗收工作,能夠促進(jìn)項目的順利完成,避免延期。
回到目錄
四、 需求分析
1. 需求分析的過程
需求過程包括需求開發(fā)和需求管理2個部分:
(1) 需求開發(fā)就是對開發(fā)前期的管理,與客房的溝通過程,可以分為4個階段:需求獲取、需求分析、編寫需求和需求驗證。
(2) 需求管理:就是軟件項目開發(fā)過程中控制和維持需求約定的活動。
包括:變更控制、版本控制、需求跟蹤、需求狀態(tài)跟蹤。
2. 需求的層次
需求的層次包括:業(yè)務(wù)需求、用戶需求、功能需求、非功能需求等4個方面。
3. 需求開發(fā)階段的重點
(1) 提取業(yè)務(wù)對象
業(yè)務(wù)對象是指系統(tǒng)使用的真實對象,例如一個供應(yīng)鏈管理 (Supply Chain Management ,簡稱SCM) 業(yè)務(wù)對象主要包括:生產(chǎn)批發(fā)商、零售商、送貨商、顧客多個層次。
(2) 提取業(yè)務(wù)流程
在了解業(yè)務(wù)邏輯的過程中,應(yīng)該列舉出所開發(fā)軟件模塊的各自職能,并細(xì)化每個工作流程,深入分析業(yè)務(wù)邏輯。
(3) 性能需求
在分析的前期應(yīng)該注意客戶對所開發(fā)軟件的技術(shù)性能指標(biāo),如存儲容量限制、運行時間限制、安全保密性等。
(4) 環(huán)境需求
環(huán)境需求是指軟件平臺運行時所處環(huán)境的要求,如硬件方面:機型、外部設(shè)備、數(shù)據(jù)通信接口;軟件方面:系統(tǒng)軟件,包括操作系統(tǒng)、網(wǎng)絡(luò)軟件、數(shù)據(jù)庫管理系統(tǒng)方面;使用方面:使用部門在制度上,操作人員上的技術(shù)水平上應(yīng)具備怎樣的條件。
(5) 可靠性需求
對所開發(fā)軟件在投入運行后發(fā)生故障的概率,應(yīng)該按實際的運行環(huán)境提出要求。
對于重要的軟件,或是運行失效會造成嚴(yán)重后果的軟件,應(yīng)提出較高的可靠性要求。
(6) 安全保密要求
在需求分析時應(yīng)當(dāng)在這方面恰當(dāng)?shù)刈龀鲆?guī)定,對所開發(fā)的軟件給予特殊的設(shè)計,使其在運行中,其安全保密方面的性能得到必要的保證。
(7) 用戶界面需求
為用戶界面細(xì)致地規(guī)定到達(dá)的要求。
(8) 資源使用需求
開發(fā)的軟件在運行時和開發(fā)時所需要的各種資源。
(9) 軟件成本消耗與開發(fā)進(jìn)度需求
在軟件項目立項后,根據(jù)合同規(guī)定,對軟件開發(fā)的進(jìn)度和各步驟的費用提出要求,作為開發(fā)管理的依據(jù)。
(10) 開發(fā)目標(biāo)需求
預(yù)先估計以后系統(tǒng)可能達(dá)到的目標(biāo),這樣可以比較容易對系統(tǒng)進(jìn)行必要的補充和修改。
4. 需求分析的任務(wù)
需求分析的主要任務(wù)是借助于當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型,其流程如下:
(1) 確定對系統(tǒng)的綜合需求(功能、性能、運行、擴充需求)
(2) 制作產(chǎn)品需求文檔 (PRD)
(3) 分析系統(tǒng)的數(shù)據(jù)需求(概念模型、數(shù)據(jù)字典、規(guī)范化)
(4) 導(dǎo)出目標(biāo)系統(tǒng)的詳細(xì)的邏輯模型(數(shù)據(jù)流圖、數(shù)據(jù)字典、主要功能描述)
(5) 開發(fā)原形系統(tǒng)
(6) 從PRD提取編制軟件需求規(guī)格說明書(SRS)
注解:SRS格式
1.引言 2系統(tǒng)概述(項目背景、系統(tǒng)目標(biāo)、核心業(yè)務(wù)流程) 3.術(shù)語說明 4.系統(tǒng)結(jié)構(gòu)(架構(gòu)圖、功能圖)
5.主體功能與業(yè)務(wù)邏輯(重點) 6.接口需求(內(nèi)部、外部接口、) 7.網(wǎng)絡(luò)總體設(shè)計(拓?fù)渚W(wǎng)絡(luò)、主機、組網(wǎng))
8.運行環(huán)境(Linux、Windows、IIS、 WebLogic、Tomcat、OLAP、OLTP、JDK 8.0 、.NET Framework 4.0等)
回到目錄
五、 面向?qū)ο蟪绦蛟O(shè)計(略)
1. 設(shè)計原則
(1) SRP單一職責(zé)鏈
每個類都應(yīng)該只負(fù)責(zé)做一件事。
(2) OCP開封閉合原則
軟件的實體(類、模塊、函數(shù)等)應(yīng)該是可以擴展的,但是不可修改的。
(3) LSP替換原則
子類必須能替換他們的基類型。
(4) DIP依賴倒置原則
高層模塊不應(yīng)該依賴于低層模塊,二者都應(yīng)該依賴于接口與抽象類。
抽象不應(yīng)該依賴于細(xì)節(jié),細(xì)節(jié)應(yīng)依賴于對象。
(5) ISP接口隔離原則
不應(yīng)該強迫客戶依賴于并未使用的接口,而應(yīng)該把胖接口分離。
2. 實現(xiàn)UML建模
(1) 業(yè)務(wù)對象的提取
(2) 根據(jù)SRS、CRC等實現(xiàn)用況建模
(3) 實現(xiàn)業(yè)務(wù)順序圖
(4) 建立類圖,根據(jù)用況圖建立對象之間的關(guān)聯(lián)
(5) 繪制活動圖、實現(xiàn)協(xié)作圖、狀態(tài)圖
回到目錄
六、 開發(fā)管理
1. 建立項目計劃
(1) 設(shè)計總體架構(gòu)
針對系統(tǒng)的實施需要,采取適當(dāng)?shù)那页墒斓目蚣芙Y(jié)構(gòu)。
(2) 控制可擴展度
擴展度過大,將提高系統(tǒng)的復(fù)雜程度,延長開發(fā)時間;擴展度過低,會直接影響系統(tǒng)的二次開發(fā)與維護(hù)。
控制系統(tǒng)的可擴展性,能提高開發(fā)效率,降低系統(tǒng)維護(hù)的難度。
(3) 建立基礎(chǔ)設(shè)施
合理分配部署軟、硬件等基礎(chǔ)設(shè)施所需要的時間與成本(例如:服務(wù)器的訂購安裝、光纖接入、軟件平臺訂購)。
(4) 劃分開發(fā)任務(wù)
利用WBS(Work Breakdown Structure,工作分解結(jié)構(gòu))對可交付結(jié)果進(jìn)行分類與劃分。
每個項目都能劃分為多個不同階段,每個階段又可以分為多個工作包(Work Package),工作包是WBS里最小的可交付結(jié)果,最后從工作包中分解出多個開發(fā)任務(wù)列表。
(5) 部署開發(fā)進(jìn)度
一個項目應(yīng)該按進(jìn)度劃分為多個開發(fā)階段,每個階段的開發(fā)周期一般在30~60個工作日以內(nèi)。
在此階段內(nèi)應(yīng)該與客戶舉行協(xié)商會議,制定產(chǎn)品路線圖,在開發(fā)過程中邀請客戶積極參與并提出反饋意見。
然后把該時段內(nèi)的開發(fā)任務(wù)按照開發(fā)難度,依賴性,重要性等多方條件劃分為多個迭代周期。
在Scrum 敏捷軟件開發(fā)原則中,應(yīng)該把每個迭代任務(wù)進(jìn)一步細(xì)分為多個開發(fā)任務(wù)列表,再開發(fā)任務(wù)分配給組員各自負(fù)責(zé),而開發(fā)時間應(yīng)該控制在15個工作小時以內(nèi)。
如果開發(fā)時間超出15個工作小時,應(yīng)該考慮把開發(fā)任務(wù)再度細(xì)化。
開發(fā)任務(wù)建議應(yīng)該由組員自主選擇,而不要使用強制分配的方式。
(5) 測試項目成果
每個工作包都應(yīng)該同步部署測試工作,提高項目的質(zhì)量。
對出錯BUG的工作包應(yīng)該由測試人員以文本方式記錄,向開發(fā)人員展示錯誤所在,讓開發(fā)人員及時進(jìn)行修改。
2. 管理開發(fā)團隊
(1) 組建團隊
按照工作任務(wù)與項目時間的前提條件建立團隊,按團隊職責(zé)分配人員,一般團隊人數(shù)應(yīng)該控制在8~12人之間。
當(dāng)團隊人數(shù)超過15人時,應(yīng)該考慮把團隊分解成2個獨立團隊,負(fù)責(zé)不同的開發(fā)任務(wù)。
(2) 分配開發(fā)任務(wù)
在每個迭代周期內(nèi)(一般是15~30個工作日),應(yīng)該把每個工作包進(jìn)一步細(xì)分為多個開發(fā)任務(wù),再開發(fā)任務(wù)分配給組員各自負(fù)責(zé),開發(fā)時間應(yīng)該控制在15個工作小時以內(nèi)。
如果開發(fā)任務(wù)的開發(fā)時間超出15個工作小時,應(yīng)該考慮把任務(wù)再度細(xì)化。
而開發(fā)任務(wù)應(yīng)該以自由選擇的方式分配給每個組員。
(3) 監(jiān)督開發(fā)進(jìn)度
在迭代的前期舉行一次會議,讓組員了解開發(fā)的進(jìn)展及流程,并以自主選擇的方式分配開發(fā)任務(wù)。
期間可使用Microsoft Project等工具記錄開發(fā)流程的進(jìn)展,在每個工作包完成開發(fā)后應(yīng)該進(jìn)行性功能的測試,并以文本方式記錄測試結(jié)果。
每天舉行一次15分鐘的站立會議,讓組員交待昨天已完成的開發(fā)任務(wù),當(dāng)天將要做的任務(wù),與開發(fā)過程中所遇到的問題。
并在每周末舉行一次例行會議,交待總體進(jìn)程。
在迭代末期舉行一次沖刺會議,總結(jié)項目的進(jìn)展,交行已完成的任務(wù),回顧該迭代周期內(nèi)所遇到的問題,為下一個迭代做好準(zhǔn)備。
(4) 系統(tǒng)測試
對每個已完成的工作包進(jìn)行適時的測試,保證系統(tǒng)質(zhì)量與性能。
對測試結(jié)果進(jìn)行文本的記錄,并把測試結(jié)果與績效工資收入掛鉤,并以真實數(shù)據(jù)計算組員的績效收入。
(5) 解決開發(fā)中所遇到的問題
對開發(fā)人員進(jìn)行前期培訓(xùn),可適當(dāng)按工作能力分配任務(wù),指導(dǎo)組員的開發(fā)。
當(dāng)遇到問題時應(yīng)該在當(dāng)天的站立會議時即時提出,并在15個工作小時內(nèi)解決所遇到的問題以防止問題進(jìn)一步擴大。
3. 監(jiān)管產(chǎn)品質(zhì)量
(1) 質(zhì)量需要的是計劃、設(shè)計而并非審查的。
在產(chǎn)品建立的初級,必須與“質(zhì)量保證”(QA)的部門進(jìn)行協(xié)商,以正式文檔的方式,決定恰當(dāng)?shù)馁|(zhì)量策略和標(biāo)準(zhǔn)。
(2) 在開發(fā)過程中使用TDD(測試驅(qū)動開發(fā))的模式,提高開發(fā)質(zhì)量。
測試人員應(yīng)該以文本方式記錄bug,并與開發(fā)人員共同工作的,把突出的缺陷演示給開發(fā)人員,以提高修改的效率。
(3) 在每個迭代的結(jié)束時進(jìn)行一次產(chǎn)品效果的演示,從客戶、使用者、高層領(lǐng)導(dǎo)中收集反饋信息。
在團隊內(nèi)部舉行評審會議,分析測試結(jié)果,了解產(chǎn)品性能,為下次迭代所需要做的改進(jìn)做好計劃。
4. 修改項目計劃
(1) 在產(chǎn)品需要識別階段,應(yīng)該以文檔形式記錄產(chǎn)品功能與開發(fā)流程,在開發(fā)計劃需要修改時,應(yīng)該與客戶共同探討,讓客戶了解計劃修改對項目進(jìn)度所造成的影響。
(2) 項目計劃的修改應(yīng)該由統(tǒng)一的負(fù)責(zé)人提出,并且由用戶需求的審核領(lǐng)導(dǎo)者認(rèn)可。
需求變更的提出應(yīng)該是定期而不是隨時的。
(3) 計劃的變更應(yīng)該做好詳細(xì)的文本記錄,讓客戶了解需求變更的實際情況和開發(fā)方為之所付出的成本代價。
回到目錄
七、 產(chǎn)品交付
1. 項目的后期審核
在項目開發(fā)最終完成后,對開發(fā)人員來說可算是放下工作的重?fù)?dān),但對項目經(jīng)理來說這往往是項目的關(guān)鍵時刻。
前期的風(fēng)險評估、成本預(yù)算、需求分析、軟件設(shè)計都是為了引導(dǎo)項目走向這一時刻,此時所有的目光都將投向項目管理人員。
你可能發(fā)現(xiàn)大量而瑣碎的工作將要在幾個小時內(nèi)完成,此刻項目經(jīng)理更需要保持清醒與鎮(zhèn)定,把最后的工作視為微型項目來對待。
細(xì)致地對項目進(jìn)行后期的審核,分析項目成果、項目團隊的效率、可交付產(chǎn)品的價值,以此審核結(jié)果可作為項目管理經(jīng)驗總結(jié)的一部分。
2. 質(zhì)量評審
在項目交付前,應(yīng)該把項目交給相關(guān)的“質(zhì)量保證”(QA)部門進(jìn)行質(zhì)量評審,并邀請典型用戶感受產(chǎn)品的質(zhì)量。
3. 項目的最終交付
正常情況下在項目的前期就會訂立項目交付的協(xié)議,項目交付方式分為非正式驗收與正式驗收兩種。
一般在項目完成后都會先進(jìn)行非正式驗收,讓客戶體會項目的質(zhì)量并提出反饋意見,最后在客戶肯定產(chǎn)品質(zhì)量后再以書面協(xié)議的形式進(jìn)行正式的產(chǎn)品驗收。
4. 項目的最終報告
在項目的最后,應(yīng)該制定項目的最終報告,此報告可以視為是對該項目一個記錄,但報告不必包含項目的所有方面。
一般最終報告應(yīng)該包含以下方面:
(1) 最初引進(jìn)項目時的初期項目視圖
(2) 對該項目的價值評估及支持性信息
(3) 項目的范圍
(4) 項目的開發(fā)流程及WBS
(5) 項目的會議記錄
(6) 項目變更的報告及變更的理由
(7) 與項目相關(guān)的溝通過程文件
(8) 項目的審核報告與客戶驗收報告
(9) 項目成員的表現(xiàn)報告
(10) 項目的最終成果
【項目管理總結(jié)ppt】相關(guān)文章:
項目策劃書ppt10-08
土地項目策劃書ppt10-06
項目建議書ppt模板10-08
項目計劃書模板ppt10-09
工程項目管理總結(jié)10-06
項目管理的工作總結(jié)10-08
項目管理個人總結(jié)10-08
項目管理沙盤實驗總結(jié)10-06
總結(jié)及計劃ppt模板10-05