軟體市場推廣方案

1. 市場推廣計劃方案

市場銷售方案可不是千篇一律的呀，通過市場調研後做出的方案才叫方案

2. 如何做市場推廣方案

正常的市場推廣方案確實有很多的輔助操作工具，而且相關的市場推廣方案中也是有些里德助手去將市場推廣的方案完成，而且也是非常地方便

3. 急！！軟體推廣方案

我認為通過網路宣傳更好

和網路游戲公司合作

盛大，9YOU等等

4. 市場推廣方案

是啊,哪個有這方面的方案可以大家一起討論一下啊~~~~

5. 請教軟體市場開拓營銷方案

快速見效的推廣方式，做GOOGLE的競價廣告，當天就能看到效果了

麻煩採納，謝謝!

6. 軟體產品，如何快速做好市場營銷

一、做好市場調研
新產品在上市之前，一定要做好市場調研，如果是常規性產品，首先從調研中找到自己的對手，要是沒有競爭對手，就不會有市場的硝煙出來，這樣可能從競爭中更快地得到產品在市場中的份額。其次是從調研中找出屬於新產品的目標群體，而不是消費者對產品的消費市場有多大，因為這不是新產品的主要市場矛盾，沒有目標怎麼開槍呀，所以目標消費群是調研中的重中之重。第三則是需要專家對調研結果進行有效地分析，這是最為關鍵的，要是單獨靠一些數據，憑企業自己的營銷部門或老總的主管想法，那麼可能會釀成新產品上市的決策錯誤，而到最後形成夾生飯的市場局面。

二、把好策劃這一關
產品有了前面兩個前提，才能做產品的市場營銷策劃了，但必須注意一點，企業在對新產品策劃時，最好不用自己下屬的策劃部門，因為這些部門對於企業的內部太了解，容易做出極右的策劃出來，記住一句話，再高明的醫生也不會給自己和家人看病的，不要不捨得花這個錢，先會舍，後才能得。
營銷策劃包括五大部分：廣告策劃、營銷通路策劃、包裝策劃、終端策劃、招商策劃，做好這五個策劃就需要有以下的三個基本思路：
只有做完了以上的策劃內容，那麼你這個產品才是相對來說是比較完善的可以上市的產品，要是其中一項以上的內容沒有徹底解決，那麼新產品上市的夾生飯隱患可能會就此埋下。

三、執行要流程不要制度
前面所有的工作做好了，但要是方案沒有一個好的執行，那麼也會容易在這個環節上出現夾生飯現象。有些營銷部門的營銷領導，喜歡講個性，把企業的營銷策劃方案當兒戲，私下裡會自己搞一套，結果方案的執行力只有五分之一，所以我們要用三個方法來解決：
1、企業要抽出主要有權威的領導來做好方案理解督導工作，領導自己不懂，那麼無法做好方案的整體督導工作，督導的目的是把方案的每一個環節做到正確無誤，而不是把領導的個人思想融入到方案中去，那是大忌。
2、在方案出台後，一定要同時出台一整套的工作執行流程方案，而且要對於流程進行全面的培訓，流程做的越細，其防止新產品形成夾生飯的機率越小。凡是所涉及的執行人員都是要有工作流程的，只要其中有一部分執行人員沒有流程操作，那麼可能就會把整個一鍋粥全壞掉，流程更比制度重要，因為制度是出了事情後才會用制度來糾正這種錯誤行為的，而流程是在工作沒有開始就知道只有規范地去做，才有可能不違反制度，而最後使產品順利上市。
3、搞好制度的有效制約，制度要強調每一個細節，因為制度太粗，一旦犯了錯誤可能連糾正的機會都沒有，只有制度細化，當問題出來時，由於是細化性制度，就不會影響其它工作計劃的實施，把問題消滅在最小的范圍內。

7. app推廣是什麼意思app市場推廣方案怎麼寫

什麼是APP，APP即第三方應用。現在APP市場比較活躍的就是安卓和蘋果的移動應用。
APP推廣，APP推廣即將自己的應用推廣出去。

8. 如何做市場推廣方案

可以使用郵件群發軟體，群發郵件推廣。群發郵件數量大，成本低，使用門檻低，效果可觀。雙翼郵件群發軟體，一天的發送量可以達到一萬封。而且模擬手工一對一的發送，有專門的「宏」可以使得郵件更加的個性化。1.每封郵件都不一樣 2.低速發送,發送量控制 3.斷點重發 4多郵箱發送 5.自動換IP 6.郵件地址管理 7.回復指定郵箱 軟體功能做的很多,支持7天無條件退款。

