對軟件研發(fā)項目管理的深入探討分析(共12頁)

1、精選優(yōu)質(zhì)文檔-傾情為你奉上對軟件研發(fā)項目管理的深入探討第一章 簡介1.1 研究背景我之前曾在廈門一家中等規(guī)模(合計開發(fā)人員50人)的軟件公司擔任項目經(jīng)理，開始由于對軟件工程 的不怎么重視，一些失敗的軟件項目給我留下了極深的映象。在失敗和困惑中，我們開始反思，也總結(jié)了一些經(jīng)驗教訓。后來，我們在開發(fā)過程中引入了 MSF(Microsoft Solutions Framework)軟件開發(fā)模型，并結(jié)合公司的具體情況進行了裁減。實踐證明，我們的軟件工程過程管理能力大為提高，軟件的質(zhì)量也有較大程度的提高，軟 件的交付期也得到了基本保證，已經(jīng)沒有再發(fā)生那種“永遠也完不成項目”的情況。1.2 研究動機在這篇

2、文章中，主要談論了在產(chǎn)品開發(fā)中的項目管理問題，此處的“產(chǎn)品開發(fā)”是指做一個通用的軟件產(chǎn)品或者一些具體的領域性系統(tǒng)集成項目。下面我主要結(jié)合我們公司實施MSF的情況，談談自己對軟件工程的一些初步看法。第二章 MSF概要介紹MSF主要由幾個模型構成，其中包括：組隊模型、開發(fā)過程模型、應用模型、風險管理模型。下面只對組隊模型進行較詳細的介紹，其他模型則簡要說明，更詳細的資料請查閱2。2.1組隊模型MSF把軟件開發(fā)分成了六個小組，分別是：程序管理組、產(chǎn)品管理組、開發(fā)組、用戶培訓組、測試 組、安裝管理組。組隊的原則是小隊(一般3-8人)、多側(cè)面;角色交叉、目標一致;人員技術、業(yè)務精;關注能力和交貨期;對項

3、目的前景認識一致;人人參與 設計;善于總結(jié)經(jīng)驗;共同管理、共同決策，項目人員同地工作等。程序管理組的工作是：推動開發(fā)過程;負責產(chǎn)品規(guī)范說明;溝通和協(xié)調(diào)各組關系;管理項目進度，報告項目狀態(tài);把握總體決策。產(chǎn)品管理組的工作是：代表客戶(customer);描述項目產(chǎn)品輪廓;負責需求定義;平衡功能和進度要求;負責市場、宣傳、公共關系等。開發(fā)組的工作是：概要、詳細設計;完成產(chǎn)品開發(fā);準備安裝的產(chǎn)品。測試組的工作是：制定測試策略和計劃;盡可能發(fā)現(xiàn)問題。用戶培訓組工作是：代表終端用戶(end user);負責用戶需求定義;項目管理者聯(lián)盟文章把握可用性和用戶性能指標。項目管理培訓安裝管理組工作是：負責產(chǎn)品安

4、裝;把握可管理性和可支持性。項目管理培訓各組的地位同等，非領導關系，并充分授權，保證目標清晰一致，由各組的負責人共同管理項目。項目管理者聯(lián)盟2.2過程模型項目管理者聯(lián)盟文章MSF過程模型主要確立了四個重要的里程碑：前景范圍確認、項目規(guī)劃確認、開發(fā)完成、對外發(fā)布，通過控制這四個里程碑來分解管理項目過程。2.3應用模型項目管理論壇MSF應用模型是分層次的應用模型，大體可分為三層，用戶層、業(yè)務層和數(shù)據(jù)層，各層次通過標準組件進行封裝，互相通訊調(diào)用來完成系統(tǒng)任務。項目管理論壇2.4風險模型MSF風險管理過程主要包括：風險識別、風險表述，通過分析、計劃、跟蹤和控制過程，最終解除風險。第三章 MSF在項目中

5、的具體應用項目經(jīng)理圈子3.1組隊模型裁減在中小軟件企業(yè)中，一般項目的規(guī)模不會太大，通常是十幾個人，少的只有幾個人，所以必須對MSF 的組隊模型進行簡化。通常的做法是劃分成三個組，程序管理組：一般對應于原來的項目經(jīng)理，通常就項目經(jīng)理一個人，如果需要還可以給他配個組手，通常稱為 “項目秘書”;產(chǎn)品管理和測試組：一般包括MSF中的產(chǎn)品管理組，測試組、用戶培訓和安裝管理，主要代表用戶確定軟件需求并測試產(chǎn)品是否滿足需求;開發(fā) 組：和MSF的開發(fā)組相同。這樣的組隊，比較符合中小項目的需要，在實踐中也證明是比較合理的。首先，確立項目經(jīng)理角色，符合一般公司的管理模式，比較容易被接受。如果有多人同時負責的話，容

