編輯導(dǎo)讀：版本管理，是對(duì)軟件開發(fā)過程中特定功能的集合或特定代碼構(gòu)建結(jié)果進(jìn)行管理。本文作者圍繞軟件項(xiàng)目版本管理進(jìn)行了分析，希望對(duì)你有幫助。

什么是版本管理？版本管理，是對(duì)軟件開發(fā)過程中特定功能的集合或特定代碼構(gòu)建結(jié)果進(jìn)行管理，主要包括版本編號(hào)的管理、版本的前期規(guī)劃、版本開發(fā)時(shí)的需求變更應(yīng)對(duì)以及版本發(fā)布上線后的總結(jié)回顧等內(nèi)容。

在版本開發(fā)前：通過建立版本號(hào)標(biāo)識(shí)，明確版本目標(biāo)，制定好版本上線需求內(nèi)容，設(shè)計(jì)好發(fā)布策略，可以讓產(chǎn)品功能和質(zhì)量盡可能地符合用戶的預(yù)期。

在版本開發(fā)時(shí)：通過提升需求分析的確定性，提高需求方需求變更的成本，降低開發(fā)響應(yīng)需求變更的成本，從而幫助團(tuán)隊(duì)積極地應(yīng)對(duì)需求變更。

在版本發(fā)布后：通過對(duì)Bug和用戶反饋以及線上日志的收集分析，對(duì)版本進(jìn)行復(fù)盤，有助于及時(shí)應(yīng)對(duì)版本問題，從而制定有針對(duì)性的版本優(yōu)化。

一、如何對(duì)版本進(jìn)行規(guī)劃

對(duì)產(chǎn)品版本的規(guī)劃，主要包括四部分內(nèi)容：一是建立明確的版本號(hào)標(biāo)識(shí)，二是確定版本的目標(biāo)，三是制定版本內(nèi)容，四是設(shè)計(jì)發(fā)布的策略。

1. 建立明確的版本號(hào)標(biāo)識(shí)

為了使工作規(guī)范化、統(tǒng)一化，我們需要明確標(biāo)識(shí)產(chǎn)品的版本編號(hào)。目前業(yè)界在軟件版本的命名上，通常會(huì)采用以下方式：

版本號(hào)命名規(guī)則

例如：1.2.1, 2.0, 5.0.0 build-13124。其中，構(gòu)建版本號(hào)通常由編譯程序自動(dòng)生成，對(duì)外不提供。

1、版本號(hào)更新規(guī)則

• 主版本號(hào)更新規(guī)則：產(chǎn)品功能發(fā)生全新的優(yōu)化，包括頁(yè)面、體驗(yàn)和技術(shù)上的全面更新優(yōu)化。如下圖所示兩個(gè)產(chǎn)品的版本號(hào)升級(jí)。
• 子版本號(hào)更新規(guī)則：1、產(chǎn)品新增了重要功能模塊；2、在原來功能基礎(chǔ)上作了重要更新；3、嚴(yán)重Bug的修復(fù)。
• 修訂版本號(hào)更新規(guī)則：1、新增或優(yōu)化一般的功能模塊；2、一般Bug的修復(fù)。

2、版本號(hào)后綴

版本號(hào)后面可以加入Alpha、Beta、Gamma、RC、Release等后綴，用來表示軟件當(dāng)前所處的階段。

• Alpha：內(nèi)測(cè)版。此版本表示該軟件在此階段主要是以實(shí)現(xiàn)軟件功能為主，通常只在開發(fā)者內(nèi)部交流，或者提供給測(cè)試人員測(cè)試用，一般而言，該版本軟件的Bug較多，需要繼續(xù)修改。
• Beta：公測(cè)版。該版本相對(duì)于α版已有了很大的改進(jìn)，消除了嚴(yán)重的問題，但還是存在著一些缺陷，需要經(jīng)過多次測(cè)試來進(jìn)一步消除，可以提供給一定的目標(biāo)用戶大規(guī)模體驗(yàn)測(cè)試。
• RC 版：候選版本。是 Release Candidate 的縮寫，意思是發(fā)布倒計(jì)時(shí)，該版本已經(jīng)相當(dāng)成熟了，完成全部功能并清除大部分的Bug。
• Release 版：該版本意味“最終版本”。是經(jīng)過前面版本的一系列測(cè)試之后，最終交付給用戶使用的一個(gè)版本。該版本有時(shí)也稱為標(biāo)準(zhǔn)版。