9. 急需一份軟體的市場計劃書

軟體開發商業計劃書
摘要
本文主要對軟體開發項目計劃書的格式及主要內容的編寫要點進行說明，對一些內容進行了舉例說明。
關鍵詞
項目、計劃書、格式、編寫說明
正文
一、項目計劃書格式
根據《GB8567－88計算機軟體產品開發文件編制指南》中項目開發計劃的要求，結合實際情況調整後的《項目計劃書》內容索引如下
1 引言
1.1 編寫目的
1.2 背景
1.3 定義
1.4 參考資料
1.5 標准、條約和約定
2 項目概述
2.1項目目標
2.2產品目標與范圍
2.3假設與約束
2.4 項目工作范圍
2.5 應交付成果
2.5.1 需完成的軟體
2.5.2 需提交用戶的文檔
2.5.3 須提交內部的文檔
2.5.4 應當提供的服務
2.6 項目開發環境
2.7 項目驗收方式與依據
3 項目團隊組織
3.1 組織結構
3.2 人員分工
3.3 協作與溝通
3.3.1 內部協作
3.3.2 外部溝通
4 實施計劃
4.1 風險評估及對策
4.2 工作流程
4.3 總體進度計劃
4.4 項目監控
4.4.1 質量控制計劃
4.4.2 進度監控計劃
4.4.3 預算監控計劃
4.4.4 配置管理計劃
5 支持條件
5.1 內部支持（可選）
5.2 客戶支持（對項目而言）
5.3 外包（可選）
6 預算（可選）
6.1 人員成本
6.2 設備成本
6.3 其它經費預算
6.4 項目合計經費預算
7 關鍵問題
8專題計劃要點
二、項目計劃書的編寫說明
1 引言
1.1 編寫目的
說明編寫這份項目計劃的目的，並指出預期的讀者。
作用本節是為了說明編制「項目計劃書」亦即本文檔的意圖和希望達到的效果。注意這里的「目的」不是「項目目標」，而是為了說明本文檔的目的與作用。「項目目標」在2.1中說明。
意義使項目成員和項目干係人了解項目開發計劃書的作用、希望達到的效果。開發計劃書的作用一般都是「項目成員以及項目干係人之間的共識與約定，項目生命周期所有活動的行動基礎，以便項目團隊根據本計劃書開展和檢查項目工作。」
例如可以這么寫為了保證項目團隊按時保質地完成項目目標，便於項目團隊成員更好地了解項目情況，使項目工作開展的各個過程合理有序，因此以文件化的形式，把對於在項目生命周期內的工作任務范圍、各項工作的任務分解、項目團隊組織結構、各團隊成員的工作責任、團隊內外溝通協作方式、開發進度、經費預算、項目內外環境條件、風險對策等內容做出的安排以書面的方式，作為項目團隊成員以及項目干係人之間的共識與約定，項目生命周期內的所有項目活動的行動基礎，項目團隊開展和檢查項目工作的依據。
常見的問題把項目本身的「項目目標」誤作編制項目開發計劃的目的。
1.2 背景
主要說明項目的來歷，一些需要項目團隊成員知道的相關情況。主要有以下內容
項目的名稱經過與客戶商定或經過立項手續統一確定的項目名稱，一般與所待開發的軟體系統名稱有較大的關系，如針對「XX系統」開發的項目名稱是「XX系統開發」。
項目的委託單位如果是根據合同進行的軟體開發項目，項目的委託單位就是合同中的甲方；如果是自行研發的軟體產品，項目的委託單位就是本企業。
項目的用戶（單位）軟體或網路的使用單位，可以泛指某個用戶群。注意項目的用戶或單位有時與項目的委託單位是同一個，有時是不一樣的。如海關的報關軟體、稅務的報稅軟體，委託單位是海關或稅務機關，但使用的用戶或單位不僅有海關或稅務機關，還包括需要報關、報稅的企業單位。
項目的任務提出者本企業內部提出需要完成此項目的人員，一般是領導或商務人員；注意項目的任務提出者一般不同於項目的委託單位，前者一般是企業內部的人員。如果是內部開發項目，則兩者的區別在於前者指人，後者指單位。
項目的主要承擔部門有些企業根據行業方向或工作性質的不同把軟體開發分成不同的部門（也有的分為不同事業部）。項目的特點就是其矩陣式組織，一般一個項目的項目成員可能由不同的部門組成，甚至可能由研發部門、開發部門、測試部門、集成部門、服務部門等等其中幾個組成。需要根據項目所涉及的范圍確定本項目的主要承擔部門。
項目建設背景從政治環境上、業務環境上說明項目建設背景，說明項目的大環境、來龍去脈。這有利於項目成員更好地理解項目目標和各項任務。
例句根據《某部關於某建設工作的實施意見》精神，為了保障某建設工作的正常實施，必須加強監督考核，建立督查通報制度，某市某建設工作小組辦公室把此項建設工作實施列入督查的重要內容，及時掌握進度，相關部門建立市某建設工作簡報制度，及時反映全市某建設工作動態。
目前對於某建設工作的工作主要採用計劃部門手工編制年度計劃、建設工作主管部門和建設工作實施單位聯合手動編制進度計劃，某建設工作單位手工上報建設工作進度情況的方式，而全市的建設工作有數百個，加上前期建設工作的數量和今後某市建設發展的趨勢，建設工作的數量將越來越多，原來的工作模式已經越來越無法適應市委市政府的要求。因此，充分利用現代信息化、網際網路的優勢，建立「某市某建設工作信息報送反饋系統」，提高某建設工作信息報送反饋工作效率，提高信息的及時性、減輕各級相關工作人員的勞動強度是非常有必要和緊迫的任務。
軟體系統與其他系統的關系說明與本系統有關的其他系統，說明它們之間的相互依賴關系。這些系統可以是這個系統的基礎性系統（一些數據、環境等必須依靠這個系統才能運行），也可以是以這個系統為基礎的系統，或者是兩者兼而有之的關系、互相依賴的系統。例句本系統中對外部辦公部分如需要各個建設單位報送材料的子系統應當掛在市政府網站。
軟體系統與機構的關系說明軟體系統除了委託單位和使用單位，還與哪些機構組織有關系。例如一些系統需要遵守那些組織的標准、需要通過那些組織機構的測試才能使用等等、是否需要外包或與那些組織機構合作。
1.3 定義
列出為正確理解本計劃書所用到的專門術語的定義、外文縮寫詞的原詞及中文解釋。注意盡量不要對一些業界使用的通用術語進行另外的定義，使它的含義和通用術語的慣用含義不一致。
1.4 參考資料
列出本計劃書中所引用的及相關的文件資料和標準的作者、標題、編號、發表日期和出版單位，必要時說明得到這些文件資料和標準的途徑。本節與下一節的「標准、條約和約定」互為補充，注意「參考資料」未必作為「標准、條約和約定」，因為「參考」的不一定是「必須遵守」的。常用資料如
本項目的合同、標書、上級機關有關通知、經過審批的項目任務書；
屬於本項目的其他已經發表的文件；
本文檔中各處引用的文件、資料，包括所要用到的軟體開發標准。
1.5 標准、條約和約定
列出在本項目開發過程中必須遵守的標准、條約和約定。例如相應的《立項建議書》、《項目任務書》、合同、國家標准、行業標准、上級機關有關通知和實施方案、相應的技術規范等。
「參考資料」一般具有「物質」特性，一般要說明參照了什麼，要說明在哪裡可以獲得；「標准、條約和約定」一般具有「精神」特性，一般是必須遵守的，不說明在哪裡可以獲得。參考資料的內容應該涵蓋「標准、條約和約定」。
2 項目概述
2.1 項目目標
設定項目目標就是把項目要完成的工作用清晰的語言描述出來，讓項目團隊每一個成員都有明確的概念。注意，不要簡單地說成在什麼什麼時間完成開發什麼什麼軟體系統或完成什麼什麼軟體安裝集成任務。注意「要完成一個系統」只是一個凝的目標，它還不夠具體和明確。明確的項目目標應該指出了服務對象，所開發軟體系統最主要的功能和系統本身的比較深層次的社會目的或系統使用後所起到的社會效果。
項目目標應當符合SMART原則
l S Specific 明確的陳述
l M Measurable 可以衡量的結果
l A Attainable 可以達成的目標
l R Realistic 合理的，現實的或者說是能和實際工作相結合
l T Trackable 可以跟蹤的
項目目標可以進行橫向的分解也可以進行縱向的分解♂向分解一般按照系統的功能或按照建設單位的不同業務要求，如分解為第一目標、第二目標等等；縱向的分解一般是指按照階段，如分解為第一階段目標、第二階段目標等等，或近期目標、中期目標、遠期目標等等。階段目標一般應當說明目標實現的較為明確的時間。一般要在說明了總目標的基礎上再說明分解目標，可加上「為實現項目的總目標，必須實現以下三個階段目標••••••」
2.2 產品目標與范圍
根據項目輸入（如合同、立項建議書、項目技術方案、標書等）說明此項目要實現的軟體系統產品的目的與目標及簡要的軟體功能需求。對項目成果（軟體系統）范圍進行准確清晰的界定與說明是軟體開發項目活動開展的基礎和依據。軟體系統產品目標應當從用戶的角度說明開發這一軟體系統是為了解決用戶的那些問題。產品目標如「提高工作信息報送反饋工作效率，更好地進行工作信息報送的檢查監督，提高信息的及時性、匯總統計信息的准確性，減輕各級相關工作人員的勞動強度。」
2.3 假設與約束
對於項目必須遵守的各種約束（時間、人員、預算、設備等）進行說明。這些內容將限制你實現什麼、怎樣實現、什麼時候實現、成本范圍等種種制約條件。
假設是通過努力可以直接解決的問題，而這些問題是一定要解決才能保證項目按計劃完成。如「系統分析員必須在3天內到位」或「用戶必須在8月8日前確定對需求文檔進行確認」
約束一般是難以解決的問題，但可以通過其他途徑迴避或彌補、取捨，如人力資源的約束限制，就必須犧牲進度或質量等等。
假設與約束是針對比較明確會出現的情況，如果問題的出現具有不確定性，則應該在風險分析中列出，分析其出現的可能性（概率）、造成的影響、應當採取的相應措施。
2.4 項目工作范圍
說明為實現項目的目標需要進行那些工作。在必要時，可描述與合作單位和用戶的工作分工。
注意產品范圍與項目工作范圍的不同含義。
產品范圍界定軟體系統產品本身范圍的特徵和功能范圍。
工作范圍界定為了能夠按時保質交付一個有特殊的特徵和功能的軟體系統產品所要完成的那些工作任務。
產品范圍的完成情況是參照客戶的需求來衡量的，而項目范圍的完成情況則是參照計劃來檢驗的。這兩個范圍管理模型間必須要有較好的統一性，以確保項目的具體工作成果，能按特定的產品要求准時交付。
2.5 應交付成果
2.5.1 需完成的軟體
列出需要完成的程序的名稱、所用的編程語言及存儲程序的媒體形式。其中軟體對象可能包括源程序、資料庫對象創建語句、可執行程序、支撐系統的資料庫數據、配置文件、第三方模塊、界面文件、界面原稿文件、聲音文件、安裝軟體、安裝軟體源程序文件等等。
2.5.2 需提交用戶的文檔
列出需要移交給用戶的每種文檔的名稱、內容要點及存儲形式，如需求規格說明書、幫助手冊等。此處需要移交用戶的文檔可參考合同中的規定。
2.5.3 須提交內部的文檔
可根據《GB8567-88計算機軟體產品開發文件編制指南》附錄O「文件編制實施規定的實例（參考件）」結合各企業實際情況調整制定《軟體開發文檔編制裁減衡量因素表》。根據《因素表》確定項目對應的項目衡量因素取值，以確定本項目應完成的階段成果。將不適用於本項目的內容裁減，以減少不必要的項目任務和資源。
根據因素取值列出本項目應完成的階段成果，說明本項目取值所在的區間，將其他因素值區間刪除。
2.5.4 應當提供的服務
根據合同或某重點建設工作需要，列出將向用戶或委託單位提供的各種服務，例如培訓、安裝、維護和運行支持等。具體的工作計劃如需要編制現場安裝作業指導書、培訓計劃等，應當在本計劃「4.3總體進度計劃」中條列出。
2.6 項目開發環境
說明開發本軟體項目所需要的軟硬體環境和版本、如操作系統、開發工具、資料庫系統、配置管理工具、網路環境。環境可能不止一種，如開發工具可能需要針對Java的，也需要針對C++的。有些環境可能無法確定，需要在需求分析完成或設計完成後才能確定所需要的環境。
2.7 項目驗收方式與依據
說明項目內部驗收和用戶驗收的方式，如驗收包括交付前驗收、交付後驗收、試運行（初步）驗收、最終驗收、第三方驗收、專家參與驗收等等。項目驗收依據主要有標書、合同、相關標准、項目文檔（最主要是需求規格說明書）。
3 項目團隊組織
3.1 組織結構
說明項目團隊的組織結構。項目的組織結構可以從所需角色和項目成員兩個方面描述。所需角色主要說明為了完成本項目任務，項目團隊需要哪些角色構成，如項目經理、計劃經理、系統分析員（或小組）、構架設計師、設計組、程序組、測試組等等。組織結構可以用圖形來表示，可以採用樹形圖，也可以採用矩陣式圖形，同時說明團隊成員來自於哪個部門。除了圖形外，可以用文字簡要說明各個角色應有的技術水平。
注意雖然有一些通用的結構可以套用，但各種不同規模、不同形式的項目組織結構是不一樣的。如產品研發項目可能就不需要實施人員（小組），但需要知識轉移方面的人員（小組）。而軟體編碼外包的項目則不需要程序員，測試人員也可以適當地減少。
3.2 人員分工
確定項目團隊的的每個成員屬於組織結構中的什麼角色，他們的技術水平、項目中的分工與配置，可以用列表方式說明，具體編制時按照項目實際組織結構編寫。以下是一個示例。

