編輯導語：對一個產品經理來說，一個項目從最初的點子到最后的發布整個流程都需要參與。本篇文章中作者從概念提出與篩選、需求階段以及項目階段三個方面，循序漸進地詳細分析了點子到項目發布的全流程。相信能夠對你有所幫助，感興趣的小伙伴們快來一起看看吧！

關于流程的重要性，淘寶UED小組流傳著這樣一個理念：設計流程的目標，在于保證“無論誰來做這個產品的設計，都能達到80分”。

沒錯，80分已經很難了，當產品越大的時候，誕生天才產品的概率也就越小?！坝挚煊址€定又有才”的100分產品是可遇不可求的。

PMP說高績效組織的三大特征是項目管理標準化、注重人才培養、持續改進。流程是管理保準化的重要組成部分。

這里并不是說在任何情況下都需要流程，流程是手段，不是目的，但是合適的流程可以促進目的的達成。

這篇文章是根據蘇杰老師的書籍，人人都是產品經理紀念本和2.0，結合工作經驗，并融入部分項目管理理念而成，下面這張圖是本篇的主要內容，可以根據需要閱讀。

一、概念提出與篩選

1. 概念提出

很多項目都是從一個點子開始的，這個點子就是所謂的產品概念，它包含5個關鍵要素：核心用戶、剛性需求、典型場景、產品概念、競爭優勢。

核心用戶：目標用戶中最重要的用戶是誰，表達為一個抽象的人群。

剛性需求：Ta們碰到的最痛的痛點是什么。滿足剛性需求要優先于彈性需求；

典型場景：這些痛點最常出現在怎樣的生活、工作場景

產品概念：用什么解決方案，用一個詞、最多一句話概括你的解決方案是什么，一個App，一個網站，一個服務體系，還是一個企業協同辦公的工具

競爭優勢：相對已有方案的競爭優勢。

這個時候的剛性需求、典型場景都是YY出來的，還未經驗證。

比如某Boss想做一款校園社交App，那核心用戶就是一批?；?，典型場景就是各位帥哥想去追漂亮的女生，解決方案就是校園社交App。

2. 概念篩選

產品概念篩選的目的是對其進行可行性分析，通過對產品概念進行深入分析，產出商業論證。

商業論證會包含商業需求和成本效益分析，以論證項目是否可行及項目邊界。

提出產品概念后，如何快速判斷它是否靠譜呢？

通常是先隨手找幾個人問問，把產品概念將給他們聽，如果聽到大家說“呵呵，我好像不需要”、“好奇怪，不理解為什么這樣做”，那就需要回爐重想，如果聽到“這個準備賣多少錢”、“有點用，但是不是已經有類似的東西了”這樣的問題，就說明這個概念靠譜，大家已經認可你的大方向了。

對這些相對靠譜的概念我們再次進行篩選，因為產品概念其實是在一個時間切片，所以每隔一段時間就要做一次。下圖篩選的要素。

二、需求階段

產品概念篩選之后，就需要投入更多的資源推進這個產品了，在進入開發之前，需要收集盡可能多的信息，并進行分析和篩選。

1. 需求采集

需求采集的目的是通過研究用戶來更好的滿足需求。需求采集方法的分類有如下四種：

（1）直接采集與間接采集

直接采集與間接采集，獲取到的需求分別是一手需求和二手需求，可以從以下兩個角度來理解它們的差異。

需求的提出者是不是有需求的人。如果用戶為自己提需求，采集到的是一手需求，反之為二手需求。

需求是原始的還是加工過的，比如和用戶直接聊，采集到的就是一手需求，而去看第三方機構的做的一些行業分析報告，就是二手需求。

（2）定性與定量，說與做

怎么說表達了觀點，怎么做反映了行為，用戶的說和做經常是不一致的。

“說”的最大劣勢是“耳聽為虛”，怎么解決耳聽為虛呢？看他怎么做。

“做”的優勢是“眼見為實”，但也有劣勢：我們不知道用戶是為什么這么做，不知道背后的原因，就意味著不能從根本上解決問題。

于是，需要再去聽他如何說，所以說和做事一對不可拆分的方法，盡可能用于一次需求采集，否則可能出問題。

定性研究可以找出原因，偏向于了解，屬于個體研究；而定量研究可以發現現象，偏向于證實，屬于群體研究。

