從需求分析、產(chǎn)品設(shè)計到部署交付各階段說明

需求分析、產(chǎn)品設(shè)計到部署交付各階段圖解

下面用一張圖來表示產(chǎn)品設(shè)計到部署交付階段：

研發(fā)流程各環(huán)節(jié)：

• 需求分析
• 產(chǎn)品設(shè)計
• UI設(shè)計
• 開發(fā)和測試
• 部署交付

團隊劃分

按職能劃分團隊

• 產(chǎn)品團隊
• 后端開發(fā)團隊
• UI 設(shè)計團隊
• 前端開發(fā)團隊
• 運維和測試團隊
• 移動開發(fā)團隊
  按職能來劃分團隊，每個團隊有一個團隊負(fù)責(zé)人，比如小組長。

組織結(jié)構(gòu)如下圖：

跨職能團隊

跨職能團隊一般是基于某個產(chǎn)品、項目 或功能特性來組織一個團隊，在這個團隊內(nèi)，就可以完成需求、開發(fā)、并交付成果，然后進行下一個產(chǎn)品特性開發(fā)。
這樣的團隊成員組成由 產(chǎn)品、UI、后端開發(fā)、運維測試、交付等組成一個跨職能的全功能開發(fā)團隊。

架構(gòu)師團隊

在稍微大一點公司里，可能還有一些公共技術(shù)團隊，比如架構(gòu)師團隊，這個團隊基本職責(zé)是負(fù)責(zé)公司的項目的技術(shù)架構(gòu)設(shè)計、攻堅技術(shù)難題，還可能負(fù)責(zé)公司技術(shù)基礎(chǔ)設(shè)施建設(shè)。
開發(fā)人數(shù)較少的公司可能沒有架構(gòu)師團隊，那怎么辦？一般由技術(shù)經(jīng)理來兼任架構(gòu)師的職責(zé)。

跨部門團隊

有的公司可能按照職能職責(zé)組成一個一個的委員會，來解決公司內(nèi)遇到的各種技術(shù)、溝通、協(xié)調(diào)等問題。

比如說技術(shù)委員會，公司最高技術(shù)決策組織，里面成員有 CTO 、各技術(shù)組長、架構(gòu)師，他們通過溝通、討論和解決公司里遇到的各種技術(shù)難題。

產(chǎn)品與設(shè)計委員會，成員由CTO、產(chǎn)品經(jīng)理、設(shè)計師、架構(gòu)師、業(yè)務(wù)員等組成，評審產(chǎn)品項目、各種需求等，解決公司產(chǎn)品相關(guān)問題。

需求分析

什么是需求

什么是需求？在經(jīng)濟學(xué)中 需求 是消費者愿意并且能夠在給定時間段內(nèi)以不同價格購買的商品數(shù)量。
在產(chǎn)品中，需求又是什么？
從問題角度來理解，在某個場景下，用戶為了解決某個問題。
從心里角度來理解，在某個場景下，為了實現(xiàn)用戶內(nèi)心的某種欲望。

需求 = 用戶 + 場景 + 問題

怎么獲取用戶需求

首先需要洞察用戶需求，將洞察到的用戶需求收集起來，然后進行分析 - 需求分析。分析真需求和偽需求，然后形成一份需求文檔。

• 洞察用戶需求，把自己想象成用戶，進入到用戶的場景里去。這就是馬化騰說的5秒鐘進入用戶狀態(tài)。
• 第二可以實地考察，進行用戶訪談來了解用戶的需求。
• 第三可以用調(diào)查問卷的方式進行需求收集。
• 第四可以借助第三方的數(shù)據(jù)或?qū)ψ陨懋a(chǎn)品數(shù)據(jù)進行分析，獲取需求。
• 第五可以進行競品分析，獲取需求。

等等一些需求洞察的方法。

（需求收集分析）步驟圖

用戶分析

比如用戶年齡、學(xué)歷、興趣愛好等進行分析，確定哪些用戶是目標(biāo)用戶，然后可以進行需求分析。

需求分析步驟

需求分析步驟：

需求過濾 -> 需求審核（審核需求真?zhèn)危?-> 需求分類 -> 需求排序（優(yōu)先級）

后面是需求實現(xiàn)，需求交付和驗證。

• 需求過濾 ：一些低級需求去掉，一些需求內(nèi)容不完整、格式不對的需求，這些需要產(chǎn)經(jīng)理繼續(xù)去溝通、完善這份需求。
• 需求審核 ：評估需求是否真實存在，需求對產(chǎn)品、業(yè)務(wù)是否有價值，沒有話需要去掉或重新收集需求。
• 需求分類 ：對正式需求進行分類，后續(xù)將對不同需求采取不同處理方式。一個產(chǎn)品可能有很多不同產(chǎn)品小組，哪個產(chǎn)品小組承接這個需求。
• 需求優(yōu)先級排序 ：對需求進行優(yōu)先級排序，高優(yōu)先級的需求優(yōu)先做，因為開發(fā)資源是有限的。

一種需求分析模型，KANO模型介紹：

