前言：
爲優化移動開發技術小組的開發流程及效率，根據當前現狀，制定開發流程規範，以達到明確職責，提高效率的目的。
App項目現狀
1.邏輯細節不明確。
2.UED保真度不高。
3.口述需求後即進入開發環節，導致開發週期顯示較長。
4.App整體滿意度不高。
研發流程現狀
1.邏輯不清晰，無PRD文檔，在研發中耗費較多精力在邏輯討論上，思路總是會被打斷。
2.文案不清晰，無PRD文檔，導致iOS和Android兩端文案展示不統一。
具體現狀：
1.只有原型，無PRD文檔
2.文案和業務、交互邏輯缺失。
3.沒有確認產品文檔最終稿確認時間點。
4.無明確連續2個時間段的迭代計劃。
5.開發中需求變更頻繁，或有新增需求。
3.UED不細緻，標註說明不夠詳細，研發細節差異較大，UED保真度不高。
具體現狀：
1.UED保真度不高。
2.開發過程中需要UED不斷跟進，耗費UED人力。
4.研發內部缺少評審環節，導致邏輯不清晰，不利於團隊維護和技術能力提升。
具體現狀：
1.缺少評審環節，項目安全性和規範性不高。
2.缺少代碼評審，項目邏輯性不夠明確。
3.團隊其他成員不瞭解項目，不利於維護和共享。
5.研發內部缺少交叉自測環節，iOS和Android太過分離，統一性不高，質量不高。
具體現狀：
1.提測後，研發等候時等待測試反饋。
2.提測後，研發內部沒有自檢。
6.沒有總結，無法根據實際情況分析進行改進，團隊效率無法提高。
具體現狀：
1.上線之後，研發並沒有對項目進行總結。
2.上線之後，研發並沒有提出問題點以及相關優化建議，不利於項目長期發展。
7.無明確制定研發流程，職責不明確，流程問題點無法定位，團隊效率無法提高。
具體現狀：
1.無研發流程規範。
2.其他團隊成員不知悉項目開發流程。
依據以上現狀，現移動端技術管理中心制定App研發流程，請項目所有涉及人員遵守支持，以達到互不推脫，明確職責，互相監督、互相促進，共同提高團隊效率。
App正常規範流程圖
App研發正常流程規範
- 產品評審
產品負責人發起會議
1.評審時間
產品迭代前，產品負責人把控具體時機
2.參與人員
產品、各端研發負責人、設計相關負責人
3.評審內容
1）要求產品人員需求評審前必備：原型，PRD文檔。
2）要求PRD文檔：文案、邏輯註明明確。
4.評審會輸出
1）輸出評審最終稿，文案和邏輯註明明確，產品研發同時能夠理解和知曉。
2）設計評估出相應的設計工作時長。
注：
1）開發需求中若變更以及新增需求，需重新評審以及評估延期時間。（研發也以此考覈產品人員，並記錄反饋，分析優化。）
2）輸出評審時長和評審次數，以此來評定PRD文檔輸出的細緻性。
3）明確產品PRD文檔輸出時間點
2. UED
1. 內部流程
用戶研究 -> 交互設計 -> 視覺設計 -> 產品確認
2. 參與人員
產品、UED相關人員
3. 開始設計
4.輸出
1）交互設計方案和說明。
2）視覺設計方案、標註、切圖。
3.需求講解
產品負責人發起
1.發起時間
迭代上線後的某天。
2. 參與人員
項目所有人
3.講解內容
1）原型、PRD文檔
2）交互設計說明和方案
3）視覺設計方案、標註和切圖
4.產品研發
1.接口評審
1）根據需求和設計圖，要求的相關接口信息。
2）根據優先級，討論好主要接口的約定字段，並錄入femock。
3）研發相關人員參加
2.研發概要設計
1）開發前必須經過團隊設計思想、開發思路評審。
2）在開發起始節點的第一天發起。
3）各端負責人發起，全員參加。
4）輸出：設計評審文檔以及邏輯流程圖。
3.編碼實現
4.代碼審覈
1）參考設計評審的思路，進行代碼校驗。
2）各端負責人發起，全員參加。
5.產品測試。
1）iOS與android位置互換，交叉測試，保證雙方開發功能點的統一性。
2）bug修改。
3）測試進行全面測試。
6.產品上線
1.上線郵件
1）註明需求講解的時間結點。
2）註明研發時長。
3）註明測試時長。
4）註明Bug數。
5）註明本期干擾正常開發的問題點。
6）註明本期項目重構優化的功能以及優越性。
7.定期上線總結會。
有產品定期發起會議總結
1）軟件的反饋和運營狀況。
2）當前的發展防線。
3）迭代過程的問題總結。
4）問題避免和改進。
以上是移動端技術管理中心暫定的流程規範，在實施過程中，根據具體的實施流程以及發現的問題，經討論後可隨時做優化改進。規範的流程和高效的團隊合作，離不開大家的大力支持。請大家多多參與並給出寶貴建議。
App研發特批流程規範
因特殊原因，基於現有需求直接指定上線時間的項目，採取反推方式。
1）瞭解需求背景粗略評估測試時間
2）研發粗略評估研發時間
3）ued粗略評估時間
4）剩餘時間產品快速規劃、制定原型、需求講解
注：評估時間佔比 測試30%以內 研發40%以內 ued20%以內 產品10%左右
FAQ
- 誰負責研發流程的時間、節奏把控？
答：產品負責人。產品負責人把需求規劃的越早，產品評審提前的越早，越有利於所有人員的充分利用。
例：按照流程執行的前提，如果產品評審在開發上線後進行，則評審和UED時間將會使研發人員和測試人員時間安排不飽和。同時，迭代上線週期過長。
通過預估UED時間，提早安排評審，進行設計，在開發上線後的接着進行需求講解，會達到所有人員的工作最大飽和度。同時縮短整個迭代的上線時間。 - 需求講解後，開發人員以什麼爲標準去開發？
答：文案、邏輯、頁面跳轉，以PRD文檔爲準。
UI、交互體驗以交互方案、設計標註爲準。
交互、設計標註需在UED階段，有產品確認，並有產品保證原型和UED的統一性。 - 開發過程中，產品需求發生變更，如何解決？
答：如果產品需求發生變更，則根據變更內容進行預估，如果半天內能解決的，加入本次開發進行變更。
如果需1天以上解決的，則根據安排，決定是否延遲上線時間或將需求推遲下期上線進行安排。
變更需更新PRD文檔，給出變更原因和變更記錄，根據變更內容決定口頭下發還是開會下發給研發、測試人員。 - 不同部門提出的需求，誰負責下發？
答：如設計部門，運營部門提出需求後，需統一由產品整理，再反饋到相應部門做確認，再有產品按流程進行下發。 - 需求講解流程是什麼？
答：第一步：說明需求背景，爲什麼做該需求。
第二步：說明需求實現，該需求如何做。。
第三步：如果需求實現沒有整理清晰，需說明並告知先做成什麼程度。
第四步：說明需求未來的可能性改動。 - 需求講解的時機？
答：講解時機：上午或下班後。
講解前準備：需提前一天發出郵件說明PRD和設計稿給所有人，供提前預習，以便講解時及時做反饋。 - PRD文檔中，研發需要產品做什麼？
答：1.註明功能邏輯，條件判斷。
2.發起頁面展示的來源、返回到哪個頁面等交互。
3.給出網絡提示異常文案，不符合條件的異常文案，空數據展示文案，頁面默認展示文案等。 - App需求概要設計，都設計什麼？
答：1. 概要設計以需求功能點劃分，具體分爲頁面+邏輯。
2. 頁面的組成方式。
3. 邏輯的實現過程和判斷邏輯，以及頁面間傳輸數據約定字段，以及異常的處理過程。 - 研發需求如何加入產品需求？
答：1.建立研發內部優化需求池。
2.研發期間內部安排時間計劃。
3.研發、測試期間，建立代碼分支進行優化，優化完成並自測後，提到下期產品需求中，方便測試。 - 何時給出評估具體時間。
答：概要設計後，根據概要實際內容進行評估。 - 何時講解Checklist？
答：上午或者下班後。