我的B端產品經理工作流

產品老司機手把手教寫文檔,10天線上課程,零基礎掌握產品經理必備7大文檔撰寫法。了解一下>

相對于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端產品,日常工作的流程速覽內容了。基本上大一點的需求我都是按照這樣的流程來走的,其中有幾個點是我迭代過多次然后沉淀下來的,當然有些內容也會隨著業務發展或者我個人能力的提升而優化,在此僅做一個拋磚引玉的作用罷了。

05 最后

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

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

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

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

#專欄作家#

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

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

題圖來自Unsplash,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
  1. 首先贊樓主的總結,很詳盡,可用性也很強,下面說一點自己的看法哈。

    B端產品或后臺產品,從字面上分內工作是對靠前的產品和產品支持到位;

    從過程上講,可以從對業務效率這個角度拎起再發散,
    包括需求調研過程中對前臺業務的場景的還原、效率提升點的分析,評審過程中對該項目對效率提升價值的預期(最好可量化),產品架構分析中對核心流程與分支流程的定位,項目需求細分的輕重緩急;設計過程中,豐富后臺彈藥庫(支撐邏輯中,中間件、獨立功能等可復用部分)可能性的思考;
    開發過程中對項目管理理論的落地、風險的管理;測試或上線后,對于效率提升增量的總結等。

    每個細分過程其實都有很多可分析總結的,不過大部分B端/后臺產品在企業內行使著支撐角色,方法論在圈子里露出的也少。

    而且不如C端/前端產品那么引人注意,后臺產品的價值更需要產品同學自驅去梳理包裝。

    回復
    1. 同意你的觀點,里面有很多點都可以發散,否則產品兜來兜去也就那么點東西,大家早就看膩了。B端的方法論確實太少了,大家都沒有可交流和可發散的機會和環境。

      回復
  2. 從18年底開始接觸產品開發以來,都是B端的產品,
    你的經歷和思考和我簡直一模一樣,擔憂走成野路子,擔憂成長太慢,擔憂沒有同行可以借鑒,
    也在一步步的探索之中,令我感到慚愧的是你可以把自己的想法和行為記錄下來逐步修正,而我都是一直在腦子里徘徊,
    這篇文章對于剛入門產品,特別是B端產品的同學們很有借鑒作用,和PMP 以及工作實踐結合起來,可以總結出適合自己的方法論和規范流程,
    以后有機會希望可以多交流

    回復
    1. :grin: 我好像回復什么都有違禁詞

      回復
    2. hhhh 我猜是SNS

      回復
  3. 寫的特別好,受教了

    回復
  4. B端周期往往更長,所以流程來說整體更接近瀑布模式,而在調研和評審中會接入不同程度環來實現小范圍修正。流程落實是會有差別,但是總體的思想還是根據現有的人力、物力、時間等方面,在加法堆砌的需求上做出初期目標,用減法來做MVP版本。個人認為理想的流程不是本身多完善,而是參與的每個角色都能物盡其用又不會感覺特別難受

    回復
    1. 同意,核心點確實不是流程多完善,而是每個流程和參與的角色都能物盡其用,到位。

      回復
  5. 典型常規產品經理的工作模式,但差不多不很正常?

    回復
    1. 嗯,差不多是正常的,但是也有差很多的,所以每個人的需求和關注點的會不一樣,所以才需要溝通交流嘛

      回復
  6. 1.項目立項
    2.競品分析
    3.業務調研,一般使用用例圖獲取功能性需求
    4.整理成流程圖
    5.明確產品形態與需求列表
    6.繪制原型
    7.原型評審
    8.UI設計 開發 測試
    9.發布
    不斷穿插各種新需求與需求變更

    回復
    1. 很相似哦

      回復
    2. 666

      回復
  7. 您梳理的產品研發流程實際上企業erp的實施流程類似,還是對B端產品孵化有很深的理解,B端產品是一個重流程、偏業務的工具。我是做大型erp項目管理出身,轉產品經理3年,個人感覺B端產品更重要的是一種業務與軟件工具的結合能力,產品經理需要理解業務,更要理解工具與業務相輔相成的關系,在這基礎上把握好產品的范圍,最終為B端業務賦能;

    回復
    1. 對的對的,其實哪怕都是說B端,也會有很多人接觸的東西不一樣,所以我這塊只是我個人的所見所得。但是我認同您說的,業務和軟件工具結合,其實就是開發一套工具來解決業務,提升效能。

      回復
    2. 我的思維模式更偏應用一些,更多考慮的是產品的實際應用成功和價值輸出,對于實現過程我覺得你分析的沒問題。但是現實中接觸產品經理多了之后,發現很多人其實不清楚B端產品的定位,都糾結于功能的實現,被業務牽著走,變成需求運輸機,做的產品只能叫功能集合;

      回復
    3. 說的太對了,做久了,在一個圈子里就會容易變成需求運輸機,感覺每天把需求轉為實際可以開發的內容就是產品的全部了,這個當然是很片面的。但是我也覺得這個狀態是一個過程,每個人都應該從剛入門到需求處理機,運輸機這個過程成長,然后到了一定的程度之后,再考慮產品的價值,經濟,市場的局勢,商業的應用等。否則上來就因為一個按鈕大談用戶轉化,商業邏輯什么的,顯得也很輕浮。

      回復
    4. 666

      回復
  8. 同行

    回復
  9. 項目立項更多的是得到上級的支持,產品宣講更多的是讓關聯同事了解吧

    回復
    1. 是的,往往很多時候要做什么項目基本都是上級提出的,立項更多的是有點政治意味,為自己的項目爭取資源和確認地位;而產品宣講一方面是讓相關方來參與產品的開發生命周期,另外一方面也為了讓更多的同事了解你在做什么,這個項目的存在等,也可以爭取資源。

      回復
  10. 畫圖建議還是用工具,復雜的圖,老是修改,添加,再紙上根本沒得效率,更不用說拿著和別人討論講解。

    回復
    1. 這個地方我沒有闡述清楚,我的意思是初稿用紙和筆,最后成品肯定想用工具,我一般最后用visio定稿。所以這個地方可能給你帶來誤解了。

      回復
  11. 非常清晰!!!!!受益了

    回復
    1. 受教了

      回復
    2. 666

      回復
    3. 666

      回復
  12. 產品宣講,應該是團隊內部的宣講,用來傳遞一些信息內容,便于團隊對項目的理解,有些項目是分為不同子團隊來實現的,視具體情況而定

    回復
  13. 寫的很不錯,有一個清晰工作流,就不會太拖延,不然感覺每一步沒有邊界~

    回復
    1. 是的,有流程制度就會有約束力

      回復
  14. good

    回復
    1. 感謝支持。

      回復
  15. 1.需求調研,競品分析(一般沒有,toG)
    2.編寫立項報告 PPT 預算表,評審
    3.繪制流程圖 信息框架圖
    4.繪制原型
    5.原型評審
    6.UI設計 開發 測試
    7.編寫標案 報價
    8.發布
    9.投標
    10.中標 了解本地化需求
    11.再循環

    回復
    1. ;-) 很多流程都會有相似性,你這個也很棒。

      回復
    2. 這個相對來說,從流程這塊比你那合理,立項之前先要理順需求

      回復
    3. 也有道理,各個公司和環境不一樣,按我這邊接觸到的,我們的立項都是因為業務驅動或者市場行為驅動,可以簡單理解為,這個項目必須做,而調研可以前也可以后,我接觸到的比較多的都是后的。而且立項這個事情,絕大多數人遇到的都少,畢竟從0開始做一款產品的機會還是少。

      回復
    4. 沒有需求,就沒辦法去估算工作量,也沒法去估算費用,如果只是大概的估算,很有可能會導致項目延期。這里面還有很多東西,比如需求的優先級,迭代計劃,什么時候能上線那些功能。

      回復
    5. 66

      回復
虎扑足球手机虎扑网 11选5高手是怎么赢钱的 宁夏11选5前三直走势 360山东11选5 理财产品排行榜2018 内蒙古十一选五开 广西快乐双彩开奖结果开奖号码 黑龙江大庆微乐麻将 三国麻将无双破解版下载 恒乐股资 四川快乐十二的走势 疯狂飞艇害了多少人 大乐151期透开奖结果 股票配资推荐公正卓信宝配资精湛 河北省11选5开奖 黑龙江36选7近100期 佰亿配资