2. 確定版本目標(biāo)

版本規(guī)劃的第二部分內(nèi)容是關(guān)于版本目標(biāo)的確定。

在確定版本上線需求的時(shí)候，往往容易只考慮那些最緊急的、用戶反饋?zhàn)疃嗟摹⑺^優(yōu)先級(jí)最高的需求，然后將這些需求整合到下一次的版本發(fā)布計(jì)劃中，但是這么做無疑是撿了芝麻卻丟了西瓜，因?yàn)楹鲆暳藢?duì)整個(gè)產(chǎn)品目標(biāo)的實(shí)現(xiàn)。

比如：需求A屬于模塊1，需求B屬于模塊2，需求C屬于模塊3，這些需求分屬于不同的業(yè)務(wù)，解決的是不同場(chǎng)景的需求，但同時(shí)實(shí)現(xiàn)這幾個(gè)需求，并不能體現(xiàn)出產(chǎn)品的目標(biāo)和優(yōu)勢(shì)。一個(gè)版本，就好比一個(gè)產(chǎn)品，產(chǎn)品要有自己的優(yōu)勢(shì)，版本也要有自己的目標(biāo)和優(yōu)勢(shì)。

基于海盜模型確定版本目標(biāo)

海盜模型是一種以用戶為中心的、著眼于轉(zhuǎn)化率的漏斗模型。這個(gè)經(jīng)典的數(shù)據(jù)模型把目標(biāo)整體分成了五個(gè)部分，即：獲取用戶（Acquisition）、激活用戶（Activation）、提高留存（Retention）、獲取收入（Revenue）和自傳播（Referral）。

1、獲取用戶

即拉新，一般是用戶的注冊(cè)、下載、關(guān)注等行為。通常用新增用戶數(shù)來作為考量。任何一款產(chǎn)品上線之初都避不開這個(gè)環(huán)節(jié)，而且拉新是會(huì)持續(xù)的伴隨整個(gè)產(chǎn)品生命周期。一般在剛剛上線核心功能后，都會(huì)重點(diǎn)關(guān)注并優(yōu)化用戶的注冊(cè)登錄的路徑，甚至通過不斷的埋點(diǎn)來獲取數(shù)據(jù)，從而做數(shù)據(jù)分并優(yōu)化需求。

案例：最初新浪微博的注冊(cè)流程，是需要用戶在第一次注冊(cè)時(shí)綁定手機(jī)號(hào)、身份證、輸入賬號(hào)密碼和保密郵箱等等非常多的內(nèi)容，后來在后臺(tái)的數(shù)據(jù)埋點(diǎn)中發(fā)現(xiàn)由于注冊(cè)流程繁瑣，導(dǎo)致不少用戶在注冊(cè)了一半的情況下就跳出了頁(yè)面。之后隨著版本的不斷迭代，如今新浪微博的注冊(cè)只需要輸入賬號(hào)和密碼即可，只有在需要用到核心功能時(shí)才會(huì)需要我們綁定手機(jī)號(hào)和身份證等相關(guān)信息。這樣就大大降低了用戶的操作成本，讓獲取用戶變得更容易。

2、激活用戶

即促活，一般會(huì)以用戶的在線時(shí)長(zhǎng)、與其他用戶的互動(dòng)頻次等數(shù)據(jù)來做以考量。初期用戶的活躍度是至關(guān)重要的，甚至對(duì)產(chǎn)品以后的發(fā)展會(huì)有很長(zhǎng)遠(yuǎn)的影響。

案例：抖音在最初的版本上線的時(shí)候，通過各種渠道吸引了很多在校的大學(xué)生錄制作品，他們大多來自于音樂學(xué)院、表演系等顏值出眾的年輕人。這些用戶的積極互動(dòng)和推廣為抖音在用戶的心里留下了一個(gè)新潮時(shí)髦的印象，從而吸引更多人參與到短視頻的制作和互動(dòng)中來。

3、提高留存

留存：指在經(jīng)過一段時(shí)間后有多少用戶留了下來，一般情況下會(huì)以月、周、日的時(shí)間維度來作為數(shù)據(jù)考量，也就是我們常說的DAU、WAU和MAU。

