前言
剛剛做完乙個專案，值得總結，在此記錄一下。
歡迎加入學習小組qq群:156958554。
一款應用的開發大體流程如下：
1、專案立項：產品經理
2、需求確認：產品經理(業務邏輯說明文件)
3、業務確認：產品經理，技術經理，架構師
4、業務架構：技術經理，架構師（業務流程文件）
5、ui確認：產品經理，設計人員，開發人員全體
6、ui互動確認：產品經理，移動端，前段開發人員
7、介面確認：架構師，介面開發人員，移動端、前端開發人員
8.1、ui工**估：產品經理，設計人員
8.2、介面工**估：架構師，介面開發人員
8.3、移動端、前端工**估：相關開發人員，技術經理
9、工時確認：產品經理，技術經理，設計人員
10、專案開發
11、測試用例及流程設計：產品經理、測試組
12、測試用例及流程確認：產品經理、開發人員，測試組
13、測試及debug：產品經理，測試組，開發
14、產品定版，release
文件管理：svn伺服器管理
1、需求文件：需求列表，業務說明文件
2、ui互動文件：互動稿（互動細節）
3、技術文件：業務邏輯的技術實現流程（技術流程文件：異常處理）
4、介面文件：資料格式（統一大小寫，編碼格式，浮點型精度，使用long型別表示浮點資料），通訊協議，資料結構
5、設計文件：效果圖，切圖，標註圖
6、**：**更新和共同維護
7、上線資料
8、測試用例
流程管理：
1、需求變更：原則上可以中前期增加需求；原則上不允許頻繁變更需求；原則上不允許修改業務邏輯。需求變更必須經過產品經理、技術經理共同確認後才可變更。
2、業務邏輯變更：原則上不允許更改業務邏輯。
3、技術邏輯變更：架構師，介面開發人員，移動端開發人員共同確認
4、測試流程變更：產品經理確認
開發管理：
1、開發人員：明確需求和業務、互動邏輯。開發以需求和業務邏輯為準。
2、發現業務缺陷：需與產品經理，技術經理匯報。如要變更業務邏輯：必須重新評估開發工時和工期。
3、如沒有明確要求，ui在細節和使用習慣上，請盡量遵守各自系統的設計規範。
4、協同開發：需分工明確，工作量盡量均衡。分工應報與技術經理知曉。
5、變更需求，開發人員需向技術經理確認。
6、當前的bug,當日盡量解決。
7、優化性、新需求性bug：請分發產品經理。
8、優化性、新需求性修改：請知會其他平台開發人員。
9、週報：本週開發內容；本週技術點總結；自評開發中最好的地方；遇到的問題；下週計畫。
測試：mantis bug tracker管理bug
1、新需求性bug：提交產品經理，產品經理作為新需求提出，不分發bug。
2、優化型bug：提交產品經理，產品經理作為新需求提出，不分發bug。
3、開發bug：提交開發人員。
注：1、明確bug等級，非業務性bug、非嚴重缺陷bug、非崩潰性bug謹慎提交為嚴重缺陷等級。
2、重點把握測試流程，明確測試方向：前期重點為功能性測試，業務邏輯測試。中後期加入互動性測試。
3、謹慎使用邊開發邊測試的開發測試流程：這種模式下，請明確測試重點（開發完畢前側重功能性、業務性測試）
4、開發沒有結束前的測試：測試人員禁止頻繁交涉開發人員，所有bug只需提交伺服器。
5、測試人員發起的需求性、優化性bug，請提交產品經理，產品經理請嚴格遵守需求變更流程。
上線：
1、測試發布測試完結，產品達到上線要求報告。
2、技術經理發布上線申請。
3、產品經理確認可以上線，發布上線請求。
4、上線人員release應用到各個渠道，上線後郵件知會相關人員產品上線情況。
1、產品經理：新需求追加列表，優化性需求追加列表。
2、設計人員：改版明細
3、開發人員：改版明細，開發模組，**量及技術點總結報告。
4、測試報告，測試資料統計。
5、專案總結報告
情緒管理在專案開發中尤其是高壓快節奏的開發中很重要但也很容易被忽略。一旦產生了情緒，對專案的推進和溝通必然存在影響。
其實，開發人員希望自己能夠開發出具有良好使用者體驗和易擴充套件的應用；測試人員希望盡可能多的測出bug，盡可能的優化使用者體驗；產品經理希望自己的產品能夠盡量的功能完善，體驗最佳；管理人員希望我們的軟體能夠盡可能的穩定、健壯。
單獨來看，大家的意願和目標都是好的，高度一致的，那為什麼還會產生情緒，進而發生執行困難呢？
經過思考，總結出大體以下幾點：
1、初期業務沒有思慮清晰、周全，導致中後期業務邏輯發生改變。
2、業務邏輯的改變，導致ui互動邏輯的改變。
3、業務和互動邏輯（流程）缺乏有效、明確的文件，導致開發人員、產品對業務的理解各自出現偏差，這種偏差發現的越晚，矛盾就會越大。
4、研發人員技術崇拜，又或者軟體上的設計方案和各平台本身的設計規範衝突，導致開發人員的開發意願和產品經理的設計意願衝突。
5、高強度工作等導致的生理性反應。
6、不同平台的開發者之間，對一些細節或需求變更沒有相互通知，造成相互挖坑的被坑情緒。
7、加入存在邊開發邊測試的情況，測試人員頻繁的交涉技術人員，會導致開發流程中斷，在開發階段為開發人員產生非功能性、業務邏輯性的bug,導致開發人員可測試人員各自的情緒波動。
8、產品失敗，努力白流，付出無法得到認可導致的情緒。
以上幾點，基本可以涵蓋主要的影響整個產品涉及人員的情緒波動的原因。
那麼，該如何盡量的減少負面的情緒波動呢？
1、產品在立項和需求確認階段，要充分的討論和思考整個業務邏輯，盡量達到少更改或不更改需求。
2、業務邏輯和互動邏輯，要形成明確細緻的流程性文件，避免出現需求不明確和業務理解偏差。
3、在開發階段，產品與測試人員儘量減少交涉，有問題盡量通過技術經理溝通傳達。
4、在產品開發階段，如果要進行並行測試，盡量合理規劃測試流程，明確測試重點。
5、整個產品週期中，遇到任何問題，需要主動溝通。
6、開發啟動前，明確專案的管理流程，開發中盡量嚴格按照管理流程推進。
7、產生負面情緒，要學會調節和溝通釋放負面情緒，歸根結底，大家的目標都是一致的。
後記
流程是死的，人是活的，問題是在所難免的。在實際的專案管理中，各自都盡量的把自己的工作在專案早期完善，後面才會更加順利的推進。
如圖所示，一項工作，假如我們在前50%的時間完成了80%工作，那麼最終的結果我們可能會達到90%或100%期望；如果我們在前50%的時間只完成了30%的工作，那麼我們就有很大的風險到最後只達到60%的期望。
App移動端專案管理
目錄 前言 剛剛做完乙個專案，值得總結，在此記錄一下。歡迎加入學習小組qq群 156958554。一款應用的開發大體流程如下 1 專案立項 產品經理 2 需求確認 產品經理 業務邏輯說明文件 3 業務確認 產品經理，技術經理，架構師 4 業務架構 技術經理，架構師 業務流程文件 5 ui確認 產品經...
App移動端專案管理
一款應用的開發大體流程如下 1 專案立項 產品經理 2 需求確認 產品經理 業務邏輯說明文件 3 業務確認 產品經理，技術經理，架構師 4 業務架構 技術經理，架構師 業務流程文件 5 ui確認 產品經理，設計人員，開發人員全體 6 ui互動確認 產品經理，移動端，前段開發人員 7 介面確認 架構師...
App移動端專案管理
一款應用的開發大體流程如下 1 專案立項 產品經理 2 需求確認 產品經理 業務邏輯說明文件 3 業務確認 產品經理，技術經理，架構師 4 業務架構 技術經理，架構師 業務流程文件 5 ui確認 產品經理，設計人員，開發人員全體 6 ui互動確認 產品經理，移動端，前段開發人員 7 介面確認 架構師...