第三章：產品設計

產品設計是一個由抽象的概念到具體形象化的處理過程，通過文字或圖像等方式將我們規劃的產品需求展現出來。它將產品的某種目的或需求轉換為一個具體的物理或工具的過程，把一種計劃、規劃設想、問題解決的方法，通過具體的操作，以理想的形式表達出來。

由于產品設計階段要全面確定整個產品策略、外觀、結構、功能，從而確定整個產品系統的布局，因而，產品設計的意義重大，具有“牽一發而動全局”的重要意義。如果一個產品的設計缺乏具體形象的表述，那么研發時就將耗費大量資源和勞動力來調整需求。相反，好的產品設計，不僅表現在功能上的優越性，而且便于執行時理解，從而使產品的研發效率得以增強。

1、產品需求文檔介紹

產品設計的最終表述的形式被稱為產品需求文檔，業界常常稱呼為PRD文檔，這是英文Product Requirement Document的縮寫。產品需求文檔是將產品規劃和設計的需求具體形象化表述出來的一種展現形式，主要用于產品界面設計和研發使用。

PRD文檔是基于BRD、MRD的延續文檔，主要是一份給執行層面的工作人員閱讀的文檔，這部分人群絕大多數是設計與技術人員。在這類人群中，設計師更多依賴于產品原型進行交互或視覺的設計，因此看這份文檔的人主要是技術人員。相對于技術人員，他們不太關注產品的商業需求和市場愿景，因為在進行產品討論立項時，產品的定義就已經向參與設計和研發的人員宣講過，因此技術人員更多的是關注界面、功能、交互、元素等等內容，因此產品需求文檔是一份詳細的產品功能需求說明文檔，是產品文檔中最底層和最細致的文檔。

因為閱讀人類的因素，所以產品需求文檔是一份沒有閑話，直入主題的功能說明文檔。并且產品需求文檔是沒有標準規范的，也沒有統一的模板，每個公司都不一樣和每個人也不一樣，這個取決于個人習慣和團隊要求。雖然產品需求文檔沒有明確的規范，但是目的都是一樣的，必須能夠明確產品的功能需求，便執行人員理解任務要求。

2、產品需求文檔寫作

產品需求文檔是產品經過規劃和設計之后的最終執行文檔，因此這份文檔的質量好壞直接影響到執行部門是否能夠明確產品的功能和性能。

2.1、羅列信息（信息結構圖）

在寫產品需求文檔之前，我們需要先羅列出產品功能的信息內容，這一步是將想法逐漸清晰的第一步，也是幫助我們接下來設計功能的輔助信息，同時也可以輔助服務端技術人員創建數據庫。因為這是第一步，所以我們不需要羅列的很詳細，在之后的步驟里，我們會逐步改進和完善信息內容。

羅列信息內容的方式有很多種，文本形式、思維導圖形式等等都可以，最主要的是能夠清晰易懂，我最常用的方法就是使用思維導圖軟件(MindManager)羅列成結構圖，因此我稱這一步為“信息結構圖”。

上圖是一張以Blog系統為示例的信息結構圖。信息結構圖是一種接近數據庫結構的圖表，在羅列信息結構時，更多的是考慮信息數據，但是他并不是真正意義的數據庫結構。信息結構圖是提供給產品經理自己梳理信息內容的結構圖，也是方便產品經理和服務端技術人員溝通數據結構的參考圖，技術人員會根據這張圖表的內容再結合產品原型或需求文檔，然后規劃和設計出真正意義上的數據庫結構。

信息結構圖中關于友情鏈接功能的信息數據只有“名稱”和“鏈接”兩個內容，但是在實際功能需求中，友情鏈接還有兩個功能，分別是“顯示或隱藏”和“是否新窗口打開”，這兩個功能會在產品原型和需求文檔中詳細描述，但是在信息結構中是沒有體現的，因為從產品層面上來說，這兩個只是功能，并不是信息內容。但是在真正數據庫中，友情鏈接的這兩個功能分別也是有字段參數的，程序在讀取該參數后便知道友情鏈接的屬性，然后處理友情鏈接是顯示還是隱藏，是新窗口打開還是本窗口打開。通過友情鏈接這個例子，我們就知道了在實際中數據結構和信息結構是不一樣的，信息結構只是產品層面的數據內容。

無論是什么樣的產品類型，無論從哪里入手，我們第一步都是先要羅列信息結構，因為信息結構圖不僅是輔助技術人員創建數據庫的圖表，也是輔助產品人員進行產品功能規劃的參考，只有對信息或數據的結構了解了，我們才能更好的設計產品。信息結構圖是我們將概念想法形成結構化的第一步，也是我們接下來幾步工作的輔助文檔，同時在接下來的幾步工作中，我們還會不斷的完善信息的結構。

2.2、梳理需求（產品結構圖）

當我們對產品的信息結構了解后，我們就需要規整腦海中的產品需求，讓想法更加結構化，因此這一步就要梳理產品的需求。在設計產品原型之前，我們首先要羅列出產品的功能結構，包括頻道、頁面、模塊及元素。這一步依然使用思維導圖軟件，像繪制樓盤鳥瞰圖一樣將產品的結構繪制成結構圖，因此我稱這一步為“產品結構圖”。

