我理解的產品經理與開發的關係

我也是第一次意識到這個問題，同樣作為職場中的一個環節，我們的每一個輸出都有其存在的意義。

團隊中的每個角色所掌握的技能，最終都是為團隊服務的，換言之，其實每一個角色所具備的技能，都值得我們去思考，分析，從而改良自身的技能。

☆反向思考：如果沒有輸出效果圖標註，會怎麼樣？

標註的意義在於將設計元素的位置參數化，而不是模糊的概念，憑感覺調整。

圖中的登錄按鈕是放在什麼位置呢？ 沒有標註尺寸，就無法確認按鈕位置，只能由前端開發同學憑感覺來調整。

可以想像到，在元素較多的頁面，開發同學會花費極大的成本調整元素位置，在多人合作的項目中，還可能因為協作衝突，以及自定義布局，導致研發成本增加。

根本性質的原因在於，反覆調整。

為了避免這樣的成本，現在標註已經成為了設計師的基礎輸出工作。

是不是有點敏感了？

反覆調整 恰恰是產品和研發協作過程中所經常爭論的 「需求變更」。

我們是守衛

當我意識到「標註」對於團隊意義時，我開始反思產品經理的「標註」。

既然設計師通過「標註」解決了反覆調整的額問題，產品經理是不是也有這樣的輸出技能，能夠解決「需求反覆」的問題。

這讓我發現了一個新的認知：產品經理與開發之間的關係，我們是守衛。

某種意義上，產品經理和設計師有很強的相似性，我們都是將頭腦里的概念交付於其他角色共同實現的性質。

設計師的效果圖其實沒有太大作用，因為最終研發還是要再做一次，無法直接將效果圖使用到最終效果上。

這就好比我們的原型圖，我們輸出原型圖，最終任然是由開發同學「再一次」實現出來。

是不是意味著，我們的原型圖和設計師的效果圖只是一個過程，可有可無，只要最終實現出來的效果是正確的就可以了。

也許最開始，真的是由一個人完成的，這個人非常強大，自己做產品，自己做UI，自己寫代碼。

我在許多「大道理」的書上，都看到了近似「混沌」的定理，包括我們國家的哲學概念：太極。

「易有太極，是生兩儀。兩儀生四象，四象生八卦。」

當我們從一個角色里拆分出來，原本的角色必然會被削弱，於是我們的開發就不再自己做設計圖了，而是交給從整體分離出來的設計師來完成相應的輸出。

除了被削弱的，我們還有被釋放的負擔，典型的被釋放的負擔便是「反覆調整」。

外圍的角色就像衛兵一樣，為內部角色阻擋一些不必要的負擔，我們把右圖放大看看會發生什麼變化。

如果，我們是一名合格的衛兵。

（我不會說我是一邊笑，一邊畫完這個概念圖的， 不如叫 寶可夢模型？）

作為守衛的我們，面對開發有兩個責任與義務。

第一，替開發過濾一些不需要做的事情。

第二，建立與開發的信息傳遞通道。

第一個責任很好理解，想一想我們廢棄的那些方案吧，這些就是被我們過濾掉的事情。

我們的原型往往要畫好幾個版本，還有設計師的效果圖改了又改，除了最終被傳遞給開發的效果圖，其他的都是被我們過濾掉的事情。

這是我們作為守衛的第一個責任，我相信大家都主動或者被動的在這麼做。

只是也許我們並沒有意識到這些行為背後的含義。

第二個責任是我要重點分享的內容。

建立我們與開發人員之間的信息傳遞通道

我們再把圖放大一點看看吧，這一次，請把設計師想像成開發的助理，所謂的助理，就是將一切事情準備好。

你知道廚房的學徒嗎？我在一部美食漫畫里看到了廚師學徒的工作內容，除了基礎的打掃衛生之外，還需要將食材準備好，包括清潔， 加工，裝盤等等。

所以我們的設計師同學除了將廢棄方案幫助開發過濾掉，還得像助理一樣幫助開發把所需要的材料準備好，這其中就包括切圖與標註。

藉助由標註和切圖構成的通道，設計師和開發之間的協作才會通暢，不會出現反覆詢問這裡幾個像素，哪裡什麼顏色的問題。

同樣是作為開發的守衛，產品經理的通道又是由什麼構成的呢？

產品經理的「標註」

當然，我們需要向開發人員輸出的產物，不會只有需求文檔，但最重要的便是「需求文檔」。

我們把需求文檔理解成設計師的標註，也許會比較困難，換個思維，需求文檔所要達到的目的與設計師的標註相同，是否能夠更容易理解呢？

這是一個段子，也是我最近才看到的一個真實的段子：

產品經理：你把talkingdata統計加上。

程序員：寫個文檔要加哪些統計。

產品經理：好。

文檔：

1.talkingdata增加全局統計。

2.統計日活，留存，使用時長。

The end

程序員：…

這是另一個段子：

產品經理：老闆，這個是我這個版本想做的功能，我們要像微信一樣，讓用戶自己上傳視頻文件。

老闆：要做多久。

產品經理：我讓開發他們10天做完，開發那邊說沒問題。

