㈠ 前端工作流程是什麼
公司性質決定流程，不過一般大體都是需求--設計--頁面製作--效果製作--添加程序。
假設 sys 級的規范和標准模塊已經完成（包括全局樣式、布局規范、標准盒模型等），這時需要開發一個項目，假設為淘江湖 SNS 項目。理想中的開發流程為：
a). PD 產出 PRD.
b). 交互統攬全局，將 PRD 中的可復用部分，拎取出來，產出 base-prototype.
c-1). 視覺根據 base-prototype，產出 base-mockup.
c-2). 前端根據 base-prototype 和 base-mockup 產出 app-dpl（該項目的 DPL）。
c-3). 交互繼續具體頁面的 page-prototype 產出工作。
以上三步是並行和迭代進行的。
d-1). 視覺根據 page-prototype 產出 page-mockup.
d-2). 前端根據 page-mockup 產出 page-demo.
以上兩步迭代進行。
流程的核心是迭代、是敏捷、是短周期。
最重要的一步是 base-prototype 的產出。交互要避免一個頁面一個頁面的產出順序，而應該先有一個統攬全局、拎取通用部分的步驟。
以上流程可以簡述為：sys -> app -> page. app 層的抽取很重要，可以提高團隊的開發效率和協作程度，讓團隊更融合、更高效。
感覺 LSM 強調的是前端工程師實現 demo 時的微流程。告訴我們做一個頁面時，需要 html 整體 -> 局部模塊的 css/js, 逐層開發，先整體後局部，先框架後細節。這是非常好的最佳實踐。
㈡ 產品經理應該怎麼寫BRD，MRD，PRD
在外企也好，合資也罷，職場中每個人都有自己的代號，不僅僅是Peter、Mary、Jack、Rose，還有各種PM、RD、QA、OP！這些英文縮寫都是什麼意思？初入職場或者准備踏入職場的你是不是已經有點犯暈了？今天小編就來給大家科普一下那些聽起來神秘又高端的英文職位縮寫。 1.PM: Proct Manager，產品經理，又稱品牌經理（Brand Manager）。舉凡產品從創意到上市，所有相關的研發、調研、生產、編預算、廣告、促銷活動等等，都由產品經理掌控。 2.RD: Research and Development engineer，研發工程師，對某種不存在的事物進行系統的研究和開發並具有一定經驗的專業工作者,或者對已經存在的事物進行改進以達到優化目的的專業工作者。 3.FE: FE有多種解釋，在實體經濟中，FE可以指Facility Engineer，廠務工程師，主要負責工廠的外圍的一些支持系統。在網路經濟中，FE可以指Front-End Development，前端開發，新新職業。 4.QA: Qualtiy Assurance，品質保證。QA的主要職責就是質量保證工作。 5.OP: Operator，操作員，管理員。
㈢ 你認為做出高保真原型還需要再寫PRD文檔嗎，為什麼
高保真原型只為在溝通中更為直觀的讓UI，開發了解你的功能需求。
內嵌的邏輯，細節，設計思維都還是得用PRD來講清楚的。
我個人認為：
高保真原型只是一個溝通的橋梁，具象化需求。
實質的邏輯還是得用PRD交代清楚。
給不懂技術的領導看，這個頁面估計還行，要是給開發前端UI測試看，這里還缺少大量的需求描述。一個完整的注冊功能需求描述應該包含如下幾個部分：
1）邏輯規則。例如：手機號碼長度11位、只能以13x開頭、不能重復注冊驗證碼重新獲取時間為60s，驗證碼有效期為20分鍾獲取驗證碼後，未收到簡訊，可以獲取語音驗證碼語音驗證碼獲取流程
2）交互規則。交互規則需描述「在什麼條件下，給用戶什麼樣的反饋」條件為各種事件，例如單擊、失去焦點、滑鼠移入、載入、刷新等反饋為各種展現，例如顯示彈窗、關閉窗口、打開網頁、文本框旁邊文字提示等
㈣ 倒推：小紅書話題模塊V1.0需求【PRD】
總結與思考：
在倒推了小紅書話題模塊之後，明顯感覺其中邏輯混亂，且運營未重視話題模塊，或因為後續小紅書更多是通過推薦邏輯演算法的方式去進行產品導向，此時前期的話題模塊因人力成本等過大原因而被弱化，且小紅書獨特的筆記方式其實更能很好地組織開展活動，因此小紅書現已逐漸淡化話題模塊的意義，之後或小紅書也會一並砍掉這一塊內容。
但話題模塊依舊是各個推薦演算法還不成熟的UGC類社區向內容產品的重要核心模塊內容。
目錄
一、 功能列表 1
二、 需求背景與目的 2
三、 話題模塊 3
3.1 搜索話題流程梳理 3
3.2 搜索頁面 4
3.3 話題詳情頁 5
3.4 關注話題 6
3.5 立即參與 6
四、運營配置後台 6
4.1 操作（新增/編輯話題） 6
4.2配置後台信息查閱 8
4.3篩選 8
小紅書本身是一個看起來不太重的產品，但實際上背後涉及的各個部分與各個邏輯都非常多，因為筆者也是屬於小白型，因此本次先提取小紅書運營相關工作的話題模塊來進行分析。
現有標簽內容但均為運營設置與篩選，缺少能直接通過特定頁面與特定內容，借用運營手段，調動用戶積極性，因此考慮借用話題內容，搭建一個個話題方式使用運營手段強引導用戶的參與與討論。
主要目的是通過運營手段刺激用戶引起共鳴從而進行點贊、收藏、評論、參與話題等行為，以此調動社區活躍度與營造社區氛圍。
目前用戶僅能通過搜索功能中的熱門話題模塊查看到運營設置的話題，或者通過查看別人關注的話題搜索到話題模塊。
點擊首頁搜索框，彈出搜索框模塊內容。搜索框模塊內容排序：歷史記錄（如有）、熱門搜索、話題搜索
話題搜索模塊頁面邏輯：
話題搜索同時最多展示10條記錄，包括運營設置的話題和相似標簽推薦話題，其中運營設置話題>相似標簽推薦
單條內容展示形式：左上角展示話題名稱，以「#」開頭，右上角展示該話題內總共擁有的筆記篇數，單條記錄中展示3篇筆記縮略圖
圖片筆記展示首張圖片並自動裁剪成正方形；視頻筆記展示視頻封面並在筆記上面出現播放按鈕，明確表示該筆記為視頻筆記。點擊縮略圖直接進入筆記詳情頁
單個話題內筆記排列順序：使用現有推薦演算法排序邏輯
特指針對運營設置的話題創建的話題詳情頁
思考：在分析小紅書的這一塊內容的時候其實提出了一個大大的疑問，為什麼要特定弄首頁和圖集模塊，難道單獨一個不就可以了嗎？這樣子不顯得多次一舉了嗎？
3.4.1 頂部介紹
頂部介紹內容包括：話題名稱、話題介紹、該話題的筆記數、瀏覽次數、關注按鈕
話題名稱、話題介紹：由運營在後台配置對應內容
話題筆記數：展示該話題所屬的筆記篇數
瀏覽次數：將所有筆記的瀏覽次數相加，再*X
關註：點擊關注按鈕，視為關注此話題。點擊關注後，對應話題會被收入到tab【我】-【關注】-【話題】中，具體邏輯見4關注話題
下拉內容後，話題介紹與關注按鈕隱藏，話題標題、筆記數、瀏覽次數居中顯示
3.4.2 首頁tab
點擊首頁展示所有筆記，其中提供筆記類型篩選項和不同排序項
篩選項：全部筆記、視頻筆記，默認展示全部筆記，切換到視頻筆記則只展示視頻筆記
排序項：按「推薦」、「最新」、「最熱」順序排列，默認按照「推薦」順序排列。
按「推薦」順序排列：按現有推薦演算法排序
按「最新」順序排列：按筆記發布時間倒序排列
按「最熱」順序排列：按熱度值計算公式倒序排列
首頁下拉，隱藏篩選項與排序選擇項
3.4.3 圖集tab
點擊圖集tab，筆記排列順序不改變，展示形態改變。展示形態變化。圖片筆記展示首張圖片並自動裁剪成正方形；視頻筆記展示視頻封面並在筆記上面出現播放按鈕，明確表示該筆記為視頻筆記。點擊縮略圖直接進入筆記詳情頁
3.5.1 關注邏輯與流程
（點擊大圖可以看到清晰版）
話題關注邏輯的完整路徑分為兩個階段：發現話題階段、已關注的話題查詢階段。
發現話題階段：用戶路徑：點擊【搜索】→ 看到「熱門話題」模塊 → 進入話題詳情頁 →點擊【關注】
已關注的話題查詢階段：用戶路徑：首頁點擊【我】→進入【關注】→進入【話題】
3.5.2 已關注了的話題
已關注的話題會被收納到底部tab【我】-【我的關注】中，用戶可在關注中查詢自己已經關注了的話題。此處展示邏輯：首先展示「你可能感興趣的話題」模塊，其次展示「我關注的話題」模塊。
「你可能感興趣的話題」模塊：此模塊展示的話題為涵蓋與特定用戶的部分用戶標簽匹配的話題。例如A用戶的標簽為」美食-午餐」、」綜藝-中國-天天向上」，A話題涵蓋的標簽包括「美食-午餐」，此時A話題出現在A用戶的「你可能感興趣的話題」模塊中，即每位用戶此處看到的是不同內容。默認展示3個話題，更多話題被收納到「查看更多」中。話題的排序按照話題旗下擁有的筆記創作人數倒序排列。
「我關注的話題」模塊：展示當前該用戶已關注的話題
前端顯示邏輯：展示 話題名稱、討論人數、關注按鈕
討論人數：指該話題旗下擁有的筆記創作人數
【關注】按鈕：按鈕狀態默認為關注，點擊按鈕，按鈕狀態切換為「已關注」，且所有地方查看該話題的時候，其對應的按鈕狀態均為「已關注」。「已關注」狀態下二次點擊按鈕，切換回「關注」狀態，且所有地方查看該話題的時候，其對應的按鈕狀態均為「關注」
點擊立即參加按鈕，跳轉進入拍攝功能，拍攝結束後創建筆記出現在該話題內
新增話題中一共涉及7塊內容：話題名稱、搜索關鍵詞、話題介紹、話題背景圖、關聯標簽、開始時間、結束時間。
話題名稱：輸入字元≤150，超過部分無法輸入
搜索關鍵詞：通過某一關鍵詞搜索可搜索出該話題。可輸入多個搜索關鍵詞，關鍵詞之間以「，」隔開
話題介紹：簡單說明該話題的介紹，或者該話題的活動規則。輸入字元≤150，超過部分無法輸入
話題背景圖：圖片格式為jpg、png或gif，圖片尺寸＜200K。圖片≥200K，上傳圖片失敗，toast提示【圖片過大】，提示3秒自動消失；圖片格式不符合要求格式，上傳圖片失敗，toast提示【圖片格式錯誤】，提示3秒自動消失
關聯標簽：話題關聯的內容標簽，可關聯多個內容標簽。內容選擇可通過下拉方式選擇或者直接輸入關鍵詞進行模糊檢索。其中內容標簽排列原則為同層級之間按字母排序，不同層級之間按從屬關系排列。三級標簽從屬於二級標簽，二級標簽從屬於一級標簽
開始時間/結束時間：點擊彈出時間選擇，其中選擇項包括年-月-日 時-分-秒，選擇後點擊確認按鈕，顯示設定值。配置時間段包括現在時間，配置內容即刻生效；結束時間在現在時間之前，內容可正常配置
表格包含內容：話題id、話題名稱、搜索關鍵詞、話題介紹、背景圖、關聯標簽、展示時間、當前狀態、操作。其中一頁至多展示20條記錄，多餘部分使用分頁方式解決。配置內容按照時間倒序順序排列
話題id：系統自動生成話題id
話題名稱、搜索關鍵詞、話題介紹：正常顯示配置內容
背景圖：展示縮略預覽圖
關聯標簽：每個標簽之間用「，」隔開，每行至多展示3個標簽
展示時間：顯示方式為 開始時間「~」結束時間，時間中間用「~」隔開
當前狀態：分為上線和下線。上線是指該話題正在前端展示中；下線是指該話題暫未達到展示時間或者已經結束，未呈現在前端頁面中，但如果用戶已關注該話題，依舊可以「我的關注」中查看到該話題。其中上線狀態單元格顏色為黃色（#FFFF00），下線狀態單元格顏色為綠色（#66FF00)
【修改】按鈕：對現有的標簽內容進行修改。點擊【修改】，打開「操作（新增/編輯話題）」窗口，進入該條記錄配置內容頁，原配置的內容保存在上，修改之後點擊保存，即刻生效；修改後點擊取消，內容無修改，記錄不更新
可根據當前狀態進行全局篩選。篩選項分為全部、上線、下線，默認為全部。
㈤ 如何更容易理解PRD－業務流程圖/數據流程圖（2）
仔細看了PRD，也和商品線的TL和DEV做了討論，雖然有很多細節（比如：搜索給用戶搜索習慣日誌結構，多種直達比處理結果）沒有確定下來，但是總體業務流程還是清晰了。昨天說了，PRD需要和很多角色溝通，所以我今天寫了2個重要交付文檔。（1）業務流程圖：站在用戶的角度，做了AsIs－ToBe分析；這種圖形化的對比非常清晰的表達了我們要實現的項目目標。在很多公司也叫UserCase，也叫StoryBoard，還有公司直接就叫Story。有了這個圖，就很容易看到我們要改什麼，和業務部門溝通起來就顯得非常簡單而且有效了。在這個基礎上在做一些細節的溝通就顯得簡單很多。 我喜歡看傑克遜的MTV，原因是什麼呢？有一個很經典的鏡頭，就是導演先放星球、然後地球、然後某個城市上空、然後某個大樓、然後某個房間、然後房間裡面有個漂亮的小孩在很響的彈吉他。影片感覺起來非常容易接受。這也許是溝通的一個技巧吧。先總體介紹，然後細節討論。一下子進入細節就很容易讓別人糊塗。當前的PRD材料就存在這個問題，大片的材料都是細節內容。未來可以考慮優化的就是適當增加一些圖形。 其實，在業界有種測試叫UAT，就是根據這個StoryBoard來展開的。對用戶（操作者）來說，他不關心內部是怎麼變化的，他只關心我Input進去的東西，output出來是我要的。前端的測試也是給予這個使用場景來的。（2）數據流程圖 數據流程圖，是一個更深入的讓業務和技術交流的圖形。這個圖可以讓信息流的變化清晰明了。然後我們就知道哪些地方數據如何處理，處理就要涉及到環節角色許可權等，信息的狀態變化就清楚的得到表達。數據流程圖還是資料庫、安全以及配置環境的重要參考資料。數據流程圖和業務流程圖的主要變化就是對信息流進行公開化。很多黑盒的變化過程被顯示出來。對於資料庫部門來說，可以清晰的看到哪些地方需要New一個資料庫，哪些地方需要修改，哪些地方需要考慮備份。 對於安全來說，從存儲、傳輸、訪問、日誌的角度，看哪些信息會在什麼情況下得到使用，狀態變化等，從安全的角度，要求加密、許可權控制等就可以清晰的看到。對配置管理來說，要配置什麼樣的環境也很清晰了。 對測試來說，也存在一個功能、性能測試的問題。從功能角度來說，我們跟著數據流走，很多功能就嵌在信息流變化上，我們在准備測試數據的時候就可以有針對性的准備了。有些公司還做另一些非功能測試，比如斷網、斷電、斷資料庫等，也可以從這個數據流程圖上來看。
㈥ web前端與產品經理哪個薪資發展好一點
我覺得是產品經理，前端局限性大一些，產品經理涉及的范圍更廣。
產品經理（Proct manager，簡稱為 PM，也稱產品企劃）是指在公司中，針對某一項或是某一類的產品進行規劃和管理的人，主要負責產品的需求分析，研發、製造、營銷、渠道等工作。一般來說，產品經理是負責並保證高質量的產品按時完成和發布的專職管理人員。他的任務包括傾聽用戶需求；負責產品功能的定義、規劃和設計；做各種復雜決策，保證開發隊伍順利開展工作及跟蹤錯誤等，總之，產品經理全權負責產品的最終完成。
簡單點就產品經理就是收集分析用戶需求，寫MRD，然後根據需求來策劃產品功能，畫產品原型、編寫PRD等文檔，同時也要負責產品的項目進度，與產品設計師、交互設計師、技術開發人員做溝通。
跟去年上半年相比，IT行業的產品經理的職位需求同比增長了50%。去年上半年平均每天在線的職位發布有5088個，今年上半年是7788個。在線職位的增長體現了企業在這方面的需求。互聯網的職位需求狀況呈現一個橄欖球的形狀，產品經理是屬於中間偏上的。北京一家網路技術公司10月22日發布了產品經理的職位招聘，在一個月內收到了103個申請；京東商城11月22日發布的產品經理職位，一天之內收到了32位在線申請者。這些其實都算是比較熱的。所以說前途可見無限。
另外關於產品經理的薪資，如果是一般的產品專員，年薪范圍是3萬到14萬，平均年薪是8萬；產品主管在5萬到24萬之間，平均年薪是10萬，產品經理是8萬到40萬，平均年薪為15萬；產品總監在20萬到40萬，平均年薪20萬。
IT和互聯網行業在快速發展，對人才的需求量也會變大。現在大家都強調用戶體驗，所以產品經理相比行業內的其他職位，增長是最快的。前景很不錯，但同時競爭也很激烈，因為它的要求比較高。大部分都會要求你有3年以上相關工作經驗，需要懂得設計、用戶體驗、市場調研、數據分析，研發之後還要能夠去做市場推廣，是一個綜合能力的體現。
㈦ 協同開發
通過需求評審，我們確定了具體工作內容，即將PRD中要求的功能實現出來。為此，各個工種互相配合，將功能落地實現。 在開發過程中需要多人進行合作開發，這其中最重要的事情是相互之間能否將事情說清楚，讓產品做出你想要的樣子。為了達成這樣的效果，要做好兩件事： • 第一是PRD寫的明白無歧義，所有的開發以PRD為標准； • 第二，無規矩不成方圓，規定好工作流程，每一個人按照流程做事。（其實，需求評審做好了，一般情況下協同開發時大家的目的都是清晰的，然後每個人按部就班做好自己的事情就能順順利利的將產品開發出來） 這里大致說一下一個產品流程，會牽涉到哪些人員。對於互聯網產品，最基本的要有五個人員，按照流程：由產品人員進行功能設計，接著由UI設計人員進行界面視覺設計，然後交給前端工程師進行前端開發，以及後端工程師進行後台數據搭建，當產品開發完後，需要運營人員開始運營產品。 開發過程中，誰都無法保證產品沒問題，所以有測試人員進行系統功能測試。一個產品為了增強用戶體驗，可能會需要UE設計師多去考慮用戶體驗效果，設計一些動態效果。產品、UI、UE、前端、後台、測試、運營，這些人構成了一個公司的開發部門。 不同公司會增加或減少這些人員，但無論怎麼變，絕對不會缺少產品、UI、前端、後台、運營這五個職位。其中前端指的有Web前端工程師、Android工程師以及IOS工程師。 工作流程上面已經提到了一些。按照產品、UI、前端、後台的順序進行功能產品的開發。每個環節交接時，上一級要給清楚下一級需要的所有東西，下一級要進行確認。要在限時時間內做好各自對應的工作。產品居中調控。 協同開發的時候，畢竟是多部門的合作，所以在這個過程中一定會出現很多問題。為了讓合作更加順暢，作為產品經理要做到團隊管理的角色。但在職位上產品經理和其他人員平級，沒有上下級的關系，所以要從哄、騙、信任感、責任感、打氣、畫餅、個人魅力等上面花些功夫，從而推動工作進行下去。 記住，工作中和同事之間工作的交接一定按規則辦事，將所有的交接文檔做好記錄。不是為了出問題的時候撇干凈自己，而是為了讓整個工作更加清晰，不至於混亂。當然，真出問題，有些鍋我們不能背，我們是有存檔的。
㈧ UI設計都包括什麼
【概念簡述】UI=User Interface，即：用戶界面。UI設計，也叫用戶界面設計，是指對軟體人機交互、操作邏輯、界面美觀的整體設計。
【應用場景】我們日常生活中所用到的：手機、電腦、電視、車載系統、iPad、ATM機、工業中控系統......只要是帶有電子屏幕的顯示設備，都有需要UI設計。
【實際意義】UI/用戶界面，就是我們：獲取信息、調用設備資源、控制設備運作的一個可視化入口界面
【設計職能】UI設計的職能，大體分為4個方面。
二，互聯網產品的開發流程是怎樣？UI設計處在哪一個環節？
簡要來說，一個互聯網產品（或App）的開發流程可分為四個階段：
調研與立項→設計與開發→測試與發布→發布與推廣，而UI設計則處在第2個階段。
調研與立項：確立產品需求文檔（PRD），為UI交互設計做准備。通常由產品經理（PM）主導完成。
設計與開發：依據產品需求文檔（PRD）→完成UI交互原型設計→完成UI的圖形視覺設計→研發工程師技術實現（前端工程師實現UI圖形界面的重構→後端工程師實現業務邏輯的數據處理）
測試與發布：團隊全體開發人員協作，解決交互、視覺、技術上的bug，由產品經理把控質量、協調時間，確保產品准時上線。
發布與推廣：多渠道、多方式、多媒介、的投放廣告，讓項目產品觸及目標客戶。
最後的環節就是，持續的內容運營輸出，提升用戶活躍度、拓展目標人群。接受用戶反饋，持續優化產品體驗，迭代更新。
三，UI設計師（圖形設計師）的主要工作內容有哪些？
我們通常所說的UI設計師，大多是指GUI圖形設計師，主要工作內容就包括：圖標製作、APP品牌製作、界面設計、切圖標注、推廣運營的活動頁面、banner製作等。
在互聯網產品開發的實際工作中，上游和你對接的是產品經理（或者交互設計師）；下游和你對接的前端工程師。所以，你通常是根據產品經理出具的交互稿，做UI界面的圖形視覺設計。這就要求你能看懂交互稿，懂一點交互知識是最好的。
在做完UI界面的視覺稿後，UI設計師將其標注好，再交付給下游的前端工程師，用作界面重構。必要的時候，設計師還可能會要用一些UI動效，去闡明設計師的設計意圖，所以懂一點UI動效設計也是一個加分項。
四，做UI設計，要用什麼軟體？
【UI視覺設計】的主力軟體其一是Photoshop。無論是圖形設計、還是圖像處理Photshop都能勝任，這是UI設計師必學一款軟體。其二是Sketch，目前僅支持Mac電腦，可作為選學。
【UI交互設計】的主力軟體其一是Axure，其二是諸如Adobe XD、墨刀、Sketch軟體，市面上的交互設計軟體非常之多，你要選擇哪款，這就看緣分了。
【UI動效設計】的主力軟體是After Effects。還有就是上面提及的交互設計軟體，不過只能應付一些簡單的頁面轉場切換動畫的交代，但並不適合用來製作增強用戶體驗的GIF，比如loading、下拉刷新的一些趣味動畫，不如AE製作出來的幀動畫效果細膩。
㈨ 女生做前端開發怎麼樣還是產品經理
產品經理是指在公司中，針對某一項或是某一類的產品進行規劃和管理的人，主要負責產品的需求分析，研發、製造、營銷、渠道等工作。一般來說，產品經理是負責並保證高質量的產品按時完成和發布的專職管理人員。他的任務包括傾聽用戶需求、；負責產品功能的定義、規劃和設計；做各種復雜決定，保證開發隊伍順利開展及跟蹤錯誤等。總之。產品經全權負責產品的最終完成。
簡單點就是產品經理就是收集分析用戶需求，寫MRD，然後根據需求來策劃產品功能，畫產品原型、編寫PRD等文檔，同時也要負責產品的項目進度，與產品設計師、交互設計師、技術開發人員做溝通。
關於產品經理的薪資，如果是一般的產品專員，年薪范圍是3萬到14萬，平均年薪是8萬；產品主管在5萬到24萬之間，平均年薪是10萬，產品經理是8萬到40萬，平均年薪為15萬；產品總監在20萬到40萬，平均年薪20萬。
IT和互聯網行業在快速發展，對人才的需求量也會變大。現在大家都強調用戶體驗，所以產品經理相比行業內的其他職位，增長是最快的。前景很不錯，但同時競爭也很激烈，因為它的要求比較高。大部分都會要求你有3年以上相關工作經驗，需要懂得設計、用戶體驗、市場調研、數據分析，研發之後還要能夠去做市場推廣，是一個綜合能力的體現。
企業需要高端人才。前端的市場的缺口是非常大的，但是缺的都是有實戰項目經驗的、自身經驗的深資前端工程師，而不是那些剛從培訓機構出來的菜鳥，會切個圖片，從網上找個相似效果嵌套就可了的。
2017年的web前端工程師想要獲得高薪，最需要具備的web前端知識：根據不同的薪資程度去深入的不同程度提升自己技能，華清遠見有健全完善的前端知識布局體系，不局限於前端，後端，資料庫，學會其他語言，開發者擁有深度和廣度的技能提升，等於擁有了企業最需要的技能，到時候你不但是HR爭相搶聘的人才，也是開發行業中的前端佼佼者。
㈩ 職業話題社區PRD——「職業社」
職業社App產品需求說明書
修訂記錄：
本文檔主要定義「職業社」App的功能詳細描述和前端頁面各個模塊之間內容和邏輯
0、商業畫布
1、目的
清晰有層次的定義頁面原型中各個模塊內容來源和相關邏輯
2、范圍
對「職業社」App中前端頁面涉及到的功能點、相對應的後台管理功能支持，以及部分交互細節。
本文檔主要讀者為技術部的前端工程師，以及視覺部的視覺設計師。
行業分析：針對現今愈發巨大化且偏向年輕化的求職市場，提供給待業以及使用過本產品的職場人員學習，交流等幫助求職的UGC問答社區平台
產品定位：定位於年輕化人群（20-40歲）的求職話題問答社區平台
一句話簡介：用戶在app中了解求職相關信息，與同行同業互動，幫助自己或他人找到心儀的工作，同時提升自我的平台！
用戶場景模擬
1、目標
創建一個只屬於求職者和職場人士的互助社區知識平台
2、總體流程
3、產品結構圖
4、 產品信息結構圖
5、功能摘要
6、全局說明
6.1 頁面結構
6.2 交互說明
1、登錄注冊
1.1 需求說明
1.2 用戶界面
1.3 流程圖
2、話題頁（導航、搜索和提問）
2.1 需求說明
2.2 用戶界面
2.3 流程圖
3、問題內容頁面
3.1 需求說明
3.2 用戶界面
3.2 流程圖
4、社區頁
4.1 需求說明
4.2 用戶界面
4.3 流程圖
5、消息頁面
5.1 需求說明
5.2 用戶界面
5.3 流程圖
6、我的頁面
6.1 需求說明
6.2 用戶界面
7.3 流程圖
此PRD文檔以需求構思+網路資料參考撰寫，仍有大量漏洞和細節部分未完善，需求為結合自身環境想像而來，文檔僅為提升自我學習參考使用。
有相近部分產品，以下
網路求職社交類：赤兔、獵聘同道、脈脈
知識社區分享平台：知乎
這款產品有點像將求職和知識問答社區融合在一塊的感覺，但不同還是很明顯的。
「職業社」是只提供職業相關（接近行業內部知識溝通）的職場類垂直知識問答社區。