案例：在一些社區(qū)及游戲行業(yè)中留存是一個(gè)相當(dāng)重要的指標(biāo)，當(dāng)一款產(chǎn)品的用戶留存越來越低，即使有新用戶進(jìn)來，也依然難以擺脫冷清的局面。例如，根據(jù)王者榮耀的數(shù)據(jù)發(fā)現(xiàn)，在非長(zhǎng)假期間用戶的留存率會(huì)出現(xiàn)下降的情況，所以為了搶占用戶的時(shí)間，提高留存率，程序會(huì)經(jīng)常發(fā)布一些諸如簽到送皮膚和送鉆石金幣等任務(wù)活動(dòng)。

4、獲取收入

即變現(xiàn)。不止是軟件的開發(fā)方獲得收入變現(xiàn)，用戶也可以在這一步獲得利益。

案例：知乎為了更好的促進(jìn)用戶進(jìn)行高質(zhì)量?jī)?nèi)容創(chuàng)作，增加了付費(fèi)問答等功能，這些功能讓用戶有更強(qiáng)烈的動(dòng)機(jī)去進(jìn)行持續(xù)的內(nèi)容輸出，同時(shí)也為平臺(tái)帶來了部分收益。

5、自傳播

自傳播：即用戶可以自發(fā)的向身邊用戶推薦我們的產(chǎn)品。

案例：拼多多采取了拼團(tuán)模式讓用戶獲取到折扣和優(yōu)惠，同時(shí)進(jìn)一步刺激了用戶分享給身邊人，加強(qiáng)了產(chǎn)品本身的傳播性。

3. 制定版本內(nèi)容

版本的目標(biāo)確定了，我們就需要從需求池中挑選需求了。需求很多，但是開發(fā)資源緊張或存在其他一些客觀因素，不能在一個(gè)版本中全部實(shí)現(xiàn)。那么我們?cè)趺磳?duì)這些需求進(jìn)行排序呢？

基于KANO模型確定需求優(yōu)先級(jí)

KANO模型是東京理工大學(xué)教授狩野紀(jì)昭（Noriaki Kano）發(fā)明的對(duì)用戶需求分類和排序的工具。我們可以通過使用KANO模型，分析需求的優(yōu)先級(jí)，完成對(duì)版本上線內(nèi)容的制定。具體就是：要盡量避免無差異型需求，不做反向型需求，做好基本型需求和期望型需求，努力挖掘興奮型需求。

在KANO模型中，根據(jù)不同類型的需求與用戶滿意度之間的關(guān)系，可將影響用戶滿意度的因素分為五類：興奮型需求、期望型需求、基本型需求、無差異型需求、反向型需求。

1、興奮型需求

興奮型需求，就是哪些藏在暗處的、用戶意想不到的，需要挖掘/洞察的需求。

若不實(shí)現(xiàn)此需求，用戶滿意度不會(huì)降低；若實(shí)現(xiàn)此需求，用戶滿意度會(huì)有很大的提升。當(dāng)用戶對(duì)一些產(chǎn)品或服務(wù)沒有表達(dá)出明確的需求時(shí)，如果提供給用戶一些完全出乎意料的產(chǎn)品屬性或服務(wù)行為，會(huì)使用戶產(chǎn)生驚喜，提升用戶滿意度，從而提高用戶忠誠(chéng)度。這類需求往往是代表著用戶的潛在需求。

例如網(wǎng)易云音樂的評(píng)論功能：網(wǎng)易云音樂剛推出時(shí)就摒棄了傳統(tǒng)音樂APP“音樂播放器”的普遍定位，以“音樂社交”為差異化切入點(diǎn)，讓用戶聽音樂后投入的情感以F發(fā)表評(píng)論的形式參與進(jìn)來，讓用戶體驗(yàn)的不僅僅只有音樂，還有情感的共鳴。

2、期望型需求

期望型需求，是處于成長(zhǎng)期的需求，也是體現(xiàn)競(jìng)爭(zhēng)能力的需求。

實(shí)現(xiàn)此需求，用戶滿意度會(huì)提升；不實(shí)現(xiàn)此需求，用戶滿意度會(huì)降低。對(duì)于這類需求，不僅要滿足，還要保證質(zhì)量。

例如：電子書APP閱讀方式的多樣性，既支持文字閱讀，又能支持語(yǔ)音聽書。

