中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

相對于C端來說，目前對于B端產品經理的工作流程、整體方法論的討論還在少數，即使有也都是針對某一個細化部分進行展開，缺少從整體上去總結。于是筆者作為一個B端產品經理，就結合工作實踐與認知，與大家分享一下B端產品經理工作流是怎么樣的？

2020年1月份快過年的時候，我在脈脈上看到一個產品分享了一張圖，內容為《我領悟出的B端產品經理工作流》，其中有些內容與我實際所做的有很多相似之處，所以我點了個贊、收藏了一波。事后一直想著能有機會對這個圖中的知識點進行拆解，同時也加上一下自己的理解在里面。

根據帕金森定律，如果我們不給自己設定一個Deadline，那么做一件事的時間就會無限地占用掉別的事情的時間，以至于到最后我們只會留一點點時間來做這件事。

所以，趁著有點熱情和動力在，趕緊補完這篇內容。

下面的長圖是我重新梳理并重置的高清圖版本，具體的作者不詳，所以也不知道原圖是誰做的，就只能說摘自脈脈了。如果你對里面提到的工作流感興趣，可以直接長按保存長圖到本地。

01 我的擔憂

上面提到我是在脈脈上看到的這張圖，其實對B端的產品來說關于工作流，方法論的文章比較少，尤其是經歷項目不多或者是體會不深的初級產品同學，感覺別人說的工作流和方法論都對，都挺不錯的。

結果自己來做的時候，毫無章法，今天是用降龍十八掌，明天是乾坤大挪移，后天就九陰真經走火入魔了。

究其原因，核心點還是因為知其然而不知其所以然。

去年上半年我一直在努力調整自己的工作方式，盡量走一種模式化，規范化的路子，這樣可以確保我做的東西都是有一個體系或者是原則在里面的。

例如螞蟻金服的Ant Design里面就有很大的篇幅去闡述關于這套UI的設計原則。

B端產品也一樣，需要一套行之有效的工作流，一方面約束自己，一方面協同他人。

但是市面上關于B端產品這一塊的資料太少了，或者說有很多資料都是反反復復將一些淺層的東西，缺乏實戰性、指導性，同時還能兼顧一些全流程體系的知識。

這意味著，當我在B端這一塊沉浸的時間不夠的時候，我是充滿擔憂的，擔憂的原因有：

• 擔憂走彎路，變成野路子。因為年輕人不怕走彎路，就怕一直走彎路到回不了頭的時候才醒悟；
• 擔憂不成體系，成長太慢。很多時候我們都說討厭框架，因為框架培養出來的人都千篇一律的，但是很多時候往往如果沒有框架，那么可能培養都會成問題，更不用談后續的千篇一律了；
• 擔憂定位不了自己，不知道自己現在水平如何，是在淺海里裸泳呢？還是在波濤中弄潮？沒有對比，就不知道自己是幾斤幾兩；
• 擔憂無法賦能他人，畢竟行業待久了，職業干久了，總是會面臨老人帶新人的問題，如果自己的理解和方式方法都有問題，到時候帶新人，培養新人的時候不就翻車了么。

擔憂了一段時間，發現好像這個事情就是沒得解，因為不是所有的知識都是有人嚼碎，加料，再主動推送給你，即使有這樣的知識，你也未必就能一擊即中。

所以那段時間，我翻閱了大量的跟B端產品有關系的書籍和相關資料，其中李寬老師的《B端產品經理必修課》給了我很大的幫助，我還中途翻閱了好幾遍，最后消化了一下核心的知識后，我開始在TAPD的WIKI中編輯產品經理日常工作規范，這個WIKI內容至今還在不斷地完善補充中。

同時我也無意中在慕課網中找到了一個產品相關的課程，其中有提到關于產品工作流介紹，其中的內容與我正在做的十分相似。因此更加令我堅信，我自己所走的這條路，悟出的門道并不是與市場脫軌或者很“野生”，沒有章法的。

02 走在路上

既然找不到那種嚼碎了就能直接喂給自己的知識，那就干脆找個有營養的大家伙先啃一下，然后自己嚼碎并記錄下來。以后能不能投喂別人不知道，但是起碼可以做一個參照。

去年的我是如何看待這個工作流程的？我當時的思路和心路歷程是怎么樣的？而一年過去了，當下的我，又是怎么樣的一種感受？

感悟了這個道理之后，我就開始記錄一些日常所見和所感悟的產品相關的知識和方法論。也就是從那個時候開始，我會頻繁地更新博客，更新公眾號，投稿《人人都是產品經理》，這一系列操作下來之后，收益頗豐。