定性的的問題是“以偏概全”，可能會被部分樣本的特殊情況帶入歧途，需要輔以定量的方法，定量研究的問題是“以表帶本”，只能用來發現表面現象，卻無法從中知道背后的原因，可以通過定性研究加以證實。

（3）是否在真實場景中

需求通常是帶場景的，只有到那時那刻去親身體會，或者通過想象去體會，才知道你的設計有沒有問題。

（4）是否與用戶發生交互

有時候和用戶溝通的時候，用戶還沒有接觸這個產品，更沒有真正用過這個產品。這種需求采集可能更多的是“發現新問題”。

還有一種需求采集方法是在用戶和產品發生交互的狀態下采集，往往用于“優化現有方案”。

所以，不同階段，需要使用不同的需求采集方法。

需求采集，并不是產品設計之前的工作，而是一個貫穿始終的過程；它不是產品人員的中的事情，而是所有人的責任；它沒有特定的方法，不管白貓黑貓，抓到老鼠就是好貓；它并不怕發現什么荒謬的需求，而是怕遺漏合理的需求。

2. 需求分析

用戶說了很多需求，產品經理要“聽用戶說但不要照著做”，必須明確我們存在的價值是“把用戶需求轉化為產品需求”，這一過程就是需求分析。

（1）需求轉化

在采集需求的時候，很多用戶習慣給出Ta認為的問題解決方案，采集完需求后產品人員也會給出解決方案。

這個時候，對于同一個問題，就有了兩套解決方案，它們的區別是，一個是用戶需求，一個是產品需求。而這個中間轉化的過程就是–需求分析。

用戶需求：用戶自以為的需求，并且經常表達為用戶的解決方案

產品需求：經過我們的分析，找到真實需求，并且表達為產品的解決方案

需求分析：從用戶提出的需求出發，找到用戶內心真正的渴望，再轉化為產品需求的過程

在需求轉化的過程中，我們也會做一輪篩選，把明顯不靠譜的用戶需求直接過濾掉，不計入產品需求列表，當然是否“明顯不靠譜”，就要由產品團隊來把握了，不要把“沒資源做”、“短期內有技術難點”的用戶需求給錯殺了，這類需求可以標記為暫緩，并注明重啟條件。

需求有三種深度：觀點和行為，目標和動機，人性與價值觀。

運用Y模型的一個主要的好處在于它不能跳過用戶目標而直接從用戶需求到產品功能，對用戶的需求有更深層次的分析，我們才能夠不被偽需求欺騙、能夠解決需求沖突、能夠發現更多用戶目標、能夠抓住恒定的人性、能夠在成熟市場中找機會。

·?“1”是用戶需求場景，經常簡單說成用戶需求。這是起點，是表象，是需求的第一種深度—觀點和行為。

·?“2”是用戶需求背后的目標和動機，是需求的第二種深度，產品經理在思考用戶目標時也要綜合考慮公司、產品目標。

·?“3”是解決方案，是實施人員能夠看懂的描述。

·?“4”是人性，或者說是價值觀，是需求的第三種深度，是需求的本質。

案例練習： 我們用Y模型來分析以下“秀場直播”觀看者的人性需求。

·?“1”用戶的觀點和行為是給主播送花，送游艇

·?“2”用戶的目的是和主播互動

·?“3”解決方案是提供送禮物功能，并且在屏幕突出顯示

·?“4”從人性的角度分析，這么多人送禮，怎么讓他們更開心，就會發現突破口是炫耀和攀比

好比在線下的演藝酒吧，經常出現前排卡座里的老板斗富的場景，這在線上也可以復現。

于是，所有的直播應用里，都可以找到排行榜，并且還有分類。

送禮榜表示誰為主播花的錢最多；分享榜表示誰榜主播做的宣傳最多，即沒錢的捧個人場；時長榜表示誰最忠誠，一直在看。

用戶需求轉化為產品需求后，我們會把它存儲到產品需求列表。

（2）確定基本屬性

轉化的產品需求，我們會把它維護起來，這個時候就需要確定需求列表中需要哪些屬性。

它大致包含了基本屬性、種類、商業價值、開發量幾個方面。

基本屬性包括了下表中的字段：

需求的種類：

（3）需求的商業價值

基本屬性和需求種類相對簡單，可以由需求錄入人獨立完成。