產品結構圖是一種將產品原型以結構化的方式展現的圖表，結構內容也如同產品原型一樣，從頻道到頁面，再細化頁面功能模塊和元素。所以產品結構圖是產品經理在設計原型之前的一種思路梳理的方式，并不是給其他工作人員查看的文檔，通過類似鳥瞰式的結構圖可以讓產品經理對產品結構一目了然，也方便思考。

如上圖示例，“活動大全”的產品結構依次是：產品 -> 頻道 -> 頁面 -> 頁面元素 -> 操作 ->元素。我們換一個角度觀看示例，產品結構圖實際上就是一種結構化的產品原型。這樣做的目的就是梳理產品結構邏輯，讓我們清楚的知道產品有幾個頻道，頻道下面有沒有子頻道或者有多少個頁面，這些頁面里又有哪些功能模塊，這些功能模塊里又有哪些元素。

上圖以我們第一步的“信息結構圖”為基礎繪制的“產品結構圖”，有了這份結構導圖，我們可以對產品進行鳥瞰式考慮和完善，當有問題時，修改起來也比原型和文檔方便很多。比如在后續規劃中，我們發現文章的圖片等附件上傳后，管理不太方便，這時就可以在結構圖中增加一個“附件管理”頻道。如果我們使用產品結構圖的方式，那么附件管理的功能增加和修改就會比原型工具更加便捷和效率。

產品結構圖的方法同樣適用于移動互聯網產品的設計，并且比起Web產品更加容易梳理產品結構。

產品結構圖是一種讓產品經理通過思維導圖的方式梳理思路的方法，通過這種方法可以明確產品有多少個頻道、有多少個頁面、頁面有多少個功能模塊、功能模塊有多少個元素，逐步的將腦海里的想法明確梳理成結構。雖然這種方法能夠明確產品的結構，但是這樣的思維導圖也就只有產品經理自己能夠看懂，因為對于設計和技術人員這是一個抽象的表述方式，如果沒有詳細的講解，是很難理解的。

產品結構圖是將產品原型具體化的一種方式，只是羅列了產品的頻道頁面和功能，但是沒有詳細的進行推演，關于細化方面是否符合產品邏輯，是否符合用戶體驗，這些都是沒有深思過的，因此我們接下來就要進行原型設計，開始具體的考慮可行性。

2.3、原型設計（界面線框圖）

當我們逐漸清晰了產品的需求后，并梳理了產品的各個頻道及頁面，那么這一步就要開始驗證這些想法的具體界面表現和方案的可行性了。

原型設計是幫助我們更細致的思考，并做各項需求的評估，同時也是將自己腦海里的想法進行輸出的一種方式。通過原型設計后，我們就可以進行產品宣講了，相比較于抽象的文字描述，原型則更加直觀的展現產品的需求，設計和技術人員或者老板也能夠更加直觀的了解到產品意圖。

原型設計是將結構化的需求進行框架化，因此原型也被稱為線框圖，具體的表現手法有很多種，相關的輔助軟件也有很多，例如：Axure RP、Balsamiq Mockups、UIDesigner等等。

當到了原型設計這一步時，已經不僅僅是構思了，我們需要更加深入的了解每個頁面上元素和這些元素的屬性。例如按鈕元素，我們就需要考慮這個按鈕的功能，并且這個功能操作后帶給后端和前端的反饋。例如注冊會員按鈕，用戶操作后，第一步邏輯是驗證用戶輸入的信息是否合法，不合法則給出前端反饋；合法則和后端通信驗證是否已經存在同樣信息，已經存在則給出前端反饋，不存在則進入下一步，注冊成功；注冊成功后的反饋是跳轉頁面，還是彈出層提示用戶完善資料，

這些都是需要更詳情的考慮。當然這些更細致的思考是留在需求文檔撰寫時的，而此時我們需要做的就是把這些元素通過原型表現出來。

原型設計的表現手法主要有三種：手繪原型、灰模原型、交互原型。從工作效率的角度考慮，我非常建議先通過手繪的形式快速在草紙上繪制出產品的原型，推演和討論方案的可行性。當方案的可行性被驗證之后，我們再根據個人習慣或團隊要求，通過軟件工具進行更深入的設計。

① 手繪原型

因為原型也被稱為線框圖，因此手繪是最簡單直接的方法，也是最快速的表現產品輪廓的手法。

手繪原型在初期驗證想法時非常高效，也方便討論和重構，同時也適合敏捷開發時快速出原型。

② 灰模原型

灰模原型是由圖形設計軟件制作而成，最常用的軟件是Photoshop和Fireworks，相對手繪原型，灰模更加清晰和整潔，也適用于正式場合的PPT形式宣講。

灰模原型也可以稱之為平面原型，所以如果不會使用圖形軟件也可以使用Axure RP設計，相比交互原型，灰模原型只是缺少交互效果，僅僅是將產品需求以線框結構的方式展示出來，讓產品需求更加規整的直觀展現。

③ 交互原型

交互原型是使用原型設計軟件完成的原型，常用軟件是AxureRP，通常情況交互原型的設計要早于產品需求文檔，是產品經理想法推演的重要一步。通過AxureRP之類的交互原型軟件制作出來的產品原型，在功能需求和交互需求的表現上，幾乎和正式產品是一致的，所以有時交互原型也被稱為產品Demo版。