3、基本型需求

基本型需求，即痛點(diǎn)，對(duì)于用戶而言，這些需求是理所當(dāng)然必須滿足的。

當(dāng)不實(shí)現(xiàn)此需求，用戶滿意度會(huì)大幅降低，但優(yōu)化此需求，用戶滿意度不會(huì)得到顯著提升。這類需求是核心需求，也是產(chǎn)品必做的功能，所以應(yīng)該不斷地調(diào)查和了解用戶需求，并通過合適的方法在產(chǎn)品中體現(xiàn)。

例如：電商購(gòu)物類APP的支付和訂單這兩種需求。

4、無差異型需求

用戶根本不在意的需求，對(duì)用戶體驗(yàn)毫無影響，無論提供或不提供此需求，用戶滿意度都不會(huì)有改變。對(duì)于這類需求，沒有必要花大力氣去實(shí)現(xiàn)。

5、反向型需求

用戶根本都沒有此需求，實(shí)現(xiàn)這類需求用戶滿意度反而下降。所以這類需求不能去實(shí)現(xiàn)。

4. 設(shè)計(jì)發(fā)布策略

版本規(guī)劃的第四個(gè)內(nèi)容是設(shè)計(jì)發(fā)布策略。版本發(fā)布策略需要考慮的問題是：直接發(fā)布給所有用戶？還是先讓一部分用戶試用？

比如說可以先讓內(nèi)部用戶使用，內(nèi)部用戶對(duì)軟件質(zhì)量問題容忍度是很高的，還可以幫助發(fā)現(xiàn)很多問題。還有就是采用灰度測(cè)試的發(fā)布策略，讓一小部分用戶先用新功能，如果沒發(fā)現(xiàn)什么問題，再繼續(xù)擴(kuò)大用戶規(guī)模，如果有問題，也只是影響少量用戶。例如：蘋果的iOS系統(tǒng)，用戶也可以選擇安裝最新的 Beta 版本，可以先體驗(yàn)新功能，但是必須忍受系統(tǒng)的不穩(wěn)定。

二、如何應(yīng)對(duì)版本需求變更問題

從版本的規(guī)劃進(jìn)入版本的實(shí)現(xiàn)階段，業(yè)務(wù)需求的變更是無法避免的，所以需要考慮如何應(yīng)對(duì)版本需求的變更問題。

問題一：同樣是工程，建筑工程也是有需求變更的，但卻不會(huì)像軟件項(xiàng)目這么頻繁和失控。為什么呢？

原因一：需求的確定性

建筑需求是很具象的，而軟件工程的需求是抽象的。所以建筑項(xiàng)目里面，無論是提出需求還是變更需求，客戶和施工方都明確地知道他們想要什么。然而，軟件需求則經(jīng)常是抽象、模糊、不精確的，模糊不清的需求導(dǎo)致在軟件開發(fā)有了雛形后，才慢慢想清楚真正的需求是什么，從而導(dǎo)致需求變更。

舉個(gè)例子：客戶最開始對(duì)軟件界面的顏色是沒有任何要求的，當(dāng)?shù)谝话姹镜能浖o客戶看的時(shí)候，客戶覺得白色背景太難看了，希望換成藍(lán)色的；第二版本換成藍(lán)色后，客戶現(xiàn)在已經(jīng)覺得黃色更好看，希望改成黃色背景；第三版本的時(shí)候，產(chǎn)品經(jīng)理?yè)?dān)心客戶還想換顏色，就直接做成了換皮膚功能，用戶可以自己選擇顏色，客戶還是不滿意，問能不能把背景換成圖片……

原因二：需求變更的成本

建筑項(xiàng)目里面的需求變更，都很容易和成本掛鉤，因?yàn)檫@些東西已經(jīng)是生活常識(shí)了，而軟件項(xiàng)目里需求的變更成本比較模糊不確定。