一個公司的任何產品，一個產品的任何需求，最終都要滿足一定的商業目的，所以“需求的商業價值”是最核心的內容，有條件的團隊最好利用群體智慧，比如可以舉行“需求討論會”，如何通過具體的方法來衡量商業價值呢？

需求的商業價值可以通過重要性、緊急程度、持續時間3個維度來綜合衡量。

重要性：可以細分為滿足后“一般”到“非常高興”；未實現“略感遺憾”到“非常懊惱”。

緊急程度：從時間維度上判斷這個需求是否迫切。通常采用重要緊急程度四象限評估法和重要性結合使用。

持續時間：需求有長壽的，也有短壽的，比如為了迎合逢年過節做的需求，一般來說是短壽的，但是把過節做成一個可配置化的功能模塊，不用每次都重新開發，就是長壽的，我們可以持續優化。

需求討論會：商業價值的判斷，直接影響產品未來的走向，一般的做法是需求討論會上由產品團隊集體討論，再叫上有必要的干系人，比如銷售、服務等。

對于某個需求，需求提交人是對它最熟悉的，提交人先基于自己對商業目標的理解，做下陳述，主管定個級別，可以用1到5來表示。然后大家討論，討論前參會人員要做好功課。

上述那么多維度，可以加權平均得到綜合的商業價值，但是實施起來成本太高，很難推動，也不是很有必要。

所以建議在討論的時候，大家充分表達完意見后，安全的做法是誰官大誰負責，俗稱老板拍腦袋，最終由會場上級別最高的人報一個數字結束（1-5之間），這就是現實，也是一種高效的方法。

一般我們還會在列表中添加1列“商業價值描述”，通俗點就是這個需求的賣點是什么，可以給用戶提供什么價值，對公司有什么幫助。

（4）初評需求的實現難度

絕對不能因為某個需求的商業價值很大就馬上去做，也不能因為另一個需求的商業價值不大就不做。

我們知道了每個需求的商業價值，決定是否做還要參考另外一個關鍵指標—實現難度，實現難度太難量化，工作中一般簡化為開發工作量（人天）。

（5）性價比

絕不能因為某個需求的實現難度大就不做，某個需求的實現難度小就做。

比如我們的用戶群體有99%是A類型，1%是其他類型，現在有兩個需求分別針對A類型、其他類型，針對A類型用戶的需求需要4人天，針對其他類型用戶需要3人天，在不考慮其他因素的情況下，會做哪個需求呢？這就涉及到這一節的標題“性價比”。

性價比= 商業價值 /實現難度（簡化為開發量）。這也是商業價值用1到5之間數字表示的原因，便于計算性價比。

現在我們就可以把產品需求列表按照“性價比”從大到小進行排序了，先做上面的就可以了。

3. 需求篩選

資源總是有限的，所以我們只能做性價比高的事情。

BRD是我們的武器，產品會議是我們的戰場，經過產品經理間的PK，最后由公司各個相關部門的領導決定做BRD中的哪些需求。

產品會議：各個產品帶著自己的BRD給公司高層領導講解為什么要做這個產品？需要做什么？怎么做？

通過的需求會作為項目立項的輸入，沒有通過的需求會被標記為暫緩或拒絕。

（1）需求打包

產品是需求的集合，我們會在每個迭代上線一些功能，選取上線哪些功能的過程就是需求打包。

那打包多少需求呢？這就涉及到項目管理的問題了，做項目的終極目的是“多快好省，即范圍大、時間短、質量好、資源低”。

但又要馬兒跑又想馬兒不吃草的想法是不現實的，所以通常我們需要在上述4個條件中尋求平衡。

我們以互聯網常用的開發方法，敏捷型開發方法來聊下需求打包，迭代周期固定、團隊穩定、任何項目都要保證質量，那變量就只能是量—項目范圍了。

有人說，在產品需求列表中我們已經把需求按照“性價比”進行排序了，每個需求后面都對應著工作量，直接從上向下加起來就可以了，實際情況是不可以的，為了讓項目靠譜，還要注意下面的幾個地方。

“需求打包”最好打包類似的功能點。是否類似取決于需求的基本屬性，一般來說業務上緊密聯系的才會打包在一起，不然產品就成修修補補的大雜燴了。需求在打包以后，最好通過業務邏輯圖的方式可視化可以更直觀地給別人講解。

