小公司產(chǎn)品經(jīng)理:如何改善“野路子”,構(gòu)建自己的方法論?
編輯導(dǎo)讀:產(chǎn)品經(jīng)理屬于新興職業(yè),沒有太多職場老鳥能帶人,除了少數(shù)大廠擁有完備的產(chǎn)品體系,大部分產(chǎn)品人都是摸著石頭過河,也就是所謂的“野路子”。那么,作為一個小公司產(chǎn)品經(jīng)理,該如何改善野路子習(xí)慣,構(gòu)建自己的方法論呢?本文作者依據(jù)自身產(chǎn)品實踐中的所思所想,結(jié)合案例對上述問題展開了分析探究,與大家分享。
所謂“野路子”,即沒有規(guī)范的工作方式,做事情沒有依據(jù),想到哪做哪,做到哪算哪,經(jīng)常會陷入自己不知道干嘛的境地,這樣的工作狀態(tài)會極大的降低工作效率,長期以往甚至?xí)绊懽约旱墓ぷ髑榫w。
如何改善“野路子”,即流程化、標準化做事,最佳的方法就是定義Standard Operating Procedure(標準作業(yè)程序),以下簡稱SOP,讓自己在遇到問題時有所依據(jù)。
下面我將結(jié)合個人經(jīng)驗,詳細闡述產(chǎn)品工作中如何通過定義SOP,改善野路子,形成自己的產(chǎn)品方法論。
一、定義與同事配合的工作流程
1. 了解互聯(lián)網(wǎng)公司需求迭代的流程
如圖:
2. 明確自己需要做以上流程中的哪些事
根據(jù)自己公司的情況細化,明確自己需要做以上流程中的哪些事,比如我司就需要產(chǎn)品做需求調(diào)研、產(chǎn)品設(shè)計、產(chǎn)品方案宣講、研發(fā)過程跟進、收集反饋這幾類事情。
3. 確定以上的事情需要哪些人(WHO)對接,以及如何(HOW)和他們對接
(1)需求調(diào)研
需求調(diào)研根據(jù)需求來源一般分為兩種:
一種是內(nèi)部需求,一種是外部需求。內(nèi)部需求對接人包括BOSS、研發(fā)、測試、運營、市場,這些需求調(diào)研的工作和他們約好時間,反復(fù)溝通直到雙方都沒有異議就可以了;
外部需求一般對接人是客戶,要復(fù)雜一點,懂得隨機應(yīng)變,不要當場答應(yīng)實現(xiàn)需求,只要做好訪談記錄,回來可以和決策人(一般小公司是boss,有些是產(chǎn)品總監(jiān)或者技術(shù)總監(jiān))講清楚大概需求,至于要不要做,怎么做,什么時間做(需求優(yōu)先級的問題),這些問題留給決策人。
(2)產(chǎn)品設(shè)計
產(chǎn)品設(shè)計一般情況下是初級產(chǎn)品經(jīng)理最重要的工作,設(shè)計過程中的對接人主要是需求方,有時也要需要技術(shù)參與討論方案可行性,最重要的是和需求方反復(fù)確認以保證最終的方案過關(guān),這一點會在定義自己工作的SOP中詳細討論。
(3)產(chǎn)品方案宣講(評審會)
產(chǎn)品方案宣講,一般對接人包括UI/研發(fā)/測試,有時需求方也會參與。這時候要提前預(yù)約時間,準備好產(chǎn)品方案的產(chǎn)出物,比如流程圖、功能架構(gòu)圖、原型圖、PRD文檔,如果涉及項目管理,要在禪道等團隊協(xié)作的工具中建好需求號,便于開發(fā)人員領(lǐng)任務(wù)。
宣講的順序一般是先業(yè)務(wù)流程圖,再功能架構(gòu),然后根據(jù)業(yè)務(wù)流講一遍原型圖,至于文檔就不用講了。記得講完一定要同步,如果團隊有同步的軟件,比如svn,git,也可以用郵箱,我們公司用的git,然后在群里發(fā)一句,“**原型圖V1.0.0,PRDV1.0.0已經(jīng)更新至git,請有需要的小伙伴自取”。
【PS:請在每次需求變更后,及時更新為原型圖和PRD文檔,并同步給相關(guān)同事,必要時重新開會強調(diào)變更,這一點尤為重要】
(4)研發(fā)過程跟進
研發(fā)過程中可能會出現(xiàn)各種各樣的情況,對接人一般是開發(fā)和測試。比如開發(fā)、測試不理解需求,你要解釋;開發(fā)、測試發(fā)現(xiàn)需求有些情況沒有考慮到或者有規(guī)則不清晰的,你要補充需求(這種情況雖不能完全避免,但越少越好);甚至,前后端聯(lián)調(diào)出現(xiàn)問題,需要你定義接口。總之,就是在開發(fā)過程中一切的問題你需要負責(zé)解釋。
(5)收集反饋
收集反饋一般對接人是運營或者用戶,這里主要是記錄上線后出現(xiàn)的問題,為后續(xù)產(chǎn)品迭代提供依據(jù)。
以上的5點是僅為個人總結(jié)的內(nèi)容,不同公司的情況可能略有不同。
二、定義自己的工作流程
最重要的就是產(chǎn)品設(shè)計SOP的定義,這個過程需要自己反復(fù)思考總結(jié),每一階段都有相應(yīng)的輸出物,并且在平常工作中不斷實踐才有效果,以我總結(jié)的產(chǎn)品設(shè)計SOP為例:
需求調(diào)研→業(yè)務(wù)模型搭建→流程圖→產(chǎn)品功能架構(gòu)→原型圖→PRD文檔
1. 需求調(diào)研
這一步需要盡可能多的收集需求的信息點,包括需求的目的,參與的角色,上線時間,很多細節(jié)的想法等等。如果只是需求方只是一個人,那么他會提關(guān)于很多需求的描述,盡可能記下來;如果是頭腦風(fēng)暴式的需求,那么有不同的人提出不同的需求描述。
以PCG(Professionally-generated Content)的課程APP為例,A可能說課程要能定義屬性(視頻/文檔),包括價格,名稱等,B可能說課程要能下架,下架后前臺就看不到了,C說用戶要能夠選課程,購買課程,D說要有購物車,只要是會上沒有發(fā)現(xiàn)有明顯問題的信息,統(tǒng)統(tǒng)記下來;我一般用onenote分點記,很多人喜歡用思維導(dǎo)圖。
示例:
推薦工具:onenote
2. 業(yè)務(wù)模型搭建
根據(jù)需求調(diào)研記錄的信息點搭建業(yè)務(wù)模型,最重要的是梳理主流程,聽起來好像很難,但實際操作比較簡單,在草稿本上列兩點:參與角色、每個角色涉及的操作。
同樣以上述課程APP為例,涉及到的角色:包括平臺運營人員、用戶,涉及到的操作:平臺運營人員上架課程,用戶選擇并購買商品;注意,這里涉及的操作不是要列系統(tǒng)中詳細的操作,而是業(yè)務(wù)過程中完整的閉環(huán)操作(包括線上、線下)。PCG的內(nèi)容是自己生產(chǎn)的,所以線下還包括制作流程,那么完整的業(yè)務(wù)模型應(yīng)該是:
運營人員制作課程→運營人員上架課程→用戶選擇并購買商品
注意:業(yè)務(wù)模型的搭建一定要閉環(huán),所謂的閉環(huán)就是實現(xiàn)最終的效果,比如C端的產(chǎn)品一定是要通過用戶直接購買/廣告/增值服務(wù)賺錢的,B端產(chǎn)品一定是要解決閉環(huán)解決問題的,一定要考慮系統(tǒng)層面做到哪一步,作為需求的邊界。
我一般只會粗略的列,因為這個時候列得太細反而會干擾自己的思考。
推薦工具:草稿紙,筆
3. 流程圖
一般畫三種業(yè)務(wù)流程圖,功能流程圖,任務(wù)流程圖。
業(yè)務(wù)流程圖一般用泳道圖(如有并行則用UML),主要是根據(jù)搭建的業(yè)務(wù)模型,在相應(yīng)的泳道里按照順序畫出每個角色的操作。切記,不要想一步把所有流程畫在一個業(yè)務(wù)流程圖中,只需要把整個過程中最關(guān)鍵的一條/多條業(yè)務(wù)流畫出來即可,否則適得其反。
示例:
功能流程圖:主要是為了實現(xiàn)某種具體的功能,比如支付功能的驗證流程,需要給出不同情況下的結(jié)果說明,包括支付成功的流程,支付失敗的各種異常流程,開發(fā)很有可能拿著你的流程圖去寫邏輯判斷的,測試可以直接拿著流程圖寫測試用例;
示例:
任務(wù)流程圖:是為了實現(xiàn)某種任務(wù)的整個流程,只會在關(guān)鍵節(jié)點做判斷,主要是為了讓開發(fā)和測試知曉用戶的核心使用路徑。
示例:
推薦工具:ProcessOn
3. 產(chǎn)品功能架構(gòu)
產(chǎn)品功能架構(gòu)是就是用思維導(dǎo)圖呈現(xiàn),該產(chǎn)品需求包含哪些模塊,這些模塊包含哪些功能;
示例:
推薦工具:X-mind
4. 原型圖
用界面化的方式展現(xiàn)元素,一般分角色,把對應(yīng)的模塊列在相應(yīng)角色的文件夾下,先把框架搭起來,再從數(shù)據(jù)流的角度一個一個頁面去畫,我一般會把頁面跳轉(zhuǎn)和一些動態(tài)面板的交互畫出來,比只畫靜態(tài)頁面要直觀很多。
過程中會有很多創(chuàng)意和想法,記錄下來,畫完自己按照流程跑一遍,看下有沒有流程上的障礙,如果有的話,記錄下優(yōu)化的點,逐個優(yōu)化。
原型圖需要保留版本,每更新一個版本同步更新給團隊成員。
示例:
推薦工具:axure
5. PRD文檔
PRD文檔每個人寫法不同,不必按照別人的模板生搬硬套,現(xiàn)在很多團隊敏捷開發(fā)直接在原型旁邊標注,看起來很方便。我一般是在原型旁邊注明重要的邏輯,另外再寫一份Word文檔。文檔需要做一個目錄,方便后期定位,還有每次更改的記錄,最好在相應(yīng)的位置標上最新更改的時間并顯紅,內(nèi)容主要包括流程圖、功能架構(gòu)圖、功能描述、原型圖。
(1)流程圖
把業(yè)務(wù)流程圖貼在PRD文檔的總述里,記得axure第一頁也貼一份,功能流程圖、任務(wù)流程圖貼在相應(yīng)的功能描述下。
(2)功能架構(gòu)圖
功能架構(gòu)圖在PRD文檔綜述里貼一份。
(3)功能描述
功能描述需要分角色、分模塊,分頁面,一般是一個頁面一段描述,彈窗放在同一段描述,但也不絕對,也可以用功能點劃分,比如列表、增、刪、改、查,規(guī)則就是用MECE(互相獨立,完全窮盡)的原則分清楚,具體描述主要包括三個方面:
- 數(shù)據(jù)的呈現(xiàn),這個頁面呈現(xiàn)的數(shù)據(jù)是哪里來的;
- 每個原型每個元素的描述,按照原型的頁面,從左到右,從上到下擼一遍,每個UI/字段代表什么意義,有哪些規(guī)則,每個操作相應(yīng)的頁面變化是什么,數(shù)據(jù)變化是什么,想清楚,寫出來;
- 描述異常情況,每種異常情況對應(yīng)的頁面是怎么樣的,提示是什么。功能描述就是窮盡所有你能想到的注意點,如果你自己都覺得哪些規(guī)則好像不對勁,那一定是哪里沒想清楚,一定要靜下心來好好理理,否則開發(fā)和測試后面會找你的。
(4)原型圖
在每段功能描述下貼上相應(yīng)的原型圖。
PRD需要記錄版本,每一版本記錄修改的地方、時間等,而且每次變更及時修改并同步給團隊成員。
示例:
在小公司沒人指導(dǎo)一定要勤于總結(jié)經(jīng)驗并運用在以后的工作中,不斷調(diào)整,最終形成自己的方法論,這樣一方面可以提高自己工作的效率,另一方面不論是轉(zhuǎn)行或是跳槽都能很快的適應(yīng),為以后的工作打下堅實的基礎(chǔ)。
以上。
本文由 @娃哈哈 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
收藏了。
這種感覺不適合快速迭代的產(chǎn)品
寫的很不錯,期待您的更多作品!
應(yīng)該是PGC吧,另外流程圖部分判定的時候用,動名詞表達會更清晰,自己會理解,但是其他人是需要一點思考的,比如賬單存在這是一個表示肯定,建議換成賬單是否存在然后yes or no,如果其他部門同學(xué)理解的話其實也無所謂了哈哈
感想指正!
通過讀完這篇文章,我已經(jīng)清楚的知道自己還是產(chǎn)品渣渣了,做了兩年居然還是渣渣,咋辦啊
不要輕易否定自己,嘗試復(fù)盤項目,總結(jié)經(jīng)驗,你一定可以找到屬于自己做產(chǎn)品的套路。
我以前也是渣渣,自從我靜下心學(xué)習(xí)一門程序語言后,你會發(fā)現(xiàn)新世界。我現(xiàn)在臺頭已經(jīng)是高級產(chǎn)品經(jīng)理了,祝你好運
什么程序語言啊,我就是不會技術(shù)才做的產(chǎn)品哈哈
很不錯,自成體系。
已經(jīng)很完整了,很不錯,感覺已經(jīng)像大公司的流程了