3.3 協作與溝通
項目的溝通與協作首先應當確定協作與溝通的對象，就是與誰協作、溝通。溝通對象應該包括所有項目干係人，而項目干係人包括了所有項目團隊成員、項目介面人員、項目團隊外部相關人員等等。
其次應當確定協作模式與溝通方式。溝通方式如會議、使用電話、QQ、內部郵件、外部郵件、QuickPlace、聊天室等等。其中郵件溝通應當說明主送人、抄送人，聊天室溝通方式應當約定時間周期。而協作模式主要說明在出現什麼狀況的時候各個角色應當（主動）採取什麼措施，包括溝通，如何互相配合來共同完成某項任務。定期的溝通一般要包括項目階段報告、項目階段計劃、階段會議等
3.3.1 項目團隊內部協作
本節說明在項目開發過程中項目團隊內部的協作模式和溝通方式、頻次、溝通成果記錄辦法等內容。
3.3.2 項目介面人員
應當說明介面工作的人員即他們的職責、聯系方式、溝通方式、協作模式，包括
a、負責本項目同用戶的介面人員；
b、負責本項目同本企業各管理機構，如計劃管理部門、合同管理部門、采購部門、質量管理部門、財務部門等的介面人員；
c、負責本項目同分包方的介面人員。
3.3.3 項目團隊外部溝通與協作模式
項目團隊外部包括企業內部管理協助部門、項目委託單位、客戶等等。本節說明在項目開發過程中項目團隊內部與介面人員、客戶溝通的方式、頻次、溝通成果記錄辦法等內容。明確最終用戶、直接用戶及其所在本企業／部門名稱和聯系電話。明確協作開發的有關部門的名稱、經理姓名、承擔的工作內容以及工作實施責任人的姓名、聯系電話。確定有關的合作單位的名稱、負責人姓名、承擔的工作內容以及實施人的姓名、聯系電話。
4 實施計劃
4.1 風險評估及對策
識別或預估項目進行過程中可能出現的風險。應該分析風險出現的可能性（概率）、造成的影響、根據影響應該採取的對策，採取的措施。風險識別包括識別內在風險及外在風險。內在風險是指項目工作組能加以控制和影響的風險，如人事任免和成本估計等。外在風險指超出項目工作組等控制力和影響力之外的風險，如市場轉向或政府行為等
風險的對策包括避免排除特定危脅往往靠排除危險起源；減緩減少風險事件的預期資金投入來減低風險發生的概率，以及減少風險事件的風險系數；吸納接受一切後果，可以是積極的（如制定預防性計劃來防備風險事件的發生），也可以是消極的（如某些費用超支則接受低於預期的利潤）。
對於軟體開發項目而言，在分析、識別和管理風險上投入足夠的時間和人力可以使項目進展過程更加平穩，提高項目跟蹤和控制的能力，由於在問題發生之前已經做了周密計劃，因而對項目的成功產生更加充分的信心。
軟體開發項目常見預估的風險
1) 工程／規模／進度上的風險
規模大，規模估算不精確甚至誤差很大；就規模而言，用戶要求交付期、費用很緊；預料外的工作(測試未完時的現場對應等)；
2) 技術上的風險
使用新的開發技術、新設備等，或是新的應用組合，沒有經驗；是新的行業或業務，沒有經驗；性能上的要求很嚴；
3) 用戶體制上的問題
用戶管理不嚴，恐怕功能決定、驗收不能順利地完成（或者出現了延遲）；或者恐怕功能會多次變更；與用戶分擔開發，恐怕工程會拖延（或者出現了延遲）；用戶或其他相關單位承擔的工作有可能延誤；
4) 其它應該包含此處沒有、但據推測有風險的項目。
4.2 工作流程
說明項目採用什麼樣的工作流程進行。如瀑布法工作流程，原型法工作流程、螺旋型工作流程、迭代法工作流程，也可以是自己創建的工作流程。不同的流程將影響後面的工作計劃的制定。必要時畫出本項目採用的工作流程圖及適當的文字說明。
4.3 總體進度計劃
這里所說的總體進度計劃為高層計劃。作為補充，應當分階段制定項目的階段計劃，這些階段計劃不在這份文檔中，當要以這份總體計劃為依據。
總體進度計劃要依據確定的項目規模，列表項目階段劃分、階段進度安排及每階段應提交的階段成果，在階段時間安排中要考慮項目階段成果完成、提交評審、修改的時間。
對於項目計劃、項目准備、需求調研、需求分析、構架設計或概要設計、編碼實現、測試、移交、內部培訓、用戶培訓、安裝部署、試運行、驗收等工作，給出每項工作任務的預定開始日期、完成日期及所需的資源，規定各項工作任務完成的先後順序以及表徵每項工作任務完成的標志性事件（里程碑）。
例如