需求依賴，功能互相之間有依賴關系，哪些功能點需要優先去做，需要在需求列表中注明。功能與人力資源之間的依賴關系也會經常存在，比如某個功能只有團隊中某個人才能實現。在項目立項后就需要評估工作量，最好的方式組建項目團隊時候就重點考慮，或者提前培養提升團隊成員的能力才是王道。

需求的粒度大小問題，商業價值很高的功能，如果細分的話，我們會發現其中有價值相對低的部分，所以需求的粒度要盡量細，前提是細化引起的管理成本在可接受范圍內。在打包這個階段的工作量還是比較粗粒度的評估，一般不要超過“5人天”就可以。

（2）編寫BRD

BRD主要回答三個問題，為什么要做這個產品？需要做什么？怎么做？

Why：為什么要做這個產品， 動之以情（通過用戶故事，讓受眾一開始就感到需求之強烈，問題之嚴重），曉之以理（產品概念階段做的內部能力、意愿；外部的價值、成本判斷就用上了），誘之以利（做了這個項目會產生什么價值做一個ROI預估，當然，這里的ROI是廣義的，回報的不一定是金錢，還可能是用戶數，市場占有率等其他指標）

What：產品MVP包含哪些功能（功能需求，非功能需求）及要做什么。

How：項目計劃及風險對策等。 說清楚項目計劃需要多少資源做保障，讓老板知道需要多少人、財、物。

所以BRD主要組成部分是項目背景、商業價值、資源評估、功能需求描述、非功能需求描述、風險和對策。

（3）產品會議

產品會議的目的，是通過對BRD的評審，決定是否做BRD中的功能，獲得開發的資源。參與BRD評審的一般都是各個部門的高層，資源掌握在他們的手里。

一般先回顧下上次產品會議通過的項目，進展情況如何，是否需要調整資源、時間，是否有重大變更，發布后的項目表現如何，有什么問題。

這樣一方面可以各位領導更新各個項目的信息，更重要的是為了積累經驗，讓今后的產品決策更合理。

回顧之后，就是最關鍵的部分，拿出準備好的BRD進行講解，通過動之以情、曉之以理、誘之以利的講解，力爭通過評審，并獲得各位領導對資源的承諾。

三、項目階段

通過概念提出與篩選、需求采集、需求分析、需求篩選等前期過程決定了“做不做，做多少“的問題，接下來通過項目階段來回答怎么”做出來“的問題。

產品會議評審通過后，確保有的放矢，不要努力做錯誤的事，這是在產品立項前做的最重要的判斷。

因為立項就意味著資源的正式投入，在這個節點的驗證，叫原型驗證，之前的驗證，主要目的是驗證用戶需求抓的準不準，而本次驗證則是考察用戶是否認可解決方案。

有的公司把這個環節叫做POC，產品概念測試，在這個環節，需要用盡量低的成本，做出某種形式的產品原型或demo，來讓用戶試用。用戶試用通過就可以正式進入立項環節了。

1. 立項

項目啟動總是以“Kick Off”開始，我們確定了團隊成員、時間計劃、溝通方法等，就可以在任何時候都做到心中有數。

（1）團隊組建

經過產品會議后，需求基本確定下來了，項目經理就可以根據需要列出團隊需要的角色有哪些，需要的數量大概是多少，當然團隊成員需要使用的各種軟硬件設施也是必不可少的。

團隊成員招募完成后，不要忘記重要的一點，在項目的組織結構中，項目經理并不是結構中的頂端，我會組織一個“變更控制委員會”，這很有必要，成員一般是項目成員的領導，甚至領導的領導，他們的任務也很簡單—“背鍋”和“買單”，因為權力越大，責任越大，權責利對等。

當項目因為種種原因出現重大變更的時候，比如成本、時間、需求等，我會向他們提出申請，獲得批準后才執行變更，這也是項目經理對自己和項目成員的保護。

在整個項目過程中，需要他們來提供項目資源，包括人、財、物。

這樣有兩個好處，對項目變更控制委員會來說，他們可以及時了解項目情況，領導在不知道項目具體情況時也會焦慮的，對項目成員來說，知道領導在監督工作，并且看到自己的努力，所以也會格外賣力。

（2）開發計劃確定

決定何時做，誰來做，在項目中，就是項目計劃，在這里最重要的一件事情就是：再次評估“工作量”，并推算出工期。