不能說我的產品工作流有什么很特別的提升，對行業的認知有什么獨特的見解，更不能說自己對產品這一行有什么高談闊論。

但是，很明顯地感受就是我感覺自己上道了，而且還是個快車道。

我制定的工作流一開始可能很簡陋甚至有些東西我也是改來改去，多次打臉?？墒?，不久之后我就發現我的工作模式和心態變化了，我為自己制定了規則和玩法，也遵從這樣的規則和玩法，這讓我對日常工作的很多需求和項目都能保持一貫的風格和體系。

這種風格和體系還在培養新人的時候能顯現出奇效，以此為基準搭建培養的框架。

大家都是一個模子出來的人，不會特別優秀，但是也不會特別粗糙，因為基礎功和一些底層地基已經打牢固。剩下的就是，靠后天自己的打磨，自個兒成全自個兒。

03 我「看」B端產品工作流

上面鋪墊了很多，算是給自己賣了一個慘。因為很多時候，自我學習和成長確實挺慘的，感覺很慘可能是因為自己沒人教，受挫太多，總是學不會，成長的太慢。

但是回頭看，又會發現，學習也有運氣成分在里面的。有時候憑借運氣，偶然間你就學到了某些拓展的知識，而這些可能就幫助你打通了任督二脈。

最近很火的一句毒雞湯，叫做：

你永遠賺不到超出你認知范圍外的錢，除非你的運氣很好，靠運氣賺到了這些錢。但是，靠運氣賺到的錢，最后往往也會憑實力虧掉。

但是，學習不是這樣的，你學不會超出你認知范圍外的知識，但是你靠運氣學到了這些知識，最壞的結果就是你可能用不上就忘記了，但是對你自己卻沒有什么虧損。而往積極一點想，也許你學到的知識讓你觸類旁通還拓展了更多的知識，由此開啟了你探索求知的大門。

而我的B端產品之路，也是從一個簡單地認知之外的知識，然后慢慢地接觸到了更廣、更全面的知識，從而開啟了我探索求知的大門，最后這些知識引領我走向了產品的快車道。

好的，現在就針對上面提到的B端產品經理工作流，來談一下我自己對B端產品工作流的見解和看法。

1. 項目立項

項目立項一般來說都是從0到1的時候用的上的，但是往往很多時候大家能接觸從0到1的情況并不多，所以這一塊我也沒啥特別要補充的。但是根據PMP的指導，項目立項報告應該算是啟動開工的必要輸出文件，所以這一塊不能省。

2. 需求調研

這個似乎是老生常談的一個話題了，需求調研也是一個蠻大的概念，但是顯然無論是B端還是C端的產品，都需要進行需求調研。

而我常用的需求調研方法，一般是自己先分析然后給出一個框架，給出一些問題，然后采用訪談式收集需求。

因為目前我所做的業務，需求方基本上都是公司的其他部門，即使有非內部的需求，也可以當面溝通或者微信溝通。

至于網上常提到的，問卷調查、數據分析、行業調研等用的很少，基本上是靠訪談+競品分析一把梭搞定的。

3. 產品宣講

這個地方我有點不同的意見，按理說項目立項的時候其實就已經需要對產品進行宣講了，甚至在項目立項前，就應該開始需求進行調研，行業分析，競品分析等工作，所以這個點放在這里我覺得有點多余或者累贅了。

4. 競品分析

剛剛提到第3點是多余的，所以我一般就是第2點和第4點一套組合拳，也就是需求調研+競品分析一把梭。這個和我的理解是一致的，操作流程的順序也是相當的。

5. 畫用例圖

用例圖是一個存在鄙視鏈的東西，據我觀察，大多數開發轉行產品，或者是計算機相關專業的產品，會比較熱衷于用這個東西；而非計算機相關專業的產品，也許UML都沒有聽過，更不用談畫用例圖了。

所以，鄙視鏈是這樣是：常用用例圖的>知道用例圖但是不怎么畫的>不知道用例圖更不會畫的。

我會畫用例圖，但是畫的不熟悉，畫的很少，所以我應該是站在鄙視鏈中間的那一層。

而我自己的看法則是，工具只是手段，從結果來看，只要能表達清楚相關的信息，那其實都可以接受。UML這么多年的發展，自然有它的道理，但是未來如果被時代拋棄，也不必驚訝，畢竟誰也不能獨領風騷數百年。

6. 畫系統流程圖