通常情況下交互原型是產品經理與交互設計師共同討論確定，然后由交互設計師制作，但是絕大多數的公司是沒有交互設計師這個職位的，因此這類工作最終是由產品經理來負責的。

以上三種方法并不是漸進的流程，而是三種原型設計的方法，具體取決于你的產品需求和團隊要求。

對于產品經理來說，原型設計是為了幫助我們細致的考慮方案，并論證方案的可行性，同時也是為了產品宣講時讓聽眾能夠清晰直觀的了解產品，避免抽象的語言描述導致聽眾理解困難和理解偏差。產品原型也是為了確保產品在執行過程中，是按產品經理最初設想的需求和期望完成的，因此產品經理的原型是沒有很高的要求的，只要對方能夠聽懂看懂就可以了，所以使用手繪原型是最高效率的方法。

2.4、用例模型（產品用例圖）

用例(UseCase)是一種描述產品需求的方法，使用用例的方法來描述產品需求的過程就是用例模型，用例模型是由用例圖和每一個用例的詳細描述文檔所組成的。在技術和產品的工作領域里都有用例模型的技能知識。技術人員的用例主要是為了方便在多名技術人員協同工作，或者技術人員任務交接時，讓參與者更好的理解代碼的邏輯結構。產品人員的用例主要是為了方便技術研發和功能測試時，讓參與者更好的理解功能的邏輯。

用例起源和發展于軟件時代的產品研發，后來被綜合到UML規范之中，成為一種標準化的需求表述體系。雖然用例在軟件研發和技術工作中應用的非常廣泛，但是在互聯網產品規劃和設計中，并不經常使用，互聯網產品的需求表達為了敏捷效率，通常采用原型加產品需求文檔。

UML是英文Unified ModelingLanguage的縮寫，中文稱為統一建模語言或標準建模語言，是用例模型的建模語言，常用工具是Microsoft OfficeVisio。產品用例是一種通過用戶的使用場景來獲取需求的方式，每個用例提供了一個或多個場景，該場景說明了產品是如何和最終用戶或其它產品互動，也就是誰可以用產品做什么，從而獲得一個明確的業務目標。

① 用例圖

用例圖并不是畫成了圖形的用例。用例圖包含一組用例，每一個用例用橢圓表示，放置在矩形框中；矩形框表示整個系統。矩形框外畫如圖所示的小人，表示參與者。參與者不一定是人，可以是其它產品、軟件或硬件等等。某一參與者與某一用例用線連起來，表示該參與者和該用例有交互。

許多人通過UML認識了用例，UML定義為展現用例的圖形符號。UML并不是為描述用例定義書寫格式的標準，因此許多人誤認為這些圖形符號就是用例本身；然而，圖形符號只能給出最簡單的一個或一組用例的概要。UML是用例圖形符號最流行的標準，但是除了UML標準，用例也有其它的可選擇的標準。

② 用例描述文檔

用例圖只是在總體上大致描述了產品所能提供的各種服務，讓我們對于產品的功能有一個總體的認識。除此之外，我們還需要描述每一個用例的詳細信息，這些信息應該包含以下內容：

用例名稱：本用例的名稱或者編號

行為角色：參與或操作(執行)該用例的角色

簡要說明：簡要的描述一下本用例的需求(作用和目的)

前置條件：參與或操作(執行)本用例的前提條件，或者所處的狀態

后置條件：執行完畢后的結果或者狀態

用例描述文檔基本上是用文本方式來表述的，為了更加清晰地描述用例，也可以選擇使用狀態圖、流程圖或序列圖來輔助說明。只要有助于表達的簡潔明了，就可以在用例中任意粘貼用戶界面和流程的圖形化顯示方式，或是其它圖形。如流程圖有助于描述復雜的決策流程，狀態轉移圖有助于描述與狀態相關的系統行為，序列圖適合于描述基于時間順序的消息傳遞。

在互聯網產品和設計中，用例的使用越來越少，通常有了產品原型再加上功能流程圖和功能說明文檔就能夠將產品需求詳細的表述清楚，所以也沒有必須撰寫用例了。但是在大公司里，往往會追求產品流程的規范性，要求撰寫用例，不過在敏捷開發的時候也會采用其它更有效率的方式，不一定非要撰寫用例。

前面幾步我們將產品需求逐漸細化并且通過原型的方式將產品需求形象化的展現了出來，但是在產品功能的邏輯細節方面，原型就非常不直觀了，所以用例是一個非常重要的描述需求過程的文檔。

但是由于用例文檔以文字為主，并且格式復雜，不適用于高效率的產品需求表述，所以展現邏輯流程的“功能流程圖”是一個簡潔直觀的可替代用例文檔的方式。

如上圖所示，功能流程圖是一種使用圖形的方式表示算法邏輯的圖表，因為千言萬語不如一張圖，通過流程圖將“優惠券”功能模塊的邏輯和需求非常形象直觀、一目了然的展現了出來。

流程圖的展現方式也不會產生“歧義性”，便于理解，邏輯出錯時也非常容易發現，并且可以直接轉化為程序需求描述文檔。

