需求分析、產品設計到部署交付各階段圖解
下面用一張圖來表示產品設計到部署交付階段：
研發流程各環節：
- 需求分析
- 產品設計
- UI設計
- 開發和測試
- 部署交付
團隊劃分
按職能劃分團隊
- 產品團隊
- 後端開發團隊
- UI 設計團隊
- 前端開發團隊
- 運維和測試團隊
- 移動開發團隊
按職能來劃分團隊，每個團隊有一個團隊負責人，比如小組長。
組織結構如下圖：
跨職能團隊
跨職能團隊一般是基於某個產品、專案 或功能特性來組織一個團隊，在這個團隊內，就可以完成需求、開發、並交付成果，然後進行下一個產品特性開發。
這樣的團隊成員組成由 產品、UI、後端開發、運維測試、交付等組成一個跨職能的全功能開發團隊。
架構師團隊
在稍微大一點公司裡，可能還有一些公共技術團隊，比如架構師團隊，這個團隊基本職責是負責公司的專案的技術架構設計、攻堅技術難題，還可能負責公司技術基礎設施建設。
開發人數較少的公司可能沒有架構師團隊，那怎麼辦？一般由技術經理來兼任架構師的職責。
跨部門團隊
有的公司可能按照職能職責組成一個一個的委員會，來解決公司內遇到的各種技術、溝通、協調等問題。
比如說技術委員會，公司最高技術決策組織，裡面成員有 CTO 、各技術組長、架構師，他們透過溝通、討論和解決公司裡遇到的各種技術難題。
產品與設計委員會，成員由CTO、產品經理、設計師、架構師、業務員等組成，評審產品專案、各種需求等，解決公司產品相關問題。
需求分析
什麼是需求
什麼是需求？在經濟學中需求是消費者願意並且能夠在給定時間段內以不同價格購買的商品數量。
在產品中，需求又是什麼？
從問題角度來理解，在某個場景下，使用者為了解決某個問題。
從心裡角度來理解，在某個場景下，為了實現使用者內心的某種慾望。
需求 = 使用者 + 場景 + 問題
怎麼獲取使用者需求
首先需要洞察使用者需求，將洞察到的使用者需求收集起來，然後進行分析 - 需求分析。分析真需求和偽需求，然後形成一份需求文件。
- 洞察使用者需求，把自己想象成使用者，進入到使用者的場景裡去。這就是馬化騰說的5秒鐘進入使用者狀態。
- 第二可以實地考察，進行使用者訪談來了解使用者的需求。
- 第三可以用調查問卷的方式進行需求收集。
- 第四可以藉助第三方的資料或對自身產品資料進行分析，獲取需求。
- 第五可以進行競品分析，獲取需求。
等等一些需求洞察的方法。
（需求收集分析）步驟圖
使用者分析
比如使用者年齡、學歷、興趣愛好等進行分析，確定哪些使用者是目標使用者，然後可以進行需求分析。
需求分析步驟
需求分析步驟：
需求過濾 -> 需求稽核（稽核需求真偽） -> 需求分類 -> 需求排序（優先順序）
後面是需求實現，需求交付和驗證。
- 需求過濾：一些低階需求去掉，一些需求內容不完整、格式不對的需求，這些需要產經理繼續去溝通、完善這份需求。
- 需求稽核：評估需求是否真實存在，需求對產品、業務是否有價值，沒有話需要去掉或重新收集需求。
- 需求分類：對正式需求進行分類，後續將對不同需求採取不同處理方式。一個產品可能有很多不同產品小組，哪個產品小組承接這個需求。
- 需求優先順序排序：對需求進行優先順序排序，高優先順序的需求優先做，因為開發資源是有限的。
一種需求分析模型，KANO模型介紹：
KANO模型是由東京理工大學教授狩野紀昭（Noriaki Kano）和他的同事 Fumio Takahashi 聯合建立的使用者對產品功能滿意度模型。在需求分析中一般用來進行需求分類和優先順序排序的工具。
KANO 模型可用於定性分析使用者對新功能的接受度。
該模型核心理念：
使用者對產品或服務的滿意度並不是簡單地隨著功能的增加而成正比例提升，而是呈現出更為複雜的非線性關係。
KANO模型圖：
KANO模型需求分類：
-
必備型需求（屬性 ）（一定要有）：有的也譯作基本型需求（屬性）。使用者認為理所應當、必須要有的需求，這些需求必須被滿足。當這些需求不被滿足時，也就是不提供這些需求，使用者滿意度會大幅降低；當這些需求被滿足時，使用者滿意度不會得到提升。例如：手機打電話、發簡訊。
-
期望型需求（屬性）：滿足此需求時，使用者滿意度會提升；不滿足此需求時，使用者滿意度會降低。
-
魅力型需求（屬性）：使用者對這種需求沒有太大期望，需要產品經理對使用者有深刻的洞察才能挖掘到此隱性需求，屬於給使用者驚喜的需求。不滿足此需求，使用者滿意度不會降低；滿足此需求，使用者滿意度會急劇提升。有時是產品很 有競爭力的體現。
-
無差異需求（屬性）：無論是否滿足此需求，對使用者滿意度都不會產生影響。
-
反向型需求（屬性）：有無此類需求，使用者根本不在意。若滿足此需求，使用者滿意度反而會下降。
它們的優先順序排序為：
必備型需求 > 期望型需求 > 魅力型需求 > 無差異需求
KANO模型的分析步驟包括：問卷收集→資料清洗→屬性歸屬分析→Better-Worse係數計算。
使用者分析
比如使用者年齡、學歷、興趣愛好等進行分析，搞清楚使用者畫像，確定哪些使用者是目標使用者，然後進一步進行使用者需求分析。
業務分析
業務分析中的一些概念：
業務目標，業務流程分析，關鍵業務流程是什麼，業務場景有哪些，業務物件有哪些，業務物件之間關係是什麼？業務活動有哪些，業務規則是什麼，相關角色有哪些？抽象出業務模型。
圖解業務，比如用 UML 繪圖，繪製出業務各步驟、用例圖、業務流程圖 等。
產品設計
產品方案設計
使用者和業務需求 -> 產品定義 -> 產品解決方案 -> 詳細設計
上面把使用者需求和業務需求分析完成後，就要進行產品定義 。
- 產品定義：把使用者和業務需求轉換為產品實現的描述，形成產品需求。
- 產品解決方案：產品定義完成後，可以有多種方案來實現產品，就可以進一步來討論哪種方案更合適。
總體解決方案，產品架構設計，子系統設計，業務模組設計等等。
- 詳細設計：各個模組的功能清單，各種功能詳情說明，模組之間的關係、介面詳情等
產品PRD
產品經理可以輸出一份產品 PRD 文件，這份文件是面向後端開發、前端開發、互動設計、QA測試的一份文件。
PRD 文件組成：
- 需求背景說明
- 產品流程圖
- 功能清單
- 功能詳情
- 迭代路線圖
- 產品原型圖
這裡很重要的產品原型圖，畫出了產品的介面、功能、操作、規則等。
產品原型設計工具有Axure、藍湖、Figma等工具軟體。
最後，PRD文件的評審工作。
UI設計
根據產品經理畫出的原型圖，設計產品 UI、互動設計。
開發和測試
到這一步，就是產品的真正實現了。
架構設計
架構設計，一般可分為：業務架構、產品架構、應用架構、資料架構、技術架構。
-
業務架構可以是對業務整體分析完成後，業務可以由哪些業務系統組成。
-
產品架構對應著業務架構，一種產品的實現是對業務的一種實現，所以往往業務架構和產品架構圖有很多相似處。
-
應用架構對應著產品架構，開發的應用系統有哪些組成。
-
資料架構是關於資料設計、資料管理、資料分析等。
-
技術架涉及到具體技術系統架構、應用技術架構等。
應用架構、資料架構、技術架構 這 3 種架構相對來說，是技術層面的架構。
技術架構
- 系統架構：
根據上面的產品架構文件，PRD 文件來設計應用系統。
系統設計：
- 需要設計成多個應用系統嗎？按照產品生命週期的 4 個週期，在第一個週期裡，從 0 開發的產品不需要劃分多個應用系統。單個應用系統就可以。
- 子系統和模組：如果應用系統不復雜，也不需要劃分子系統。直接把單應用系統進行模組劃分。
架構選型：單體架構足矣。
最後可以畫出一份應用系統架構圖。
- 應用技術架構：技術選型和進行整體技術架構設計，出一份設計圖。例如使用SpringBoot、MySQL、Kafka 進行架構與開發。
- 模組和類設計：模組的劃分，模組裡類設計。類的各種關係、介面。
- 資料庫設計：資料庫欄位設計。
- API 介面設計：與前端互動的 API 介面設計以及其它介面設計，比如第三方介面。
上面的設計都可以產出對應的技術文件。
資料架構：資料管理，資料分析
開發實現
可以採取敏捷開發的方法，迭代的方式進行產品功能開發。每一個開發週期實現一個產品目標。
Scrum 敏捷開發方法：
- 產品負責人負責產品待辦事項（Product Backlog），並進行優先順序排序。
- 敏捷負責人負責迭代計劃（Sprint Planning）。每一個迭代週期（通常為1-4周）從迭代計劃裡篩選出衝刺的任務進行開發，然後交付增量迭代成果。
- 開發團隊成員每天進行簡短的站立會議，分享進度、計劃以及遇到的問題。
- 每一個迭代週期完成後，要進行評審會議，展示交付的成果，並收集相關反饋。
- 每一個迭代週期完成後，進行回顧會議，覆盤哪些做得好，哪些做得不好，並制定改進措施。
持續整合與測試
完成衝刺後，原始碼提交到 Gitlab 程式碼儲存庫中，然後觸發構建，完成程式碼覆蓋率、單元測試等成功後，完成構建，構建結果可以儲存在 artifactory 中，然後部署到測試環境中。
QA 測試團隊進行 QA 測試，效能測試 和迴歸測試。QA 團隊測試透過，則部署到 UAT（User Acceptance Test 使用者驗收測試） 環境中。如果 UAT 測試透過，則成為部署到生產環境的候選版本。
部署交付
如果上面的測試全部透過，測試部門同意上線，則建立相應的 tag 版本，準備上線。
運維團隊建立好上線的時間，上線的版本號，評估上線後的影響範圍。