軟件項目管理精選(九篇)
前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的軟件項目管理主題范文，僅供參考，歡迎閱讀并收藏。
第1篇：軟件項目管理范文
關鍵詞：軟件；項目管理；SW-CMM；模型；市場競爭力；企業
中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044(2016)04-0113-03
在當前形勢的影響下，一些中小軟件企業在實際的發展過程中，由于對軟件項目管理認識不足，導致在相關的產品質量管理方面出現了各種各樣突出的問題。這些問題的存在，客觀地說明了軟件企業在發展過程中工作思路的不科學及對項目管理認識不清，阻礙了企業的正常發展。做好軟件項目管理的基本工作，必須理解和掌握對中涉及的相關技術概念及基本原理，為后續工作的開展奠定良好地基礎。SW-CMM軟件項目管理模型，結合了項目管理的主要內容及軟件的相關特點，有利于提升企業整體的項目管理水平，擴大自身的經營范圍。SW-CMM體現了這個時代無數成功軟件企業的研發能力和先進的管理理念，為相關中小企業的項目管理提供了一定的參考思路。
1軟件項目管理的研究背景及意義
1.1軟件項目管理的研究背景
軟件項目管理主要針對的是軟件行業。它是項目管理與軟件行業結合的產物，對于軟件行業工作效率的提高有著重要的影響。軟件行業的生存和發展依賴于企業內部團體的研發能力，主要是通過相關技術人員彼此間工作的配合逐步實現的。軟件項目管理為軟件企業未來的生存和發展帶來了巨大的推動力。SW-CMM又稱軟件能力成熟度模型。它最早誕生于20世紀80年代，是由美國的大學研究機構主持開發的。這種軟件項目管理的理論體系龐大，內容比較豐富，涉及的范圍也比較廣泛。其本質上是一種先進的管理方法，主要應用與軟件領域，體現的是管理方面的思想。通過對不同層次的內容指出了軟件工作機制中控制活動所遵循的基本原則，為軟件項目管理和項目施工提供了可靠的工作思路。這給軟件企業處理實際問題帶來了一些指導性建議，節約了研發人員的工作時間，加快了研發速度，為企業的整體發展帶來了積極的推動作用。同時，作為一種參考標準，SW-CMM對于軟件企業的預算管理有著一定地影響：對企業如何控制生產成本，實現利潤最大化目標提出了具體的解決方法。相對國外比較成熟SW-CMM，我國在這方面的研究理論非常少，缺乏科學的參考標準，相應的軟件組織更是很少，只有部分的中小組織。將復雜的SW-CMM理論體系變得簡單化，是未來軟件研究工作者需要完成的主要工作任務。
1.2軟件項目管理的研究意義
軟件項目管理直接關系著軟件企業的生存和發展，是保證企業競爭力的重要措施。做好軟件項目管理的研究工作，有利于提高軟件產品的質量，擴大企業的生產經營范圍。同時，這種管理理念和管理方法的實施，從根本上降低了企業的生產成本，為企業整體經濟利益的增加帶來了積極的影響。中小企業在軟件項目的管理過程中一直存在著很多的問題，管理方法的不合理，管理機制的不完善，都阻礙著企業正常的發展。因此，做好軟件項目管理的研究工作，對于軟件企業整體的發展具有現實的參考意義。軟件項目管理是決定軟件企業戰略部署的關鍵措施，這也客觀地決定了開展軟件項目管理研究工作的必要性。
2軟件項目管理及SW-CMM的相關內容
2.1軟件項目管理概念及特殊性的表現形式
軟件項目管理主要是指企業通過對項目成本、施工進度、質量管理、人員配置方面的控制而開展的相關活動。軟件項目管理對于企業技術人員的研發能力影響很想很大，也直接體現著企業整體的研發水平。軟件生產技術相對較高的企業，其項目管理水平較高，綜合的研發能力比較突出。軟件項目管理的特殊性主要是指這種管理與其他項目管理的區別。主要表現在；1）思維上的獨特性。軟件項目是通過技術人員的思維能力逐步開展實施的，具有抽象性的邏輯實體。在具體的研發過程中相對比較自由，需要經過一定的研發時間才能獲得最終的產品；2）組成結構的復雜性。這主要是指軟件本身具有一定的復雜性。其復雜性包括：代碼組成的復雜性和解決實際問題的復雜性。當軟件在應用過程中遇到特殊的問題時，必須從程序的設計、實際的需求、研發角度等方面展開必要地研究，而這樣的處理過程增加了整個工作機制的復雜性，使得整體結構的復雜性逐漸地體現出來；3）層次感鮮明。軟件中某些符號存在著優先級，使得系統在處理實際的問題時，必須充分考慮優先級的高低，間接地使軟件項目管理在某些應用方面的層次感非常鮮明，為相關工作的開展帶來了極大的方便。通過這些不同的表現形式，可以清楚地看到軟件項目管理的特殊性。
2.2SW-CMM的基本結構
當前形勢下，國際上較為流行的SW-CMM主要分為軟件能力成熟度模型和軟件能力成熟度的具體實踐。這兩種技術報告有著不同的側重點：前者是強調軟件實施中的相關原則，主要是為了使軟件能夠朝著更高層次的方向發展，最后保持一定的成熟度。這種成熟度側重于具體的過程。而后者主要強調的是不同級別實踐過程中的成熟度，側重于成熟度實現的途徑研究。通過對成熟度內涵的分析，可以為軟件實施做出一定的綜合評估，以達到軟件改進的最終目的。SW-CMM結構的基本原理主要是指：在具體的過程中通過各項實踐活動的有效開展，可以實現關鍵過程的相關目標。這些目標象征著不同的成熟度級別。這也客觀地體現出了SW-CMM結構中成熟度級別的高低是與一定過程內實現目標相關的。這為軟件項目管理帶來了重要的參考思路，也為軟件實施過程中評估報告的評價指標指明了方向，給相關模型的構件帶來了一定的參考依據。
2.3SW-CMM等級的研究
SW-CMM的等級主要包括五個方面：優先級、管理機、定義級、重復級和初始級。這些不同的級別反應了SW-CMM的基本結構特點，在實際的應用中有著特定的含義。五個級別的相關含義主要有：1）初始級。這主要是指軟件的生產組織的起始階段，基本沒有形成真正的軟件研發環境。無論是管理上還是具體的實踐應用方面，都無法達到相關的設計要求；2）重復級。這一級別中的內容較豐富。主要是指它涉及的對象較多，包括人、物、組織及相關的信息傳遞。這種過程中信息之間的交流需要結合實際的情況隨時地調整。應用、測量、研究、規范化、標準化等組成了一個嚴密的體系，對于軟件項目管理起著科學的引導作用。所謂的重復是指在軟件項目管理中可以對制度、合同、預定方案等方面重復執行。不同的項目允許在一定的控制范圍內出現一些偏差。這主要是從局部的細節方面研究的。而從整體上觀察，可以看出這些重復的行為基本的原理都是一樣的。無論是參考標準還是項目控制管理，其中的某些過程中是可以重復的；3）定義級。這是軟件研發的關鍵階段。軟件項目管理模型的形成涉及了軟件工程和項目管理。在定義級階段，需要制定相關的參考標準。這些標準的形成，為未來軟件的使用進行了必要地規范，為軟件的順利實施指明了方向。這個級別所涉及的軟件過程的特點主要是：規范化和互不排斥性。突出了軟件工程和項目管理過程的相關特點。當軟件進入生產階段，需要對軟件的整體框架、生產數量、生產質量等方面進行綜合地管理；4）管理級。這一級別主要是為了做好軟件產品的質量指標的制定工作。通過設置一定的質量指標，可以使軟件生產組織的活動更加規范，為軟件項目的質量控制提供了可靠地保障。當軟件處于該級別時，軟件實施及相關的評估報告有了一定的參考依據。通過控制軟件的過程，對于可能出現的偏差進行隨時地調整；5）優化級。該級別主要的工作內容是為了使軟件的性能更加可靠，實際的應用范圍更大，從而對軟件進行持續地改進。通過相關的試驗查找軟件中的漏洞，并對實驗數據進行全面的分析。最終的目的是為了使該軟件在技術上和方法上有所突破。通過對SW-CMM不同級別的分析研究，可以清楚地看到軟件的設計、制定及實施的過程是可以不斷地改進的，這也是對應軟件項目管理存在的意義。
3SW-CMM的軟件項目管理模型分析與研究
3.1項目啟動
項目啟動是整個SW-CMM模型內的初始階段，需要從項目的可行性、項目方案的制定與實施、資源配置管理等方面展開深入地分析。其中，項目的可行性分析主要包括三方面的內容：1）技術角度的可行性。主要是指技術的選擇能否對市場風險起到一定的預防作用；2）經濟角度的可行性。主要是指項目的成本預算是否合理；3）社會推廣的可行性。主要是指項目在推廣過程中是否合法，相關的操作方式是否合理。同時，項木啟動也對具體的工作目標、整個項目的估算及項目立案的管理等方面做出了一定的說明。
3.2項目的整體計劃
在整個模型中這部分的內容相對比較豐富，其中主要涉及了成本控制、風險規避、項目方案指導、工作步驟的有效分解及職責的明確等方面的內容。其中的工作步驟的有效分解可以起到對整個軟件綜合評估的作用。項目的成本控制可以通過多種方式達到預期的目的。主要有：相似項目的比較；專家團隊的評估；算法模型的模擬及特殊的估計法等。對于一些規模較小的項目可以采用一些SW-CMM模型的建立進行相關地估算。
3.3項目的風險評估
無論是在項目的啟動階段還是后續的項目實施階段，都必須對整個項目的工作機制進行的綜合的風險評估。風險評估的過程有著相對完整的體系。主要包括：風險的識別、風險的分析等。利用風險評估體系對SW-CMM項目管理進行整體的評估，主要是從項目實施中三方面的內容展開的。由于軟件工程項目在具體的推廣過程中可能出現各種類型的風險，需要對項目的風險評估機制進行隨時地修改。
3.4項目的實施與控制
這一階段是項目取得成功的關鍵所在。由于項目在實際的實施過程中可能會遇到各種各樣的突發狀況，僅僅利用項目的風險評估機制很難對項目計劃做到準確地預估，必然會導致一些偏差的存在。因此，利用項目的實施與控制的作用可以及時地修正這些偏差，保證整個項目能夠順利地實施下去。項目的實施與控制主要包括：需求管理、項目的全程監督及項目的有效控制。通過這些方面工作的開展，可以提高項目實施整體的工作效率。
3.5項目的維護與軟件質量管理
當所有的項目結束后，需要開展相關的資料整理及項目驗收的工作。項目的驗收一般是通過用戶的體驗完成的。由于最終的軟件主要是為用戶服務的，用戶的客觀評價是對整個軟件安全性能的最好體現。除此之外，也需要對項目中一些重要的資料進行及時的歸檔整理。并對相關的工作做出一定地總結。SW-CMM軟件的質量管理包含著許多重要的內容。由于軟件最終的應用與推廣主要是針對用戶與社會的，必須對軟件的質量進行一定的管理，防止意外事件的發生。軟件的質量管理主要包括：軟件的綜合評審、軟件的性能測試、軟件的漏洞、解決軟件存在問題的方法。通過對這些方面的有效控制，可以保證軟件的質量可靠性。
3.6軟件的配置管理
作為SW-CMM的軟件項目管理模型的重要支撐平臺，軟件的配置管理對于整個軟件的生命周期起著至關重要的作用。軟件配置管理主要是對軟件生命周期內產品的變更及相關的演化過程進行一定地管理。它主要解決的問題是軟件變更過程中的標識、變更過程的控制及最終的等方面的問題。最終的目的是為了使最終的產品在有效性、需求性及可控性等方面達到用戶的實際的要求。
4結束語
SW-CMM軟件項目管理模型在實際的應用中起著至關重要的作用，主要是因為它深入地分析了軟件企業在項目管理工作方面存在的問題，并找到了科學的解決措施。這為軟件企業未來的發展帶來了積極地影響，使得企業在實際的項目開發中擁有了更多的選擇。文中通過對SW-CMM項目管理模型實際應用的研究，為中小軟件企業的發展提供了有效的策略。
參考文獻：
[1]魏國興.基于CMM的軟件過程管理系統的設計與實現[D].北京:北京郵電大學,2010.
[2]張策.CMM/CMMI模型在成品油協同監管服務平臺項目中的應用研究[D].長春:吉林大學,2011.
[3]周津衍.基于CMM的A軟件項目開發過程改進研究[D].上海:東華大學,2015.
第2篇：軟件項目管理范文
相關熱搜：項目管理 軟件項目管理 項目管理工程
隨著計算機硬件水平的不斷提高，計算機軟件的規模和復雜度也隨之增加。軟件項目中一些問題也應運而生：項目無法按期完成、項目合作方的工作難以協調、用戶需求經常變動、工作質量難以保證。為了避免愈來愈多的“項目黑洞”給企業帶來的損失，各個軟件企業都將軟件項目管理引入到開發活動中來，對開發實行有效的管理。
一、軟件項目引入項目管理的必要性軟件項目即軟件開發項目，是一個用計算機程序和相關技術文檔把思想表達出來的過程。軟件項目所涉及到的內容大多是無形的東西，既看不到質，也看不到量，從而使軟件項目的管理難度加大。
隨著信息技術的飛速發展，軟件產品的規模也越來越大，完全由個人完成一個軟件項目幾乎是不可能的，軟件項目的開發都是以項目組為單位完成的，這必然涉及到對軟件項目的管理。一個軟件項目的成敗，不在于其項目組的技術人員的技術水平，而在于是否采用合適的管理方式。好的管理方式不一定能使項目完全成功，但是一個不合適的管理模式肯定會導致軟件項目的失敗。
項目管理是指在一定資源如時間、資金、人力和設備等約束條件下，對一個有既定目標(質量、投資、進度)要求的任務進行計劃和控制的過程。項目管理以系統的觀點來對一個項目進行全程的控制，同樣也可以用此來完成對軟件項目的管理，而且由于軟件項目的特殊性，項目管理在應用于軟件項目的管理時，也會有其獨特的一面。在項目管理應用于軟件項目的管理方面，已經有了不少成功的案例。
二、影響軟件項目管理的關鍵要素
(一)可靠的軟件需求
軟件需求是軟件項目的根本所在，需求不明確，工作就沒有方向，因此影響軟件項目的第一個因素就是項目要有一個可靠的需求。軟件需求應當是項目有關的人員一致同意的、清楚的、完整的、詳細的、可實現的和可測試的。
需求的確定，開發者應該認真聽取用戶的意見，并進行記錄，反復和用戶溝通，不能想當然地把自己的想象當作用戶的需求。在確定用戶需求的時候，應該盡可能從專業的角度發掘用戶的潛在需求，以達到最大限度地滿足用戶的目標，只有這樣才能可能開發有價值的軟件項目。一定要強調的是，在項目開始以后，應該盡最大可能不更改需求，要與用戶進行很好地溝通，以確保開發工作能按照需求進行，也就是說，只有有了可靠的需求，項目開發才有基本保證。
(二)可行的項目計劃
凡事預則立，不預則廢。這里的預就是指計劃。明確了項目目標，還必須有一個切實可行的計劃。軟件項目計劃的目的是為完成軟件工程和管理軟件項目。制定合理的計劃，它包括以下步驟:估計軟件
產品規模及所需的資源，制定時間表，鑒別和評估軟件風險和協商約定，而且要標志出幾個階段性的里程碑，這是極為關鍵的一點。對于軟件企業來說，一個可行的計劃的重要性是不言而喻的。但是在一些單位，很多人都聽過這樣的一句話一“計劃趕不上變化”。這種變化對某些行業來說也許并不會產生太大的影響，但是對于軟件企業來說，卻會對軟件產品的保證帶來嚴重的負面影響。造成這種現象的原因很多，主要是因為對計劃的重視程度不夠，計劃過于籠統、粗糙，導致可執行性差，再加上一些人為因素的影響，必然會產生一些不良的影響。因此，要想成功進行項目管理，就要對計劃高度重視，周密制定，嚴格執行。只有嚴格進行計劃，才能使項目管理得以成功實施。
(三）規范的操作流程
軟件開發流程非常規范和系統化，其流程的可執行性很高，并且能在實踐過程中不斷改進。流程是保證項目成功的一個關鍵因素。由優秀的項目成員按照規范的操作流程進行項目開發，才能最大限度地保證項目的成功。一個規范的流程可以保證不是很出色的人開發出來的，產品不至于太差，但不能保證做出精品，而一個不規范的流程很難做出好的產品。
通過流程可以實現一種規范化、流水線、工業化的軟件，從而最終實現成功的項目管理。對于軟件項目的每一個階段均要做出工作計劃并交有關部門監督執行，在階段結束之后，要對該階段的工作活動進行評價，并對后續階段的時間、人員、資金方面的需求做出估計。每個階段的工作成果需經項目的技術管理部門審查合格后，方能開始下一階段的工作。
(四）有效的人員溝通
軟件項目的實施對人的依賴性比其他行業更為突出，它是一項知識性極強的工作，因此對人的管理相當復雜，如何加強人員之間的有效溝通，是軟件項目成功的一個非常關鍵的因素。這里的溝通包括兩個方面：一個是軟件項目組開發人員與用戶的溝通;另一個是軟件項目組內人員的溝通。只有對用戶的需求非常明確，軟件項目的實施才有一個堅實的基礎。對用戶的需求不明確，開發出的軟件根本沒法用，所以這樣的項目在一開始就是失敗的。組內人員的溝通有助于在明確了用戶需求后，使得項目能按計劃進展，最后才有可能完成該軟件項目。
沒有最好的溝通方式，只有最有效的溝通。因此溝通因人因事而采用不同的溝通方式，才可以達到良好的效果。有時項目組需要和用戶溝通，面談是一種較為花時間的方式，而用戶方常常以忙來說明自己沒有時間，這時候可以采用電話溝通的方式，這樣馬上就可以得到答復。有時可以將項目進展情況用郵件的方式發給對方，使得軟件開發的工作也成為用戶的一種工作，只有這樣才能正確把握用戶的真正需求，才能使得開發出的軟件真正是滿足用戶需求的軟件。而在內部的溝通形式就可以多樣，如定期的項目溝通會議、項目進展文檔等。
總之，只有加強溝通，才能使得軟件項目順利實施，溝通是成功軟件項目管理的很重要的因素。
(五)健全的項目文檔
軟件項目的文檔在整個生命周期中的地位和作用尤為重要，無論怎樣強調都不過分。文檔作為軟件產品的主要形式，集中體現了軟件人員的勞動成果，沒有文檔就稱不上軟件。但是實際情況是許多軟件開發人員從一開始就不注重文檔的寫作，尤其是當軟件項目的工期又很緊張時，在沒有任何文檔或只有少量文檔的情況下就開始了具體的開發工作。有的寫了文檔，但是在開發過程中需求發生了變更，也沒有及時在文檔中體現出來，使得過一段時間后開發者對所開發的內容也記得不清了，當項目出現問題時，沒有有效的文檔可查，致使軟件項目延期或失敗。
軟件開發過程中各階段的文檔不健全，往往在項目接近尾聲時為了驗收才補寫文檔。最常見的是有系統分析與概要設計文檔，但是沒有詳細設計文檔，在程序開發過程中，開發人員往往最大限度地發揮著自己高超的編程技巧，以至于在后期維護時，因為沒有詳細的設計文檔，給項目的后期維護帶來困難。
編寫文檔的工作量是很大的。有時會占整個項目的40%,所以文檔的編寫會花費大量的時間和精力，但是有了好的文檔，會對后期的開發工作帶來很多的便利。健全的文檔管理是軟件項目成功實施的一個重要因素。
三、軟件項目管理的方法
軟件項目管理有階段化管理，量化管理和優化管理三個層面。
(―)階段化管理
階段化管理指的是從立項之初直到系統運行維護的全過程，將項目分成小的階段。比如，通常分為問題定義、可行性研究、需求分析、總體設計、詳細設計、編碼、狽彳試和維護等幾個階段。每個階段都有明確的目標和成果驗收，以及必要的監督回饋，這樣就能夠很好地減少項目負責人和客戶的分歧，增加項目風險的可控性。在項目負責人提交給客戶的需求分析和初始報告里，就已經把每個階段要完成的工作，可出的成果，甚至具體到有多少個界面，都能清晰的描述出來。這樣，在每個階段完成后，客戶和項目負責人都能夠比較清楚地了解項目的進展、完成情況，以及客戶對項目完成部分的滿意程度。同時，也方便進行項目組成員的績效評估。
(二)量化管理
把項目的方方面面盡可能地進行數量化，做到責任清楚。給客戶做軟件，時常碰到這種問題：某階段成果A(比如說，包括A1、A2、A3等不同部分）出來了，客戶看了以后，可能認為A1完全符合要求，A2根本就不對，A3雖然有毛病但改改還可用，等等。那么，這其中的問題出在哪里？責任該由誰負?責任又有多大呢?為此，必須把各種目標、投入、成果等分類量化。比如，用明確的模塊或子系統表達客戶需求，精確計算A1、A2、A3每部分花費人工、物力、財力等等。把各種量化指標存入數據庫，就能夠輕而易舉地解決上述的問題了。而且，每個階段都有清晰的量化管理，也非常有利于整個項目進程的推進。
(三）優化管理
優化管理就是分析項目每部分所蘊涵的知識、經驗和教訓，更好地發揚項目進程中的經驗，吸取教訓，在全公司傳播有益的知識。再如前面例子，通過分析發現A1部分的領頭人能力強，就可以讓他以后多帶幾個人，使他的知識和經驗更好地發揮成效。A2、A3部分為什么不成功？是客戶的需求沒提清楚，是理解的錯誤，還是有設計的問題？通過這些分析后，有利于進一步優化項目管理。
四、軟件項目管理過程中的幾個誤區
(一)對需求的修改是必然的，具體細節可在以后的開發過程中填充
在軟件項目的需求分析階段，軟件開發人員和項目負責人通常認為開發方與客戶方在各種問題的基本輪廓上達成一致即可，具體細節可以在以后填充。理由是無論開始時多么細致，以后對需求的修改幾乎是必然的。但在實際操作中，由于需求階段對問題的描述不夠細致，導致后來預算超支或者時間進度達不到要求的情況并不少見。正確的做法應該是:在項目需求分析階段，雙方必須全面地、盡可能細致地討論項目的應用背景、功能要求、性能要求、操作界面要求、與其他軟件的接口要求，以及對項目進行評估的各種評價標準。在需求分析結束以后，雙方還要建立可以直接聯系的渠道，以便盡早地對需求變動進行溝通。
(二)軟件項目的需求可以持續不斷地改變，并且可以很容易地得以實現
在需求分析階段，還有一個經常出現的問題，就是認為軟件項目的需求可以持續不斷地改變，而且這些改變可以很容易地實現。在具體實際中由于種種原因，客戶方很難在需求分析階段就能全面而準確地描述所有問題。隨著開發進度的推進，往往會有一些需求的改變。現代軟件工程理論也利用軟件的靈活性特點通過各種方式來適應這種情況。實踐表明:隨著開發進度的推進，實現軟件需求更改所需要的代價呈指數形式增長。假定在需求分析階段實現需求更改要花費1倍的代價，那么，在系統設計和編碼階段，則需要花費1.5~6倍的代價；在系統測試階段需要花費10~20倍的代價，在軟件版本以后，甚至要花費60~100倍的代價。由此可見，在項目開展過程中，軟件需求的改變應當盡早提出。這樣才能做到既節省開銷，又較容易實現。
(三)在系統詳細設計階段，必須寫出所有程序的偽碼
在詳細設計階段，起初為了便于代碼的維護修改，要求文檔工作應該做到寫出所有程序的偽碼。偽碼的最大作用是對程序的算法流程進行描述，便于人們深入了解程序的功能和實現過程。因此，偽碼在一定程度上的確有利于對程序代碼的維護和修改。但在實際工作中，這種做法卻很難實施。為了保證項目文檔和程序代碼的一一對應關系，維護程序代碼的同時也需要對項目文檔進行維護。偽碼和程序代碼非常接近，對偽碼進行維護，就相當于進行了加倍的程序代碼維護。為了趕進度，這種方法在實踐中往往會流于形式。所以，切合實際的方式應該是對一般的程序文檔做到程序流程圖即可，對涉及了較復雜算法的程序才需要偽碼。
(四)編碼階段是整個軟件項目中最重要的階段
在軟件開發階段，項目負責人往往認為軟件程序主要由代碼組成，因此編碼階段是整個軟件項目中最重要的階段，應該給予大量時間，集中主要資源。與編碼階段相比，需求分析、詳細設計以及測試時間較少，容易造成測試不完全及軟件上線后的先天不足，給今后的工作造成被動。如今，由于軟件的規模和復雜度都較以前有較大的增加，再加上半自動化軟件代碼開發平臺的出現，現代軟件項目管理的中心已經發生了轉移一不是著重編碼階段，而是著重系統總體/詳細設計階段。一般，系統總體/詳細設計階段應占整個軟件開發時間的一半。這樣才能充分考慮系統將會出現的各種問題及其解決辦法，為以后的編碼、測試工作爭取主動。
(五)軟件所有的內部測試工作應由測試人員完成
在軟件測試階段，由于在項目人員配置中設置了專門的測試人員，人們通常認為軟件所有的內部測試工作應該由測試人員完成。但這種做法往往會造成測試不全面，軟件交付后經常出現問題的情況。在實際工作中，由于使用“白盒法”對測試人員各方面素質有著較高的要求，進行程序測試時，測試人員總是優先使用“黑盒法'狽j試沒有通過才會考慮對程序代碼進行“白盒法”測試。顯然，這種對“白盒法，有意無意的“逃避”，對軟件的可靠性和穩定性構成了威脅。要解決這個問題，一方面需要提高對測試人員的要求;另一方面也需要讓程序員完成部分的“白盒法”測試。
(六)軟件項目管理只是相關技術部門的事，與公司其他部門無關
在競爭日益激烈的今天，軟件項目規模大、復雜度高，而且時間要求緊迫。要想提高公司的軟件項目管理水平，就需要提高公司的整體參與意識，需要公司各個部門協同作戰。例如，需要會計部門協助進行項目預算、財務管理和費用控制;需要研究部門(技術委員會)指派專家協助進行各種風險評估，提供技術指導;需要后勤部門提供各種保障。
(七)開發進度滯后時，可以聘請更多的程序員加入到開發團隊中，通過增加人力資源追趕開發進度
如今，在注重團隊開發的時代，開發方應該根據目前的軟件項目管理水平慎重考慮這個做法。如果新加入的程序員對目前軟件項目的應用行業有一定了角解并且可以很快地適應開發方的項目管理方式、軟件開發風格、團隊協作氛圍，那么“新人”的加入是有益的。否則，可能會“好心卻辦了壞事”。因為盡管新人的個人能力很高，但為了使其與大家一起協同工作，開發團隊不得不分出人手對新人進行與項目有關的技術、業務培訓。更重要，也是難度最大的是，還要引導新人融入到整個開發團隊中。這可能需要花費開發團隊大量的時間和精力，很有可能使項目進度更慢。
第3篇：軟件項目管理范文
首先，團隊溝通的成本上很高的，而且隨著以下因素，溝通的成本會越來越高：人數的增加，工作地點的分離，缺乏共同的語境平臺，不相同的價值觀或者判斷準則等等。人數的增加，使得相互之間的溝通線越來越多，而且，信息的增加，不見得就一定能夠把你導向成功，你將不得不判斷各種不同的信息，從而使得成本越來越高。根據這點，我們在管理上，推薦進行單頭領導（而不是多頭領導）就是這個原因，我們贊成使用少量的高素質人員替代大量無經驗的人員，也是基于這一點的判斷.工作地點的分離，也將導致溝通成本急劇上升。我不知道大家如何看待在這樣的一個團隊：我們的需求團隊在北京，設計團隊在上海，開發團隊在武漢，測試團隊在大連。如果是我看見這樣的團隊，將使得我很撓頭。而且，但凡有可能，我極其不愿意使用這樣一種團隊，因為地點的分離，使得溝通和交流的數量和質量大大低于直接的面對面的交流。對于一般的開發團隊來說，我希望他們不僅僅是在一個辦公室里，而且更希望他們的辦公位本身就是挨在一起的，這樣他們抬起頭就能交流。
他們會變得更喜歡進行交流。很多項目經理告訴我，我們有MSN進行日常的溝通，我們有電話會議進行項目會議，我們有視頻會議來解決面對面溝通的問題。但是，事實上，這一點遠遠不夠。我們現在有很多手段進行溝通，但是諸位請回答我一個問題，以前你在家的時候，每天和你母親說多少話？你離開母親以后，雖然你也同樣有各種很方便快捷的聯系手段（而且我很多時候也和母親在MSN上聊天），但是你每天聊多少句？你們的了解是更多了還是更少了？和母親之間的溝通尚且如此，那么和一個項目組團隊（甚至是你沒有見過面的項目組成員），你們的溝通又是如何？人和人之間的溝通和交流，沒有比直接的面對面更加有效的了，我們可以聽見對方的話音，看見對方的每一個眼神……更重要的是，我們能夠相互之間觸手可及，這是一種鮮活的溝通手段，任何手段都比不上他。所以，除非萬不得已，不要把你的團隊分成那么多地點。
有一個例子，我們曾經試驗過軟件工廠（在武漢設立了軟件工廠，以至于我看見我們舉行會議的時候，總是會有幾個武漢的同仁，風塵仆仆地趕到北京），理想狀態下，我們希望在北京做需求、設計和驗收測試，在武漢進行開發和測試。而且主要是研發一些獨立性很強的產品（比如一個顯示報表的工具），或者一個很簡單的功能實現。當時，為了體現軟件工廠的有效性，總經理下令，不強求在北京的團隊使用武漢的軟件工廠。結果幾乎沒有人使用武漢的軟件工廠，而且即使有人使用了，也是直接把需求和設計人員直接派到武漢，象項目經理一樣帶這個項目。當時我們很現實，軟件工廠是否成功，不是我的事情；但是我的項目失敗了，就是最大的問題了。所以，還是請一幫張口閉口軟件工廠的兄弟們，至少自己親手干一干，你會發現，其中的難度是非常高的，你仿佛一朝之內回到解放前，對于項目的憂慮和風險會急劇上升的。他并不是如同你所想像的那么容易駕馭。當然了，如果你真的能夠很輕松地駕馭這方面的團隊，我不得不說，你的項目管理能力以及團隊管理能力非常出色，是一個國際性的項目管理大牛，但是……，國內的98%以上的小型項目，有必要采用這種方式研發嗎？我覺得沒有太大的必要。所以還是不要開口閉口的軟件工廠，軟件工廠的。
我們知道一點，我們現在面臨的問題，如同20年前提出軟件工程的時候一樣，是軟件項目失敗率太高，而不是我們已經解決了軟件項目失敗率問題，那么對于絕大多數項目來說，還是如何保證成功率，如何來做吧。缺乏共同的語境平臺，也會導致溝通成本的上升。比如我們希望某一種設計文檔，能夠按照一個相對固定的格式來做。當然，這種做法不值得走得太過（章節內容完全規定得非常死非常死，就容易引發負面效應了），但是，這種做法有效的一點是，他統一了語境平臺，大家很清楚，到哪里可以找到你的某一部分內容。舉一個通用管理上的例子來說，在聯想，我們都清楚“我們把這件事拉一下”，這句話的意思是，我們找個地方，把這件事情好好梳理一下。比如我們看見一個哥們在會議上說話說錯了（當然是那種一般的內部性質的會議，可不是很要命的地方、很要命的時間說錯話），我們會善意地笑一下，說“再給他一次機會吧”。因為每一個剛進想的兄弟們，都會參加一個一周的“入模培訓”，意思是，無論你在社會上是一個什么樣子的人，進想就必須經過這個模子套一下，然后至少你們就能擁有相對比較一致的價值觀了（這個入模培訓基本上可以看成一個優秀傳統介紹＋聯想常用語的潛移默化＋簡單拓展訓練。也許過去N年以后，聯想人會忘記很多事情，但是入模培訓想來是難以忘記的了，至少我離開聯想2年了，口頭和做事方式中，還是多多少少帶有一些聯想的東西）。“給他一次機會吧”，這句話出自每一個入模培訓中都會講的小故事，說一個某某教練帶著“某某學員”（這兩個某某都可以換成你想說的人），去參加文化考試。
老師：“9+10等于多少啊？”
學員：“20！”
教練：“這種題目都會做錯，老師，再給他一次機會吧！”
……
老師“那1+1等于多少啊？”
學員：“2！”
教練：“老師，要不……再，再給他一次機會？”
講得興起，再多說一點。通常每一期入模培訓完畢以后，都是聯想內部郵件系統受到很大壓力的時候，因為這時候，很多“模友”（進入同一期入門培訓的人，稱為模友；如果你們有幸被分在一個組內，那就是更親密的模友了，我們當時組名叫“VII”，發音為VTwo，靠，一個土得掉渣的名字，現在還覺得有點臉紅，當時就是老實，不然死也不會讓這個名字通過啊。
還有的隊叫“大刀隊”，呵呵那就更搞笑了，看見那個Team的組長上去，是個小小的瘦子，我還想著：這大刀敢情說的是水果刀？呵呵）。在聯想這樣一個大型公司中，部門層出不窮，我們在部門之間合作的時候，如果發現你的合作部門接口人是你的模友，那恭喜你了，一般來說，他不會太難為你的，甚至給予你很大的幫助。于是，你會發現，在很多的需要多部門合作的項目中，正式依靠著這種親密的關系，才使得事情更容易推進。模友們的關系會維持很長的時間，以至于我們會聚在一起，給某個模友過生日；模友離開聯想的時候，也會給我們發一份郵件，告知我們離開聯想了。甚至上你的部門，向你當面
道別。這是一個不錯的方式啊。這就是為了建立起來一個共同的語境平臺（順便說一句，程序是一種極其好的，無二義性的語境平臺哦，無論是美國人還是中國人寫出來的程序，都是我們能夠看懂的的程序）。如果缺少這個語境平臺，不理解對方所說的話，還是小事，但是他會使得你會象個外人一樣，不能融入到整個團隊中。不相同的價值觀或者判斷準則，也會潛在得極大提高溝通成本。因為他會使得一些基本的判斷發生偏差，使得管理者傾向于收回所有的判斷權和決策權，并且使得團隊成員喪失很多的鍛煉的機會，。最后變得，團隊Leader忙死，下面團隊成員閑死（更可能的是，團隊成員也忙死，但是忙得不得其要而已）。管理者會傾向于把做一件事情分解稱為各種操作性指令，而總體目標在團隊成員腦子里就是一個模糊的東西。這是一件很恐怖的事情。呵呵，講到這一點，我想開過車的兄弟們都知道，我們總是希望在去某一個地點的時候，腦子里大致有一條路線圖，我想很多人會很討厭，在某一個非常繁忙的地段，然后旁邊的哥們不告訴你目的地何在，開始發各種命令：“往左并線……”，“并線哪！”，“唉，唉，跟著那輛大車出去”，“那輛，那輛，跟著這輛有啥用處啊！”。如果這是一個哥們敢長期這么說，我就會打開車門，讓他下車滾蛋！這至少會讓我非常光火，因為我不得不到處尋找他所說的標幟物，而我實際上不知道他到底要干什么。會顯得很笨拙，而且很不爽！我喜歡的指示是：“從橋下左拐，你需要在這里出高速道路”。這我就明白多了，然后即使你再給我各種指示，我也很容易理解了。
舉一個現實的例子，一般來說，銷售團隊和研發團隊之間的溝通，總是存在部分的問題。銷售團隊人員一個好產品，就是一個能夠銷售出去的產品；而研發團隊所謂的一個好產品，是從技術本身出發所描述的。所以，銷售一般不太愿意，為了所謂的框架來花費成本，但是研發總是對此念念不忘。類似的，提高團隊溝通成本的地方還有很多，比如語言的不通（比如一個英語不好的人員和老外溝通），相互之間背景的不相同（上面的銷售和研發的沖突，就是如此），私下之間的關系屬于臭魚看不上爛蝦的那種（當然，非常具備職業素養的人，會很好得平衡工作和私下的關系，但是這畢竟是很少部分人所具備的優秀的職業素養）等等。都會很大的提高溝通成本。以上說了提高溝通成本的一些事情，對于一個溝通如此重要的領域來說，盡可能降低一些溝通的難度和溝通的成本，對于項目來說總是有利的。這會潛在降低很多你的軟件成本的。下面說說溝通上面一些需要注意的地方了。不說復雜的，就說簡單的。
溝通，其實往簡單了說，就是“聽”和“說”。說出你想說的，聽別人想說的。這一點在溝通中極其重要。如果很枯燥地說教，令人也很煩哪，好像是老師在夏日悶悶的教室中，毫無語調地讀書，下面學生昏昏欲睡。如果繼續如此說下來，我幾乎能夠聽到蟬的叫聲了(我最喜歡，在那樣的環境下，慢慢地睡著，臉上露出陽光燦爛的笑容，那簡直就是一種享受)。我們換一個說法，讓我們大家來結合BBS上的論戰，來看看“說”和“聽”好了。
首先說“聽”，一般來說，這一點更難。雖然原則上說，聽和說一樣困難，但是現在聰明人太多了，以至于大家都能言善辯，但是，是否能夠聽到別人所說的，就不好說了。在溝通方面，我們經常犯這樣的錯誤，包括：
我們會經常斷章取義，有意無意地把其中某一段話理解成為全部的意思。當然了，這是論壇上一個慣用伎倆。在長篇大論中，總是會抓住一些說得不恰當的話的，然后從這個話題開始猛攻，使得對手離開他已經勝利的領域，從一個很難受的起點開始出發，這很無聊（更為好用的是，我們一般用引號去引用對方一小段話，如果對方一定要廢話更多，引用以前他所寫的1/3的段落，估計很多沒有耐性的人也不會看，于是，他的話就成了證據確鑿的罪證了），不是嗎？我們聽別人話，也要注意，是否我們顧及了上下文，而不是從中抽取一段出來，發揮和理解。
我們經常帶著反駁的態度來看待對方的意見。本來嘛，在BBS上，一旦開始掐架了，就必須掐贏，雖然大家口口聲聲說著，自己為了討論問題，估計到最后，討論問題的心情沒有了，腎上腺素才是維持我們掐架的由來了。我們經常使用的一個方式就是，帶著有色眼鏡看著對方的話，然后惡毒地把他往他所支持的觀點方向一個勁地猛推，比如，某一個人支持在工作中贊成目標驅動的考核制度，于是大家說他：目標一切啦，只重視目標不重視過程啦，風險大啦，管理者的Training職責啦等等，比如另外一個人贊成過程考核的方式，于是別人開始說他目標不明晰啦，管理者容易做老好人啊，容易導致面子工程啦……等等。于是，大家覺得，對方那簡直就是胡扯嘛。但是，實際上，這是因為我們本身就是帶著反駁的態度來聽別人如何說的。管理是在很多時候，都是一種權衡的藝術，所以，如果你把別人推到如此極端的地步，那么你的觀點自然是正確的。
BBS上用來這種方式掐架是可以，但是用于現實中，這樣“聽”對方的觀點恐怕就不成了。這一點現象非常普遍，所以，在聽到這些東西的時候，至少讓自己考慮一下，我是不是也犯了這個毛病了？說對方錯，真的很爽啊，不是嗎？我們會象看著一個小丑或者一個孩子一樣，感覺自己很明智，但是這種狀態可不好，用這種方式去聽，溝通基本上就不成了。過于敏感，特別對于很多自我感覺非常良好的人來說，他會把任何建議和意見，看成對他個人全部的挑戰。還記得大仲馬筆下《三個火》中的主人公嗎？那是小說，如果現實中，你也如此的敏感的話，會令別人覺得你很難相處的啊。有的設計人員認為，任何的對設計提出的意見都是對自己的攻擊，自己永遠是對的。如果是那樣的話，你就不是一個Teamplayer。在工作中很難和你合作啊。
不尊重人，BBS上很常見的一種無禮之舉是，沒有看完別人的貼子，就開始瘋狂批評。不錯“嘗一口就能夠知道的臭雞蛋，就不用吃完它”，但是（事情往往壞在“但是”上）如果你僅僅想爽一下，可以罵罵人，出出氣。但是，如果你想討論問題，最好還是看看清楚別人到底寫了什么東西。這是一種對別人的尊重。不要根據只言片語，按照自己的理解，狠狠說一通，那樣價值何在？典型的無效溝通。我們不是為了把人批臭批倒，來證明自己的勝利，我們是為了通過溝通解決問題。所以還是尊重一點比較好一些。
聽基本上說完了，很不完全，但是至少這些是第一時間反應到我腦子里面的東西，也是對我感觸最深的地方。下面該說說“說”了。
首先，理清楚你的思路，不要說到東，說到西，我根本不知道你想說什么。這是一個思路的清晰程度的問題。同時也是IQ組成很重要的一點。至少體現出一些高IQ人員的素質（大家不是說IT人員的人，要IQ比較高嗎？）。比如我們在面試中，喜歡用的一個方式是，一下子問7-8個問題，然后讓面試者按照順序回答下去（這7-8個問題，是有內在邏輯聯系的，而且邏輯相對比較明了。對于低級的崗位來說，我們一般連續問4-5個問題），并且在他回答過程中，我們會企圖問一些問題，然后讓他繼續回答。看他是否能夠回答完畢這些問題，而且思路比較清晰。如果一個人員，連4-5個連續問題的壓力都承受不了，一般來說，我就不再考慮了。所以，請維持一個清晰的思路，知道你要回答什么，不要象一個沒頭蒼蠅一樣，撞到哪里算哪里。
其次，請整理清楚你的邏輯，你舉出的實例要能夠證明你的論點，不要說得云山霧罩的，很讓人困惑的。這一點在BBS上經常看見，一個哥們說完N段以后，突然告訴我，上面的例子也許舉得不好，重新來過。我簡直不知道該說什么好了。你不是我的冤家派來玩我的吧？最簡單的邏輯整理方式是，提出你的觀點，然后用1、2、3、4列出你的論據，這樣大家比較容易溝通，不是嗎？不要一會一個例子，一會一個例子，而且我都不能分辨前后例子之間存在什么邏輯關系。對此，我只能承認，自己的理解能力實在有一些跟不上你跳躍的思維了。
再次，如果不是萬不得已（比如需要盡快的一個決策過程，不能再過多地討論了）盡量少用一些攻擊性很強的話。攻擊性很強的話，基本上不能起到加強你觀點的作用。這種方式類似一些懷疑別人做事的動機啊，問候別人的家人啊等等，一般來說，都是不必要的。對方會由此變得更加難以說服。因為他會自覺地保護自己，這時候已經不是事情本身了，而是變成人的事情了。一般來說，這更難以解決問題。當然，如果團隊內部已經建立起來這樣的文化，比如罵娘文化，那么有時候用用也無妨。但是我不喜歡這種文化而已。比如，有一個總監，和我爭論下一階段工作的時候（當然，這也是一種溝通，呵呵），曾經用手推了一下我胸口，當時正是夏天，本來就容易上火，我腦子突然一沖，幾乎揚手一個耳光就過去了。但是還好忍下來了。但是那次爭論沒有任何結果。
最后，說話請靠譜一些。我很不喜歡的一種人是說話不靠譜，什么都敢說，但是基本上胡扯居多。所以，請注意你的說話，說話要保證你說的，至少是你認為對的東西，不然就悠著點說，很容易誤導別人的。而且一旦被別人抓住，舉幾個數字出來，你就全完了。所以，我喜歡的一句話就是：“我不說，你不說，數字來說話”。呵呵，當然了，你讓數字如何說話，里面還是有大講究的。我的一個姨媽在統計局工作，她和當時在大學的我，講了很多如何讓數字來證明觀點的小伎倆，以至于我現在看見數字，也會留一個心眼，看看有沒有人在數字方面糊弄我。呵呵。學過統計學的哥們一定對這個很熟悉吧。好了。以上是一些常規的溝通，至于上下級之間的溝通，我就不在這里說明了，更多的會在團隊管理中說明。溝通成本很高，所以，讓我們盡量有效地溝通，而少一些無畏的溝通。說和聽都很重要，所以請認真對待。接下去的一點，是給不少在“說”方面略有欠缺的技術兄弟們寫的。我知道有一些技術人員，心中有很多東西，但是臨到說的時候，突然說不出來了，感覺很虧。如果你在公司被別人稱之為“噴壺”或者“噴泉”，就不用看了，這方面技能你一定不缺少，我這點經驗也不夠你笑話的了。最常規的鍛煉，是讓你能夠在大家面前滔滔不絕地說一些至少有一點意義的話。呵呵，這一點說起來難，其實也比較容易鍛煉。比如，在部門級會議的時候（呵呵，本來我今年想在得實開發一部中推開，但是還沒有來得及干，就離開得實了，很多得實的兄弟們說，希望如此做呢，這一點向兄弟們道歉了！將來有機會大家一起聚聚吧，很想念大家啊），湊個20-30個人，當然了，用其他方式，集中多一些人也是可以的，只是人不能太少。當然了，即使再少也是有用處，但是效果就沒有那么好了。然后準備一個大盒子，盒子里面是各種小紙條，小紙條上寫一個名詞（比如竹子、比如長城），隨意抽一個出來，然后用5-10秒作準備，然后就開始說，在5分鐘時間中，不允許任何超過3秒鐘的停頓（也不允許和朗讀詩歌一樣，一個“啊……”整個7-8秒，聽的人感覺很不好，感覺你在臺上公然被人毒打一樣）。如果超過3秒的停頓，就下臺，算失敗。如果挺過了5分鐘，然后大家來評判這些說話的內容是否連貫性強，思路是否清晰，演講的時候的語氣和語速控制等等。這也是聯想入模培訓的一環，當時我面對100多個模友，突然開始說，多少感覺有點口干舌燥，但是過了一段時間，后來就好很多了。要有自信，這一點真的不難，問題是大家沒有太多的機會來鍛煉，往往鍛煉的時候，就是公開演講的時候，越做得不好，越沒有自信；越沒有自信，越給下次埋下失敗的種子。所以，自信一些，大家都是這么來得。練幾次就好了。
下面，就是一些技巧的東西了，在“說”的方面的一般常用的技巧，我經常會用如下幾種：
首先，明白你所對話的人，是一種什么樣的人。然后再考慮如何說，對象是不懂技術的人，與精通技術的人，說話的方式是完全不一樣的，這一點很簡單，不多說了。關鍵一點，就是說對方能夠明白的話。你溝通不是用來賣弄的，是要讓對方明白你的意思。如果對方聽不明白，不是對方的問題，是你說話沒有水平哦。
其次，不要僅僅考慮你自己，而要考慮對方，是否明白你說話的意思。也就是說，你要從對方的思路上著手，而不是從你的思路上著手。舉一個例子，如果你研發了一個電熱水壺。你會如何說明給你的客戶聽？很多人上來就會說：“他會叫耶，水燒開了他就會叫耶”，“他熱得比別人快，省電哪”。但是，我還不知道你的產品是個什么玩意呢。所以，最保險和最常規的（當然也是最沒有創意的，如果要有創意一些該如何干？也許5年以后我會明白一些，但是現在我不知道）的做法是：
第一，介紹產品是什么：電熱水壺，就是用電把水燒開的東西；
第二，介紹產品能夠為客戶帶來什么價值；為你燒開水唄；
第三，我們產品的特色是什么：電熱的，
第四，為什么選擇我們？用電的，環保，干凈……
這樣的描述相對客戶容易理解一些。
再次，在介紹之前，首先很明確地說出你的觀點是什么（當然，這是一種常規的說法，如果你要由對方自己導出觀點，然后你再贊揚他幾句，把這當做他自己的觀點，那么就不用提出了）。
再次，說出你的論證體系。這是一個我習慣稱之為“思維管道”的東西，我會告訴對方，我是根據什么體系來導出結論的。比如，我會說，我根據SWOT、競爭力模型分析得出結論，或者告知對方，你的出發點是什么，比如我認為你這個問題，實際上需要解決的這樣一個難題等等。這主要有兩個作用，首先劃一條道路出來，讓對方的思路在下面的時間中，在你的規則中走；其次，如果發生誤解，那么也最快可以知道，免得說了一大通，發現說錯了，很難看的啊。會顯得你很笨的。
再次，也是很重要的一點，明確說，我有5個理由，或者3個因素使得我認為應該如此做。這樣做，容易使得別人感覺你的思路非常敏捷而且快速，或者你對這個問題已經考慮得很多了，是個非常專業的人。但是，在現實操作中，往往你聽到一個問題，只有大約3秒鐘的考慮時間，你需要利用這些時間來考慮明白你要說的理由，如果你想到了3-4點，請直接說我考慮有6個因素（因為你在說的過程中，多少會想到一些前面沒有想到的東西的）。那么如果你按部就班說下來，如果發現：靠，只有5個啊，少一個；這一點很惡心，不過沒有關系，你隨便想一個好了，或者把前面的一個觀點換一個方式說出來好了，如果你追求保險，最后總結的時候，說：“這一點和前面的某一點存在一些關系，但是有一些不同”，只要找到一點不同就可以了。相反的，如果你認為，壞了，少說了1點，應該是7點，該如何辦啊。呵呵，這恭喜你，你的思維太敏捷了，以后要記得多說一些哦。但是這次呢，就說：“最后補充一點，雖然放在最后說，但是并不代表他不重要”，然后，坦白地說出來好了。總不能讓自己的思路爛在肚子里啊。這不是教你扯謊，只是說，你用一種更有條理的方式，表達你的想法，僅此而已。
當然，這個要素不是越多越好，別人也記不住，你需要分層次來說，一般來說，5-7點就是極限了。
再下來，就應該一點一點表述你的論據了，如果能夠使用數字，就用數字來說明問題，太多的修飾詞會引起別人的反感的。比如“很多”、“大量”等等，說多了，很容易被老板一句，“到底多少？”給悶在里面，很難受的。
最后，要適度總結，在最后的時候，請回顧一下你的觀點摘要，這樣有助于對方整理思路。如果對方聽下來感覺很清晰，那么他會認為你的思路也很清晰。聰明人總是喜歡和聰明人溝通的，不是嗎？必要的時候，和對方的問題掛接一下以后再結束，因為對方的問題，也是對方最關心的東西。
最后，想說的一點是，明白一點，和聰明人說話，不用說得太詳細，說得太詳細，面面俱到，容易讓對方困倦，而且感覺很羅嗦（有的人還真喜歡這么說話，和他們對話，真的很累哦）。當然，如果和你對話的是個典型的棒槌，不妨說多一些（但是，老實說，我很少碰到過這樣的人。不過還是有的！第一次向他匯報的時候，說完以后，他兩眼茫然，搞得我很困惑；不明白是我說明上存在問題，還是他理解上存在問題。
至于在“聽”的方面，我一般常用的技巧是：
首先，請凝聚起來你的眼神（當然不要太兇，這會使得別人感覺你在審問他的），至少要裝得很聰明，很精干的樣子；而且也使得對方認為你在認真聽他說話。而且，據我自己的經驗，在這種狀況下，你的確在很認真地聽人說話。這一點很重要。
另外，把腰挺起來，跟一灘稀泥一樣躺在椅子里的，看上去比較不健康，而且懶散。
其次，請把看著對方，如果是對方是女性，一般目標關注的范圍大一些（不要盯著別人的眼睛看，會給人很大的心理壓力的），如果是男性，但是他的目光老是躲開你的目光，可能他是一個相對比較軟弱的人，不要老是盯著對方看了。適度多一些看看別的地方。我們看著對方，只是希望讓對方知道，我們很認真地在聽他說話，不是給人太大的壓力。另外，如果某個人身上有某個缺陷（比如眼睛斜視等等），請務必不要盯著看（雖然也許你很好奇），這會使得別人更加不自然的。
第4篇：軟件項目管理范文
關鍵詞：項目管理；工程管理
一、項目管理軟件的發展與現狀
項目管理技術的發展和計算機技術的發展是密不可分的。項目管理技術的出現適逢計算機誕生，因此，早期開發的網絡計劃軟件都是在大型機上運行的，主要運用于國防和土木建筑工程。20世紀80年代隨著微型計算機的出現和運算速度的迅猛提升，項目管理技術也呈現出繁榮發展的趨勢，涌現出大量的項目管理軟件，軟件的價格也大幅下降。目前項目管理軟件根據功能和價格水平被分為兩個檔次：高檔項目管理軟件供專業項目管理人士使用，這類軟件功能強大，價格昂貴；低檔項目管理軟件應用于一些中小型項目，盡管功能不是很齊全，但價格較便宜。
（一）高檔項目管理軟件
在此以國際上項目管理軟件的領頭羊Primavera項目管理系列軟件為例，介紹當今高檔項目管理軟件的現狀。
美國Primavera公司在1983年推出了日后成為項目管理軟件領頭羊的Primavera Project Planner（簡稱P3）1.0 for DOS。目前的最新版本為P3 3.0 for Windows。P3首先是基于廣義網絡計劃技術的理論編制的項目管理軟件。傳統的網絡計劃技術研究的都是進度方面的問題，所做的分析也主要是工期分析。實際上資源和投資都制約進度，一個合理的工期必須考慮資源和投資的因素。P3處理單個項目的最大工序數達到10萬道，資源數不受限制，每道工序數上可使用的資源數也不受限制。P3還提供資源均衡的功能，可以自動解決資源不足的問題。
P3中的節點號可以任意編制。傳統網絡技術的節點號只能是數字，而且后面的節點必須大于前面的節點。廣義網絡技術則不存在這樣的限制。P3中，節點號可以是數字，也可以是字母，后續作業的節點號不一定要比緊前作業的節點號大。此外，P3還能使用日歷來設置不同的節假日和工作時間，使用限制條件來表示項目的特殊要求。
P3采用目標管理的模式對項目實施控制。它將優化后的計劃作為目標計劃進行保存，隨時可調出來與當前的進度和資源消耗進行比較，可以方便地發現哪些作業超前，哪些作業落后，這些對整個工期有沒有影響。這樣，對工程的按期完工很有幫助。
P3能夠根據項目的工作分解結構（WBS）將項目的工作范圍從大到小進行分解，直至可操作的工作單元，也可以將組織機構逐級進行分解（OBS），形成最基層的組織單元，并將每一工作單元落實到相應的組織單元去完成。然后P3根據不同管理層的要求，在工作分解結構或組織分解結構的任意層次上進行統計和匯總。除此之外，P3還可以根據工程的屬性任意對工作進行篩選、分組、排序、匯總。
作為商品化的軟件，P3的數據接口功能齊全。既可以輸出到傳統的dBase數據庫、Lotus文件和ASCII格式文件，也可以接收dBase、Lotus格式的數據，還可以通過ODBC與Windows程序進行數據交換。使用P3的批處理程序經簡單編程就可以執行P3的大部分功能。此外P3還提供了開發引擎RA，編程人員使用其他編程工具如Visual、Basic、Visual C++、PowerBuilder通過RA來讀寫P3數據。Primavera還提供與Oracle數據庫的雙向接口DataStore。
P3還提供Primavera Postoffice郵局軟件，項目施工人員可以使用該郵局軟件打開總部的工作安排，并將實際進展反饋給總部。Primavera還提供了Webster for Primavera，使用該軟件的各單位和個人可通過瀏覽器來訪問和更新項目數據。
（二）低檔項目管理軟件
目前市場上有大量簡單的項目管理軟件，也有許多“公開源代碼”的項目管理軟件。這些軟件一般只完成項目管理某一階段和某一方面如計劃安排、人員管理、風險分析等功能。
Project Scheduler 7就是一個廣受歡迎的項目事件安排和管理程序，它提供了風格獨特、省錢的功能，并且方便易用。可在桌面完成基本的工作，或與SQL數據庫一起處理大的、復雜的程序。它包括向導、當日竅門、域級幫助等，還具有非常好的靈活性，適合組織、合并及查看項目情況。它還提供一個HTML網頁出版程序，快速、專業地交流項目的進展。
Microsoft Project 98是一個易于使用、特性齊全、獲獎的項目管理軟件包。它是一個強有力的計劃、分析和管理工具，能夠創建企業范圍對具體任務要求較高的項目管理解決方案。該程序通過把一個項目分解為易于管理的步驟，能夠對最復雜的計劃進行可視化分析，可以看到任務是如何相互聯系的，這對于制定全面的計劃非常關鍵。同時可以找到瓶頸所在，以及整個項目的未來開銷。也可以將幾個項目進行合并，以便對共享資源、團隊工作量以及正在同時籌劃的多個項目放在一起是否合理進行評估。甚至可以自動地交流項目的狀態。內置的到Microsoft Exchange的鏈接可以讓該程序方便地一個項目所選定的屬性，并且可以連接到Microsoft Mail、Schedule+、 Microsoft Back Office（TM）或者數以百計的附加程序。
二、國內應用狀況
運用項目管理軟件編排進度計劃，在項目投標以及工程開工之前均能用這些軟件來編制計劃。部分企業還處于被動使用狀態，因為項目招標書中要求使用項目管理軟件進行項目管理，而被迫使用相應軟件。
通過進度和資源結合使用，分析資源的強度和資源的使用安排是否滿足要求。很多企業和項目通過使用項目管理軟件，嘗到了甜頭，希望通過項目管理軟件的資源分析和成本管理的功能，合理配置資源，使得進度計劃更為合理。
根據施工組織措施來編制進度和資源計劃，根據計劃來安排生產，通過計劃對進度進行控制。有部分項目的計劃編制十分漂亮，資源配置也很合理，但是現場施工沒有按照計劃來執行。這就要求計劃的編制人員必須按照施工方案來編制計劃，現場施工人員按照計劃安排生產，并及時將實際進程向上反饋，實施動態跟蹤。能做到這一點，已基本體現了項目管理軟件的功能。目前國內已有部分項目正在按照該模式進行動態控制。
項目管理的數據與企業管理信息系統（MIS）集成，通過數據共享，減少重復輸入。通過項目管理軟件的接口功能與企業的管理信息系統連接，對于企業項目管理系統可進行該部分工作，對于非超長工期型項目而言，不必提出該要求。
通過Internet和Intranet對遠程項目進行控制。分散在全球各地的分公司或項目工地上的工程數據通過Internet和Intranet傳遞到本部，在總部進行匯總和統一安排，并將指令通過郵件下發給分公司或工地。企業和戰線偏長的項目可推廣此應用。
三、前景展望
在項目上應用項目管理軟件系統首先要解決兩個問題：其一是自主開發還是引進為主，再做二次開發？其二是項目管理的核心是什么？
通過長期的實踐，在項目上馬后再找開發人員開發項目管理系統，已經在過去十多年的實踐中證實是行不通的。我們提倡在對待項目管理軟件時，對核心軟件還是以引進為主，在此基礎上做少量二次開發工作，以滿足工程的某些特殊需求。
對于項目管理的核心問題，確定了核心之后，就應圍繞著核心來構筑項目管理系統。先確定核心軟件，然后再著手開發和引進周邊軟件系統。構筑一個工程項目的管理軟件，首先，在招標階段就選定核心軟件，并在標書及今后的合同文件中規定使用相同的軟件；其次，在項目開工之前，就要組織各方有關人員進行培訓，并進行統一WBS編碼、工作編碼、資源編碼的工作，同時制定項目管理軟件的實施辦法；最后，在工程開工后，定期收集工程的進展情況，通過一定的獎懲措施，促使各單位嚴格按照計劃組織生產，及時準確地反饋數據，確保整個工程處于控制之中。
第5篇：軟件項目管理范文
1、什么是項目管理？
項目管理是在一定的約束條件下，以高效率地實現項目業主的目標為目
的，以項目經理個人負責制為基礎和以項目為獨立實體進行經濟核算，并按照項目內在的邏輯規律進行有效的計劃、組織、協調、控制的系統管理活動。
2、為什么要有項目管理？
沒有項目管理，項目也有可能成功。但沒有管理的項目，很難保證項目
的利潤空間，對公司來說，虧損的風險就大。所以我們要有項目管理，以保證公司在總體上是盈利的，注意不是每一個項目都要盈利。
另外，有了項目管理，就有了管理改進的基礎，無論剛開始的項目管理多么糟糕，只要有管理，就有了改進的可能性，至于能不能得到改進，以及改進的快慢，則取決于兩個因素：一個是人，特別是各級管理者；另一個是利益。關鍵是“利益”，準確的說是“利益的分配”，在權責利明確的前提下，人才能充分的發揮作用。還需要指出的是“利益”是多元的，這里的多元不僅指利益的具體形式，而且指利益的受眾是多元的，包括客戶方相關人員個人的利益。
3、項目管理的發展與現狀。
今天，項目管理作為一種現代化管理方式在國際上已獲得了廣泛的應用，從最初的國防、航天、建設工程領域，迅速發展到電子、通信、計算機、軟件開發、金融等行業以及政府機關的項目管理工作。隨著計算機、網絡系統的迅速發展，項目管理技術的不斷進步，項目管理軟件產品層出不窮，其功能、特點、應用對象也各不相同。當前，越來越多的企業和組織在內部推廣項目管理的理論方法及管理模式，如果都采用項目管理軟件進行管理，效果就更加明顯，可以節省大量的資源和財富。國外90%以上的項目管理都采用軟件進行，但我國在這方面的應用還不到10%。新世紀項目管理在中國的迅速興起，給軟件企業的發展帶來了前所未有的發展機遇。
項目管理在軟件開發中的應用的成因
隨著信息技術的飛速發展，軟件產品的規模也越來越龐大，個人單打獨斗的作坊式開發方式已經越來越不適應發展的需要。各軟件企業都在積極將軟件項目管理引入開發活動中，對開發實行有效的管理。從概念上講，軟件項目管理是為了使軟件項目能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動。實際上，軟件項目管理的意義不僅僅如此，進行軟件項目管理有利于將開發人員的個人開發能力轉化成企業的開發能力，企業的軟件開發能力越高，表明這個企業的軟件生產越趨向于成熟，企業越能夠穩定發展（即減小開發風險）。同時，隨著軟件開發規模及開發隊伍的逐漸增大，軟件開發不再是向過去那樣一二個開發人員即可解決的事情。迫切需要一種開發規范來規范每個開發人員、測試人員與支持人員的工作，每個項目組成員按約定的規則準時完成自己的工作。同時采用規范化管理，專業分工也可以降低對開發人員的要求，從而降低產品研發成本。
軟件開發是一項復雜的系統工程，牽涉到各方面的因素，實際工作中，經常會出現各種各樣的問題，甚至面臨失敗。如何總結、分析失敗的原因，得出有益的教訓，對一個公司來說，是在今后的項目中取得成功的關鍵。
早在20世紀60年代中期，人們就發現軟件的生產出現了“問題”，主要表現在生產過程不規范，缺乏管理。后來，人們在軟件工程方法學中引入了工程的概念、原理、技術和方法，這種思想在一定程度上解決了軟件生產過程中遇到的問題。但是直至80年代還是沒有提出一套管理軟件開發的通用原則，軟件管理不善的問題依舊在大范圍內存在。
目前的軟件開發正逐步趨向于復雜化、多元化，大多數開發團隊中都會出現同時開發多個版本、開發/維護工作并存、多地點同時開發等情況，給軟件開發管理帶來了前所未有的困難。如果管理不善，必將造成版本混亂，各個開發人員的工作相互交叉、干擾，整個開發團隊的工作在一種無秩序的不良狀況下運行，嚴重影響軟件產品開發的進度和質量。
因此，隨著軟件開發的深入、各種技術的不斷創新以及軟件產業的形成，人們越來越意識到軟件過程管理的重要性，管理學的思想逐漸融入軟件開發過程中，應用開發的項目管理日益受到重視。而項目管理技術的發展與計算機技術的發展是密不可分的，隨著計算機性能的迅速提高，大量的項目管理軟件涌現出來。它們可以用于各種商業活動，提供便于操作的圖形界面，幫助用戶制定任務、管理資源、進行成本預算、跟蹤項目進度等。
軟件項目管理常見問題及解決方案
對于軟件開發項目中，經常出現兩種極端情況，一種是創造了新的生產率和質量的紀錄；一種則完全是一場災難，不是被取消就是拖延很長時間。前者如在很短的時間內，為了趕進度，在幾乎不可能的時間內開發出一套軟件產品，創造了軟件開發的記錄，滿足了上級所要求的上機日期，由于開發時間太短，過于倉促，上機時，問題百出，試運行時間長達幾個月或一年半載的，而且程序一改再改，維護工作量大。
后者，如某套系統未弄清楚需求，或因設計問題，開發失敗。通過提煉這些成功和失敗的例子，軟件項目成功或失敗的根本原因可能會更清晰一些。
目前我國大部分軟件公司，無論是產品型公司還是項目型公司，都沒有形成適合自己公司特點的軟件開發管理模式，雖然有些公司根據軟件工程理論建立了一些軟件開發管理規范，但并沒有從根本上解決軟件開發的質量控制問題。這樣導致軟件產品質量不穩定，軟件后期的維護、升級出現麻煩，同時最終也會損害用戶的利益。
分析目前項目管理需要改進的問題可以從幾種相關角色的角度去考慮：項目經理、項目組成員、公司管理人員、市場人員、客戶等。
問題一：缺乏項目管理系統培訓（相關對象：項目經理、管理人員）
項目經理在項目管理方面的培訓較少或不夠系統。項目經理或管理人員不了解項目管理的知識體系和一些常用工具和方法，所以在實際工作中沒有項目管理知識的指導，完全依靠個人現有的知識技能，管理工作的隨意性、盲目性比較大。在軟件企業中，以前幾乎沒有專門招收項目管理專業的人員來擔任項目經理（甚至很少是管理專業的），被任命的項目經理主要是因為他們能夠在技術上獨當一面，而管理方面特別是項目管理方面的知識比較缺乏。
解決方案：項目經理接受系統的項目管理知識培訓是非常必要的，有了專業領域的知識與實踐，再加上項目管理知識與實踐和一般管理的知識和經驗的有機結合，必能大大提高項目經理的項目管理水平。應實行項目經理知識技能資格考核制度，讓項目經理自覺補充學習項目管理的知識和一些常用工具和方法。
問題二：項目計劃意識問題（相關對象：項目經理）
項目經理對總體計劃、階段計劃的作用認識不足。項目經理認為計劃不如變化快，項目中也有很多不確定的因素，做計劃是走過場，因此制定總體計劃時比較隨意，不少事情沒有仔細考慮；階段計劃因工作忙等理由經常拖延，造成計劃與控制管理脫節，無法進行有效的進度控制管理。沒有計劃或者是隨意的不負責任的計劃的項目是一種無法控制的項目。
解決方案：在高技術行業，日新月異是主要特點，因此計劃的制定需要在一定條件的限制和假設之下采用漸近明細的方式進行不斷完善。提高項目經理的計劃意識，采用項目計劃制定相關各種知識、技術、工具，加強對開發計劃、階段計劃的有效性進行事前事后的評估。
問題
三、管理意識問題（相關對象：項目經理）
部分項目經理沒有意識到自己項目經理的角色，從總體上去把握管理整個項目，而是埋頭于具體的技術工作，造成項目組成員之間忙的忙、閑的閑，計劃不周、任務不均、資源浪費。在軟件企業中，項目經理大多是技術骨干，技術方面的知識比較深厚，但無論是項目管理知識，還是項目管理必備的技能、項目管理必備的素質都有待補充和提高，項目管理經驗也有待豐富。有些項目經理對于一些不服管理的技術人員，沒有較好的管理方法，工作不好安排的工作只好自己做。另外由于工作分解結構設計的合理性，項目任務無法有效、合理地分配給相關成員，以達到“負載均衡”。
解決方案：加強項目管理方面的培訓，并通過對考核指標的合理設定和宣傳引導項目經理更好地做好項目管理工作。技術骨干在擔任項目經理之前，最好能經過系統的項目管理知識，特別是其中的人力資源管理、溝通管理的學習，并且在實際工作中不斷提高自己的管理素質，豐富項目管理經驗，提高項目管理意識。
問題四：溝通意識問題（相關人員：項目經理、項目組成員）
在項目中一些重要信息沒有進行充分和有效的溝通。在制定計劃、意見反饋、情況通報、技術問題或成果等方面與相關人員的溝通不足，造成各做各事、重復勞動，甚至造成不必要的損失；有些人沒有每天定時收郵件的習慣，以至于無法及時接收最新的信息。
解決方案：制定有效的溝通制度和溝通機制，對由于缺乏溝通而造成的事件進行通報作為教訓提醒，以提高溝通意識；溝通方式應根據內容而多樣化，講究有效率的溝通；通過制度規定對由于未及時收取郵件而造成損失的責任歸屬；對于特別重要的內容要采用多種方式進行有效溝通以確保傳達到位，例如除發送郵件外還要電話提醒、回執等，重要的內容還要通過舉行各種會議進行傳達。
問題五：風險管理意識問題（相關人員：項目經理）
項目經理沒有充分分析可能的風險，對付風險的策略考慮比較簡單。項目經理在做項目規劃時常常沒有做專門的風險管理計劃文檔，而是合并在項目計劃書中。有些項目經理沒有充分意識到風險管理的重要性，對計劃書中風險管理的章節簡單應付了事，隨便列出幾個風險，隨便地寫一些簡單的對策，對于后面的風險防范起不到什么指導作用。
解決方案：通過學習項目管理知識掌握風險識別、量化、對策研究、反應控制的工具和方法掌握項目風險管理所必備的知識。通過加強對項目規劃中風險管理計劃的審核提高項目組的風險管理意識。總結本行業項目中常見的風險及其對策作為風險管理計劃中必要的風險內容，并切實評估相應對策的有效性和可行性。
問題六：不重視項目經驗的總結（相關人員：項目經理、管理人員）
項目經理在項目結束時有些是因為自身對寫文檔工作的興趣或意識，或
者是因為緊接著要參加下一個項目，總體對項目總結的重視程度不夠。有些是項目總結報告一再拖延，有些是交上來的報告質量較低，敷衍了事。
解決方案：在制度上鼓勵和加強項目經驗總結工作，使得項目總結及時并且具有指導意義而不是走過場。
問題七：項目干系人相關問題（相關人員：項目經理、項目成員、客戶）
在范圍識別階段，項目組對客戶的整體組織結構、有關人員及其關系、
工作職責等沒有足夠了解以致于無法得到完整需求或最終經權威用戶代表確認的需求。由于項目經理的工作問題，客戶參與程度部不高，客戶方相關責任人不明確或對范圍和要求責任心不強，提出的要求具有隨意性，項目前期對需求的確認不夠積極；或者是多個用戶代表各說各話、昨是今非但同時又要求項目盡早交付；項目后期需求變化隨意，造成項目范圍的蔓延，進度的拖延，成本的擴大。
解決方案：項目的目的就是實現項目干系人的需求和愿望。項目干系人管理應當從項目的啟動開始，項目經理及其項目成員就要分清項目干系人包含哪些人和組織，通過溝通協調對他們施加影響，驅動他們對項目的支持，調查并明確他們的需求和愿望，減小其對項目的阻力，以確保項目獲得成功。
問題八：項目團隊內分工協作問題（相關人員：項目經理、項目成員）
項目團隊內部有時由于各階段不同角色或同階段不同角色之間的責任
分工不夠清晰而造成工作互相推諉、責任互相推卸的現象，有時各階段不同角色或同階段不同角色之間的責任分工比較清晰但是各項目成員只顧完成自己那部分任務、不愿意與他人協作。這些現象或多或少地造成了項目團隊內部資源的損耗，從而影響了項目的進展。
解決方案：項目經理應當對項目成員的責任進行合理的分配并清楚地說明，同時應強調不同分工、不同環節的成員應當相互協作，共同完善。
以上對軟件開發項目管理中出現的問題的分析還不夠深入，也無法列舉所有遇到或將遇到的問題，解決方案也要根據實際情況進行調整，希望引起對這些問題更多的思考和改進。
結束語：項目管理雖然沒有非常高深的理論，但要真正實施起來，也絕非易事。對于軟件開發企業而言，這不是一個小的改變，而是一種變革，企業需要為此付出艱苦的努力，宣傳并樹立公司范圍內的項目管理文化十分重要。從而在實踐中鍛煉提高，解決各種各樣的問題，使項目管理工作越做越好。
內容摘要：隨著信息產業的飛速發展，項目管理對于以應用開發為主的軟件企業是一個行之有效的管理方法，項目管理在軟件開發中的應用日益受到重視。本文主要通過對項目管理在軟件開發中的應用的成因、存在的問題以及相應的解決方案進行了分析和論述。
第6篇：軟件項目管理范文
關鍵詞：軟件項目管理；需求管理
中圖分類號：TP311 文獻標識碼：A文章編號：1007-9599 (2011) 17-0000-01
Demands Management in Software Project Management
Yuan Jue,Hu Jun
(Shanghai Asia&Pacific Computer Information System co.,Ltd,Shanghai200040,China)
Abstract:Demand management is the foundation in whole software engineering management,also is to determine key of success or failure.This paper discusses the importance of demand management,the existing problems.In the light of these problems,puts forward relevant solutions.
Keywords:Software project management;Demands management
何謂需求管理？理解需求管理的第一步就是對什么是需求管理達成共識。需求是正在構建的系統必須符合的條件或功能，符合某些需求決定了項目的成功或失敗，因此找到這些需求、記錄它們、追蹤它們的變化，都是很有意義的活動。換句話說，需求管理就是：一種獲取、組織并記錄系統需求的系統化方案，以及一個使客戶與項目團隊對不斷變更的系統需求達成并保持一致的過程。
一、需求管理的重要性
系統開發團隊之所以管理需求，是為了讓項目獲得成功。滿足項目需求即為成功打下了基礎。2001年，Standish Group的CHAOS Reports報導了該公司的一項研究，該公司對多個項目作調查后發現，百分之七十四的項目是失敗的，即這些項目不能按時按預算完成，其中提到最多的導致項目失敗的原因就是“用戶需求變更”。
軟件項目的開發過程中，需求變更貫穿了軟件項目的整個生命周期，是軟件開發的第一步，關鍵的一步，也是最難把握的一步。項目管理過程中，項目經理經常面對用戶的需求變更，如果不能有效處理這些需求變更，項目計劃會一再調整，軟件交付日期一再拖延，項目研發人員的士氣越來越低落，直接導致項目成本增加、質量下降及項目交付日期推后。這些都決定了項目組必須擁有需求管理策略。
二、存在的問題及解決策略
（一）項目干系人的確立
項目用戶方干系人，指所有可能受到項目結果重大影響的人，即可能是項目的受益者，也可能是項目的受害者。項目用戶干系人往往涉及到多個層面、多個部門的用戶，其中的關系錯綜復雜，對項目的需求也不盡相同，甚至是相互矛盾沖突的，這些大大增加了需求調研工作的難度和不確定性。
因此，從項目啟動初期，就要分清項目用戶方干系人包含哪些人和組織，在組織結構圖基礎上，勾畫出全體項目用戶干系人結構圖，明確項目干系人之間的關系，通過溝通協調對他們施加影響，驅動他們對項目的支持，調查并明確他們的需求和愿望，減小其對項目的阻力，以確保項目獲得成功。
同時，不同的項目用戶方干系人其愿望和追求的目標往往相差甚遠，因此對項目用戶方干系人的愿望進行平衡是一件非常重要而又相當困難的事情。當不同用戶方干系人有不一致的需求時，必須決策出滿足哪一類用戶方干系人的需求更為重要。了解可能使用系統的用戶種類、各類用戶對系統的用法、以及與系統業務目標的關系，將有助于決定哪一個用戶類所占份額更大。當開發者想象的產品與客戶需求沖突時，通常應該由客戶做出決策；然而，不要陷人“客戶總是對的”的陷阱中去，現實中，客戶并不總是對的。
（二）需求描述的細致性、準確性、完備性
一般來說，需求描述越詳細越好，但系統的需求是層出不窮的，并且隨著時間的推進，用戶的需求也會越來越多，要在需求分析階段做到窮舉需求是不可能的。因此在需求描述的問題上，如何把握需求階段投入的人力、時間、需求描述的細致程度，是沒有統一的界定，需要需求分析人員學會適當的把握，采取恰當的需求獲取方法，盡可能詳盡到位的挖掘用戶需求。
首先，項目需求包含明確的和隱含的，也可以分為NEED，WANT，WISH等不同的層次。為了獲取最貼近用戶的需求，應對項目所有用戶方干系人進行足夠的溝通，使其盡可能地參與項目，盡可能避免出現用戶相關責任人不明確、提出的需求具有太多的隨意性、項目前期對需求的確認不夠積極、項目后期需求變化隨意等極可能造成項目范圍的蔓延，進度的拖延，成本的擴大，甚至項目的完全失敗的現象發生。
其次，各種用戶對系統的要求不盡相同，比如一個沒有經驗的用戶更關心系統是否簡單易用，對于高級用戶則關心系統的易用性和高效性。因而需要對用戶進行分類，每一個用戶群將有自己的一系列功能和非功能要求。在項目中，要盡早為系統確定并描述不同的用戶群，這樣就能從每一個重要的用戶群中獲取不同的需求。
最后，當面對缺乏計算機知識，無法提出完整準確、隱含或潛在需求的用戶，可以利用各種可視化需求調研的方法啟發引導用戶清楚地敘述需求，使需求更加全面完善。需求分析人員應善于想用戶所想，用啟發的方式與用戶探討隱含的或潛在的需求，并結合各種調研分析技術挖掘超出客戶期望的令人興奮的需求。
（三）需求變更的控制
需求的變化問題是每個開發人員、每個項目經理都遇到的問題，也是最頭痛的問題，一旦發生了需求變化，你不得不修改設計、重寫代碼、修改測試用例、調整項目計劃等等，需求的變化好比是萬惡之源，為項目的正常進展帶來不盡的麻煩，怎么辦？管理它！使需求在受控的狀態下發生變化，而不是隨意變化，需求管理就是要按照標準的流程來控制需求的變化。
軟件開發過程中有這樣一條真理：需求的變化是永恒的，需求不可能是完備的。因此軟件開發的過程實際上是一個變化的過程，需求變更貫穿軟件項目的整個生命周期，通過建立規范的變更控制流程，改進軟件分析與設計，把變化納入計劃之中是完全必要的。
實現需求文檔的版本控制是最基本的。變更的需求之所以變得難以管理，不僅是因為一個變更的需求意味著要花費或多或少的時間來實現某一個新特性，而且也因為對某個需求的變更很可能影響到其他需求。應確保賦予需求一個有彈性的結構，使它能適應變更，并且確保使用可追蹤性鏈接表達需求與開發生命周期的其他工件之間的依賴關系。
三、結束語
需求管理是一個持續的不斷完善的過程，軟件項目開發過程中需求管理的問題有很多，隨時都有用戶提出需求變更，需求分析的錯誤也時常發生，需求質量難以保證，針對這些問題，如何采取有效的措施盡可能減少這些問題可能給項目造成的影響顯得尤其重要。另外關于需求的質量問題，怎樣結合CMMI標準進行需求的質量管理，有效提高軟件的總體質量水平也是值得我們關注的問題。
參考文獻：
[1]毋國慶等編著.軟件需求工程[M].機械工業出版社,2008,8:1
第7篇：軟件項目管理范文
論文關鍵詞：能力成熟度模型 能力成熟度模型集成 個體軟件過程 群組軟件過程
論文摘要：從軟件項目管理的重要性談起，研究分析了四個主流的軟件項目管理技術，指出了它們的缺陷，最后結合實踐提出了一種新穎的軟件項目管理概念。
1引言
軟件項目管理是為了使軟件項目能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動。最早源自于70年代中期。當時美國國防部曾立題專門研究軟件項目做不好的原因，發現70％的項目是因為管理善引起的，而并不是因為技術實力不夠，進而得出一個結論，即管理是影響軟件項目全局的因素，而技術只影響局部。這個結論非常重要。到了90年代中期，軟件項目管理不善的問題仍然存在。據美國軟件工程實施現狀的調查，軟件研發的情況仍然很難預測，大約只有10％的項目能夠在預定的費用和進度下交付。在商用軟件產業中，這一現象尤為嚴重。1995年，美國共取消了810億美元的軟件項目，其中31％的項目未做完就取消了，53％的軟件項目進度通常要延長一半的時間，通常只有9％的軟件項目能夠及時交付并且費用也不超支。由此可見，軟件項目管理技術的研究至關重要。
2軟件項目管理技術綜述
隨著上世紀末軟件工程的快速發展，軟件項目管理水平也有了很大提高，提出了很多的軟件項目管理技術，極大地推動了軟件業的發展，這里我們主要談以下四種主流的軟件項目管理技術。
2．1 CMM
CMM是美國卡納基梅隆大學軟件工程研究所(CMU／SEI)提出的軟件研發項目管理的一系列方法，它基于組織對關鍵過程域的支持，定義了軟件過程成熟度的五個級別。
級別1(初始級)描述了不成熟，或者說是未定義過程的組織。級別2(可重復級)，級別3(已定義級)，級別4(已管理級)和級別5(優化級)分別描述了軟件過程成熟度級別遞增的組織。和這些級別相關的KPA是：
級別2：需求管理，軟件項目計劃，軟件項目跟蹤和監控，軟件子合同管理，軟件質量保證，軟件配置管理。
級別3：組織級過程焦點，組織級過程定義，培訓大綱，集成軟件管理，軟件產品工程，組間協調，同行評審。
級別4：定量過程管理，軟件質量管理。級別5：缺陷預防，技術更新管理，過程更改管理。
2．2 CMMI
CMMI被看做是把各種CMM集成為一個系列的模型中。CMMI的基礎源模型包括：軟件CMM2．0版(草稿c)，EIA一731系統工程，以及IPDCMM(IPD)0．98a版。CMMI也描述了5個不同的成熟度級別：
級別1(初始級)代表了以不可預測結果為特征的過程成熟度。過程包括了一些特別的方法、符號、工作和反應管理，成功主要取決于團隊的技能。
級別2(已管理級)代表了以可重復項目執行為特征的過程成熟度。組織使用基本紀律進行需求管理、項目計劃、項目監督和控制、供應商協議管理、產品和過程質量保證、配置管理、以及度量和分析。對于級別2而言，主要的過程焦點在于項目級的活動和實踐。
級別3(嚴格定義級)代表了以組織內改進項目執行為特征的過程成熟度。強調級別2的關鍵過程域中前后一致的、項目級的紀律，以建立組織級的活動和實踐。附加的組織級過程域包括：①需求開發：多利益相關者的需求發展。②技術方案：展開的設計和質量工程。③產品集成：持續集成、接口控制、變更控制。④驗證：保證產品正確建立的評估技術。⑤確認：保證建立正確的產品評估技術。⑥風險管理：檢測、優先級，相關問題和意外的解決方案。⑦組織級培訓：建立機制，培養更多熟練人員。⑧組織級過程焦點：為項目過程定義建立組織級框架。⑨決策分析和方案：系統可選的評估。⑩組織級過程定義：把過程看做組織的持久發展的資產。⑩集成項目管理：在項目內統一各個組和利益相關者。
級別4(定量管理級)代表了以改進組織性能為特征的過程成熟度。3級項目的歷史結果可用來交替使用，在業務表現的競爭尺度(成本、質量、時間)方面的結果是可預測的。級別4附加的過程域包括：①組織級過程執行：為過程執行設定規范和基準；②定量的項目管理：以統計質量控制方法為基礎實施項目。
級別5(優化級)代表了以可快速進行重新配置的組織性能和定量的、持續的過程改進為特征的過程成熟度。附加的級別5過程域包括：①因果分析和解決方案：主動避免錯誤和強化最佳實踐；②組織級改革和實施：建立一個能夠有機地適應和改進的學習組織。
2．3 PSP
PSP(PersonalSoftwareProcess，個體軟件過程)是由CMU／SEI開發出來的，它的推出在軟件工程界引起了極大的轟動，可以說是由定向軟件工程走向定量軟件工程的一個標志。PSP為基于個體和小型群組軟件過程的優化提供了具體而有效的途徑，例如如何制訂計劃，如何控制質量，如何與其他人相互協作等等。在軟件設計階段，PSP的著眼點在于軟件缺陷的預防，其具體辦法是強化設計約束準則，而不是設計方法的選擇。因此，PSP保障軟件產品質量的一個重要途徑是提高設計質量。
2．4 TSP
TSP(TeamSoftwareProcess，群組軟件過程)是CMU／SEI在PSP基礎上又發展出的軟件項目管理技術，它主要是指導項目組中的成員如何有效地規劃和管理所面臨的項目開發任務，并且告訴管理人員如何指導軟件開發隊伍。始終以最佳狀態來完成工作。TSP實施集體管理與自己管理自己相結合的原則，最終目的在于指導開發人員如何在最少的時間內，以預定的費用生產出高質量的軟件產品，所采用的方法是對群組開發過程的定義、度量和改進。
實施TSP的先決條件有三條：首先，需要有高層主管和各級經理的支持，以取得必要的資源；其次，項目組開發人員需要經過PSP的培訓并有按TSP工作的愿望和熱情；第三，整個開發單位在總體上應處于CMM二級以上，開發小組的規模以3～20人為宜。在實施TSP的過程中，首先要有明確的目標，開發人員要努力完成已經接受的委托任務。在每一階段開始，要做好工作計劃。如果發現未能按期按質完成計劃，應立即分析原因，以判定問題是由于工作內容不合適或工作計劃不實際所引起，還是由于資源不足或主觀努力不夠所引起。開發小組一方面應隨時追蹤項目進展狀態并進行定期匯報，另一方面應經常評審自己是否按PSP的原理工作。開發小組成員應按自己管理自己的原則管理軟件過程，如發現過程不合適，應及時改進，以保證用高質量的過程來產生高質量的軟件。項目開發小組則按集體管理的原則進行管理，全體成員都要參加和關心小組的規劃、進展的追蹤和決策的制定等項工作。 3軟件項目管理技術分析研究
CMM的基于活動的度量方法和瀑布過程的有次序的、基于活動的管理規范有非常密切的聯系，所以CMM在實踐中反映出來的問題表現為過度基于過程的管理，具有典型的傳統瀑布方法癥狀。現代主流的疊代軟件項目開發技術、軟件產業最佳實踐和經濟動機推動了軟件開發組織采用基于結果的方法：開發業務案例、構想和原型方案；細化后納入基線結構、可用，最后定為現場版本的。雖然CMMI保留了基于活動的方法，它的確集成了軟件產業內很多現代的最好的實踐，因此它很大程度上淡化了和瀑布思想的聯系，而和疊代思想聯系得更緊密。軟件項目管理技術發展到今天，有了成熟的現代軟件項目管理十大原理(沃克爾·羅伊斯)：①首先注重結構過程；②用疊代生命周期在早期防御風險；③強調基于構件的開發；④建立變更管理環境；⑤用循環工程工具使變更更自由；⑥使用嚴格的、基于模型的設計符號；⑦提供過程的客觀質量控制的手段；⑧使用中間產品的基于演示的評估；⑨細化的、展開的計劃；⑩建立一個可升級的、可配置的過程。
根據對軟件開發項目一線的多數工程師和項目經理的調查分析，我們知道CMM對現代原理幾乎沒什么影響，甚至有些現代原理實際上是和CMM關鍵過程域相沖突的。基于對產業默認實踐的觀察和分析，CMMI和現代管理原理關系十分密切，激發了半數的疊代軟件管理原則，如表1所示。
因此，對于采用瀑布過程開發軟件項目的組織來講，最好采用CMM的軟件項目管理技術，而對于采用迭代軟件開發過程開發軟件項目的組織來說，還是應該采用CMMI軟件項目管理技術進行軟件項目管理。
但是，并不是實施了CMM／CMMI后，軟件研發項目的質量就能夠有所保障了。CMM／CMMI不是萬能的，它的成功與否，與組織內部有關人員的積極參與和創造性活動密不可分，而且CMM／CMMI并未提供有關子過程實現域所需要的具體知識和技能。這就需要PSP的管理技術來協作了，PSP專注于為個體和小型群組軟件過程的優化提供具體而有效的途徑。統計數據表明，在應用了PSP后軟件中總的差錯減少了，在i貝0試階段發現的差錯減少了，生產效率提高了，軟件項目開發有了很大的改善。
眾所周知，現代軟件項目早已走出單個英雄單打獨斗的時代，而是需要眾多軟件工程師的密切合作。實踐證明，PSP已不能解決現代軟件項目管理中的所有問題，這時，擅長于項目任務規劃管理和項目人力資源規劃管理的TSP恰好可以在這方面做有益的補充。
綜上所述，單純實施CMM／CMMI，永遠不能真正做到能力成熟度的升級，達到軟件項目管理的最佳境界，只有將實施CM CMMI與實施PSP和TSP有機地結合起來，靈活地應用于軟件項目管理，才能發揮最大的效力，取得最好的效果。
第8篇：軟件項目管理范文
軟件項目管理是為了將軟件開發人員的積極性調動起來， 將開發人員的能力轉換為真正的對軟件開發有利的積極能量，降低軟件開發的風險，保證項目能夠在預想的有效期限內完成。
1 軟件開發實例
在得到用戶給的系統名稱——民族文化信息資源服務網(飲食)后我們就根據自己的理解在沒有進行需求分析、沒有對軟件開發進行設計、沒有與用戶進行溝通的前提下就開始進行該平臺的開發，然而經過2個月的開發實踐我們做出的東西和用戶想要的相差甚遠，同時我們的開發效率也相當低，從以上的開發實踐中我們得到了很多經驗教訓，下面我們就對其進行討論。
2 軟件項目的準備和啟動
在軟件項目的開發過程中，軟件項目的準備和啟動是相當中要的，在這個階段要了解項目的背景、分析在這個項目中的各個利益相關者、對軟件項目的范圍進行界定等工作，使項目的負責人可以做到心中有數。
通過與用戶的溝通與協商之后，我們大致了解到該系統的主要功能是此系統可以對少數民族的飲食文化進行管理，特別是對云南地區少數民族飲食文化的展示，系統中主要包括特色飲食的圖片、介紹以及每道美食的具體制作過程。通過該系統人們可以瀏覽云南地區少數民族的特色飲食，在此過程中同時實現民族文化的傳播與傳承，有利于我國少數民族文化的發展。
3 軟件項目的時間管理
為了能夠按時將系統實現，對所要做的工作進行計劃是相當必要的。一份可操作性較強的計劃可以使項目能夠較好地得到實現，不至于使項目拖到截止日期之后較晚的時間，同時可以保證軟件具有比較完備的功能模塊。在該階段的主要任務就是制定項目進度的計劃、并對各種變更進行有效地把握。
在制定進度計劃過程中我們要對需求分析、數據庫設計、軟件代碼編寫、素材收集、測試等過程進行較好地時間分配，在有限的時間內實現效率的最大化。在此次民族文化信息資源服務網(飲食)建設的時候有很多模塊是可以同時進行的，如我們在進行軟件代碼編寫的同時也可以進行各類民族特色飲食素材(飲食的名稱、做法、圖片)的收集。
因此為了能很好地達到時間上的準確把握，我們應該為軟件項目的開發制定良好的進度計劃。在企業軟件項目進度管理計劃發展的過程中，其進度管理內容是動態變化的。
在最初的項目計劃中，軟件項目管理首先要制定一個整體的進度計劃表，計劃表包括軟件工程的主要活動及其對應的軟件產品功能。隨著項目的逐步進行，整體進度表的內容得以進一步精細化，進而形成一個比較具體的進度表，表中要標明軟件項目完成所必須實現的特定任務，并針對不同任務制訂了對應的進度和產品項目要求。
4 軟件項目中的進度計劃實施
在此次需求分析后我們就開始將任務分配給各個小組分別自由地進行各自的工作，但各小組對自己負責的那部分的進展都比較緩慢，然而是由于時間緊任務重，我們必須對各個小組采取適當的措施。
(1)自身能力弱，完成任務的熱情低的人員。由于這部分人的技術能力普遍不強，同時對工作又不積極主動，不能按時完成上級交付的任務要求是在意料之中的事情，因此必須采取強制性的態度，對其加強培訓、監督和督促。
(2)能力強，完成任務的熱情低的人員。很多人在一個行業中待得時間長了之后就會出現很多工作不積極的人。對于這樣的人我們應該采取跟進方式。因為由于這些老員工自身的原因，往往會存在著一些工作熱情低，完成任務不主動的現象。所以我們要隨時了解這些人的想法，多與他們進行溝通和交流，給予其足夠的空間和時間，讓他們充分發揮自己的各項技能，而不是過分約束這一部分人。
(3)工作熱情高，但能力低的人員。這些人往往會使團隊中的新人，加入到一個新的領域中，由于之前沒有涉及這個領域，因此他們欠缺的是一定的技術經驗，但往往是這些新人有高漲的工作熱情，他們會給整個團隊帶來新的活力，針對這樣的人我們要有足夠的耐心來引導他們，并且我們要為其提供相關的理論經驗，同時我們也要給予他們相應的支持和鼓勵。
(4)能力較高，工作熱情也較高的人員。對于這樣的優秀人才應該采用授權時的跟進方式，項目負責人要適當地給予其一定的決策權和管理權，在一些重要的環節上對其進行監督。
5 軟件項目的溝通管理
如果缺乏團隊中人員以及團隊人員與用戶的有效溝通一些有利于的項目信息不能充分有效的溝通。計劃實施和問題反饋的結果無法及時傳遞，與其他相關人員之間沒有有效的溝通習慣，就是依照自己的方式進行工作，造成不必要的損失，嚴重影響工作效率。
因此我們在進行軟件系統開發的過程中要有效地進行溝通。項目溝通管理是成功實現項目的關鍵因素，即人、想法和信息之間提供了一個關鍵的連接。在進行民族文化信息資源服務網(飲食)的過程中，通過制度規定將收到的消息傳遞下去，因為信息溝通所造成的損失必須追究責任，監督有效的溝通，使用郵件進行傳遞，以確保信息準確及時傳達到位。
6 實施階段
通過對人力和其他資源的協調，執行已經做出的計劃，通過業務人員提供的各項資料和信息，以及所有工作人員的交流溝通，程序員著手進行系統的相關設計以及數據庫的建立。該系統分為飲食信息錄入平臺和飲食信息展示平臺。
(1)飲食信息錄入平臺：錄入標題，錄入圖片，錄入所屬民族，錄入飲食的詳細描述。
(2)飲食信息展示平臺：通過將上述信息錄入后，在前臺通過讀取數據庫中的信息將飲食信息進行有效地展示。
7 測試階段
軟件測試管理是在軟件實際開發中的不可或缺的重要環節。由于軟件項目在實際開發和應用中不可避免地存在差錯，所以企業必須在軟件產品投入運行之前做好全面的產品測試工作，并在測試管理的過程中盡可能多地發現軟件項目中存在的問題，從而有效降低軟件產品運行中故障的發生概率。軟件產品的測試管理作為保證軟件質量的重要環節，也是對企業軟件產品規格說明或者是編碼與設計的最后檢測工作。
8 結束語
以上的幾個階段并不是所有的系統開發過程中都需要的，但是沒有質量管理階段也不是說此階段不重要，同時，各個階段之間也不是具有清晰的界限。企業在軟件項目管理的實際開發中注重提高軟件運行的穩定性，能夠直接促進項目管理質量的提升，因此為了有效提升企業的軟件生產力，必須著重提高企業項目管理的能力水平。
第9篇：軟件項目管理范文
of the project management
內容摘要： 隨著信息產業的飛速發展，項目管理對于以應用開發為主的軟件企業是一個行之有效的管理方法，項目管理在軟件開發中的應用日益受到重視。本文主要通過對項目管理在軟件開發中的應用的成因、存在的問題以及相應的解決方案進行了分析和論述。
abstract content : with the development at full speed of the information industry, the project management is an effectual office procedure to the software enterprise relying mainly on application and development, the application in software development of the project management
is paid attention to day by day. this text has been analyzed and described
through the origin cause of formation , existing problem and corresponding
solution of application to the project management in software development
mainly.
關鍵詞：項目管理，軟件開發
key words: project management , software development
如果用兩個字概括當前社會的特點，那就是“變化”，而這種變化在信息產業中體現得尤為突出，技術創新速度越來越快，用戶需求與市場不斷變化，人員流動也大大加快。在這種環境下，企業需要應對的變化以及由此帶來的挑戰大大增加，也給管理帶來了很多問題和挑戰。軟件行業是一個極具挑戰性和創造性的新行業，管理上沒有成熟的經驗可供借鑒。而項目管理應該說對于軟件企業，尤其是那些以應用開發為主的軟件企業，是行之有效的管理方法。因此，項目管理在軟件開發中的應用日益受到重視。
項目管理的兩個問題
1、什么是項目管理？
項目管理是在一定的約束條件下，以高效率地實現項目業主的目標為目
的，以項目經理個人負責制為基礎和以項目為獨立實體進行經濟核算，并按照項目內在的邏輯規律進行有效的計劃、組織、協調、控制的系統管理活動。
2、為什么要有項目管理？
沒有項目管理，項目也有可能成功。但沒有管理的項目，很難保證項目
的利潤空間，對公司來說，虧損的風險就大。所以我們要有項目管理，以保證公司在總體上是盈利的，注意不是每一個項目都要盈利。
另外，有了項目管理，就有了管理改進的基礎，無論剛開始的項目管理多么糟糕，只要有管理，就有了改進的可能性，至于能不能得到改進，以及改進的快慢，則取決于兩個因素：一個是人，特別是各級管理者；另一個是利益。關鍵是“利益”，準確的說是“利益的分配”，在權責利明確的前提下，人才能充分的發揮作用。還需要指出的是“利益”是多元的，這里的多元不僅指利益的具體形式，而且指利益的受眾是多元的，包括客戶方相關人員個人的利益。
3、項目管理的發展與現狀。
今天，項目管理作為一種現代化管理方式在國際上已獲得了廣泛的應用，從最初的國防、航天、建設工程領域，迅速發展到電子、通信、計算機、軟件開發、金融等行業以及政府機關的項目管理工作。隨著計算機、網絡系統的迅速發展，項目管理技術的不斷進步，項目管理軟件產品層出不窮，其功能、特點、應用對象也各不相同。當前，越來越多的企業和組織在內部推廣項目管理的理論方法及管理模式，如果都采用項目管理軟件進行管理，效果就更加明顯，可以節省大量的資源和財富。國外90%以上的項目管理都采用軟件進行，但我國在這方面的應用還不到10%。新世紀項目管理在
項目管理在軟件開發中的應用的成因
隨著信息技術的飛速發展，軟件產品的規模也越來越龐大，個人單打獨斗的作坊式開發方式已經越來越不適應發展的需要。各軟件企業都在積極將軟件項目管理引入開發活動中，對開發實行有效的管理。從概念上講，軟件項目管理是為了使軟件項目能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動。實際上，軟件項目管理的意義不僅僅如此，進行軟件項目管理有利于將開發人員的個人開發能力轉化成企業的開發能力，企業的軟件開發能力越高，表明這個企業的軟件生產越趨向于成熟，企業越能夠穩定發展（即減小開發風險）。同時，隨著軟件開發規模及開發隊伍的逐漸增大，軟件開發不再是向過去那樣一二個開發人員即可解決的事情。迫切需要一種開發規范來規范每個開發人員、測試人員與支持人員的工作，每個項目組成員按約定的規則準時完成自己的工作。同時采用規范化管理，專業分工也可以降低對開發人員的要求，從而降低產品研發成本。
軟件開發是一項復雜的系統工程，牽涉到各方面的因素，實際工作中，經常會出現各種各樣的問題，甚至面臨失敗。如何總結、分析失敗的原因，得出有益的教訓，對一個公司來說，是在今后的項目中取得成功的關鍵。
早在20世紀60年代中期，人們就發現軟件的生產出現了“問題”，主要表現在生產過程不規范，缺乏管理。后來，人們在軟件工程方法學中引入了工程的概念、原理、技術和方法，這種思想在一定程度上解決了軟件生產過程中遇到的問題。但是直至80年代還是沒有提出一套管理軟件開發的通用原則，軟件管理不善的問題依舊在大范圍內存在。
目前的軟件開發正逐步趨向于復雜化、多元化，大多數開發團隊中都會出現同時開發多個版本、開發/維護工作并存、多地點同時開發等情況，給軟件開發管理帶來了前所未有的困難。如果管理不善，必將造成版本混亂，各個開發人員的工作相互交叉、干擾，整個開發團隊的工作在一種無秩序的不良狀況下運行，嚴重影響軟件產品開發的進度和質量。
因此，隨著軟件開發的深入、各種技術的不斷創新以及軟件產業的形成，人們越來越意識到軟件過程管理的重要性，管理學的思想逐漸融入軟件開發過程中，應用開發的項目管理日益受到重視。而項目管理技術的發展與計算機技術的發展是密不可分的，隨著計算機性能的迅速提高，大量的項目管理軟件涌現出來。它們可以用于各種商業活動，提供便于操作的圖形界面，幫助用戶制定任務、管理資源、進行成本預算、跟蹤項目進度等。
軟件項目管理常見問題及解決方案
對于軟件開發項目中，經常出現兩種極端情況，一種是創造了新的生產率和質量的紀錄；一種則完全是一場災難，不是被取消就是拖延很長時間。前者如在很短的時間內，為了趕進度，在幾乎不可能的時間內開發出一套軟件產品，創造了軟件開發的記錄，滿足了上級所要求的上機日期，由于開發時間太短，過于倉促，上機時，問題百出，試運行時間長達幾個月或一年半載的，而且程序一改再改，維護工作量大。
后者，如某套系統未弄清楚需求，或因設計問題，開發失敗。通過提煉這些成功和失敗的例子，軟件項目成功或失敗的根本原因可能會更清晰一些。
目前我國大部分軟件公司，無論是產品型公司還是項目型公司，都沒有形成適合自己公司特點的軟件開發管理模式，雖然有些公司根據軟件工程理論建立了一些軟件開發管理規范，但并沒有從根本上解決軟件開發的質量控制問題。這樣導致軟件產品質量不穩定，軟件后期的維護、升級出現麻煩，同時最終也會損害用戶的利益。
分析目前項目管理需要改進的問題可以從幾種相關角色的角度去考慮：項目經理、項目組成員、公司管理人員、市場人員、客戶等。
問題一：缺乏項目管理系統培訓 （相關對象：項目經理、管理人員）
項目經理在項目管理方面的培訓較少或不夠系統。項目經理或管理人員不了解項目管理的知識體系和一些常用工具和方法，所以在實際工作中沒有項目管理知識的指導，完全依靠個人現有的知識技能，管理工作的隨意性、盲目性比較大。在軟件企業中，以前幾乎沒有專門招收項目管理專業的人員來擔任項目經理（甚至很少是管理專業的），被任命的項目經理主要是因為他們能夠在技術上獨當一面，而管理方面特別是項目管理方面的知識比較缺乏。
解決方案：項目經理接受系統的項目管理知識培訓是非常必要的，有了專業領域的知識與實踐，再加上項目管理知識與實踐和一般管理的知識和經驗的有機結合，必能大大提高項目經理的項目管理水平。應實行項目經理知識技能資格考核制度，讓項目經理自覺補充學習項目管理的知識和一些常用工具和方法。
問題二：項目計劃意識問題 （相關對象：項目經理）
項目經理對總體計劃、階段計劃的作用認識不足。項目經理認為計劃不如變化快，項目中也有很多不確定的因素，做計劃是走過場，因此制定總體計劃時比較隨意，不少事情沒有仔細考慮；階段計劃因工作忙等理由經常拖延，造成計劃與控制管理脫節，無法進行有效的進度控制管理。沒有計劃或者是隨意的不負責任的計劃的項目是一種無法控制的項目。
解決方案：在高技術行業，日新月異是主要特點，因此計劃的制定需要在一定條件的限制和假設之下采用漸近明細的方式進行不斷完善。提高項目經理的計劃意識，采用項目計劃制定相關各種知識、技術、工具，加強對開發計劃、階段計劃的有效性進行事前事后的評估。
問題三、管理意識問題 （相關對象：項目經理）
部分項目經理沒有意識到自己項目經理的角色，從總體上去把握管理整個項目，而是埋頭于具體的技術工作，造成項目組成員之間忙的忙、閑的閑，計劃不周、任務不均、資源浪費。 在軟件企業中，項目經理大多是技術骨干，技術方面的知識比較深厚，但無論是項目管理知識，還是項目管理必備的技能、項目管理必備的素質都有待補充和提高，項目管理經驗也有待豐富。有些項目經理對于一些不服管理的技術人員，沒有較好的管理方法，工作不好安排的工作只好自己做。另外由于工作分解結構設計的合理性，項目任務無法有效、合理地分配給相關成員，以達到“負載均衡”。
解決方案：加強項目管理方面的培訓，并通過對考核指標的合理設定和宣傳引導項目經理更好地做好項目管理工作。技術骨干在擔任項目經理之前，最好能經過系統的項目管理知識，特別是其中的人力資源管理、溝通管理的學習，并且在實際工作中不斷提高自己的管理素質，豐富項目管理經驗，提高項目管理意識。
問題四：溝通意識問題 （相關人員：項目經理、項目組成員）
在項目中一些重要信息沒有進行充分和有效的溝通。在制定計劃、意見反饋、情況通報、技術問題或成果等方面與相關人員的溝通不足，造成各做各事、重復勞動，甚至造成不必要的損失；有些人沒有每天定時收郵件的習慣，以至于無法及時接收最新的信息。
解決方案：制定有效的溝通制度和溝通機制，對由于缺乏溝通而造成的事件進行通報作為教訓提醒，以提高溝通意識；溝通方式應根據內容而多樣化，講究有效率的溝通；通過制度規定對由于未及時收取郵件而造成損失的責任歸屬；對于特別重要的內容要采用多種方式進行有效溝通以確保傳達到位，例如除發送郵件外還要電話提醒、回執等，重要的內容還要通過舉行各種會議進行傳達。
問題五：風險管理意識問題 （相關人員：項目經理）
項目經理沒有充分分析可能的風險，對付風險的策略考慮比較簡單。項目經理在做項目規劃時常常沒有做專門的風險管理計劃文檔，而是合并在項目計劃書中。有些項目經理沒有充分意識到風險管理的重要性，對計劃書中風險管理的章節簡單應付了事，隨便列出幾個風險，隨便地寫一些簡單的對策，對于后面的風險防范起不到什么指導作用。
解決方案：通過學習項目管理知識掌握風險識別、量化、對策研究、反應控制的工具和方法掌握項目風險管理所必備的知識。通過加強對項目規劃中風險管理計劃的審核提高項目組的風險管理意識。總結本行業項目中常見的風險及其對策作為風險管理計劃中必要的風險內容，并切實評估相應對策的有效性和可行性。
問題六：不重視項目經驗的總結 （相關人員：項目經理、管理人員）
項目經理在項目結束時有些是因為自身對寫文檔工作的興趣或意識，或
者是因為緊接著要參加下一個項目，總體對項目總結的重視程度不夠。有些是項目總結報告一再拖延，有些是交上來的報告質量較低，敷衍了事。
解決方案：在制度上鼓勵和加強項目經驗總結工作，使得項目總結及時并且具有指導意義而不是走過場。
問題七：項目干系人相關問題（相關人員：項目經理、項目成員、客戶）
在范圍識別階段，項目組對客戶的整體組織結構、有關人員及其關系、
工作職責等沒有足夠了解以致于無法得到完整需求或最終經權威用戶代表確認的需求。由于項目經理的工作問題，客戶參與程度部不高，客戶方相關責任人不明確或對范圍和要求責任心不強，提出的要求具有隨意性，項目前期對需求的確認不夠積極；或者是多個用戶代表各說各話、昨是今非但同時又要求項目盡早交付；項目后期需求變化隨意，造成項目范圍的蔓延，進度的拖延，成本的擴大。
解決方案：項目的目的就是實現項目干系人的需求和愿望。項目干系人管理應當從項目的啟動開始，項目經理及其項目成員就要分清項目干系人包含哪些人和組織，通過溝通協調對他們施加影響，驅動他們對項目的支持，調查并明確他們的需求和愿望，減小其對項目的阻力，以確保項目獲得成功。
問題八：項目團隊內分工協作問題 （相關人員：項目經理、項目成員）
項目團隊內部有時由于各階段不同角色或同階段不同角色之間的責任
分工不夠清晰而造成工作互相推諉、責任互相推卸的現象，有時各階段不同角色或同階段不同角色之間的責任分工比較清晰但是各項目成員只顧完成自己那部分任務、不愿意與他人協作。這些現象或多或少地造成了項目團隊內部資源的損耗，從而影響了項目的進展。
解決方案：項目經理應當對項目成員的責任進行合理的分配并清楚地說明，同時應強調不同分工、不同環節的成員應當相互協作，共同完善。
以上對軟件開發項目管理中出現的問題的分析還不夠深入，也無法列舉所有遇到或將遇到的問題，解決方案也要根據實際情況進行調整，希望引起對這些問題更多的思考和改進。
結束語：項目管理雖然沒有非常高深的理論，但要真正實施起來，也絕非易事。對于軟件開發企業而言，這不是一個小的改變，而是一種變革，企業需要為此付出艱苦的努力，宣傳并樹立公司范圍內的項目管理文化十分重要。從而在實踐中鍛煉提高，解決各種各樣的問題，使項目管理工作越做越好。
參考文獻：
吳照云 《管理學原理》 經濟管理出版社
stanley e. portny（寧俊等譯） 《如何做好項目管理》 新經濟工商實務叢書
neal whitten（孫艷春等譯）《管理軟件開發項目》（第二版） 軟件項目管理系列叢書