關于流程圖的一個頓悟我之前發了一條朋友圈，主要想表達的意思就是，如果是初版流程圖，建議用筆和紙，最好是用鉛筆，還可以擦除。因為直接用Visio或者Axure來畫的話，很容易受到軟件本身的操作因素而干擾，例如對齊方式，文字大小，元素大小，以及配色等等。

對于我來說，我至今還沒有找到什么好的Visio配色，畫10次流程圖可能有6~7次都在糾結配色和樣式之類的操作因素，所以我很贊同畫流程圖的第一版，用紙和筆。

流程圖對評審或者講解產品有很大的幫助，因為可以讓一個局外人迅速用上帝視角來俯瞰流程，把握產品的脈絡或者大綱，然后對流程圖加以部分用戶故事，迅速就可以拉近產品、項目與讓“新人”之間的距離。

當然，對于流程圖來說，我一般會畫兩個，一個是業務流程圖，一個是系統（交互）流程圖。業務流程圖側重點在業務如何形成閉環，走完流程；而系統（交互）流程圖，則側重在系統或者各個模塊如何交互，形成關系脈絡。

7. 列功能清單

這一步我也會做，但是我把這一步稱之為繪制產品功能結構圖，一般是用Mindmanager來實現的，當然我也見過有人用Excel來做，但是我感覺還是用腦圖的形式會好一點。

功能結構圖和信息結構圖又是一對剪不斷理還亂的基佬關系，網上也有很多大佬對此進行了一大堆的剖析，最后還是沒有誰說服誰。

之前我也因為這兩個東西頭疼了蠻久，因為真的是越想越覺得繞口，這里我直接搬出我認可的結論，來自《人人都是產品經理》的兩篇文章：

• 功能結構圖、信息結構圖、結構圖，你還傻傻分不清嗎？（上）
• 功能結構圖、信息結構圖、結構圖，你還傻傻分不清嗎？（下）

感興趣的朋友自己去搜索一下這兩篇文章，而我想要表達的結論是這樣是：

所以，我一般會先繪制產品功能結構圖，然后再繪制產品信息結構圖，而這兩篇內容合到一起就是我最終需要的產品結構圖，它也就是產品原型的簡化表達。

8. 產品架構設計

對于B端產品來說，前后臺頁面存在的情況比較少，至于用什么載體，那絕大多數都是Web了。所以這個地方的架構設計和我平時用的工作流有出入，這一塊的排序我也是覺得有一定的問題的。

9. 畫信息結構圖

剛剛在第7點提到了，我會先畫完產品功能結構圖，然后再畫產品信息結構圖，最后將兩者合并在一起，就得到了產品結構圖，也有人稱之產品架構圖。

10. 畫原型

這個就不展開說了，因為涉及到大一點需求，有頁面增加的或者調整的，基本上都要涉及到原型的繪制，而產品繪制原型就跟人吃飯喝水一樣的平常，沒啥特別的心得或者見解。前面都已經得到了產品結構圖，再繪制原型，就是對一個抽象數據進行實體化的一個過程了。

11. 原型評審

這一塊同上，也基本上是產品必做且常見的環節。需要注意的就是不要貿然開會，最好是準備充分再來召開評審會，否則很容易導致會議時間延長，或者是會議室被打成篩子，尷尬收場。

12. 寫PRD

PRD我現在基本上不寫純文字版的了，基本上都是Axure+批注+思維導圖+TAPD的方式來替代傳統的PRD。

主要原因有以下幾點：

• Word版本的PRD寫起來又臭又長，而還不容易修改，更重要的是基本上開發不會看；
• 敏捷開發往往一個功能涉及多個迭代，而一個功能會從MVP到豪華跑車，其中會經歷很久的時間，一份文檔要描述清楚有點勉強，可能最開始是幾頁，到最后就幾百頁的小說一樣了，維護和查看都很別扭；
• PRD維護成本高，編寫時間長，不如面對面溝通來的效率快，而且目前走敏捷開發模式的團隊居多；

當然，作為一個產品如果不寫文檔記錄點什么，那肯定是偷懶和不負責任的表現。所以，針對這一塊我的處理方式是這樣的：

一般的需求都是用TAPD管理，涉及到比較大的功能和模塊，會在Axure里面寫上對應的邏輯和規則等；同時為了方便查閱和后續的培訓等，我會按菜單或者頁面，用WIKI來分別記錄，例如我一直在維護的一個WIKI叫做WMS業務邏輯和規則，如果平時發現對之前設計的邏輯不記得或者模糊，那么看一下這個就能回憶起來為什么要這樣做了。

13. 產品驗收