步驟如下：

1. 在BRD中給各項需求進行了工作量初評，現在把這些信息再一次拿出來參考，因為從產品會議結束到制定到制定項目計劃的日子中，產品經理同時也在做PRD的細化，項目經理可以根據PRD文檔，對任務進行拆分，即創建WBS，重視完整性，需遵循MECE法則。

2. 開發的同學拿到PRD和WBS時，每個功能點的工作量就可以評估的更準確一些了，最重要的區別是，初評一般是開發經理之類的角色來做，未考慮誰來做，而現在開發經理根據團隊里開發工程師的能力特點、擅長領域等因素，“因事擇人”，把各項開發任務分配給團隊里最合適的人（當然，要把高手調入項目的關鍵路徑）。之后，每位領導開發任務的開發工程師自己評估工作量，為各自任務買單，承諾最可能的時間，之前的初評只是做一個參考，畢竟每個人對自己最熟悉。

3. 這里的粒度比初評的時候更細，至少精確到“1人天”，按照經驗，這里的“1人天“通常等價于”5~6個小時“，而不是按照一天工作8小時計算，因為人很難保持持續高效，并且不被其他時期打斷。

4. 項目經理把工作量轉化為工期，同時考慮任務的依賴關系，也就得到了項目的進度計劃，通常用邏輯橫道圖呈現。

5. 詳細的項目進度計劃做完后，項目經理，需要在更大的粒度上把開需求計劃、開發計劃、測試計劃等合并成項目進度計劃，并確定項目的幾個里程碑，也就是監控點，通常是需求完成，開發完成，編碼完成，內部測試完成、UAT測試完成，發布上線，以里程碑圖呈現，便于給高層展示。

（3）Kick off

Kick Off通常意味著規劃階段結束和執行階段的開始，旨在傳達項目目標，獲得團隊對項目的承諾，闡明每個干系人的角色和職責。

主要內容如下：

參加方包括項目各重要干系人包括發起人、項目經理、項目團隊、客戶、高管層、職能管理部門、供應商代表等。

傳達的信息主要包括項目背景、項目意義、目的與目標、需求、功能點概述、項目組織結構、項目計劃、溝通計劃等。

2. 需求開發

（1）PRD文檔編寫

經過需求采集、分析、篩選，決定要做項目，通過團隊組建、計劃制定、Kick Off會議等步驟后，正式開始實施的第一步就是“寫PRD文檔”。

PRD文檔包含兩大部分：總體說明和UC(Use Case)。

總體說明主要包含了修訂歷史、項目概述、功能范圍、用戶范圍、詞匯表、非功能需求、其他說明7個部分。

（2）需求評審

我們辛辛苦苦地把各種虛偽文檔都寫完了，開發和測試可不敢拿過去直接用，為了保證產品的質量，需求還必須通過項目中各方的評審，方可進入開發階段。

項目的需求階段，通常會圍繞著“寫作–評審–修改–評審”循環展開；

一般來說，項目中最重要的三種角色是產品、測試、開發，所以派生出三次評審–需求評審、設計評審、測試評審。

需求評審：PRD編寫完成后，由產品經理把需求細化的成果說給相關干系人聽，下面會有詳細說明。

設計評審：概要設計與詳細設計完成之后，由開發工程師把對需求的理解以設計文檔的形式說給產品和測試聽。

測試評審：在TC編寫完成，測試開始執行之前進行，有測試工程師把對需求的理解以TC的形式說給產品和開發聽。

除需求評審外，設計評審和測試評審也很有必要，進入執行階段后，如果因為需求理解不一致或有偏差，返工的成本會隨著項目的進展越來越高。

一般我們會在做出比較大粒度的PRD之后馬上安排一次評審，當然會有UC和Demo的半成品，以期盡早發現問題，比如業務規則的不合理，產品界面太丑陋，某功能技術上無法實現。

這次的評審偏商業部分，建議叫上老板、營銷人員、服務人員，甚至用戶一起來聽。

粗粒度的PRD通過以后，PM會和Ui一起細化UC和Demo，而開發會同步進行一些開發前的準備工作，比如細化和修正項目計劃，部分系統的設計等，當然這些在評審的過程中會做多次。

接下來是Demo的評審，決定了產品的外觀，項目干系人最好把一下關，而UC評審偏更偏重技術實現，商業團隊人員可以不參加。

