項目管理實施方案

項目管理實施方案如何要成功的做好項目管理?首先必須先要明白的是在特定的領(lǐng)域中賦予這個角色所要實現(xiàn)的目標、承擔的職責、以及項目管理者的具體工作內(nèi)容是什么?從我個人的淺見和角度以及我們所從事的IT領(lǐng)域來分析回答以上兩個問題。第一目標作為一個項目的管理者，必須要明確的知道自己的工作目標；我個人認為項目管理者的目1、就是清晰明確地了解項目利害關(guān)系者的需求和期望，努力做到滿足項目利害關(guān)系者的不第二職責作為項日的管理者，首先要端正態(tài)度，要明確知道自己的工作職責，認識到這份工作職責的本質(zhì)。項目管理者不是來管人的，而是來支持人的，是來協(xié)調(diào)資源的，是來營造一個適合團隊成員比較認同的工作環(huán)境和氛圍的，是來為·個共同的目標和大家·起戰(zhàn)斗共同成6、項目風險識別、風險評估、風險解決和風險管理策略以及做好突發(fā)風險的應(yīng)急預(yù)案。第三項目管理工作內(nèi)容作為項目管理者必須清晰的知道自己的工作范圍和所要做的工作內(nèi)容以及工作重心，分為對項目進行技術(shù)可行性分析、技術(shù)評估、成本評估以及風險評估。與需求提出方的代表或負責人進行需求討論，明確項目的目標、價值；確定項目范圍、功能及優(yōu)先級。組建項目團隊，特別要搞清楚項目的keyperson(對產(chǎn)品有決定權(quán)的項目涉及到的開發(fā)資源、測試資源、設(shè)計資源(包括人員和軟硬件資源);數(shù)據(jù)庫設(shè)計；系對需求變更進行控制管理：對項目風險進行管理：測試階段BUGFIXED及改進、收集反饋包括制定項目發(fā)布計劃，用戶培訓(xùn)，發(fā)布上線。最后對完成的成果，系統(tǒng)部署安裝手冊、第四項目管理實施細則要做好項目管理，實現(xiàn)目標、履行職責、完成工作中的具體內(nèi)容，從我個人這幾年的工作經(jīng)驗和面臨的一些問題，還有所積累的一些項目管理中的一些知識以及自己的觀察和思考1、項目開發(fā)時間的估算制定項目進度時間表的時候，需要估算每個任務(wù)所需的時間，其中開發(fā)任務(wù)中模塊的分配在公司現(xiàn)有的技術(shù)框架下，開發(fā)人員主要的工作是投入在具體的業(yè)務(wù)邏輯上。通常每個模這里所謂的技術(shù)難點定義是：在現(xiàn)有系統(tǒng)中還未實現(xiàn)的、開發(fā)人員自身也未接觸過的技對于這樣的難點，開發(fā)者沒有相關(guān)的代碼可以參考，自己也沒有經(jīng)驗，所以需要投入一些2、然后召集所有開發(fā)人員，討論模塊的分配和開發(fā)時間估算。將劃分好的模塊，讓開發(fā)人員從中挑選他們感興趣的模塊。這樣做可以提高開發(fā)人員的主動性和參與性。在分配模塊的時候還需從以下幾方面考慮，以A、相同類似的模塊由同一人負責開發(fā)，比如用戶管理的增刪改由同一開發(fā)者負責。這樣做的好處就是開發(fā)者對相關(guān)邏輯會更加熟悉，同時接口的定義也會比較明確，溝通的成本3、模塊分配完后，開發(fā)人員評估自己負責開發(fā)的模塊所需要的時間。在此過程中最好做到要和開發(fā)者比較詳細的討論每個模塊的技術(shù)實現(xiàn)，以便使時間的估算更加準確。4、對開發(fā)人員估算的時間進行確認。在確認過程中作為項目管理者應(yīng)參考以上提到的三個因素，同時將自己估算的時間和開發(fā)人員估算的時間進行比較。這其中的差異當然會存在的。對于那些差異比較大的，將與技術(shù)人員探討其中的緣由。對于時間周期比較長的任盡量將任務(wù)通過再細分的手段細化任務(wù)，爭取每個任務(wù)的最長時間不超過3天：時間周期越長的任務(wù)，不確定性越高，風險也越高，越有可能成為項目的瓶頸，影響項目的進度。CodeReview是保證項目中代碼質(zhì)量非常重要的一個環(huán)節(jié)，在這一環(huán)中我們公司做的非常欠缺，把關(guān)不嚴格；這是導(dǎo)致每次測試后出現(xiàn)大量bug的主要原因，這一環(huán)需要納入績效考核中，實行責任追究制，實施重點監(jiān)控。出現(xiàn)這樣的薄弱環(huán)節(jié)，造成這樣的原因，我想也是有很多因素造成的：比如開發(fā)人員對需求不是很明確，以自己比較主觀的因素去完成任務(wù)的；還有對整個系統(tǒng)業(yè)務(wù)邏輯沒有正確的清晰的認識的原因，以及對項目組成員培訓(xùn)不范”文檔：記錄代碼實現(xiàn)應(yīng)該遵循的標準。通過這兩個文檔來規(guī)范開發(fā)人員的代碼實現(xiàn)，3、代碼編寫者和代碼市核者坐在一起，由代碼編寫者按照UseCase依次講解自己負責的4、代碼審核者在此過程中可以隨時提出自己的疑問，同時積極發(fā)現(xiàn)隱藏的bug:對這些5、代碼講解完畢后，代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要一行一行靜下心來看。同時代碼又要全面的看，以修改建議，然后把“審核報告”發(fā)送給相關(guān)人員。7、代碼編寫者根據(jù)“代碼審核報告”給出的修改意見，修改好代碼，有不清楚的地方可于特別值得提醒的問題可群發(fā)email給所有技術(shù)人員。如果通過以上步驟，還因為是代碼編寫者的原因而出現(xiàn)嚴重的缺陷問題，將通過績效考核來加深代碼編寫者的印象，并在周報會議上做通報批評。需求變更管理也是項目管理中最重要的一個環(huán)節(jié)，對需求變更管理的有效性將直接影響項3、積極發(fā)現(xiàn)引起變更的因素，促使變更盡可能早的出現(xiàn)，減低變更帶來的風險。1、相關(guān)的干系人必須清楚地了解發(fā)生的變通過制定需求變更的流程，確保項目中的需求變更有效地進行，實現(xiàn)上述的目標。需求變改變，都需要走需求變更流程，這一環(huán)節(jié)我們基本沒有，期間有時候使的工作很混亂，也就是因為沒有一個規(guī)范的變更流程而造成的；如果建立了這么一個流程規(guī)范和機制，需求2、項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產(chǎn)品3、項目管理者評估該需求變更。針對接收到的需求變更的要求，召集相關(guān)人員討論該需求變更的合理性、可行性，實施的代價以及對項目的影響。包括可費用，質(zhì)量等計劃。項目管理者作為項目的負責人，對項目的成功與否負有主要的責任。所以需求變更的決策者應(yīng)該由項目管理者承擔。4、需求變更確認后由專人將需求變更記錄下來，通知給項目中所有成員。其中以下人員對需求的變更是緊密相關(guān)的，他們必須知曉并認可此需求變更。包括(客戶方，需求分析人員，測試人員，相關(guān)開發(fā)人員)。需求變更記錄格式如下：序號變更提出時間變更描述對原有需求的修改還是新增需求)原因變更提出者開發(fā)人員對進度的影響(工作量)125、確定變更的負責人。承擔需求變更的具體工作，比如基線控制，對需求變更的記錄，并6、相關(guān)人員接收到確認的需求變更后，做以下事情。需求分析人員修改需求說明書和UserCase的相關(guān)內(nèi)容。測試人員修改測試用例的相關(guān)內(nèi)容。開發(fā)人員修改代碼中的相關(guān)部7、按照變更后的計劃實施項目，并進行檢查，跟蹤，對變更后的實施反饋和可能出現(xiàn)的問8、需求凍結(jié)。項目越到后期，需求變更對項目的影響就越大，所以在一定時候要進入風險管理是項目管理者最重要的工作之一。風險管理是一個持續(xù)的過程，貫穿于整個項目過程中，風險管理包括風險識別、風險評估、風險解決以及風險管理策略。在項目的實施過程中需要不斷地識別和應(yīng)對風險，并加以有效的控制，風險管理的好與壞直接影響項目的實施效果，從某種意義上講，項目實施對于項目管理者就是識別、分析、應(yīng)對、控制風險的過程，使項目的約束性目標和質(zhì)量目標朝有利的方向發(fā)展。項目不同于日常任務(wù)，它有明確的起止時間和目標，要在明確的范圍、時間和成本約束下，達到相應(yīng)的質(zhì)量標準，并取得用戶的滿意。影響項目成敗的因素涉及方方面面，并且風險伴隨著項目的始終，是客觀存在的，作為一個項目管理者，應(yīng)該具備良好的風險控制意識，善于識別風險并分析風險的影響，從中發(fā)現(xiàn)影響目標的風險點，并施加影響或采取應(yīng)對措施，把風險的負面影響降到最低，并且風險控制應(yīng)該貫穿項目始終。風險引起的負面后果集中體現(xiàn)在進度延后、成本超支、質(zhì)量不達標等方面，導(dǎo)致這些問題的因素主要包括目標以及需求不明確、范圍蔓延以及需求變更、代碼質(zhì)量或返工風險、人員技能和資源的不足、缺乏良好的團隊協(xié)作等。下面將詳細描述一下這些問題以及出現(xiàn)這為了市場競爭或內(nèi)部管理決策的需要，業(yè)務(wù)部門提出的需求往往要求的時間比較緊迫，需求的提出大多停留在幾張紙或口頭的傳達上，沒有形成正式的業(yè)務(wù)需求文檔，在沒有明確的需求范圍的情況下，有時為了迎合業(yè)務(wù)部門的口味匆匆開工，過程中用戶不斷地提出新的想法，技術(shù)人員開始疲于奔命和應(yīng)付，很難保證項目的進度和質(zhì)量，也難以取得業(yè)務(wù)部門的認可。所以，在項目的前期一定要采取相應(yīng)的手段或措施，與業(yè)務(wù)部門共同明確項目目標、需求范圍，充分考慮現(xiàn)有的時間和資源約束，將需求排定優(yōu)先級，對于關(guān)鍵的需求優(yōu)先實現(xiàn)，其他輔助性的根據(jù)過程中的具體情況進行滾動式計劃。并取得業(yè)務(wù)部門的書面確認。在此過程中要注重挖掘用戶的隱性需求，可以通過引導(dǎo)、系統(tǒng)原型等手段讓用戶在在有了明確的目標和需求范圍的情況下，需求的變更還是不可避免的，業(yè)務(wù)部門在看到具體系統(tǒng)的真實雛形之后，源源不斷地要求、新想法隨之產(chǎn)生，如果不對此加以控制，新的需求的加入通常會影響已實現(xiàn)的需求，并且對項月進度和成本產(chǎn)生很大的影響。項目管理者針對這種情況一定要采取嚴格的變更控制流程，不能礙于面子，否則最終的結(jié)果往往是出力不討好。針對用戶提出的新需求，按照正式流程提出變更申請。組織相關(guān)團隊成員進行分析及評估，作為是否實施的依據(jù)，變更控制負責人根據(jù)分析結(jié)果判斷是否批準，如果批準，那項目組可以安排實施，否則，正式拒絕用戶的請求，當然實際情況下可以采取一需求變更風險：需求已經(jīng)打上了基線，但此后仍然有變更發(fā)生，對項目造成影響。如何減前期的需求討論要詳細、充分。需求文檔中需求的范圍要明確、功能描述要清楚。找出項目中需求的決策者(通常會是產(chǎn)品經(jīng)理、相關(guān)職能主管、客戶),所有的需求要經(jīng)過他們的認可?？蛻粼陧椖窟^程中的全程參與有助于降低此類風險。需求討論、需求確認、UserCase確認、測試階段的客戶驗收等環(huán)節(jié)，都要要求客戶參與。在發(fā)生需求變更時，嚴格按照需求變更流程執(zhí)行。在分析設(shè)計階段的中的確認和評審也是降低此類風險的重要手段。3、代碼質(zhì)量或返工風險質(zhì)量風險主要指開發(fā)代碼的質(zhì)量。如何提高開發(fā)人員開發(fā)的質(zhì)量?在制定項目計劃時，對開發(fā)時間的評估要盡可能的合適。合理的開發(fā)時間對開發(fā)質(zhì)量的影響也很大。有時開發(fā)人員為了趕進度在比較緊張的時間需要完成指定的任務(wù)，可能就存在很大的開發(fā)質(zhì)量問題。開發(fā)要有一套嚴格可行的代碼規(guī)范，編碼時嚴格遵守，到現(xiàn)在為止，我們這個方面做的不是很規(guī)范，做的也很不足，大家編寫的代碼隨意性比較大，代碼編寫者的主觀意識性比較強。要建立一套大家認可并且規(guī)范可行的編碼規(guī)范和考核規(guī)范，codereview時嚴格考核。返工是項目組最不愿意看到的，既浪費人力、物力和財力，又影響團隊積極性。需求不明確或范圍沒有有效控制都可能造成返工，另外造成返工的原因是質(zhì)量沒有達到用戶要求。往往有這樣一種情況，每個團隊成員按照項目計劃報告進度都是100%完成，但一到最后系統(tǒng)交互測試或集成的時候就會發(fā)現(xiàn)一大堆問題，不得不花費很大精力回頭排查、修改程序，造成這種情況的主要原因是過程中質(zhì)量保證沒有做到位，把大部分問題留在了后面。這就需要在項目實施過程中采取有效的措施來規(guī)避返工的風險，通常的做法有同行評審，比如概要設(shè)計完成之后，邀請其他項目組的技術(shù)專家進行技術(shù)評審以發(fā)現(xiàn)架構(gòu)設(shè)計問題：管理評審，通過組織級的質(zhì)量審計看產(chǎn)品以及實施過程是否滿足質(zhì)量要求：代碼走查，在編碼過程中加入至少一次的代碼走查，排查不符合規(guī)范或性能要求的代碼，走查通常能夠發(fā)現(xiàn)50%-70%的錯誤：每日構(gòu)建，這是一種非常有效的方法，可以避免把各部分的集成問題拖到最后，并且能夠及時發(fā)現(xiàn)相應(yīng)的錯誤，日構(gòu)建一般在項目的中后期開始，每天自動從版技術(shù)人員完成同樣一個任務(wù)需要3天，但一個生手可能就需要7-10天。項目管理者應(yīng)該在前期就分析清楚項目所要采用的技術(shù)以及相應(yīng)的人員技能要求，針對不同的角色，及時采取相應(yīng)的技能培訓(xùn)，以保證項目的順利實施。如果對于項目中某些部分專業(yè)性特別強或新技術(shù)，短期內(nèi)又不能快速建立技能的情況，可以考慮將該塊任務(wù)外包，借鑒合作商的力量降低實施風險，當然要進行外購人力成本與自建人力成本的效益分析。開發(fā)過程中遇到技術(shù)難題，導(dǎo)致開發(fā)時間延遲或者需求不得不發(fā)生變更。如何減少此類風險的發(fā)生?在項目開始前的技術(shù)評估階段，明確技術(shù)難點，提前安排人員進行攻克。如果在可預(yù)期的時間內(nèi)無法解決，如果可以.將向需求提出方要求變更需求或?qū)ふ铱商娲桨?。這樣的風險應(yīng)該在項目的前期階段就應(yīng)該解決在萌芽狀態(tài)來避免這樣的風險在后期或中期出現(xiàn)。項目所需人力資源無法按時到位，導(dǎo)致資源風險。如何減少此類風險的發(fā)生?這個就需要在項目計劃制定的時候提前中請確認資源，并在項軟件項目實施屬于知識型，要發(fā)揮團隊成員的創(chuàng)造力，不同于制造業(yè)計件生產(chǎn)，各模塊最終要集成在一起形成一個有機的整體，這就需要各小組之間的密切配合，界定清楚工作界面及接口關(guān)系，并在實施過程中持續(xù)地溝通在項目啟動和團隊組建的時候就應(yīng)該加以規(guī)避這樣的風險出現(xiàn)。一、上述我們所說的風險管理都是指可以預(yù)期將要發(fā)生的風險，那些不可預(yù)期將要發(fā)生的風險不屬于風險管理的范疇。這也將是考驗一個項目管理者的經(jīng)驗和知識對能否管理好風二、對不可預(yù)期的風險，項目管理者要有潛在的風險意識評估，做好一些可操作性的預(yù)案三、詳細明確的項目計劃、以及項目執(zhí)行過程中每個要點的質(zhì)量保證是降低項目風險的必風險報告的格式：序號風險簡介對項目的影響解決方案或?qū)Σ呔褪菆F隊成員為實現(xiàn)這個共同的目標而付出的共同努力，項目團隊的工作是否有效直接關(guān)團隊管理是個漸進的過程。世界上只有完美的團隊，沒有完美的個人。好的高效的團隊不是管理出來的，而是營造出來的。團隊成員需要有大家可認同的團隊文化，這需要大家共組織會議是項目管理者日常工作中一項非常重要的工作任務(wù)，項目過程中很多重要的決定都是在會議中做出的，也有很多由于不成功的會議而對項目本身造成了不好的影響。這些不成功的會議最終的結(jié)果就是：既浪費了大家的寶貴時間又沒有達到會議的目的，很多人都對這樣的會議都有抵觸情緒，對此也是深惡痛絕。以下是組織會議時應(yīng)該注意的問題，也可看作組織會議的最