為什么要輸出標注尺寸的圖？

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

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

反向思考：如果沒有輸出效果圖標注，會怎么樣？

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

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

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

根本性質的原因在于，反復調整。

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

是不是有點敏感了？

反復調整恰恰是產品和研發協作過程中所經常爭論的?“需求變更”。

我們是守衛

當我意識到“標注”對于團隊意義時，我開始反思產品經理的“標注”。

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

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

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

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

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

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

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

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

“易有太極，是生兩儀。兩儀生四象，四象生八卦?！?/p>

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

除了被削弱的，我們還有被釋放的負擔，典型的被釋放的負擔便是“反復調整”。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

產品經理的“標注”
當然，我們需要向開發人員輸出的產物，不會只有需求文檔，但最重要的便是“需求文檔”

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

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

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

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

產品經理：好

文檔：

1. talkingdata增加全局統計
2. 統計日活，留存，使用時長

The end

程序員：…

這是另一個段子：

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

老板：要做多久

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

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

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

文檔：

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

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

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

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

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

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

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

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

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

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

關于信息傳遞

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

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

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

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

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

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

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

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

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

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

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

#專欄作家#

枯葉，近6年經驗的產品經理，微信公眾號：枯葉咖啡館，人人都是產品經理專欄作家。擅長社交，社區，細分群體挖掘。

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