6、 易產(chǎn)生責權理不清楚，互相扯皮的現(xiàn)象。有一個項目經(jīng)理對項目完全負責，遇到問題容易很快得到解決;他作為項目組代表，負責向上級匯報工作，能使其他人全力 投入到項目中，而不至于在日常的事務中耽誤太多時間，從而在某種程度上也提高了工作效率。項目管理者聯(lián)盟在原來的很多項目中，大多都沒有設置產(chǎn)品管理角色，他的工作一般由項目經(jīng)理兼任。這樣的做法已證 明存在很多問題，會使項目經(jīng)理精力分散，而且產(chǎn)品管理的任務和項目的日常管理工作也不大相同，如果叫一個人負責，怕兩頭都顧不上搞不好。在產(chǎn)品管理組中， 根據(jù)項目的大小，可以設置兩個負責人，一個代表用戶確定需求，另一個主要負責測試，但由前一個負總責。因為只有用戶代表認可

7、了的產(chǎn)品品質(zhì)，才是真正可以交 付的品質(zhì)。產(chǎn)品管理經(jīng)理(以下簡稱產(chǎn)品經(jīng)理)是項目中非常重要的角色，他可以對技術不是很精通，但是必須對 產(chǎn)品所服務的領域非常熟悉，最好是領域?qū)＜?，在他的帶領下，項目才不至于偏離預先設定的前景范圍。他必須對產(chǎn)品的需求能作出很好的把握，在適當?shù)臅r候能進 行流程重組，對產(chǎn)品的可用性和易用性有最終決定權。根據(jù)我們的經(jīng)驗，通過設定產(chǎn)品經(jīng)理，主要的感覺是產(chǎn)品受用戶的歡迎程度增加了，無用的特性少了，因而也 更容易成功。開發(fā)組主要負責產(chǎn)品的概要設計，詳細設計及代碼實現(xiàn)，這和一般項目中的開發(fā)人員差不多，就不再贅述了。根據(jù)我們的經(jīng)驗，這樣組建的開發(fā)團隊既有助于提高工作效率，又能保證有良

8、好的產(chǎn)品質(zhì)量。沒有設置產(chǎn)品管理角色的團隊最容易產(chǎn)生的問題是開發(fā)人員往往喜歡憑他們的主觀臆想來設定產(chǎn)品的某些功能，最終導致產(chǎn)品易用性極差，不容易為用戶所接受。3.2軟件過程管理MSF開發(fā)過程總的來說是一個基于里程碑的，迭代的，風險驅(qū)動的過程。一般遵循如下原則：進度計劃留有余地;項目管理培訓通過風險管理減少不確定性因素;通過快速原型法盡可能使產(chǎn)品穩(wěn)定和可預測;縮短生命周期;重視創(chuàng)新使資源和性能效率最大化;拆分大項目等。在過程模型上，主要包括四個重要里程碑：前景/范圍確認;項目規(guī)劃確認;項目管理者聯(lián)盟文章開發(fā)完成;項目管理培訓對外發(fā)布。我們把MSF的各個階段對應到傳統(tǒng)的項目開發(fā)各階段，目的是使公司所

9、有人員便于理解和使用。其中 “前景范圍確認”對應傳統(tǒng)的“可行性分析”;“項目規(guī)劃確認”對應“需求分析”和“項目計劃”;“首次運行”對應“開發(fā)完成”，“發(fā)布”的意思和傳統(tǒng)基本 相同。同時，我們也根據(jù)公司的具體情況對流程進行了相應調(diào)整，把整個流程分為可行性分析、需求分析、開發(fā)計劃、開發(fā)過程和結(jié)項總結(jié)五個階段，下面分別進行 說明。3.2.1可行性分析項目經(jīng)理圈子按照ISO9001的要求，在軟件開發(fā)前有一個可行性分析報告，討論項目的可行性和風險，一般公 司項目也都會經(jīng)歷這一階段。做可行性分析一般由未來的項目經(jīng)理和產(chǎn)品經(jīng)理共同完成，討論該項目的技術、經(jīng)濟可行性和潛在的風險等。很多小公司在做項目前都 沒有