2.6、需求文檔（PRD文檔）

前面的幾個步驟是為了幫助我們梳理需求、驗證可行性和明確細節，到了這一步的時候我們已經非常清晰的了解產品需求，此時撰寫產品需求文檔可以大大減少和避免了撰寫文檔時容易忽略的細節黑洞。

產品需求文檔是將產品規劃和設計的需求具體形象化表述出來的一種展現形式，主要用于產品界面設計和研發使用。因為每個人的習慣和團隊要求都是不一樣的，所以產品需求文檔沒有統一的行業規范標準，無論以什么樣的格式撰寫產品需求文檔，最終的目的都是讓執行人員能夠理解產品需求，根據需求完成產品。

產品需求文檔的表現形式有很多種，常見的有Word、圖片和交互原型這三種形式，文檔內容通常包含信息結構圖、界面線框圖、功能流程圖、功能說明文檔。雖然產品需求文檔沒有標準的規范，但是有兩項是必不可少的，那就是文件標識和修改記錄。文檔在撰寫過程中，我們可以自行不斷的修改完善，但是如果正式發布或交給團隊其他成員后，一旦有了修改，為了文檔的同步，我們就需要標注出文檔的修改內容，備注修改記錄，這樣可以方便大家查看和了解改動的內容。關于文件標識和修改記錄，格式都大同小異。

① Word

這是傳統意義上的產品需求文檔，主要有四個部分組成(具體根據產品要求進行劃分)，分別是：結構圖、全局說明、頻道功能、效果圖。

因為產品需求文檔的閱讀者主要是偏向于技術人員，因此文檔的目的性非常明確，就是要描述產品的功能需求，所有產品需求文檔沒有關于市場方面的描述。

為了保證需求的執行效率，建議大家盡量減少不必要的文字，在能夠讓閱讀者看懂并且了解產品意圖的情況下，文字越少越好。這主要是因為絕大多數人是沒有足夠耐心認真看完產品需求文檔的，因此我們要盡量減化文檔內容。

①-1、結構圖：

①-1.1、信息結構圖：主要是輔助服務端技術人員創建或調整數據結構的參考文件

①-1.2、產品結構圖：主要是輔助設計和技術開發人員了解產品的全局結構。

①-2、全局說明：

主要講解產品的全局性功能的說明，例如網站產品的頁面編碼、用戶角色，移動產品的緩存機制、下載機制，這類全局性功能的說明。這里我舉一個移動產品的“狀態維持與恢復”的例子。示例如下：

狀態的維持與恢復

當用戶退出產品時（誤操作、Home鍵、鎖屏、自動關機），產品需要維持用戶操作前的狀態，當用戶返回產品時仍可以恢復到之前狀態，并繼續使用。

維持狀態包括流程操作、信息瀏覽、文本輸入、文件下載。

鎖屏狀態時，如果用戶在產品中有下載任務時，仍然保持下載。

①-3、頻道功能：

以頻道為單位，頁面為子項，分別描述產品的頻道、頁面及頁面模塊元素的功能需求。示例如下：

1、頻道名：頻道介紹及需求說明

2、頁面1：頁面介紹及需求說明

2.1、頁面模塊1：模塊功能需求說明

2.1.1、頁面模塊1-元素1：功能說明

2.1.2、頁面模塊1-元素2：功能說明

2.2、頁面模塊2：模塊功能需求說明

在撰寫功能需求時，我們需要考慮用戶的流程，例如一個“完成”按鈕，我們需要描述他完成后，系統要不要給出反饋提示(反饋提示是什么樣的形式反饋，內容顯示成什么，有沒有內容需要調取數據庫)，或者要不要跳轉頁面(跳轉到哪個頁面，這個頁面是其他頻道頁面，還是這個功能的子頁面，如果是子頁面就需要再描述這個子頁面的模塊及元素內容)。

①-4、效果圖：

效果圖是由設計師完成的產品圖，和實際開發完成的產品保真度一致。

這個示例是一個移動產品(iPad)需求文檔，其中部分隱私內容已過濾隱藏，并且只保留了首頁和地圖找房頻道的需求說明。由于工作環境沒有交互設計師，所以Word文檔中包含了部分交互說明。

② 圖片

圖片形式的產品需求文檔是基于效果圖的說明文件，將傳統Word形式的功能需求說明標注在效果圖上，這種方式經常使用在移動互聯網領域，實際上是圖文形式的交互需求文件，只是在此基礎上更深入的描述出功能需求。

對于圖片形式的產品需求文檔，我們只需要另外再描述一下全局說明，其他頻道頁面的需求直接以圖片形式展示，這種方式相對于Word文檔的純文字更加生動易讀并且直觀，因此有一些產品經理非常喜歡用這種方式代替Word形式的產品需求文檔。

③ 交互原型

這里指的交互原型就是前面篇章講到的原型設計，使用Axure PR之類的交互原型設計軟件制作出來的產品原型非常真實和直觀，并且原型軟件還支持元素標注和導出Word文檔，因此很多產品經理都喜歡使用Axure PR來代替Word完成產品需求文檔。