舉個(gè)例子：裝修房子的時(shí)候，如果墻面已經(jīng)刷成白色了，但是客戶想都刷成藍(lán)色，那么他會(huì)很清楚，這涉及一系列成本：需要重新購(gòu)買涂料、需要找人重新粉刷。但換成一個(gè)軟件項(xiàng)目，客戶想把界面的白色背景換成藍(lán)色的，他會(huì)覺得這是很簡(jiǎn)單也是理所當(dāng)然的，甚至有時(shí)候產(chǎn)品經(jīng)理也會(huì)這么想，就會(huì)對(duì)開發(fā)這么說：“不就是換個(gè)顏色嗎？幾行代碼的事，客戶讓換就換了嘛！”但是實(shí)際上，軟件項(xiàng)目的需求變更，哪怕是換一個(gè)背景顏色，同樣是要涉及成本的：需要修改所有涉及背景顏色的代碼，需要更新相關(guān)測(cè)試代碼，還需要對(duì)涉及的界面重新測(cè)試。

問題二：如何緩解需求變更問題？

在軟件項(xiàng)目開發(fā)中，需求變更其實(shí)是不可避免的，找到合適的方案來改善并積極擁抱合理的需求變化，減少不必要的需求變更，這是我們討論如何緩解需求變更問題的前提條件，也是共識(shí)的基礎(chǔ)。

1、提升需求確定性，把需求分析做好，減少需求變更

例如：在了解完客戶的需求后，不急于馬上輸出PRD文檔讓開發(fā)實(shí)現(xiàn)，而是自己先用 Axure等原型設(shè)計(jì)工具，做一個(gè)簡(jiǎn)單的交互原型，給需求方演示。用戶會(huì)針對(duì)原型的效果提出一些修改意見，然后再快速地修改原型，這樣反復(fù)確認(rèn)，等到用戶沒有什么修改意見后，再著手具體的文檔編寫和開發(fā)實(shí)現(xiàn)。

2、規(guī)范變更流程，提升需求變更成本

例如：如果有條件，當(dāng)業(yè)務(wù)需求發(fā)生變更時(shí)，可以根據(jù)實(shí)際情況，要求需求部門需通過“電子化管理平臺(tái)中的需求管理流程”進(jìn)行需求變更，并提交《需求變更申請(qǐng)》，經(jīng)主管領(lǐng)導(dǎo)及項(xiàng)目經(jīng)理審批后提交給技術(shù)負(fù)責(zé)人實(shí)施”。需求變更申請(qǐng)通過后，文檔管理人應(yīng)將《項(xiàng)目需求規(guī)格說明書》同步更新到最新版本。

3、降低開發(fā)響應(yīng)需求變更的成本，積極應(yīng)對(duì)需求變更

例如：技術(shù)上可以通過換皮膚的方式來定制界面，可以通過插件的方式增加功能，以此來應(yīng)對(duì)個(gè)性化的需求。

三、版本發(fā)布后的工作

當(dāng)版本發(fā)布上線后，可能這才只是新的開始，因?yàn)檫€有兩項(xiàng)重要的工作需要繼續(xù)跟進(jìn)，一是問題跟蹤，二是版本復(fù)盤。

1. 問題跟蹤

用戶在使用產(chǎn)品的時(shí)候，可能會(huì)遇到一些 Bug 或者是有一些建議，所以需要提供用戶反饋問題的渠道，讓用戶可以有途徑對(duì)于 Bug 或者功能去反饋。

除了被動(dòng)地依靠用戶反饋問題，還需要主動(dòng)的對(duì)發(fā)布的版本進(jìn)行監(jiān)控。比如說要收集系統(tǒng)崩潰的日志、監(jiān)控服務(wù)器資源占用情況、監(jiān)控 API 出錯(cuò)的比例、監(jiān)控網(wǎng)頁(yè)響應(yīng)的速度等數(shù)據(jù)。當(dāng)發(fā)現(xiàn)數(shù)據(jù)異常時(shí)，很可能說明發(fā)布的版本是有問題的，需要及時(shí)的應(yīng)對(duì)，回滾版本或者發(fā)布新的更新補(bǔ)丁。

2. 版本復(fù)盤

對(duì)版本進(jìn)行復(fù)盤，就是通過分析和討論實(shí)現(xiàn)版本過程中出現(xiàn)的問題，進(jìn)而總結(jié)成功經(jīng)驗(yàn)，吸取失敗教訓(xùn)，提升團(tuán)隊(duì)能力。版本復(fù)盤主要包括四個(gè)步驟。

1、回顧版本目標(biāo)

版本在最開始規(guī)劃的時(shí)候都會(huì)確定該版本的目標(biāo)，所以復(fù)盤的第一步，就是要回顧最初的目標(biāo)，方便對(duì)最終結(jié)果進(jìn)行評(píng)估。