老闆：這個功能量不少，難度也不小，開發能做完嗎？

產品經理：做不完，那就是開發技術不行，反正我的需求已經給他們了，他們也答應了10天做完。

文檔：

1. 發布流程增加上傳視頻的功能。

2. 可以把手機本地的視頻文件上傳到伺服器。

我的讀者，你們怎麼看這兩個段子？

作為守衛而言，產品經理與開發之間的通道完全破碎了，不僅不能減少研發成本，反而不斷的增加研發成本，最終的結果就是溝通障礙。

人們的本能是趨吉避凶的，程序員也遵從這個定理，明明知道需求有問題，為什麼還要去做？

拖著，沒做，是因為你沒寫需求，最後大不了被罵一頓。

最終被踢出局的不會是程序員，而是這位完全沒有意識到守衛職能的產品經理。

這是一份我學生寫的需求文檔，實際開發過程中，便可以起到標註的作用。

我相信，現在大部分的產品經理沒有意識到「守衛概念」，也可能這只是我的一種個人認知。

但至少不要堅持做一位「坑經理」，向設計師學習，將我們起到標註作用的需求文檔發揮出他應有的價值。

關於信息傳遞

在團隊協作過程中，我們需要將一條信息多次傳遞，而每一次都會出現信息丟失以及變形。

產品經理與團隊中的其他角色的關係，並不是上下關係，我尤其要強調這一點，產品與設計也好，與開發也好，我們都是屬於不同的部門，只是在一個相同的項目組裡而已。

我們的關係更傾向於任務的前後關係，產品經理在項目的開始位置，接觸最多的信息，過濾最多的信息，然後將自己的思維傳遞給下一個環節，可能是設計師，可能是開發。

每一個環節都會比下一個環節收穫更多信息，一層一層過濾下來，最終到測試手上的產品才能是最合適的產品。

而這中間最大的風險地帶便是我們信息傳遞的通道。

我們理所應當的認為設計師就應該要標註，要切圖，但到了自己身上時，卻會排斥需求文檔的撰寫，甚至極不耐煩。

也許你的想法真的很好，但如果不認真對待想法的傳遞，我其實想建議你換個行業。

當我們在抬頭仰望遙遠的未來時，當我們大談用戶需求時，當我們考慮市場痛點時，你沒有發現，誰才是我們產品經理第一批用戶？

我們的team才是我們的第一批用戶，一位降低團隊效率，成為團隊負擔的產品經理，又如何分析更遙遠，面積更大的所謂的「用戶」，對眼前的痛點視而不見的產品經理，何以談論「痛點」。

最終，任然給大家一個建議。

請務必認真對待需求文檔，無論你是准產品經理，又或者你是3，5年經驗的產品經理，畢竟，這也是我們的基礎輸出內容，就像我們無法接受設計師不做標註一樣，開發也無法接受產品經理不輸出需求文檔。

關於培訓

枯葉私塾第三期培訓，產品入門整套課程

時間：1月16日-1月20日

地點：線上培訓

內容：

• 產品入門，做什麼與怎麼做

• 產品入門，需求如何被實現

• 需求文檔2.0撰寫技巧上

• 需求文檔2.0撰寫技巧下

• 原型繪製技巧上

• 原型繪製技巧下

我相信，現在大部分的產品經理沒有意識到「守衛概念」，也可能這只是我的一種個人認知。

但至少不要堅持做一位「坑經理」，向設計師學習，將我們起到標註作用的需求文檔發揮出他應有的價值。

關於信息傳遞

在團隊協作過程中，我們需要將一條信息多次傳遞，而每一次都會出現信息丟失以及變形。

產品經理與團隊中的其他角色的關係，並不是上下關係，我尤其要強調這一點，產品與設計也好，與開發也好，我們都是屬於不同的部門，只是在一個相同的項目組裡而已。

我們的關係更傾向於任務的前後關係，產品經理在項目的開始位置，接觸最多的信息，過濾最多的信息，然後將自己的思維傳遞給下一個環節，可能是設計師，可能是開發。

每一個環節都會比下一個環節收穫更多信息，一層一層過濾下來，最終到測試手上的產品才能是最合適的產品。

而這中間最大的風險地帶便是我們信息傳遞的通道。

我們理所應當的認為設計師就應該要標註，要切圖，但到了自己身上時，卻會排斥需求文檔的撰寫，甚至極不耐煩。

也許你的想法真的很好，但如果不認真對待想法的傳遞，我其實想建議你換個行業。

當我們在抬頭仰望遙遠的未來時，當我們大談用戶需求時，當我們考慮市場痛點時，你沒有發現，誰才是我們產品經理第一批用戶？

我們的team才是我們的第一批用戶，一位降低團隊效率，成為團隊負擔的產品經理，又如何分析更遙遠，面積更大的所謂的「用戶」，對眼前的痛點視而不見的產品經理，何以談論「痛點」。

最終，任然給大家一個建議。

請務必認真對待需求文檔，無論你是准產品經理，又或者你是3，5年經驗的產品經理，畢竟，這也是我們的基礎輸出內容，就像我們無法接受設計師不做標註一樣，開發也無法接受產品經理不輸出需求文檔。