當我們通過Axure PR制作出產品原型后，實際上他已經是很完善的產品Demo了，因此我們只需要加上元素的標注，在標注中說明功能需求，這樣導出的HTML文件相比Word文檔更直觀易懂，是非常高效的產品需求說明方式。

無論你采用哪種方式撰寫需求文檔，最終的目的都是為了方便團隊成員理解產品的意圖，因此哪種方法能夠避免細節黑洞，高效完成產品的設計和研發，那么這種方法就是最有效的方法。

第四章：產品管理

產品管理是公司為了管理一個產品或者產品線的產品計劃、產品市場和產品生命周期所采用的組織架構。產品管理是一個非常典型強矩陣型的管理方式，工作性質包括項目管理，但并不完全等同于項目管理，主要負責在產品生命周期中對產品規劃、設計、開發、運營等環節進行管理或支持的工作，負責這項工作的人被稱之為產品經理。

1、產品管理介紹

從產品的需求開始到產品淘汰報廢的全部生命歷程被稱為產品生命周期。在產品的整個生命周期中，產品經理需要打破部門壁壘，整合跨部門資源，實現面向市場的產品規劃和設計，確保和企業戰略的一致性。工作內容包括產品戰略、產品市場、產品需求、產品規劃、產品開發、產品上線等工作事項的管理。

雖然產品管理涉及的層面比較廣，但是實際中產品經理的工作內容并非全是如此。業界普遍的產品管理流程是由公司高層領導確定戰略規劃和方向，項目負責人分解戰略并細化，同時確定階段目標，最后由產品經理負責產品需求的規劃和設計，然后溝通和協調研發團隊完成產品需求的開發和上線。

因此產品經理除了管理產品規劃和設計之外，還需要對產品的執行進行溝通和協調，促進團隊合作，驅動產品工作的正常進行。

2、需求管理

產品因需求而生，在產品的整個生命周期中，產品經理會收到來自各個方面的需求，但是每一個需求的必要性、重要性和實現成本都需要經過深思熟慮的分析和計劃，避免盲目的決定需求或者變更需求，這樣很容易導致工作混亂，所以產品經理首要的管理工作就是對需求進行管理。

需求管理的第一步就是要梳理不同來源的需求，需求主要來自公司內部(老板或領導、其他部門或同事)、外部(用戶、客戶、合作伙伴)、還有產品經理自己(調研策劃或靈感)。當需求匯集到產品經理手里之后，我們可以根據之前在“產品規劃”章節中介紹的“需求分類”的方法，將需求進行分類管理。分類管理的常用工具有Project、Execl、MindManager等，我常用的是Execl和MindManager軟件。

需求管理的最終工作就是需求分析和決策，關于分析和決策的方式方法我們在之前的“產品規劃”章節中詳細為大家介紹過了，但是除此之外，需求管理中最重要的就是對發散性需求的管理，往往因此也會導致產品在執行過程中不斷的變更或增加需求。

由于人的思維是發散性的，所以往往在產品構思的過程中會出現各種新鮮好玩的想法，這些想法可能來自領導或者產品經理自己，但是這些想法往往都是和產品核心方向不相關的，但是由于這些想法能夠在當時帶來誘惑，因此這些不相關的需求會嚴重干擾了團隊的精力，打亂或者延誤產品原本的計劃。

很多時候需求的變更或增加是因為我們面臨太多選擇和想要的太多，沒有適當的控制自己的欲望，并以自己的喜好來決定需求，這些因素很容易導致產品沒有明確的方向、團隊成員疲于奔命，但是卻沒有實際的成果。

往往當我們擁有一個非常興奮的想法時，此時我們只是無知的樂觀，而實現這個想法則需要各個部門的配合，當隨著在這個想法上花費了越來越多的時間并且開始學習所有關于這個想法的相關事務時，我們才能意識到一個未經深思熟慮的想法所帶來的后果，這些因果最終很有可能將產品帶入危機中。

所以在需求管理的時候，產品經理首先需要控制自己的欲望，基于產品規劃的三個考慮因素和四個設計理念，重新審視產品和篩選需求的優先級，識別每一個需求的必要性、重要性和實現成本。通過深思熟慮給團隊明確方向并專注，聚焦資源的支配，確保團隊的精力都聚焦在產品的核心需求上。

3、目標管理

目標管理是以目標為導向，以人為中心，以成果為標準，而使組織和個人取得最佳業績的現代管理方法。目標管理亦稱“成果管理”，俗稱責任制。是指在企業個體職工的積極參與下，自上而下地確定工作目標，并在工作中實行“自我控制”，自下而上地保證目標實現的一種管理辦法。

3.1、產品目標管理

一個團隊的執行力低，最主要的因素就是因為領導者的執行力低下，決策效率低，無法給團隊傳達明確清晰的目標。如果領導者沒有目標管理的意識，很容易在傳達需求的時候模棱兩可，導致執行者對任務內容和目標不夠清晰，以及對所要執行的事情的重要性理解不夠，最終結果可能就是未完成或者延期完成。

目標管理并不是有了任務才有目標，而是相反，有了目標才能確定任務內容和方向，也才能對其進行有效分解，轉變成各個部門以及各個人的子目標或者小目標。