（3）需求確認

項目啟動之后，PM就得抓緊時間完成需求的開發，不時召集需求評審會，大家一起討論這樣做有哪些問題。

PM收集意見發布修改，直到最后一次，需求得以確認， 狀態變為“開發中”。

當然，之后的需求微調總是無法避免，但是“需求凍結”的里程碑要求我們在這之后不要輕易改動了。

3. 開發階段

開發階段的流程如下：

1. 開發經理或能力比較強的開發工程師會帶著普通工程師一起做概要設計、詳細設計。
2. 設計完成后會組織一次設計評審，產品和測試人員都會參與，審核一下工程師們對需求的理解是否正確。
3. 評審通過后，進入編碼階段。
4. 之后工程師需要對自己的代碼進行單元測試，自測環節做到位，可以減少測試人員的很多工作量。
5. 當開發工程師認為自測已完成，就可以把代碼提交到測試環境。按照開發計劃，當項目主體部分提交測試的時候，我們就走過了一個里程碑—開發完成。

4. 測試階段

測試階段流程如下：

1. 開發工程師在設計與編碼的同時，測試工程師也沒有閑著，他們會繼續細化和調整測試計劃，并完成測試用例的編寫。
2. TC編寫完成后，測試經理會組織TC評審，時間一般在開發人員提交測試之前，PD和開發人員都要參加，再次確認大家對需求理解是否一致。很多需求的細節無法再需求階段考慮完全，我們會通過開發和測試階段的反復溝通不斷細化。
3. ?TC評審通過，待開發提交測試后，測試人員會迅速進行一輪“冒煙測試“，目的是確認軟件基本功能正常，可以進行后續的正式測試工作。
4. ?在測試人員開始做正式測試的同時，產品經理又出場了，他們會組織一場“功能評審會“，利用測試環境，第一時間把需求展示給所有的項目干系人，進一步確保做出來的東西是大家想要的。

接下來，測試會進行多輪測試，直到項目滿足上線條件，項目就進入了發布階段。

5. 發布階段

發布階段流程如下：

1. 擬定發布計劃（checklist）：包括發布時間、發布渠道、發布節奏（什么時間點在什么渠道鋪）、應急措施（用戶使用時出現嚴重問題垓如何處理，系統是否可回滾）等，這在可能出現的混亂發布時是很有效的，避免疏漏；
2. ?發布計劃評審：對項目質量、風險點進行評審，得出評審結論，如果整體風險可控，評審通過，則進入預發布環節，反之則需要進一步完善。
3. 正式發布過程：是從更新到“預發布環境“開始的。預發布環境盡量模擬生產環境上的真實狀態，測試人員會在預發布環境進行最后的回歸測試。
4. 在預發布環境回歸測試通過后，按預定的發布時間更新到“生產環境“，測試人員再一次做簡單的回歸測試，完成發布。

6. 項目小結

發布成功！回家睡個好覺。

所有人終于如釋重負，但作為項目事情還沒有完，第一件事就是趕緊發布一封Email—”項目發布公告“，一般會寫的比較煽情，比如：

• ?項目中的各種艱辛
• 對每個參與者的感謝
• 發布之后的內心感言
• 產品對公司和用戶的革命意義
• 貼幾張產品的最新圖片
• ……

根據溝通管理計劃，發送給項目的干系人。

作為項目經理，應該做到時刻為團隊爭取各種精神、物質獎勵，這種郵件、海報、老板的回信……都是很好的鼓勵，如果還有項目經費的話，在組織一次聚餐，大家以后還要繼續合作，開開心心，皆大歡喜。

之后，以終為始，對項目進行回顧，寫一份項目小結，小結一下做這個項目的心得體會，比如:

• 碰到了什么問題
• 原因是什么
• 怎么解決的
• 怎么避免再犯
• 項目資源評估是否合理
• 收獲了哪些經驗
• 如何提高項目的準確度
• 根據數據監控的反饋分析出了什么結果
• 項目的商業目標是否達到
• ……

最后更新至組織的經驗教訓登記冊，方便追溯及參考。

至此，一個產品從“想清楚“到”做出來“已經聊完了，我們可以根據需求選擇性閱讀，這里是各個流程的概述，我們可以通過其他資料進行針對性的完善。

本文由 @PM_COOL 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議