10、這個過程，往往是不管自己的實際情況，匆忙上馬，遇到項目就接，結(jié)果是做一個死一個，成功的很少。項目管理者聯(lián)盟在做可行性分析的時候，要充分考慮公司以前的各種技術和市場積累，還有目前的資源可用性情況，特 別是要做好風險分析。我以前就碰到過這種情況，一個項目的領域和公司以前的領域不盡相同，在立項前沒有充分考慮各種情況，認為這個項目比較簡單，應該沒什 么問題，結(jié)果是沒有做得很成功，進度上也拖了一段時間。在后來結(jié)項分析的時候，認為主要的問題就是領域的區(qū)別造成了公司內(nèi)部沒有人對該領域特別熟悉，缺乏 領域?qū)＜?，并對上述風險估計不足，也沒有對風險進行較好的管理，所以造成了項目的不成功。轉(zhuǎn)自項目管理者聯(lián)盟上面提到

11、，可行性分析一般是由未來的項目經(jīng)理和產(chǎn)品經(jīng)理完成，必要時還需要市場人員的參與，項目 經(jīng)理主要考慮技術可行性，包括項目最初估計的進度表和資源需求情況;產(chǎn)品經(jīng)理主要考慮市場和經(jīng)濟上的可行性(主要是針對軟件產(chǎn)品而言)。只有預先對各種問 題進行完備的分析后，才能得出正確的決策。不要到后來因為那些事先沒考慮到的，但應該想到的各種原因造成項目失敗;或者雖然完成了，但是沒有取得預期的效 果，不能給公司帶來較好的收益。只有在可行性分析通過評審，公司高層領導者認可的情況下才能付諸實施。通過可行性分析，揭示了即 將面臨的各種問題及風險，使得公司內(nèi)部對該項目有了一致的認識，在后來的資源申請上也更容易得到高層支持，更

12、易于導致項目成功。那種只有一個想法，就開始 實施的做法是絕對不可取的，可以是單兵做戰(zhàn)，但決不是公司行為。項目管理論壇3.2.2需求分析需求管理是軟件開發(fā)中非常重要的部分，在一般的MIS型項目中，準確的把握需求往往是項目成功的關鍵。但需求管理也是個困難的過程，據(jù)我所知，太多項目的需求都沒有良好的管理過程，往往導致項目后期的大量修改或者直接使項目失敗。需求的管理主要由產(chǎn)品經(jīng)理負責，其中最終用戶(end user)的實時參與是一個非常重要的因素。在需求采集階段，我們主要采用了原型法，使用VB或者FrontPage建立最終產(chǎn)品的界面，然后把功能實現(xiàn) 和界面一一對應起來，和用戶進行討論，并不斷的修改界面

13、。最終在基本達成一致后，對應原型寫出需求規(guī)格說明書，在評審后納入基線管理。在后面的開發(fā)中，我們必須保證最終產(chǎn)品界面和原型基本一致，如有變更，則必須提交項目組和客戶討論。根據(jù)我們的經(jīng)驗，優(yōu)秀的產(chǎn)品經(jīng)理+用戶參與+原型法=良好的需求說明。項目管理論壇在需求的制定過程中，產(chǎn)品經(jīng)理必須和項目經(jīng)理、開發(fā)人員、測試人員進行良好的溝通，使項目組全體都參與到需求分析中來，并共同確定需求的關鍵特性：1.項目的范圍：在需求分析中，首先必須明確項目的范圍，去掉那些看似屬于該項目其實不該在項目 中的需求特性。特別是在一些MIS項目中，客戶往往把一些屬于他們的日常工作但不屬于該項目的需求提交給項目組，這時就必須分清項目

14、的范圍，不要在項目中 加入太多不應該做的東西，否則往往會導致項目范圍無限擴大，最終只能是使項目失敗。2.需求的優(yōu)先級：需求的優(yōu)先級是非常重要的特性，只有在準確把握的需求優(yōu)先級的基礎上我們才 可能規(guī)劃外部里程碑(產(chǎn)品版本)和內(nèi)部里程碑(開發(fā)的階段性，后面會講到)。通常是用戶最關心，使用最頻繁的功能應該屬于高優(yōu)先級，而那些不怎么重要或很 少用到的功能應該屬于低優(yōu)先級。我們必須在產(chǎn)品的開始版本和項目的開始就把重點放在高優(yōu)先級的需求上，而對于低優(yōu)先級的功能可以在項目后期根據(jù)需要進行裁 減或納入下一個版本規(guī)劃。項目經(jīng)理圈子3.產(chǎn)品的易用性：產(chǎn)品的易用性反映在原型中，是原型法的一個非常重要的作用。很多產(chǎn)品

