2014/08/25 22:58人人都是產品經理

寫給我的第一任助理

這是一個菜鳥產品經理寫給她的菜鳥產品助理的入職培訓教材，教材分為“習慣”“流程”“文檔”“產品思維”等幾個部分。

在流程篇中，我將向你介紹一個通用的流程和我們的團隊構成，你也可以從中了解到你將參與的工作內容。同時我希望能夠帶給你一個合乎邏輯的做事方式，使你在接到一個新任務的時候不會手足無措。

開始吧~

流程

舉例一個故事來進行產品開發過程的說明：

一個動機

盤古開天辟地后，女神女媧在茫茫原野中行走，她倍感寂寞，她需要陪伴，于是她想要一些能夠陪伴她的生物。

女媧決定聘請一個團隊幫她完成這件事。

產品目標

創造一個陪伴女神度過漫漫時光的物種。

用戶需求

這個物種和女神長得差不多，要能陪女神說話，要能陪女神度過長久的時光。

內容與功能需求

擁有智慧能夠思考、能夠學習進步、能夠繁殖擴張、能夠新陳代謝。

界面交互設計

外形如同女神，擁有頭腦，四肢等部件

為了確保功能，需要放入五臟六腑，各種器官

信息架構

用骨架把“人“支撐起來

布局與導航設計

眼睛放在上面，是為了看得更高；嘴巴放在下面是為了食用方便；耳朵在兩側是為了聽得更廣闊……

視覺設計（設計）

黑頭發黑眼睛，雙眼皮長睫毛……穿上衣服（差點忘了）……

開發與測試（開發）

讓人類活動起來，看看有什么錯誤需要修正。

——以上是一個傳統的產品開發過程（設計與開發的工作不詳述）

我們再來看看團隊成員在開發過程中的位置和工作內容，圖中描繪的是各個部門擔任主要職責的階段（你可以對照我們的項目文檔）。

團隊

以下是部門組織架構圖。

產品工作

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

兩種方式：文檔和語言

1制定需求

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

2輸出需求

需求文檔將給所有項目團隊的小伙伴們看，確保“用戶們”能夠通過文檔理解你的想法。

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

3管理需求

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

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

4項目

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

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

避免（重要）

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

這是我極力避免的事情。

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

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

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

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

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

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

總結

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

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