一、專案規劃階段

1.專案瞭解

  瞭解專案性質、專案需求、預期產品的功能、針對的客戶群、專案目的；瞭解客戶和公司對專案的看法、對專案的實際期望，與客戶和公司進行需求分析和技術可行性分析。

2.需求分析   

  針對專案要實現的功能和效能，召開專案需求分析會議，根據專案分析需求、確定需求、整理優先順序，保證專案組核心成員（產品經理、UI、IOS、Android、後臺）必須清晰和統一理解產品需求；展示產品原型，詳細講述產品的核心流程、功能架構、資訊架構，結合使用者使用場景進行闡述，設計出符合使用者習慣的介面和互動風格；開發出符合使用者要求的互動和產品介面；搭建出更好的資料處理後臺。

專案相關文件

序號

文件名稱

1

產品原型文件

2

UI設計圖

3

後臺API文件

4

開發計劃

5

可行性報告

    2.1建立WBS（工作分解結構）

根據產品原型，將需求細化分成工作包，每個工作包完成時間不超過一個工作日，超過的再次分解，直到分解成在一個工作日內完成的工作包；每個專案組成員明確工作包目標、時間和交付，避免出現資源空閒的狀態或者無效的資源投入；明確專案組成員的工作職能和任務。

 專案細化分包：

1.專案經理細化分包；

2.專案組長細化分包，上報給專案經理彙總；

3.專案組成員細化分包，上報給專案經理彙總；

  專案細化分包意義：

    高度細分的工作任務，將極大的提高專案進度估算的準確性，更好的把控專案進度，同時督促未完成的工作及時完成，增加開發成員的緊迫感。

工作分解結構單位

工作包：

工作包編號：

工作描述：

負責人：

開始時間：

結束時間：

工作期限：

 2.2 繪製專案進度圖

    根據工作包的前置任務和專案週期繪製專案進度圖，依賴性工作包優先，再根據每個工作包週期，計算專案的關鍵路徑，關鍵路徑是專案從開始到結束的耗時最長的一條工作流程，決定了專案的週期。

目的：專案經理從整體更好的把控專案進度；

意義：

1.更加直觀清晰的展現專案進度；

2.重點關注優先順序工作包的完成情況，決定了專案進度；

3.專案如提前完成，優先順序工作包是重中之重。

        如下：

清單

開發

完成

本次

待開發

開發中

測試

迭代

BUG

2.3 繪製專案進度甘特圖

以專案開發任務中要求的日期為準，建立1、按照專案計劃、啟動日期和結束日期； 2、每個階段計劃和實際的開始、結束日期為主的進度甘特圖。

目的：管理專案整體進度；

意義：專案進度甘特圖詳細記錄了每項工作的任務順序和完成情況。專案經理可以實時瞭解專案的進展情況。

3.協同管理

    培養專案組核心人員，協同管理專案進度，負責處理解決專案中遇見的技術問題，專案經理重點負責把控進度和協調工作。

二、執行階段

專案進入開發執行階段以後，專案經理的主要工作將圍繞把控專案進度，協調各組、各部門之間的工作，為專案做好保障工作，確保專案按時交付。對於執行階段的工作，給專案組成員分發專案進度計劃，時刻提醒什麼時間將要完成什麼任務，每天都要關注開發人員的開發進度；及時的發現問題並解決問題，前期問題越多，後期問題越少；在檢查的過程當中，有可能會發現一些還沒發現的問題，或者跟這個任務相關的問題。任務的完成進度和完成質量，是影響專案進展的一個重要因素，專案經理的一個主要職能，就是幫助每個任務的快速推進。

     1.專案晨會

對於專案組晨會，主要議題如：

1. 專案組成員更新前一天完成的進度、用時，如未完成，估算完成需要的時間；

2. 專案組成員更新今天準備完成的任務和目標；

3. 有哪些進度需要其他專案組成員配合；

專案經理將每天晨會資訊記錄並更新到專案進度計劃表內，實時把控專案進展，預測專案是否延期並採取相應措施（如增加專案成員或趕進度）。

注：晨會避免討論問題，只更新狀態，保證在10分鐘內結束，如需討論在晨會結束後單獨溝通，防止浪費專案組其他人員時間。

      2.開發/測試階段

針對APP專案，後臺和APP的互動通過介面（API）來完成，應該讓後臺寫好相應的介面（API）並編寫假資料，方便APP端順利開發。     測試工作，開發設定好里程碑，設定原則不能超過一週，每釋出一個里程碑，就必須完成測試，同時反饋給開發人員，避免週期過長對程式碼的熟悉性降低，修改BUG的效率降低。 一個專案或一個短迭代，應該列出都認同的里程碑列表；里程碑的完成有共同認同的驗證方式。 　　

      3.需求變更

      3.1 分級管理需求（或變更） 

