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

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

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

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

團(tuán)隊(duì)劃分

按職能劃分團(tuán)隊(duì)

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

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

跨職能團(tuán)隊(duì)

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

架構(gòu)師團(tuán)隊(duì)

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

跨部門團(tuán)隊(duì)

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

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

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

需求分析

什么是需求

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

需求 = 用戶 + 場(chǎng)景 + 問題

怎么獲取用戶需求

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

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

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

（需求收集分析）步驟圖

用戶分析

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

需求分析步驟

需求分析步驟：

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

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

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

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

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

該模型核心理念：

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

KANO模型圖：

KANO模型需求分類：

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

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

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

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

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

它們的優(yōu)先級(jí)排序?yàn)椋?
必備型需求 > 期望型需求 > 魅力型需求 > 無差異需求

KANO模型的分析步驟包括：?jiǎn)柧硎占�→�?shù)據(jù)清洗→屬性歸屬分析→Better-Worse系數(shù)計(jì)算。

用戶分析

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

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

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

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

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

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

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

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

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

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

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

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

產(chǎn)品PRD

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

PRD 文檔組成：

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

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

最后，PRD文檔的評(píng)審工作。

UI設(shè)計(jì)

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

開發(fā)和測(cè)試

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

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

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

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

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

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

• 數(shù)據(jù)架構(gòu)是關(guān)于數(shù)據(jù)設(shè)計(jì)、數(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)相對(duì)來說，是技術(shù)層面的架構(gòu)。

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

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

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

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

架構(gòu)選型：?jiǎn)误w架構(gòu)足矣。

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

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

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

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

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

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

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

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

持續(xù)集成與測(cè)試

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

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

部署交付

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

運(yùn)維團(tuán)隊(duì)建立好上線的時(shí)間，上線的版本號(hào)，評(píng)估上線后的影響范圍。