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

本文講解了三大工作技巧，適合0-2歲的初階產品經理，希望可以幫助到你們~

曾經一度錯誤認為，產品經理的日常就是連環撕：撕運營，撕完運營撕設計；撕設計，撕完設計撕開發，好像產品經理為了捍衛產品思路一直在做抗爭，永遠都是對方傻，對方沒明白，對方無理，對方太閑。

這一年半的產品工作，教會我學會理解不同角色的焦慮和怒點：頂著kpi壓力但不知道實際開發進度的運營喵，費神費腦把功能趕出來卻被告知需求又改了的程序猿，有交互和視覺追求和堅持的設計獅，還有八九份合同還沒看的法務兔……

很多溝通上的易燃易爆點，產品汪其實是可以把控的。產品經理的職責就是清晰表達需求，高效推進項目。讓各個崗位角色都順暢溝通舒暢干活，最終達成目標。

對于0-2歲的初階產品經理，如果能做到以下三大工作技巧，會成長得很快：

一、PRD

網上有很多需求文檔模板，產品經理入門最快的手段就是從前輩實操過的PRD中學習表達需求。同時，為了加快輸出需求文檔效率，我常常會更新我的需求文檔模板，拿來就用。

小結一下就是：創建你自己的需求文檔模板，盡量讓下次的需求少一點會被diss的漏洞，更有條理更清晰明了。這里提供我目前的模板，僅供參考：

1. 文檔基礎

（1）文檔性質

因為文檔輸出的時效性要求非常高，不能僅為了文檔的門面就耗費太多時間，所以PRD的格式不限，可以是doc、xls、rp等，只要能“清晰表達需求”即可。一個需求內容，我可能會根據實際情況用多格式文檔互為補充。

其實這里用了“組件”的思維，完整的需求表達由很多個模塊組成，每次有更新，就更新該模塊即可，對接人按需使用。

（2）文檔命名

《【文檔性質】需求名稱（備注） 文檔版本號_需求人名字_更新日期》，當需求本身和文檔分別有版本號，兩個版本號又比較重要時，我會把文檔版本號放在最后。文檔版本號不是特別重要時可不寫。

（3）修訂記錄

這是非常容易忽略的細節位，很多人沒養成好的工作習慣，工作就會很混亂，效率很低。每一次修訂需求材料，就應該及時做相關標注。更新的頻率不定，只要需求有少許變動或者補充，我都會做一次文檔更新，作為留底。

（4）頁眉頁腳

當文檔某一頁被打印或截圖出來，你是否能快速知道這是哪一份文檔的第幾頁內容？

2. 文檔結構：

（1）需求概述

產品經理可能要對接多方需求，如果對方只是“一句話需求”的時候，就可以讓需求提出方先按以下格式梳理需求，然后你再輸出后續的方案。

這些內容都是重要鋪墊，需求文檔就是要讓每一個參與項目的人都能了解需求的全貌——需求是什么以及它的目的和價值是什么，避免讓參與人員僅僅成為需求的執行者，你需要讓劃槳的每個人知道這條船究竟要駛向何方。

• 名詞解釋
• 需求背景（包括需求來源、需求目的、需求價值）
• 產品概述（包括產品簡介、基本原則、基本思路）
• 競品分析
• 投放渠道
• 性能要求（包括網絡連接、手機操作系統、消息推送系統、后臺數據庫、服務器操作系統、系統吞吐量等要求）
• 資源引入（包括資源提供方以及具體介紹）

（2）業務流

原型只是需求內容的一部分，不要讓自己掉入原型無法自拔，要關注需求的全貌。

• 需求清單（項目較小時，我會在文檔內簡單羅列；項目較大時，我會專門用一個表格文件來梳理。）
• 需求詳述（包括通用、細分的詳細說明，原型圖可在此處輔助理解需求。注意兼顧常規流程和異常流程，盡量讓設計、開發和測試沒法找茬~）
• 流程圖（當一個需求看似很簡單，一句話就表述完成時，那建議你先去畫畫流程圖，忽略的方面自然就會顯露出來。）
• 設計需求（包括風格取向、色系取向、形象標識、其他設計要點等，讓設計發揮之前，你需要先考慮你想要的是什么，避免來回改動。）

（3）后臺支撐系統

需求寫到這里，可能你也累了，但要堅持下去。