按照需求變更流程管理，專案經理提交正式的變更申請，專案組評審，評審通過後修改產品需求文件和產品原型，進入執行階段。對於專案中的需求，可以實行分級管理，以達到對需求變更的控制和管理。         一級需求（或變更）是關鍵性需求，影響專案的正常交付使用的，定為“緊急（Urgent）”, 屬於補救性的debug型別。       二級需求（或變更）是後續關鍵性需求，不影響前面工作的交付，但不完成新專案內容則無法提交或繼續，屬於“必需（Necessary）”。一般新需求關鍵性的基礎元件，屬於這個級別。       三級需求（或變更）是後續重要的需求，體現專案價值，屬於“需要（Needed）”，重大的有價值的全新需求開發，屬於這個級別。       以上三個等級是應該實施的，作優先順序的排列。       四級需求（或變更）是改良性需求，不完成也不影響已有功能的使用的，完成對功能更好的，屬於“更好（Better）”。一般是介面和使用方式的需求，如果時間和資源條件都允許的話，可以完成。         五級需求是可選性需求，一般為設想和可能，屬於“也許（Maybe）”，選擇性的完成。 

 3.2需求變更管理         專案可以分為三個階段，即專案啟動、專案實施、專案結束。需求變更的管理和控制貫穿整個專案的全過程。 需求變更管理，需要採用綜合變更控制的方法。

      （1） 專案啟動階段的變更預防         任何軟體專案，都會存在需求變更,這個應對從專案啟動的需求分析階段開始，需求分析文件越詳細清晰，需求變更的機率就越小。

      （2） 專案實施階段的需求變更            專案實施階段的需求變更需要做分析變更請求，評估變更可能帶來的風險和修改文件。         控制需求變更需要注意：       1.需求變更要經過同意並簽字。         2.需求變更要經過需求管理流程。           （3）專案完成階段的總結         專案總結工作應作為專案持續改進工作的一項重要內容，同時可以作為對專案、設計方案與目標的確認和檢驗。包括專案中發生的變更和專案中發生問題的分析統計的總結。  

      3.3 需求變更管理        （1） 建立需求基線。需求基線是需求變更的依據。在開發過程中，需求確定並經過評審後(使用者參與評審)，可以建立第一個需求基線。此後每次變更並經過評審後，都要重新確定新的需求基線。       （2） 制訂變更控制流程，並形成文件。在建立了需求基線後提出的所有變更都必須遵循這個控制流程進行控制。同時，這個流程具有一定的普遍性，對以後的專案開發和其他專案都有借鑑作用。       （3） 成立包括使用者方和開發方決策人員在內的專案決策組，負責裁定需求變更。       （4） 需求變更先申請再評估，最後評審確認。       （5） 需求變更後，受影響的專案內容進行相應的變更，保持和更新的需求一致。       （6） 儲存需求變更的相關文件。 

      4.階段會議

    專案執行階段，每完成一個專案里程碑，由專案經理召開里程碑會議，展示demo，由團隊成員評審是否達到要求。未完成的計入下一階段工作。開發組成員闡述本階段的工作，分析總結經驗教訓，更好的完成專案進度。

三、專案結束

    3.1專案結束階段，做好評估和驗收，寫專案評估驗收報告：

     1.評估投資的回報率，評估實際和計劃費用的差異；

     2.專案進度與計劃時間的一致性；

     3.專案的整體質量，預期達到的效果；

     4.專案控制

     3.2開專案總結會，分析專案成功的主要原因、專案失敗的主要原因，分析整個專案開發中的經驗、教訓，總結處理措施和解決方案，傳承專案優勢，獎懲開發人員；專案經理和開發人員分別寫專案總結報告，做好專案資訊歸檔。

3.3檔案歸檔

專案步驟

檔名稱

專案規劃

專案可行性報告、策劃書等

專案準備

WBS圖、甘特圖、風險計劃、等

專案開發

例會報告、專案會議紀要、需求變更申請表、里程碑記錄表等

專案結束

專案評估驗收報告、專案總結、專案交付等相關文件

3.4專案全部工作完成以後協調部門關係，做好專案的移交、交付工作。 ---------------------  作者：諾古言召  來源：CSDN  原文：https://blog.csdn.net/vc_bin/article/details/54914222  版權宣告：本文為博主原創文章，轉載請附上博文連結！