產品驗收環節是我做的不太到位的，用敏捷的方式來看，這個驗收叫做迭代評審會議。PO帶上開發測試等，然后給一眾相關方講解演示產品的新功能，然后有疑問的或者未解決的功能在最后討論環節提出，最后決定是繼續修補完成還是放在下一個迭代中完成。

對于這個環節，要結合公司和具體的業務場景來看，有些公司的業務或者系統適合這樣的演示、評審，而有些又不是很適合。

但是我的建議是，如果可以，還是盡量進行這樣的環節，因為再華麗、再酷炫的產品，最后還是要落地來解決實際問題，而還沒落地的時候就知道這個產品不行了，那為啥還要因為沉沒成本而一直執拗地堅持下去呢。早發現，早治療。

14. 寫操作手冊

這一塊算是B端產品的特色了，因為新功能上線，往往是因為解決了某些已知的問題或者是新出現的業務，而這個功能肯定是大家沒用過，所以培訓就很重要了。平時我有很大一部分時間就花在這里，因為海外倉庫的培訓還有時差，地域，語言等因素的困擾，并不是灑灑水寫點先這個，再這個就完事的。

操作手冊這一塊可以考慮用一些便捷的工具來提高效率，縮短時間。例如用騰訊文檔的協作功能，幾個人在線共同維護一份手冊；也可以考慮用一些視頻截取的方式來替代傳統的截圖、標注，再文字說明的方式……

15. 數據分析

數據分析往往是后續迭代的動力來源之一，因為是騾子是馬還是要拉出來遛一下才知道。上線之后，根據之前定好的指標進行驗收，或者可以用數據埋點的方式查看效果是否達成。這一步也有很大的局限性，往往C端產品用的居多，B端產品要看具體業務來定，但是不管怎么樣，產品發布上線了，并不是終點，往往是新一輪迭代的開始。

04 我的B端工作流速覽

上面提到了我「看」B端工作流，其中有很多流程和我實際工作中的流程是吻合的，但是也有一些我會有不同意見或者不同的流程。于是這里我放一下我的日常工作流，做一個簡單的速覽。

1. 項目立項；
2. 需求調研&競品分析；
3. 畫用例圖或業務分析圖；
4. 產品主體框架評審與討論，確認大框架沒問題；
5. 繪制業務流程圖和系統數據交互圖；
6. 梳理產品功能結構圖，確認功能項與產品邊界；
7. 梳理產品信息結構圖，確定細節與主體信息；
8. 畫出原型圖，做好相關批注和邏輯說明；
9. 開始評(si)審(bi) → 評審一次后修改與調整 → 繼續評審 → 繼續修改 → 看開發測試是否已清楚，若清楚則開始進入開發；
10. TAPD跟進需求，這一步可前可后，但是最終版肯定是評審完后再維護完成；
11. 跟進開發內容，可以協助解決困惑點，同時參與部分測試與驗收；
12. 制定版本上線計劃，召開相關的評審會議（驗收會議），同時給出上線計劃，并順帶找時間寫好產品說明（操作）手冊；
13. 產品上線，完成收尾工作，記錄版本發布日志等；
14. 跟進上線結果，訪談用戶，查看相應問題是否解決，是否完成指標等。

以上大概就是我作為一個B端產品，日常工作的流程速覽內容了?；旧洗笠稽c的需求我都是按照這樣的流程來走的，其中有幾個點是我迭代過多次然后沉淀下來的，當然有些內容也會隨著業務發展或者我個人能力的提升而優化，在此僅做一個拋磚引玉的作用罷了。

05 最后

這篇文章寫了好長， 應該算是我寫過最長最久的一篇文章了，甚至沒有之一。

寫這篇文章的初衷很簡單，就是我在脈脈上看到了一個人分享的工作流竟然和我的很像，而我之前竟然很少看到類似的B端產品方面的內容，這讓我感覺找到了知音一樣。很多時候，產品聚集在一起可能談的更多的是一些思維方式，或者某個問題怎么解決，亦或者是某本書怎么樣的，很少會很具象地聊工作流的問題。

所以，我也想趁此機會，記錄一下我的工作流，正不正確無所謂，關鍵是能給人一些啟發或者幫助就好了。

上述內容，請大家辯證性對待，謝謝。

#專欄作家#

vitamin，微信公眾號：皮醬叨逼叨；個人博客：只言片語 –?記錄產品工作及思考的點滴；人人都是產品經理專欄作家。

中級產品經理，一年開發經驗+兩年產品經驗。主導過在線教育類產品，目前是跨境電商供應鏈倉儲物流產品一枚，歡迎勾搭，一同學習。

題圖來自Unsplash，基于CC0協議