• 數據統計需求（具體內容我通常會放到數據模板的xls里，數據模板包括數據字段名稱、定義、報表接收名單、修訂記錄等。）
• 配套的配置系統（視各平臺業務而定）

（4）安全基礎

原型只是需求內容的一部分，不要讓自己掉入原型無法自拔，要關注需求的全貌。

• 壓力測試要求（視需求的影響范圍，參與壓力測試，保證整體鏈路的內部系統達到壓力測試要求。）
• 壓力測試流程（因為是我比較陌生的領域，所以做好相關備注，每次按流程來做。）
• 歷史壓測結果參考

（5）資金流

我通常會把信息流放到業務流一并梳理，資金流涉及實際的金錢流向會專門拎出來。

• 對賬范圍
• 對賬單
• 對賬數據規范
• 查錯處理

（6）技術對接

技術細節注意點會標注在這個板塊。開發中出現新的問題以及對應的解決方案也可以寫在這里。

（7）運營規則

產品成型后，要制定運營策略。

• 法務規則（合法是基礎。平臺協議、產品紀律等有時會是產品盲區，特意留了這個板塊提醒自己要全面思考需求。）
• 產品運營規劃
• 運營工具
• 客服文檔（提供給客服人員閱讀的產品介紹文檔。）

（8）附錄

記錄需求材料中涉及到的文檔名稱。

以上是需求文檔內基本的要素，使用時因根據需求本身按需使用，確實不涉及的領域可以不填。

二、需求池管理

近一年我的工作范圍較廣，屬于多領域嘗試，所以需求來源非常廣泛，但并不影響我成為部門內高產出的代表。這非常依靠溝通、協調和需求管理能力。

我曾經是石墨的忠實粉絲，在管理UI設計和前端團隊的需求時，就開始有意識培養團隊共同完成排期管理表，到現在他們也一直在沿用。

后來騰訊文檔出現之后，屈服于企鵝家的社交關系網，我就轉用它來與對接方進行需求池的整理（雖然線上編輯功能還不是太完善，但滿足基本的編輯需要）。別看它是個簡單的表格，細節上的用處非常多：

• 每周發出此表的更新版，讓需求提出人、需求對接人（產品經理）、需求執行人（設計、開發等人員）可以自行查閱相關需求在整體中的進度、優先級等。
• 我在表格后面設了一列自用的“上線月份”，每次填月度考核時，就導出表格然后篩選考核月份完成的需求，就不怕自己記性不好會漏掉成果。
• “需求提出時間”就能知道項目拖延程度了，如果是個人原因，就要注意做好需求優先級的考量和需求清理工作。要記得，做到清晰表達需求也是為了高效推進項目。執行力是產品經理的必備技能。項目推不動，就是你的不作為。

三、不斷學習

雖然產品經理不用手把手敲每一行代碼，但需要補充程序思維。程序猿在面對一個問題，除了已有的經驗，可能更多地是依靠搜索解決問題。

一句“Hello world”開啟的是全球知識資源的互通，只要不故步自封，多主動去挖掘有效資源，網上有那么多免費或者付費的知識內容（需自己篩選有價值的），個人增值的途徑還是有很多的。平時多逛逛技術的社區，培養對程序猿的崇拜感（哈哈哈哈哈哈）以及共同語言，對技術的敬畏可以讓你變得謙遜而不是趾高氣揚。

而培養自己的產品感，就要多體驗多思考：抖音與賭博之間的相似點是什么，上傳在抖音和微博的視頻各有哪些編輯區別點，為什么在支付寶付款碼頁要露出一個不可點擊跳轉的會員等級信息，為了用戶留存小程序們都做了哪些心機動作，還有好多類似于牛奶經濟學一樣的產品學問。

《人人都是產品經理2.0》中提到產品、開發、運營三者的關系：想清楚、做出來、推出去，在產品設計之初，就應該遠慮，產品誕生不是最終一環，被市場認可需要很多的運營手段。所以產品經理也需要學習社會新出的運營花樣，再結合到產品設計中。

我是以產品為核心，運營、開發為新觸角作為自己的發展方向，雖然離“全棧產品經理”還有很長一段路要走，但這個時代，屬于年輕人的機會太多太多了，加油~

寫在最后：需求從提需求到上線究竟經歷了什么：https://weibo.com/tv/v/GcHote2L4?fid=1034:d9cc17f3761874df3990a40806548d3e

本文由 @婉盈不是這個瑩 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Pexels ，基于 CC0 協議