寫給我的第一任助理

團隊

以下是部門組織架構圖。

產品工作

所有的工作都圍繞著“需求”展開，作為需求方，我們要做的，就是向團隊進行需求的解釋和溝通。

兩種方式：文檔和語言

1制定需求

產品在各個階段“目標——對象（用戶）——內容——結構——細化”由粗到細地制定需求，并產生相對應的“需求文檔”，這些文檔就是用來解釋需求，形式完全可以靈活多樣（不僅僅是通常理解的文字文檔，如果你能畫漫畫，說不定會更受歡迎~）。

2輸出需求

需求文檔將給所有項目團隊的小伙伴們看，確?！坝脩魝儭蹦軌蛲ㄟ^文檔理解你的想法。

然后用各種方法解釋這些需求，確保所有人都理解需求的原意。

3管理需求

我們當然希望需求不要再有改動，可惜這只是一個美好的夢想。每個負責任的成員都會向我們提一些建議，有些建議會轉化為新的需求。

新需求的管理工作更加繁瑣，因為牽一發而動全身，改了某個部分可能對前后的工作都有影響。因此要盡量避免需求脫離你的控制，避免無限制的需求變動導致項目延期。

4項目

鑒于我對于小伙伴們各自工作一知半解的程度，通常不糾纏具體細節，我們只需要在項目計劃中對時間節點和里程碑（某個時間完成了某件事情）進行跟進，大家會自己掌握工作進程。

小伙伴們在時間范圍內完成了自己安排的工作，說明一切順利。

避免（重要）

在完成文檔的過程中我犯了個嚴重的錯誤。導致我把幾個小時打出來的文字刪去了一半。因為我試圖向你描述清楚每一件事情，同時向你灌輸一些專業嚴謹地內容。我試圖讓你讀完這篇文章就變成專家了。

這是我極力避免的事情。

所以我特地在這里予以說明：

我建議你的每一份文檔都適合一個外行人流暢閱讀（起碼能夠讀懂大部分內容）。因為你不一定每次都碰到相同知識水平的成員，比如你就是這樣一個菜鳥?；蛘呒幢愣际菍＜?，但是所涉及的領域不同所理解的內容也不盡相同。

之前我被教導對設計師使用設計師的語言，對程序員使用程序員的語言（鑒于這實在需要巨量的知識庫，而我要承認力所不逮不愿意在大家面前班門弄斧）。不如使用外行人（通俗）的語言，看上去是有點蠢，但是起碼每個人都能明白你在說什么。

我們總是在強調產品的可用性，我們在制作文檔的時候也應該保證這份文檔的“可用性”。

如果你用通俗的語言向我解釋問題，我也會很感激。這樣我就不用裝作自己比你懂，然后偷偷去百度了，我們可以大大節省時間。

（希望修改之后的文檔不會讓你覺得太艱澀）

總結

開發產品的流程可以套用在大部分事情上。按照“目標——對象（用戶）——內容——結構——細化”的方式去處理，我們就不會懼怕任何一無所知的事物。

不要糾結形式和內容，重要的是用對方能理解的方法表達清楚自己的想法。

Ps：如果你發現有件雜事沒有人做，就接過來，反正最后總是我們做的哈哈哈

第一篇：嗨！菜鳥~我們來談談你的新工作（習慣篇）

第三篇：嗨！菜鳥~我們來談談你的新工作（文檔篇）

第四篇：嗨！菜鳥~我們來談談你的新工作（產品思維篇）

#專欄作家#

GaraC，知乎賬號：GaraChenV，人人都是產品經理專欄作家，專長研究用戶體驗，虐待各種形式的鍵盤。關注物聯網、互聯網金融、LBS等相關領域產品。專業掃描各種書籍，愛好：收集各種樂譜和奇怪的書。

本文系作者獨家授權發布，未經本站許可，不得轉載。