從0到1，B端產品MVP階段小結

時間＼2017-09-19

從零到一，toB端的產品的MVP階段結束，總結記錄一下其中的得失和思考。小團隊，沒有很多的方法論，以對具體事情做的思考，做總結了。

產品

1.產品開始前，產品部門一定要裡瞭解產品的商業模式，規劃清楚主線功能。能以流程圖表示的，一定要做出流程圖提供給團隊。

2.有改動的時候，一定要先產品內部思考、研究，捋清可能會關聯到的所有流程、頁面、欄位，再去找其他部門的同事討論。首先保證溝通高效性，另外能讓產品部門能對相關改動，

做整體規劃、資源協調。

3.做減法。產品摸索期，把握業務主線，保證核心業務功能完整的基礎上，做減法。快速開發試錯。重功能，少花精力在介面、交互細節。

4.產品初期，原型圖或者需求評審後，及時與研發確認技術時間節點，列出需要哪些資源協助。初期，出文檔要慎重，效率慢且改動可能性大。口述更高效，且便於團隊磨合。當然，僅限團隊初期。

5.定規矩的文檔一定要出。

比如統一欄位命名，跨部門溝通的東西，一定要出文檔，開發有據可依，也防止扯皮。

6.能具體到人的工作，溝通好後，具體指派到某個人負責。一是賦能給別人，二是事情有負責的主心骨後，參與這件事的其他人，就知道可以往哪兒凝聚。

7.產品部門提前練習，怎麼把業務流程清晰、準確的講給別的同事。像要去參加TED演講一樣認真準備，這很重要。

UI1.出圖前：

產品部門也要給UI同事講業務和背景，

便於他們對產品色調定位。

產品要參與UI與研發人員關於出保真圖的溝通，説明確認哪些介面是需要出圖的。減少出同類型重複圖。提高效率。

2.出圖後：

UI出圖，產品一定要先把關，確認介面風格不跑偏，確認重要位置處圖片的品質和防止遺漏。

面對決斷性不強的UI同事，產品部門需及時跟進，首要做鼓勵和賦能，告訴他們會尊重他們在專業領域的判斷，實在不行，產品部門再參與確定圖片樣式。

研發

1.很多時候研發拿著草圖就開始寫代碼了，邊開發、邊催要圖的情況比較多。這樣開發是高效，但是容易埋下天坑。所以，一開始，產品部門逮著溝通機會了，就要給研發多講業務流程。確保研發的主線不跑偏。

2.抓異常。研發同事大都邏輯嚴謹，很容易在實現業務中找出問題。

這兒產品部門就得注意，不可深入掉入到異常處理中。凡是不影響主線業務的異常，

都做簡單處理。非常規操作引發的問題，不處理。一定要時刻圍繞業務主線做事。

關於問題，建立bug池，排出優先順序。讓提問題的同事知道已被記錄——任何同事的參與感和被尊重感一定要有。同時還要給他們講主線業務是做什麼，優先處理影響業務主線的問題。

3.提供給研發部門的文檔。

有時花兩小時出需求文檔，還不如拿凳子坐研發跟前，告訴他要修改的需求。文檔只是表達形式，我們要的是效果和效率。而且從平時聊天就知道，大多數研發是不樂意看需求文檔的。原因不做分析了。

開發文檔處理方法：記錄事件節點、定規矩、容易出現扯皮的文檔，一定要出。

介面交互處理方法：a在草圖上加注釋進行處理，b原型上加入交互效果，c面對面講。

資料庫表單處理方法：（掉過得坑）拿出來說一下。這兒產品要做的是——整理新增或者功能改動時，可能會出現的牽連性改動（產品自己心裡沒譜的也算），講給開發聽。能讓資料庫這邊分析、先行準備。要是真有資料庫改動的話，這塊提前溝預知過，就能為後面技術開發，提高巨大的效率。

一些想法

目前對產品崗位的一些理解：

要兼聽則明，從各個角度、角色去分析問題。會做取捨，這很重要。工作重心一定要落在產品核心業務流程上。對產品，對事情，有擔當，負責任。規劃總是很好，但回歸現實，大多是要做落地性事情。出現錯誤了，自己的鍋就主動背，別人的鍋，合理範圍內，儘量減少別人的尷尬。不要逃避責任，做產品崗，一定要有責任心和肚量。關於溝通：能把別人話裡的意思，快速、準確的提煉出來。能把自己的想法流暢、準確的表達出來。溝通、交流事情的同時，也能照顧著別人的面子。達到這三點就夠了，不要把溝通能力想的太玄乎。

作為產品經理來說，一定要學著賦能。二八定律在哪兒都適用。但如果懂得協調、調動隊友。有時候他們迸發出的能力，也很驚人！！！~

生活就像盒子裡的巧克力，你永遠不知道下一顆你拿的是什麼。產品也一樣，what we can do is keep moving.

本文由 @小天狼星原創發佈于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基於CC0協議

文檔只是表達形式，我們要的是效果和效率。而且從平時聊天就知道，大多數研發是不樂意看需求文檔的。原因不做分析了。