做好版本目標(biāo)回顧的前置條件，是準(zhǔn)確和客觀的目標(biāo)描述。只有做到目標(biāo)的準(zhǔn)確和客觀，在后續(xù)才能對(duì)目標(biāo)的完成情況進(jìn)行準(zhǔn)確地評(píng)估。

2、評(píng)估版本結(jié)果

好的結(jié)果：比如說版本上線后質(zhì)量穩(wěn)定，Bug 比例低于上一次版本，沒有出現(xiàn)需求遺漏，開發(fā)和測(cè)試能及時(shí)同步需求的變更。

壞的結(jié)果：比如說開發(fā)過程中間有比較多的需求變更；項(xiàng)目發(fā)生了延期等。

3、分析原因

導(dǎo)致好結(jié)果的原因，比如：增加了自動(dòng)化測(cè)試代，改進(jìn)了開發(fā)流程，代碼合并之前有代碼審核等；改進(jìn)了項(xiàng)目流程，對(duì)于所有的需求細(xì)分后，基于任務(wù)跟蹤系統(tǒng)記錄了起來，這樣可以及時(shí)了解任務(wù)進(jìn)程。

導(dǎo)致壞結(jié)果的原因，比如：版本沒有及時(shí)凍結(jié)需求，頻繁增加新的需求，導(dǎo)致開發(fā)節(jié)奏被打亂頻繁等

4、總結(jié)規(guī)律落實(shí)行動(dòng)

例如，需求變更是導(dǎo)致項(xiàng)目延期的主要源頭，需要在后續(xù)項(xiàng)目中控制好需求的變更，比如我們將縮短項(xiàng)目周期，采用快速迭代的開發(fā)模式，及時(shí)響應(yīng)需求變更，同時(shí)在一個(gè)迭代中，沒有特殊情況，不做需求上的變更，有變更放到下一個(gè)迭代中。

或者，任務(wù)跟蹤系統(tǒng)可以方便地跟蹤需求的執(zhí)行情況，也能保證項(xiàng)目成員能及時(shí)同步需求的變更。那么就繼續(xù)使用任務(wù)跟蹤系統(tǒng)，對(duì)需求任務(wù)進(jìn)行跟蹤，并且可以嘗試對(duì)于一些臨時(shí)性的任務(wù)也用任務(wù)跟蹤系統(tǒng)跟蹤起來。

通過回顧目標(biāo)、評(píng)估結(jié)果、分析原因和總結(jié)規(guī)律這四個(gè)步驟對(duì)版本進(jìn)行復(fù)盤，有助于我們發(fā)現(xiàn)做的好的地方和做的不好的地方，找出背后的原因，最終總結(jié)出來規(guī)律，落實(shí)成行動(dòng)，做出積極的改變，把經(jīng)驗(yàn)轉(zhuǎn)化成能力。

四、結(jié)語(yǔ)

版本管理工作是軟件項(xiàng)目管理的重要內(nèi)容，該工作貫穿版本開發(fā)前、版本開發(fā)時(shí)和版本發(fā)布后的全生命周期。

版本開發(fā)前，通過建立明確的版本號(hào)標(biāo)識(shí)，明確版本目標(biāo)，制定好版本上線需求內(nèi)容，設(shè)計(jì)好發(fā)布策略，盡可能地讓產(chǎn)品版本功能和質(zhì)量符合用戶的預(yù)期；版本開發(fā)時(shí)，通過提升需求分析的確定性，提高需求方需求變更的成本，降低開發(fā)響應(yīng)需求變更的成本，幫助團(tuán)隊(duì)積極地應(yīng)對(duì)需求變更；版本發(fā)布后，通過對(duì)Bug和用戶反饋以及線上日志的收集分析，對(duì)版本進(jìn)行復(fù)盤，及時(shí)應(yīng)對(duì)版本問題，從而為下一步制定有針對(duì)性的版本優(yōu)化做好準(zhǔn)備。

以上就是本人對(duì)于軟件項(xiàng)目版本管理的一些思考和總結(jié)，希望對(duì)從事項(xiàng)目管理、產(chǎn)品管理的同行有所幫助。

本文由 @xyh產(chǎn)品研習(xí)錄 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于CC0協(xié)議