產品經理作為最終執行的領導者，需要將戰略和階段目標進行更加細化的規劃，讓籠統的目標可以具體到版本需求，便于設計師和工程師執行，所以在工作中產品經理還要有一些項目管理的常識，細化和制定需求的實施計劃，并且跟進實施進度。

運用目標管理的方法，產品經理將戰略與階段目標進行了細化，規劃和設計出了產品的各個迭代版本的需求。當有了這些細化的子目標之后，產品經理就可以對其進行有效的分解，轉變成各個部門或者各個人的任務和目標，此時便可以協調團隊成員完成產品需求的研發。

3.2、使用目標管理

目標管理的具體形式各種各樣，但其基本內容是一樣的。在業界被廣泛使用的“SMART原則”是目標管理中的一種方法，能夠有效地進行成員的組織與目標的制定和控制，SMART原則要求制定的目標要達到五個標準：明確性、衡量性、可達成性、相關性和時限性。

① 明確性

產品需求的任務和目標一定要明確，不能夠模糊。例如：“通知開會”，這就是一個籠統的目標。一個有明確性的目標應該這樣表述，“6月2日下午

15:00在一號會議室召開XX項目設計方案討論會，設計部XX項目組所有成員參與，會議時長2小時”。傳達一個明確的目標才能獲取最大的完成幾率。

所謂明確就是要用具體的語言清楚地說明要達成的行為標準。明確的目標幾乎是所有成功團隊的一致特點。很多團隊不成功的重要原因之一就因為目標定的模棱兩可，或沒有將目標有效的傳達給相關成員。

② 衡量性

目標需要可衡量，而可衡量往往需要有數字，把目標量化。如果制定的目標沒有辦法衡量，就無法判斷這個目標是否實現。可衡量的標準就是需要確定任務數量是多少？做成什么樣才是完成？完成要花多少時間？等等。

③ 可達成性

一個目標必須是可以實現的，或者說經過努力是可以實現的。所以任務目標要是執行者能力范圍內可以達到的。換言之就是目標要現實，例如讓執行者去移動公司給聯通手機號充值話費，這就是一個不現實的任務，不具備可達成性。

④ 相關性

目標的相關性是指實現該目標與其他目標的關聯情況。如果實現了這個目標，但對其他的目標完全不相關，或者相關度很低，那這個目標即使被達到了，意義也不是很大。因為畢竟工作目標的設定，是要和崗位職責相關聯的，不能跑題。

比如產品需求是研發一個iOS系統的APP，任務要求學習“iOS人機界面指導手冊”以便更好的理解系統特性和設計規范，這樣有助于提升APP的用

戶體驗。這個任務就是和目標有關聯性的，但是如果任務是學習“Android設計規范”，那么就跑題了，因為學習“Android設計規范”這一任務與研

發iOS系統的APP這一目標相關度很低。

⑤ 時限性

目標特性的時限性就是指目標是有時間限制的。必須具有明確的截止期限，即一個目標只有在一定的時間內達成才有意義。給目標一個確定的完成時間，這會有助于執行者集中精力完成目標。時限性的要求可以幫助執行者避免因為日常瑣事而耽誤了完成目標的進度。

產品經理作為團隊合作促進者、執行力驅動者、工作效率提升者，必須對目標管理有著很深的理解，在傳達產品需求和任務的時候，使用“SMART原則”可以大大提升團隊的執行效率，給執行者很明確的任務目標和時限。避免執行人不知道該如何執行，或者需要執行的事情有難度，難到不知道該如何下手。

4、團隊溝通

僅僅掌握了需求和目標的管理還是不夠的，當產品經理規劃和設計好產品需求之后，就要通過溝通來協調研發團隊完成產品需求的開發和上線。溝通是人與人之間、人與群體之間思想與感情的傳遞和反饋的過程，以求思想達成一致和感情的通暢。但是產品經理的溝通不僅僅是一種交流，目的是通過溝通傳達產品需求和意圖，以及驅動需求和意圖的執行，所以產品經理的溝通是一種執行溝通，溝通效率決定了工作效率。

產品經理作為團隊中的樞紐崗位，絕大多數的時間是用于溝通的，通過溝通促進團隊合作、驅動項目執行，所以掌握團隊溝通的技巧非常有助于我們提升工作效率。

4.1、積極主動溝通

產品經理是產品規劃和設計的直接責任人，需要多部門溝通和協調，擔當團隊的執行力推動者，所以在工作中要積極主動的溝通。

很多時候，團隊成員因為各種因素，或是忙忘了，或是不擅長主動溝通，導致工作反饋不即時，所以產品經理在工作中有工作反饋等需求時，不要等別人給，主動要。并且在工作中要積極響應需求任務，產品規劃和設計要盡量提供完善資料，不要等別人要，主動給。

4.2、換位思考溝通

產品經理需要換位思考溝通，明白各個職位的想法和知識，即時調整自己的溝通方式，要以通俗易懂的詞語和對方溝通。很多時候我們以為對方懂了，其實對方聽的很迷糊，所以在溝通中千萬別主觀的認為對方懂了，需要在溝通中互動反饋，確認對方是否真的懂了產品需求的意圖。

4.3、直接跟進工作

為了避免信息傳遞的失真，產品經理應當直接和相應的執行人溝通。在任務分配時，由部門負責人安排工作人員，產品經理直接和相應的工作人員對接，直接跟進工作，避免信息傳遞失真，也保證需求和進度。