15、的失敗其 一個重要原因就是易用性比較差，雖然它在功能上滿足了用戶需求，甚至可以說功能很強大。通過原型法，能讓用戶看到并模擬使用最終的產(chǎn)品界面，能在需求階段 通過修正軟件界面來適應用戶的偏好，從而在很大程度上提高了產(chǎn)品的易用性，使項目更容易成功。4.其他需求特性：如性能要求、健壯性等。這些特性是產(chǎn)品的非功能性需求，也是項目成功的關鍵因素，特別是在一些大型的涉及重要領域的管理信息系統(tǒng)中。需求分析是整個項目活動中的非常關鍵的部分，它的好壞往往決定了項目的成敗。根據(jù)經(jīng)驗，需求分析 所需的時間往往占整個項目時間的12%1。在需求分析中，需要防止的一個錯誤做法是太依靠一些所謂的分析方法，而使整個需求分析過

16、程非常復雜，過多的 圖表往往使人眼花繚亂，而不能準確抓住問題的本質(zhì)。一些分析人員往往對自己熟悉的簡單的業(yè)務花大力氣，而對不熟悉的則一筆帶過，也是本末倒置的錯誤行為。 在分析過程中，我們必須始終把握需求分析的目的是把模糊的流程搞清晰，把復雜的業(yè)務盡量簡化，而不是相反。項目管理培訓需求的管理也是非常重要的方面。對需求分析完后的形成的規(guī)格說明需要進行專門的評審，并且需要客 戶和最終用戶的參與，在達成一致后形成最初的需求基線。以后對需求的更改都必須在基線的基礎上進行，并需要項目組各成員的一致確認，對需求進行嚴格規(guī)劃評 審的目的也在于在項目的后期能盡量減少對需求的更改，提高開發(fā)的效率。項目管理者聯(lián)盟需求

17、分析完成后，項目組需要對項目的初步計劃進行重新審定，一般都需要變更項目時間表和資源需求。需求分析的完成也意味著項目其他部分可以齊頭并進，如概要設計、測試計劃、用戶說明書，這也在某個方面證明了需求分析的重要性-它是下面所有活動的基礎和準繩。3.2.3開發(fā)計劃軟件開發(fā)中的計劃性是非常重要的，一個沒有良好計劃的開發(fā)項目能夠成功的機會非常小，除非有天才的程序員再加上好運氣。開發(fā)計劃的主要內(nèi)容包括：項目進度安排、人力資源安排，風險管理策略等。項目的進度安排和人力資源安排可能是開發(fā)計劃中最重要的部分，也是最難以估計的部分。一般國內(nèi)的 中小軟件公司對項目工作量和開發(fā)人員能力的量化程度不高，所以導致進度和資源

18、安排不確切，有時候甚至是相差很遠。目前一個最實際的辦法就是根據(jù)以往項目的 積累，但必須要求是同一領域的類似項目，這樣才有較強的可比性。由于這些計劃安排是預估粗略的，所以還必須在以后的項目各階段完成后進行合理的變更，反應 項目的實際需求。微軟的辦法是把進度估計的權限交給開發(fā)人員，由開發(fā)人員根據(jù)自己的經(jīng)驗進行估計，由于一般開發(fā)人員往往會高估自己的能力，估計的進度也會 相應偏短，最后再做適當?shù)难娱L2。這種辦法有它合理的地方，在中國還需進行實踐摸索。對于進度的估計，我們有個經(jīng)驗公式，即您最初預估的時間再乘以2.5，可能是最后的完成時間。因 為許多人在估計進度的時候，往往忽略了很多非開發(fā)時間，如與客戶溝

19、通的時間、項目組溝通時間、公司培訓時間、假期等，所以我們在估計進度的時候，一定要全 方位周全考慮，在盡可能的情況下寧愿把進度估計的長一點，免得在項目后期導致非常被動的局面。后面我們將具體講到我們采取的階段性的開發(fā)方法，這種方法的 運用反映在進度估計時必須在各階段間預留緩沖時間，以解決那些我們事先沒有預料到的活動。如果進度表和要求的出貨時間有沖突，寧愿砍掉一些不重要的功能， 也不要盲目增加人手，這種做法可能會導致產(chǎn)品質(zhì)量下降，最終得不償失，詳細說明請參考4。風險管理是項目管理中非常重要的部分，并且要貫穿項目的始終。一些軟件企業(yè)往往不是很重視風險管理，導致在項目的后期出現(xiàn)了很多預料之外的事情，使項