KANO模型是由東京理工大學(xué)教授狩野紀(jì)昭（Noriaki Kano）和他的同事 Fumio Takahashi 聯(lián)合建立的用戶對產(chǎn)品功能滿意度模型。在需求分析中一般用來進行需求分類和優(yōu)先級排序的工具。
KANO 模型可用于定性分析用戶對新功能的接受度。

該模型核心理念：

用戶對產(chǎn)品或服務(wù)的滿意度并不是簡單地隨著功能的增加而成正比例提升，而是呈現(xiàn)出更為復(fù)雜的非線性關(guān)系。

KANO模型圖：

KANO模型需求分類：

• 必備型需求（屬性 ） （一定要有）：有的也譯作基本型需求（屬性）。用戶認(rèn)為理所應(yīng)當(dāng)、必須要有的需求，這些需求必須被滿足。當(dāng)這些需求不被滿足時，也就是不提供這些需求，用戶滿意度會大幅降低；當(dāng)這些需求被滿足時，用戶滿意度不會得到提升。例如：手機打電話、發(fā)短信。

• 期望型需求（屬性） ：滿足此需求時，用戶滿意度會提升；不滿足此需求時，用戶滿意度會降低。

• 魅力型需求（屬性） ：用戶對這種需求沒有太大期望，需要產(chǎn)品經(jīng)理對用戶有深刻的洞察才能挖掘到此隱性需求，屬于給用戶驚喜的需求。不滿足此需求，用戶滿意度不會降低；滿足此需求，用戶滿意度會急劇提升。有時是產(chǎn)品很 有競爭力的體現(xiàn)。

• 無差異需求（屬性） ：無論是否滿足此需求，對用戶滿意度都不會產(chǎn)生影響。

• 反向型需求（屬性） ：有無此類需求，用戶根本不在意。若滿足此需求，用戶滿意度反而會下降。

它們的優(yōu)先級排序為：
必備型需求 > 期望型需求 > 魅力型需求 > 無差異需求

KANO模型的分析步驟包括：問卷收集→數(shù)據(jù)清洗→屬性歸屬分析→Better-Worse系數(shù)計算。

用戶分析

比如用戶年齡、學(xué)歷、興趣愛好等進行分析，搞清楚用戶畫像，確定哪些用戶是目標(biāo)用戶，然后進一步進行用戶需求分析。

業(yè)務(wù)分析

業(yè)務(wù)分析中的一些概念：

業(yè)務(wù)目標(biāo)，業(yè)務(wù)流程分析，關(guān)鍵業(yè)務(wù)流程是什么，業(yè)務(wù)場景有哪些，業(yè)務(wù)對象有哪些，業(yè)務(wù)對象之間關(guān)系是什么？業(yè)務(wù)活動有哪些，業(yè)務(wù)規(guī)則是什么，相關(guān)角色有哪些？抽象出業(yè)務(wù)模型。

圖解業(yè)務(wù)，比如用 UML 繪圖，繪制出業(yè)務(wù)各步驟、用例圖、業(yè)務(wù)流程圖 等。

產(chǎn)品設(shè)計

產(chǎn)品方案設(shè)計

用戶和業(yè)務(wù)需求 -> 產(chǎn)品定義 -> 產(chǎn)品解決方案 -> 詳細設(shè)計

上面把用戶需求和業(yè)務(wù)需求分析完成后，就要進行產(chǎn)品定義 。

• 產(chǎn)品定義：把用戶和業(yè)務(wù)需求轉(zhuǎn)換為產(chǎn)品實現(xiàn)的描述，形成產(chǎn)品需求。
• 產(chǎn)品解決方案：產(chǎn)品定義完成后，可以有多種方案來實現(xiàn)產(chǎn)品，就可以進一步來討論哪種方案更合適。

總體解決方案，產(chǎn)品架構(gòu)設(shè)計，子系統(tǒng)設(shè)計，業(yè)務(wù)模塊設(shè)計等等。

• 詳細設(shè)計：各個模塊的功能清單，各種功能詳情說明，模塊之間的關(guān)系、接口詳情等

產(chǎn)品PRD

產(chǎn)品經(jīng)理可以輸出一份產(chǎn)品 PRD 文檔，這份文檔是面向后端開發(fā)、前端開發(fā)、交互設(shè)計、QA測試的一份文檔。

PRD 文檔組成：

• 需求背景說明
• 產(chǎn)品流程圖
• 功能清單
• 功能詳情
• 迭代路線圖
• 產(chǎn)品原型圖

這里很重要的產(chǎn)品原型圖，畫出了產(chǎn)品的界面、功能、操作、規(guī)則等。
產(chǎn)品原型設(shè)計工具有Axure、藍湖、Figma等工具軟件。

最后，PRD文檔的評審工作。

UI設(shè)計

根據(jù)產(chǎn)品經(jīng)理畫出的原型圖，設(shè)計產(chǎn)品 UI、交互設(shè)計。

開發(fā)和測試

到這一步，就是產(chǎn)品的真正實現(xiàn)了。

架構(gòu)設(shè)計