從產品原型開始，團隊之間就應該保持密切的合作，產品經理確定產品的需求，明確產品要做什么，然后調動大家積累參與到產品的設計當中。從設計部獲得最佳的用戶體驗與交互設計方案，從技術部獲得最新的技術動態，以便分析能否應用到產品當中。特別是與技術部的合作更為密切，產品經理需要了解自己規劃的產品原型從技術層面能否實現。同時也要跟技術人員溝通需求，了解是否有其他更優的解決方案。

4.4、明確工作任務

溝通中我們需要使用目標管理的方法向對方明確的傳遞工作任務，其中包括任務內容、任務目標、完成時間、任務優先級。

4.5、減少文字溝通

工作中我們或多或少會用到文字溝通，其中包括產品需求文檔、任務郵件等等。但是文字的表述是遠遠比不上當面的溝通更有成果，所以我們要盡量避免使用文字溝通，而在文字溝通時千萬別長篇大論，精簡不必要的話，直入主題。產品需求盡量使用原型表述，有說明文字以標注的形式集成在原型中。

4.6、把握時間節點

在工作中我們是不希望被別人打擾的，同樣產品經理在溝通時要注意把握時間點，在不打擾的對方的情況下找其溝通。最好是先發一封郵件，讓對方先大概了解溝通主題。

4.7、虛心接受反饋

能力的提升是通過不斷的學習、總結和檢省，因此我們需要虛心接受別人反饋的建議。如果反饋不正確或者反饋是一種抱怨與指責，那么我們先發自內心的承認錯誤，然后檢省自己并尋找問題所在，千萬別互相抱怨和互相指責，這容易讓問題越來越嚴重。

4.8、化解壓力與矛盾

產品經理是團隊的樞紐點，也是壓力、矛盾的集中營，所以我們自己需要有一個良性的化解壓力的方法，在解決自身壓力的同時還要化解團隊的矛盾。

解壓的方法每個人都有不同，但是化解矛盾都是大同小異的。團隊矛盾往往先是從抱怨與指責開始的，我們在接受反饋的時候，如果遇到抱怨與指責的時候需要清楚，這是一個毒瘤，會越長越大，最終會直接影響團隊的和諧，所以我們必須要制止它的發展，避免大家陷入這樣的慣性旋窩中。

抱怨與指責是雙向的，別人可以迷失，但是我們作為產品經理必須要保持理性，結束抱怨與指責，主動道歉，終止抱怨與指責不斷的擴大。那怕不是我們的錯，但是我們是產品經理，終止毒瘤的發展是我們的職責，等待大家保持冷靜后再溝通。因此產品經理需要時刻保持理性，除了虛心接受團隊成員的反饋，還要努力化解和減少抱怨與指責，更不能為自己找借口，必須克服所有障礙，解決所有問題。

4.9、感謝和夸獎

產品是團隊成員共同努力完成的，產品經理作為產品的負責人，需要學會感謝團隊成員的付出，并且要勇于說出感謝。感謝和夸獎可以提升產品經理在團隊成員中的良好印象，減少溝通障礙。

5、團隊協同

一個完整的產品是由團隊合作共同完成的，負責最終執行的工作人員被統稱為研發團隊，研發團隊由產品設計、技術開發兩個方面的崗位組成。產品設計人員包括產品經理、交互設計師、視覺設計師，技術開發人員包括前端、服務端、數據端、測試等方面的工程師。

在大公司里，產品、技術、設計等崗位的工作人員都被劃分在各自的部門里，然后根據項目再組成虛擬小組，由項目經理或者產品經理帶頭執行產品的研發，所以大公司里的設計和技術等工作人員并不完全只負責一個產品項目。在小公司或者創業型團隊里，可能公司或團隊只有一個產品，所以大家也就共同負責這一個產品。

無論工作環境如何，產品需求的執行都會涉及到各個方面的工作溝通和協調，在產品研發的過程中，團隊協同的默契度決定了工作的效率。但是在研發團隊中，每個人的想法都是不一樣的，默契也需要很長時間的磨合，如果我們能夠了解到各個崗位工作人員的想法，那么對于減少磨合周期，提升溝通和工作的效率，無疑是一個非常好的途徑。

① 交互設計師：想的是用戶體驗

在很多公司里是沒有單獨的交互設計師崗位的，通常都是由產品經理直接負責，所以產品經理等于半個交互設計師。在有交互設計師崗位的公司里，由于產品經理和交互設計師都會考慮用戶體驗，所以多多少少產品經理也會參與到交互設計的環節，在產品需求設計的時候很容易會和交互設計師的工作重疊，因此在工作中和交互設計師產生分歧也是常事了。

雖然產品經理比交互設計師更懂用戶需求，并且對產品感覺、把握項目進度等等綜合能力要強于交互設計師。但是交互設計師比產品經理更了解用戶行為習慣，了解用戶體驗。所以在工作中，產品經理需要相信交互設計師在領域內的專業性，畢竟交互設計師是專業人士。