20、目進度一拖再拖，往往質(zhì)量也達不到預期要求。因此我們要特別重視風險的管理，具體方法留待后面專門詳述。3.2.4開發(fā)過程在項目的開發(fā)過程中，我們采用了階段式的開發(fā)過程，這也是微軟公司所推薦的開發(fā)過程。在開發(fā)過程 的初期，首要的活動是概要設計。概要設計的目標是簡單、適用、能夠覆蓋所有的需求并能支持后面的階段式開發(fā)。微軟的應用方案解決模型是基于服務的三層(多 層)架構，包括用戶層，業(yè)務層和數(shù)據(jù)層，各層之間采用標準的接口進行通訊，至于該方法的具體使用，請參看相關書籍，在此就不在贅述了。階段開發(fā)過程不是傳統(tǒng)的根據(jù)模塊劃分來依次完成各模塊，最后再進行項目的整合，而是在每個階段完成后，項目都可以推出產(chǎn)品，只不

21、過該產(chǎn)品的功能比最終產(chǎn)品的功能弱一些。階段性完成項目比傳統(tǒng)的開發(fā)方法最明顯的優(yōu)點是不必到項目的末期才開始整合產(chǎn)品，使產(chǎn)品模塊之間 協(xié)作產(chǎn)生的問題及早產(chǎn)生，也及早修正，從而項目的風險也大大減小。傳統(tǒng)的開發(fā)總是在項目的后期才開始整合各模塊，使產(chǎn)生的問題改正起來極為困難，成本也大 大增加;前面累計的所有問題全部都拖到了后面來解決，也使后面剩下的工作量大大增加。項目往往看起來已完成了90%大部分的功能模塊都已完成，但剩下 的10%總是完不成，項目進度一拖再拖，很可能還要再花90%的時間來完成剩下的10%。當然采用階段性開發(fā)方法也有相應的代價，最大的代價可能是反復的 整合、測試已經(jīng)完成的模塊，但采用相應

22、的一些自動化工具可以減小這個代價。一般在開始的階段進行的是系統(tǒng)架構和最重要的功能，后面的階段是相對不怎么重要的功能。這樣的分 配有利于最終用戶在早期就能看到系統(tǒng)的大致模樣，便于他們及早的對產(chǎn)品提出意見，并對相應的錯誤進行修改;也有利于項目組在項目后期時間很緊的情況下，去 掉一些不重要的功能，把它們納入下一個版本處理，確保產(chǎn)品的推出時間。迭代的順利進行依賴于良好的架構設計，前面階段的設計應該給后面要加入的功能預留出 各種接口，并能使后面的工作在前面的基礎上繼續(xù)進行下去。這種在開發(fā)階段的迭代方式不同于整個項目的完全迭代開發(fā)，后者是項目的需求、概要設計、開發(fā)等全部是迭代進行，一次迭代要進行所有的項目

23、活動。至于誰優(yōu)誰劣可能在不同的情況下有不同的說法，需要根據(jù)項目和自身的情況合理采用。還有就是迭代的次數(shù)也要根據(jù)項目的具體情況而定。不能太多，導致重復的工作量過大;也不能太少， 使得該方法退化到傳統(tǒng)方法。我們的項目(項目小組在10人左右，開發(fā)時間在5個月左右)一般分了四個階段：架構完成、主要功能完成、其他功能完成、整合發(fā) 行。實踐證明，這樣的實施比傳統(tǒng)方法確實在很大程度上減小了項目失敗的風險，再沒有產(chǎn)生那種“似乎永遠也做不完的感覺”。項目管理者聯(lián)盟文章這里舉一個具體例子來更形象的說明該方法的運用。一個一般的MIS程序，第一階段可以構建數(shù)據(jù)庫 結(jié)構和基于特定領域的核心平臺服務(包括一些基本服務類)