架構(gòu)設(shè)計，一般可分為：業(yè)務(wù)架構(gòu)、產(chǎn)品架構(gòu)、應(yīng)用架構(gòu)、數(shù)據(jù)架構(gòu)、技術(shù)架構(gòu)。

• 業(yè)務(wù)架構(gòu)可以是對業(yè)務(wù)整體分析完成后，業(yè)務(wù)可以由哪些業(yè)務(wù)系統(tǒng)組成。

• 產(chǎn)品架構(gòu)對應(yīng)著業(yè)務(wù)架構(gòu)，一種產(chǎn)品的實現(xiàn)是對業(yè)務(wù)的一種實現(xiàn)，所以往往業(yè)務(wù)架構(gòu)和產(chǎn)品架構(gòu)圖有很多相似處。

• 應(yīng)用架構(gòu)對應(yīng)著產(chǎn)品架構(gòu)，開發(fā)的應(yīng)用系統(tǒng)有哪些組成。

• 數(shù)據(jù)架構(gòu)是關(guān)于數(shù)據(jù)設(shè)計、數(shù)據(jù)管理、數(shù)據(jù)分析等。

• 技術(shù)架涉及到具體技術(shù)系統(tǒng)架構(gòu)、應(yīng)用技術(shù)架構(gòu)等。

應(yīng)用架構(gòu)、數(shù)據(jù)架構(gòu)、技術(shù)架構(gòu) 這 3 種架構(gòu)相對來說，是技術(shù)層面的架構(gòu)。

技術(shù)架構(gòu)

• 系統(tǒng)架構(gòu)：

根據(jù)上面的產(chǎn)品架構(gòu)文檔，PRD 文檔來設(shè)計應(yīng)用系統(tǒng)。
系統(tǒng)設(shè)計：

1. 需要設(shè)計成多個應(yīng)用系統(tǒng)嗎？按照產(chǎn)品生命周期的 4 個周期，在第一個周期里，從 0 開發(fā)的產(chǎn)品不需要劃分多個應(yīng)用系統(tǒng)。單個應(yīng)用系統(tǒng)就可以。
2. 子系統(tǒng)和模塊：如果應(yīng)用系統(tǒng)不復(fù)雜，也不需要劃分子系統(tǒng)。直接把單應(yīng)用系統(tǒng)進行模塊劃分。

架構(gòu)選型：單體架構(gòu)足矣。

最后可以畫出一份應(yīng)用系統(tǒng)架構(gòu)圖。

• 應(yīng)用技術(shù)架構(gòu)：技術(shù)選型和進行整體技術(shù)架構(gòu)設(shè)計，出一份設(shè)計圖。例如使用SpringBoot、MySQL、Kafka 進行架構(gòu)與開發(fā)。
• 模塊和類設(shè)計：模塊的劃分，模塊里類設(shè)計。類的各種關(guān)系、接口。
• 數(shù)據(jù)庫設(shè)計：數(shù)據(jù)庫字段設(shè)計。
• API 接口設(shè)計：與前端交互的 API 接口設(shè)計以及其它接口設(shè)計，比如第三方接口。

上面的設(shè)計都可以產(chǎn)出對應(yīng)的技術(shù)文檔。

數(shù)據(jù)架構(gòu)：數(shù)據(jù)管理，數(shù)據(jù)分析

開發(fā)實現(xiàn)

可以采取敏捷開發(fā)的方法，迭代的方式進行產(chǎn)品功能開發(fā)。每一個開發(fā)周期實現(xiàn)一個產(chǎn)品目標(biāo)。

Scrum 敏捷開發(fā)方法：

• 產(chǎn)品負(fù)責(zé)人負(fù)責(zé)產(chǎn)品待辦事項（Product Backlog），并進行優(yōu)先級排序。
• 敏捷負(fù)責(zé)人負(fù)責(zé)迭代計劃（Sprint Planning）。每一個迭代周期（通常為1-4周）從迭代計劃里篩選出沖刺的任務(wù)進行開發(fā)，然后交付增量迭代成果。
• 開發(fā)團隊成員每天進行簡短的站立會議，分享進度、計劃以及遇到的問題。
• 每一個迭代周期完成后，要進行評審會議，展示交付的成果，并收集相關(guān)反饋。
• 每一個迭代周期完成后，進行回顧會議，復(fù)盤哪些做得好，哪些做得不好，并制定改進措施。

持續(xù)集成與測試

完成沖刺后，源代碼提交到 Gitlab 代碼存儲庫中，然后觸發(fā)構(gòu)建，完成代碼覆蓋率、單元測試等成功后，完成構(gòu)建，構(gòu)建結(jié)果可以存儲在 artifactory 中，然后部署到測試環(huán)境中。

QA 測試團隊進行 QA 測試，性能測試 和回歸測試。QA 團隊測試通過，則部署到 UAT（User Acceptance Test 用戶驗收測試） 環(huán)境中。如果 UAT 測試通過，則成為部署到生產(chǎn)環(huán)境的候選版本。

部署交付

如果上面的測試全部通過，測試部門同意上線，則建立相應(yīng)的 tag 版本，準(zhǔn)備上線。

運維團隊建立好上線的時間，上線的版本號，評估上線后的影響范圍。