交互設計是一種在用戶純主觀使用產品過程中建立起來的感受，用戶的行為習慣除了使用設備的基礎特性外，往往操作習慣都是被引導的，至于一個按鈕放在A位置還是B位置，在產品需求的本質上區別并不大，相信交互設計師的決定是經過專業思考的。所以產品經理在交互設計之前，只要充分和交互設計師溝通，表明產品需求和意圖，然后只要把控交互設計沒有破壞掉產品的需求和意圖。

② 視覺設計師：想的是風格美觀

視覺設計也是一種藝術，但凡是藝術的東西，都是一種主觀的行為，沒有絕對的對錯之分，也沒有懂與不懂，只有審美與訴求點不一樣而已。所以產品經理和視覺設計師之間是很難用主觀或者抽象的知識去互相說服對方的，畢竟大家的視野角度不一樣。

例如自行車產品，產品經理只需要把控好自行車這個產品的本質需求和意圖是按照產品規劃完成的即可，至于自行車的色彩風格，相信視覺設計師在色彩風格上面的美術研究要比產品經理更專業。

產品設計的本身是為用戶服務的，所以視覺也是一種溝通與傳達，當我們對視覺設計方案有異議的時候，我們應當充實自己在視覺領域的知識，盡量使用具體形象化的表述方式描繪視覺想法。如果產生爭議，我們可以多做幾個視覺設計稿，讓團隊其他工作人員或者用戶參與設計稿的體驗，收集他們的建議和反饋。

③ 技術工程師：想的是實現模型

技術人員是產品從規劃設計到實現的最后一步的執行人員，負責產品需求的開發工作，所以技術人員在理解需求的時候，考慮的是需求在技術層面的實現方法，想的是實現模型。

當需求到了實現的時候，如果存在考慮不周全的細節時，就很容易造成技術邏輯不通，往往這些因素會導致需求不夠完善，需要重新設計或者變更，這種情況就會造成技術人員之前工作量的浪費。

常見的細節缺失會出現在功能的邏輯流程方面，比如電子商務網站在促銷管理中有一個設置某個商品首次購買可以特價的功能，這個功能背后就有很多關聯性的邏輯，例如在促銷之前已經購買過，還能不能享受這次的特價購買？也就是首次購買是指所有時間的首次？還是從促銷時間之后算起的首次？并且如何遇到提交訂單后但是訂單被拒絕或者客戶取消，再購買算不算首次購買？這個首次購買的定義是指訂單成功運出，還是說只要提交過這個商品的訂單，無論有沒有成功運出，都不再是首次？

所以在和技術人員協同工作時，往往導致工作不順的原因就在于產品需求不夠細致，功能邏輯不通，這些缺失的因素，那怕是一個小改動，也許就要讓技術人員耗費好長時間去修改，并且在需求新增、變更以及項目趕進度等等情況下，工作量都會落實到技術人員身上。所以我們在和技術人員對接工作時，應當從產品技術層面的實現模型考慮，為技術人員提供明確的、完善的產品需求文檔，盡量減少和避免增加技術人員的多余工作量。

團隊協同的基礎是建立在互相尊重和信任之上的，所以在產品經理不了解的領域里，我們應當充分尊重和信任團隊里的專業人士，避免使用主觀的喜好進行溝通和決策。同時產品經理也要主動和團隊里的各個層面的人員保持溝通，即時跟進產品實施的進度和反饋，避免產品在執行過程中偏離方向。

6、項目管理

項目管理是在限定的資源及限定的時間內需完成的一次性任務。具體可以是一項工程、服務、研究課題及活動等。這項工作通常由項目經理負責，但是由于項目經理主要關注點都是質量、安全、進度、成本等方面的，具體到產品的細節則都是由產品經理負責把握。

在很多小型或者創業型團隊中，沒有單獨的項目管理的崗位，所以很多時候這項工作就由產品經理擔當了起來。就算有項目經理的公司，由于項目經理的職責沒辦法細致到產品的需求和意圖的細節把控上，所以關于產品的細節執行還是需要產品經理跟進。因此我們了解一些項目管理的知識，也是非常有助于產品管理。

項目管理不同于目標管理，目標管理是可以細化成非常小的顆粒任務，但是項目管理是一個整體的任務計劃。比如“裝修房子”，這就是一個任務計劃，管理這個計劃屬于項目管理。

但是裝修有很多細化的工作內容，有裝修之前的事務，和裝修之后的事務，都是屬于項目計劃的范疇之內。在這個大的項目計劃之中，裝修要有選購材料的事項，這個就屬于項目中的一項任務，對應這個任務的安排就是目標管理，項目管理者就需要給執行者明確選購時間、地點、材料名、用途、數量以及預算等等內容，讓任務參與或執行者清晰任務內容和達成的目標。

所以目標管理是以任務成果為標準的管理原則，但是項目管理則是一個大整體的計劃管理。在產品管理當中，一次產品的迭代便是一次項目計劃，產品迭代的需求會再細化成具體的各個任務并分配給相應的工作人員執行，而這些任務的安排便是目標管理。

項目管理的工作通常使用甘特圖對項目計劃進行管理和跟進，常用軟件有Project、Execl等，我常用的是Execl軟件。通過甘特圖分配任務和制定計劃，然后再運用目標管理的方法，向執行部門或執行人傳達任務內容和目標。