產品經理菜鳥工做--轉自《人人都是產品經理》

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

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

開始吧~

流程

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

一個動機

盤古開天闢地後，女神女媧在茫茫原野中行走，她倍感寂寞，她須要陪伴，因而她想要一些可以陪伴她的生物。

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

產品目標

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

用戶需求

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

內容與功能需求

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

界面交互設計

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

爲了確保功能，須要放入五臟六腑，各類器官

信息架構

用骨架把「人「支撐起來

佈局與導航設計

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

視覺設計（設計）

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

開發與測試（開發）

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

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

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

團隊

如下是部門組織架構圖。

產品工做

全部的工做都圍繞着「需求」展開，做爲需求方，咱們要作的，就是向團隊進行需求的解釋和溝通。

兩種方式：文檔和語言

1制定需求

產品在各個階段「目標——對象（用戶）——內容——結構——細化」由粗到細地制定需求，併產生相對應的「需求文檔」，這些文檔就是用來解釋需求，形式徹底能夠靈活多樣（不只僅是一般理解的文字文檔，若是你能畫漫畫，說不定會更受歡迎~）。

2輸出需求

需求文檔將給全部項目團隊的小夥伴們看，確保「用戶們」可以經過文檔理解你的想法。

而後用各類方法解釋這些需求，確保全部人都理解需求的原意。

3管理需求

咱們固然但願需求不要再有改動，惋惜這只是一個美好的夢想。每一個負責任的成員都會向咱們提一些建議，有些建議會轉化爲新的需求。

新需求的管理工做更加繁瑣，由於牽一髮而動全身，改了某個部分可能對先後的工做都有影響。所以要儘可能避免需求脫離你的控制，避免無限制的需求變更致使項目延期。

4項目

鑑於我對於小夥伴們各自工做只知其一;不知其二的程度，一般不糾纏具體細節，咱們只須要在項目計劃中對時間節點和里程碑（某個時間完成了某件事情）進行跟進，你們會本身掌握工做進程。

小夥伴們在時間範圍內完成了本身安排的工做，說明一切順利。

避免（重要）

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

這是我極力避免的事情。

因此我特意在這裏予以說明：

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

以前我被教導對設計師使用設計師的語言，對程序員使用程序員的語言（鑑於這實在須要巨量的知識庫，而我要認可力所不逮不肯意在你們面前班門弄斧）。不如使用外行人（通俗）的語言，看上去是有點蠢，可是起碼每一個人都能明白你在說什麼。

咱們老是在強調產品的可用性，咱們在製做文檔的時候也應該保證這份文檔的「可用性」。

若是你用通俗的語言向我解釋問題，我也會很感激。這樣我就不用裝做本身比你懂，而後偷偷去百度了，咱們能夠大大節省時間。

（但願修改以後的文檔不會讓你以爲太艱澀）

總結

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

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

Ps：若是你發現有件瑣事沒有人作，就接過來，反正最後老是咱們作的哈哈哈