數十萬互聯網從業者的共同關注！
作者：枯葉，作者授權早讀課轉載。
微信號：枯葉咖啡館
編輯 : 早讀堂-Verna
導讀：
最近開了幾期入門培訓班，有個學員問我，原型圖上的間距，需不需要寫在文檔里，於是有了這么一篇文章 。
當然，間距，尺寸，顏色是不用卸載需求文檔里的，那都是設計師標注出來的。
為什么要輸出標注尺寸的圖？
我也是第一次意識到這個問題，同樣作為職場中的一個環節，我們的每一個輸出都有其存在的意義。
團隊中的每個角色所掌握的技能，最終都是為團隊服務的，換言之，其實每一個角色所具備的技能，都值得我們去思考，分析，從而改良自身的技能。
反向思考：如果沒有輸出效果圖標注，會怎么樣？
標注的意義在於將設計元素的位置參數化，而不是模糊的概念，憑感覺調整。
圖中的登錄按鈕是放在什么位置呢？ 沒有標注尺寸，就無法確認按鈕位置，只能由前端開發同學憑感覺來調整。
可以想象到，在元素較多的頁面，開發同學會花費極大的成本調整元素位置，在多人合作的項目中，還可能因為協作沖突，以及自定義布局，導致研發成本增加。
根本性質的原因在於，反復調整。
為了避免這樣的成本，現在標注已經成為了設計師的基礎輸出工作。
是不是有點敏感了？
反復調整 恰恰是產品和研發協作過程中所經常爭論的 “需求變更”。
我們是守衛
當我意識到“標注”對於團隊意義時，我開始反思產品經理的“標注”。
既然設計師通過“標注”解決了反復調整的額問題，產品經理是不是也有這樣的輸出技能，能夠解決“需求反復”的問題。
這讓我發現了一個新的認知：產品經理與開發之間的關系，我們是守衛。
某種意義上，產品經理和設計師有很強的相似性，我們都是將頭腦里的概念交付於其他角色共同實現的性質。
設計師的效果圖其實沒有太大作用，因為最終研發還是要再做一次，無法直接將效果圖使用到最終效果上。
這就好比我們的原型圖，我們輸出原型圖，最終任然是由開發同學“再一次”實現出來。
是不是意味着，我們的原型圖和設計師的效果圖只是一個過程，可有可無，只要最終實現出來的效果是正確的就可以了。
也許最開始，真的是由一個人完成的，這個人非常強大，自己做產品，自己做UI，自己寫代碼。
我在許多“大道理”的書上，都看到了近似“混沌”的定理，包括我們國家的哲學概念：太極。
當我們從一個角色里拆分出來，原本的角色必然會被削弱，於是我們的開發就不再自己做設計圖了，而是交給從整體分離出來的設計師來完成相應的輸出。
除了被削弱的，我們還有被釋放的負擔，典型的被釋放的負擔便是“反復調整”。
外圍的角色就像衛兵一樣，為內部角色阻擋一些不必要的負擔，我們把右圖放大看看會發生什么變化。
如果，我們是一名合格的衛兵。
作為守衛的我們，面對開發有兩個責任與義務。
第一，替開發過濾一些不需要做的事情。
第二，建立與開發的信息傳遞通道。
第一個責任很好理解，想一想我們廢棄的那些方案吧，這些就是被我們過濾掉的事情。
我們的原型往往要畫好幾個版本，還有設計師的效果圖改了又改，除了最終被傳遞給開發的效果圖，其他的都是被我們過濾掉的事情。
這是我們作為守衛的第一個責任，我相信大家都主動或者被動的在這么做。
只是也許我們並沒有意識到這些行為背后的含義。
第二個責任是我要重點分享的內容。
建立我們與開發人員之間的信息傳遞通道
我們再把圖放大一點看看吧，這一次，請把設計師想象成開發的助理，所謂的助理，就是將一切事情准備好。
你知道廚房的學徒嗎？我在一部美食漫畫里看到了廚師學徒的工作內容，除了基礎的打掃衛生之外，還需要將食材准備好，包括清潔， 加工，裝盤等等。
所以我們的設計師同學除了將廢棄方案幫助開發過濾掉，還得像助理一樣幫助開發把所需要的材料准備好，這其中就包括切圖與標注。
借助由標注和切圖構成的通道，設計師和開發之間的協作才會通暢，不會出現反復詢問這里幾個像素，哪里什么顏色的問題。
同樣是作為開發的守衛，產品經理的通道又是由什么構成的呢？
產品經理的“標注”
當然，我們需要向開發人員輸出的產物，不會只有需求文檔，但最重要的便是“需求文檔”。
我們把需求文檔理解成設計師的標注，也許會比較困難，換個思維，需求文檔所要達到的目的與設計師的標注相同，是否能夠更容易理解呢？
這是一個段子，也是我最近才看到的一個真實的段子：
產品經理：你把talkingdata統計加上。
程序員：寫個文檔要加哪些統計。
產品經理：好。
文檔：
1.talkingdata增加全局統計。
2.統計日活，留存，使用時長。
The end
程序員：…
這是另一個段子：
產品經理：老板，這個是我這個版本想做的功能，我們要像微信一樣，讓用戶自己上傳視頻文件。
老板：要做多久。
產品經理：我讓開發他們10天做完，開發那邊說沒問題。
老板：這個功能量不少，難度也不小，開發能做完嗎？
產品經理：做不完，那就是開發技術不行，反正我的需求已經給他們了，他們也答應了10天做完。
文檔：
1. 發布流程增加上傳視頻的功能。
2. 可以把手機本地的視頻文件上傳到服務器。
我的讀者，你們怎么看這兩個段子？
作為守衛而言，產品經理與開發之間的通道完全破碎了，不僅不能減少研發成本，反而不斷的增加研發成本，最終的結果就是溝通障礙。
人們的本能是趨吉避凶的，程序員也遵從這個定理，明明知道需求有問題，為什么還要去做？
拖着，沒做，是因為你沒寫需求，最后大不了被罵一頓。
最終被踢出局的不會是程序員，而是這位完全沒有意識到守衛職能的產品經理。
這是一份我學生寫的需求文檔，實際開發過程中，便可以起到標注的作用。
我相信，現在大部分的產品經理沒有意識到“守衛概念”，也可能這只是我的一種個人認知。
但至少不要堅持做一位“坑經理”，向設計師學習，將我們起到標注作用的需求文檔發揮出他應有的價值。
關於信息傳遞
在團隊協作過程中，我們需要將一條信息多次傳遞，而每一次都會出現信息丟失以及變形。
產品經理與團隊中的其他角色的關系，並不是上下關系，我尤其要強調這一點，產品與設計也好，與開發也好，我們都是屬於不同的部門，只是在一個相同的項目組里而已。
我們的關系更傾向於任務的前后關系，產品經理在項目的開始位置，接觸最多的信息，過濾最多的信息，然后將自己的思維傳遞給下一個環節，可能是設計師，可能是開發。
每一個環節都會比下一個環節收獲更多信息，一層一層過濾下來，最終到測試手上的產品才能是最合適的產品。
而這中間最大的風險地帶便是我們信息傳遞的通道。
我們理所應當的認為設計師就應該要標注，要切圖，但到了自己身上時，卻會排斥需求文檔的撰寫，甚至極不耐煩。
也許你的想法真的很好，但如果不認真對待想法的傳遞，我其實想建議你換個行業。
當我們在抬頭仰望遙遠的未來時，當我們大談用戶需求時，當我們考慮市場痛點時，你沒有發現，誰才是我們產品經理第一批用戶？
我們的team才是我們的第一批用戶，一位降低團隊效率，成為團隊負擔的產品經理，又如何分析更遙遠，面積更大的所謂的“用戶”，對眼前的痛點視而不見的產品經理，何以談論“痛點”。
最終，任然給大家一個建議。
請務必認真對待需求文檔，無論你是准產品經理，又或者你是3，5年經驗的產品經理，畢竟，這也是我們的基礎輸出內容，就像我們無法接受設計師不做標注一樣，開發也無法接受產品經理不輸出需求文檔。