24、，并進行初步整合;第二階段可并行同時開發(fā)系統(tǒng)各大模塊的基本功能，并進行第二次整合;第三階段 可開發(fā)其他增強功能，也需要相應的功能整合;第四階段進行整個系統(tǒng)的最后整合，并可進行相應的性能改進，使產(chǎn)品進入可發(fā)行狀態(tài)。3.2.5結(jié)項總結(jié)很多公司在項目完成后往往忽視了最后的總結(jié)，沒有把在上個項目中得到的經(jīng)驗教訓進行分析，轉(zhuǎn)化成 公司的巨大財富。我們認為，項目的總結(jié)是整個項目的不可缺少的重要組成部分，只有通過詳盡的充分的項目總結(jié)，才能使項目組的所有成員對項目的歷程有一個清 楚的了解，提高他們對軟件項目的認識;才能真正地把以往的項目納入公司的資源庫，轉(zhuǎn)化成巨大的財富。我們的做法是在項目完成后首先由各個項目

25、成員寫出各自的總結(jié)報告，包括所從事的工作、任務的完成 情況、遇到的問題及解決方案、對項目過程的意見和自己的想法等內(nèi)容。項目負責人需要把整個的項目歷程整理成一份文件，其中包括項目的介紹、項目進行的具體 資料(如實際花費時間、源代碼數(shù)、功能模塊數(shù)量等)、項目計劃與實際的比較等。在上述完成后，全體項目參與人員舉行項目結(jié)項工作會議，對各人所列舉的問題及想法進行討論，目的是得出好的經(jīng)驗教訓，從而指導后面項目過程。會議可由分別針對的問題分為幾個部分，如項目過程方面的、質(zhì)量管理方面的、技術方面的等，整合后形成結(jié)項會議報告。項目負責人最后把項目歷程、資料、在結(jié)項會議中總結(jié)的經(jīng)驗教訓等整理成一份總的項目過程文件

26、，歸 檔并分發(fā)到各成員和上層領導，并由項目經(jīng)理向上層領導匯報，這時，一個完整的項目才真正告一段落。這些項目資料給以后的項目提供很好的模板和借鑒意義，并 可以作為以后項目預估的依據(jù)。3.3風險管理微軟公司認為，軟件開發(fā)是一個風險驅(qū)動的過程，由此可看出風險管理在軟件項目中的重要性。一個項目的風險有許多來源，如客戶、進度、開發(fā)過程、人力資源等，忽視風險的后果可能是成本超支、進度推后，最嚴重導致項目失敗。項目管理培訓MSF的風險管理原則是：1.風險應該在整個項目的進程中一直被估計，并且作為項目決策的依據(jù)之一。2.有效的風險管理過程覆蓋了所有關鍵的人力、過程、商務及技術領域。3.風險在納入管理前必須被清

27、晰的表述。4.重要的風險必須優(yōu)先被處理。MSF風險管理過程包括以下階段：風險識別、風險陳述、風險分析、處理計劃、風險跟蹤、風險控制、風險解除。在中小企業(yè)的風險管理過程中，一般項目經(jīng)理擔任風險管理員的角色，但同時需要另外的資深開發(fā)人員 輔助，一起完成風險管理的任務。他們負責維護十大風險清單(不一定非要列出十個)，并在項目進程中隨時對風險清單進行更新。對風險的評級MSF采用的方式 是：風險影響程度=風險的可能性×風險發(fā)生造成的損失，根據(jù)風險影響程度的大小對風險進行評級。項目經(jīng)理博客在項目實施中，我們總結(jié)的一些高風險事件主要有：需求的不準確、項目時間表過于短促、開發(fā)一個從 前沒進入的領域軟

28、件、開發(fā)人員對工具的不熟悉、人員流動頻繁、使用了外部軟件中間件等。如果對這些風險不提前作出計劃，可能會對項目的順利進行造成極大的 破壞，甚至直接導致項目失敗。針對每一個風險，我們需要列出who, when, how, how much等事項，并對風險處理的結(jié)果進行追蹤，最后決定是否已經(jīng)解除風險或再進入風險處理循環(huán)。一般國內(nèi)公司的風險意識不強，沒有很好的去規(guī)劃處理風險。我們當時也是這樣，往往要等到風險已經(jīng)發(fā)生了，才意識到原來沒有注意到這些問題。在風險的管理上，還需要更多的實踐探索，首先應該從加強風險意識開始。項目管理者聯(lián)盟文章3.4質(zhì)量管理關于軟件質(zhì)量管理，現(xiàn)在已經(jīng)得到了很多公司的重視，這里我想針對性地強調(diào)幾個問題：1.質(zhì)量管理不單單是測試。一個容易犯的錯誤是把質(zhì)量管理和測試等同起來，如果軟件