`

需求評審

設計評審
表格中檢查點／里程碑等階段劃分為舉例，實際作業階段劃分、階段成果等請根據項目需要確定。
制定軟體項目進度計劃可以使用一些專門的工具，最常用的是Microsoft的Project作為輔助工具，功能比較強大，比較適合於規模較大的項目，但無法完全代替項目計劃書，特別是一些主要由文字來說明的部分。小規模的項目可簡便地使用EXCEL作為輔助工具。關於如何使用這些工具不在此作詳細說明。
制定軟體項目進度計劃應當考慮以下一些因素:
1）對於系統需求和項目目標的掌握程度。如開始時對於系統需求和項目目標只有比較數的了解，就只能制定出比較粗的進度計劃，等到需求階段或設計階段結束，就應該進一步細化進度計劃。
2）軟體系統規耐項目規模，這兩個不是一個概念。軟體系統規模往往是從功能點的估算或其他估算方式得來的，而項目規模還要考慮對文檔數量與質量的要求，使用的開發工具、新技術、多少復用、溝通的方便程度、客戶方的情況、需要遵守的標准規范等等等等。例如，完成一個大型的系統，在一定的時間內一個人或幾個人的智力和體力是承受不了的。由於軟體是邏輯、智力產品，盲目增加軟體開發人員並不能成比例地提高軟體開發能力。相反，隨著人員數量的增加，人員的組織、協調、通信、培訓和管理方面的問題將更為嚴重。
3）軟體系統復雜程度和項目復雜程度和軟體系統規耐項目規模一樣，軟體系統的復雜程度主要是考慮軟體系統本身的功能、架構的復雜程度，而項目的復雜程度主要是指項目團隊成員的構成、項目任務的復雜程度、項目干係人的復雜程度、需求調研的難易程度，多項目情況下資源保障的情況，等等等等。軟體系統的規模與軟體系統的復雜程度未必是成比例的關系；同樣項目的規模與項目的復雜程度未必是成比例的關系。
4）項目的工期要求，就是項目的緊急程度。有些項目規模大，卻因為與顧客簽訂了合同，或者為了搶先佔領市場，工期壓縮得很緊，這時就要考慮如何更好地合理安排進度，多增加人選多採用加班的方式是一種萬不得已的選擇。增加人選除了增加人的成本外必定會增加溝通的成本（熟悉項目任務所需要的時間）；加班如果處理不好會造成情緒上的問題，也可能會因為過於忙碌而無法顧及質量，造成質量的下滑。
5）項目成員的能力。這些能力包括項目經理的管理能力，系統分析員的分析能力、系統設計人員的設計能力、程序員的編碼能力、測試人員的測試能力，以及企業或項目團隊激發出這些能力的能力。從另外一個角度看還有總體上對客戶行業業務的熟悉程度；對於建模工具、開發工具、測試工具等技術的掌握程度；企業內部對行業業務知識和主要技術的知識積累。
4.4 項目控制計劃
4.4.1 質量保證計劃
執行質量評審活動，對過程質量進行控制。規模較大的項目應當單獨編寫《軟體開發項目質量計劃》。根據GB/T 12504 計算機軟體質量保證計劃規范，內容包括
l 引言（本章節包括質量計劃的目的、定義、參考資料）
l 管理（描述負責軟體質量管理的機構、任務及其相關的職責）
l 文檔（列出在該軟體的開發、驗證與確認以及使用與維護等階段中需要編制的文檔，並描述對文檔進行評審與檢查的准則）
l 標准、條例和約定（列出軟體開發過程中要用到的標准、條例和約定，並列出監督和保證執行的措施）
l 評審和檢查（規定所要進行的技術和管理兩個方面的評審和檢查工作，並編制或引用有關的評審和檢查規程，以及通過與否的技術准則。至少要進行軟體需求評審、概要設計評審、軟體驗證與確認評審、軟體系統功能檢查、程序和文檔物理檢查）
l 軟體配置管理（編制有關配置管理條款，或在「4.4.4 配置管理計劃」中說明，或引用按照《GB/T 12505 計算機軟體配置管理計劃規范》單獨制定的文檔）
l 工具、技術和方法（指明用於支持特定軟體項目質量管理工作的工具、技術和方法，指出它們的目的和用途）
l 媒體控制（說明保護計算機程序物理媒體的方法和設施，以免非法存取、意外損壞或自然老化）
l 對供貨單位的控制（供貨單位包括項目承辦單位、軟體銷售單位、軟體開發單位。規定對這些供貨單位進行控制的規程，從而保證項目承辦單位從軟體銷售單位購買的、其他開發單位開發的或從開發單位現存軟體庫中選用的軟體能滿足規定的需求。）
l 記錄的收集、維護和保存（指明需要保存的軟體質量保證活動的記錄，並指出用於匯總、保護和維護這些記錄的方法和設施，並指明要保存的期限）
4.4.2 進度控制計劃
（可直接引用以下描述或根據項目情況制定本節內容）
本項目的進度監控執行本企業《項目管理規范》，由本企業過程式控制制部門如質量管理部統一進行監控，並保留在監控過程中產生的日常檢查記錄。
4.4.3 預算監控計劃
說明如何檢查項目預算的使用情況。根據項目情況需要制定。
4.4.4 配置管理計劃
編制有關軟體配置管理的條款，或引用按照GB/T 12505單獨制訂《配置管理計劃》文檔。在這些條款或文檔中，必須規定用於標識軟體產品、控制和實現軟體的修改、記錄和報告修改實現的狀態以及評審和檢查配置管理工作等四方面的活動。還必須規定用以維護和存儲軟體受控版本的方法和設施；必須規定對所發現的軟體問題進行報告、追蹤和解決的步驟，並指出實現報告、追蹤和解決軟體問題的機構及其職責。
根據《GB/T 12505 計算機軟體配置管理計劃規范》，軟體配置管理計劃內容如下
l 引言（本章節包括質量計劃的目的、定義、參考資料）
l 管理（描述負責軟體配置管理的機構、任務、職責及其有關的介面控制。）
l 軟體配置管理活動（描述配置標識、配置控制、配置狀態記錄與報告以及配置檢查與評審等到四方面的軟體配置管理活動的需求。）
l 工具、技術和方法（指明為支持特定項目的軟體配置管理所使用的軟體工具、技術和方法，指明它們的目的，並在開發者所有權的范圍內描述其用法）
l 對供貨單位的控制（供貨單位是指軟體銷售單位、軟體開發單位或軟體子開發單位。必須規定對這些供貨單位進行控制的管理規程，從而使從軟體銷售單位購買的、其他開發單位開發的或從開發單位現存軟體庫中選用的軟體能滿足規定的軟體配置管理需求）
l 記錄的收集、維護和保存（指明要保存的軟體配置管理文檔，指明用於匯總、保護和維護這些文檔的方法和設施，並指明要保存的期限）

我給你一個很全面的，你可以參考一下，摘一些對你有用的。希望能幫你到。