1樓：產品一哥
題主你好，鍛鍊對自己產品的理解，建立詞典：公司定位、使用者定位、產品定位、公司研發能力、其他部門狀況。
使得所有產品、設計、研發、測試、運維工作能圍繞著統一的需求開展。保證專案能順利進行，完成目標。
產品一哥：萬字乾貨！0基礎如何拿到產品經理offer《0基礎如何拿到產品經理offer-資料分享》，資料提取碼【z8nr】
0基礎如何拿到產品經理offer-資料分享產品經理求職-面經分享
產品經理求職-面經分享
2樓：做產品去創業
首先得確定產品階段性目的與目標。再來匹配最低限度的需求能完成目標。最低限度需求意味著最低的風險和最少的投入。
需求很多總的原則的是盡量少做。
3樓：遍歷分形2077
作為網際網路從業者，我想除了眾所周知的「996」「35歲被優化」等老梗之外，另外為人所熟知的，就是產品經理和開發之間的矛盾了，由此誕生了「砍我可以砍需求不行」、「伺服器又出故障了，該拿程式設計師祭天了」等其他相當知名的段子。
產品經理和開發之間的矛盾由來已久，段子和故事不可勝數，但是深究原因，其實無外乎需求經常變更或是專案發生延期，換言之，就是對於專案缺乏有效的需求管理，而最終的後果，小到專案員工日夜加班，大到專案失敗，甚至公司業務崩潰。
很多人往往將這些被可以避免的問題歸類於是其他難以避免的重大問題(資金不足，決策失誤，市場變化，政策變化等等），畢竟以上問題是所有公司都有可能遭遇的問題，它們太過普遍以至於如果將這些問題作為原因的話，我們很難得出更多有意義的結論。
事實上，根據 PMI 進行的多項需求管理調查得出：糟糕的需求管理流程常常被認為是專案失敗的首要原因。
以上內容出自我的專欄文章：我們應該如何進行需求管理
遍歷分形：我們應該如何進行需求管理「上篇」？
遍歷分形：我們應該如何進行需求管理「中篇」？
遍歷分形：我們應該如何進行需求管理「下篇」？
4樓：增長氪
需求管理:需求管理的核心是作為「較少彈性」的企業對「不斷變化」的市場的根源一對需求的不確定性進行有效控制和導引。市場機會就在於未被充分滿足的需求(包括反需求)和一切需求之間的失衡狀況，而營銷管理的主要任務是刺激、創造、適應及影響消費者的需求。
一百多年來，寶潔其實只專注於一件事，那就是挖掘消費者最本質的需求，以精益求精的態度打造滿足消費者需求的創新產品。寶潔在公司內部設立消費者學習中心，這裡還原了迷你超市、客廳、臥室等消費者真實的生活場景，幾乎每天都有消費者來到這裡，參與各種各樣的調研、測試。研發中心還設有試點工廠，生產用於消費者測試的小批量產品，從而快速得到消費者的反饋，這些細緻入微的消費者洞察都真切融入寶潔的產品中。
需求產生產品、產生渠道實現的方式，需求指導定位。
5樓：蘆葦微微
需求在不同階段有不同階段的處理方法。
1、需求獲取階段
與使用者交流獲取原始需求，對原始需求進行分析和挖掘真正的需求，將需求細化，輸出需求說明書。
2、需求分析階段
對各個小需求彙總，從乙個整體功能架構圖能一目了然知道這個產品是幹嘛的，不需要讀一大串長文字。
3、需求驗證階段
開發開發完成後，對需求進行驗證，是不是與使用者需求一致。
4、需求變更階段
需求存在變更，用需求矩陣記錄每次變更情況，每次變更的原因是什麼。
5、需求跟蹤階段
對需求從0-1，進行跟蹤直到專案的驗收
6樓：Vision.聲
需求分析和管理的關係在實際工作中相輔相成。
需求管理的核心需要依託於需求本身的優先順序（排列優先順序的方法最常見的方法應該是「重要、緊急」的四象限切分）。
而優先順序則是在需求分析中，基於需求被確認存在且需要實現後的最後一步。
看題主的描述，我的感覺（猜測）是，更多的問題來自對大量需求的管理（所以分析就不說了）。
首先，我認為一些需求的變更和無法落地，是大家普遍存在的問題。我們的確會在產品的迭代中對於需求有新的理解，這時候要做的是再次做需求分析，不能為了執行而執行。
其次，我的需求管理與其他答主大同小異，我的建議是定期對需求池做複查，對時間週期的判斷，還是會經常因為現實被打破的。這點沒啥轍。
最後想說，其實需求管理本身就是個苦活，更何況很多需求是產品經理控制不了的。
7樓：費曼
1、提交產品需求時，判斷消費者的接受程度。
消費者願意買的就是合適的需求，看到你的廣告就想買，就想改變，改變的手藝大於成本。
2、對需求進行分析：
（1）是不是在幫顧客做他自己本來就想做的事。
（2）顧客對現狀不滿嗎。
（3）做出改變的首選是不是你。
（4）選擇你會不會面臨風險或阻礙。
（5）是否可持續揚長避短。
8樓：執手攀花
工具只是幫助我們實現目標的，而非目標本身，所以，無論用哪個工具只要能幫忙我們完成目標就好，我們不迷信工具，只相信效率。
現在我們回歸到產品的始末
需求分析-產品生產階段
從產品的可行性分析——編寫可行性分析報告(MRD)——需求收集與匯出——需求描述——需求驗證——需求文件（PRD）。
整個的需求工程，包括了四個階段：
1.可行性分析；
2.需求匯出與分析；
3.需求描述；
4.需求有效性驗證。
整個過程走完，你會接觸到該產品的始末，因為需求過程中，涉及到了產品的研發思維及後期的軟體模型，還涉及到競品分析，得到一些新的運營思維，乙個產品的戰略思維。
這個過程涉及到文件如下：可行性分析報告、MRD、需求列表、競品分析文件、PRD、原型、DOME。
需求工程完成後就是軟體的實現，需求分析前期的工作做好後，初步的軟體模型及軟體的架構基本可成型，具體的流程及邏輯將在實現這個階段進行；個人理解為三大步驟：
設計輸入：平台模型，需求描述，資料描述及邏輯思維圖，腦圖等；
設計活動：軟體架構設計，介面設計，元件設計，系統設計；
涉及輸出：系統體系架構，資料庫描述，介面描述，元件描述；
完成軟體的實現後接下來就是測試，測試一般分三類，介面測試，元件測試，系統測試，最後交付的時候驗收測試；測試階段是乙個有效性驗證的過程，也是乙個反覆的過程；等到測試完成後就可以進行產品的交付；也可以說乙個專案的中止。
如果目前基於中小團隊、不願增加專案成本、開發資源又十分有限的前提下，幾款最適合的有teambition、teamin、worktile、tower 。如果開發資源充足，還可以考慮開源整合的工具，比如Trello和Forecast都提供了開發者文件，另外還有Redmine、Jira、禪道等各式各樣的專案管理工具可以參考。
9樓：
有多少產品經理系統地學過軟體工程？
有多少產品經理看過《軟體需求》？
有多少產品經理理解scrum並不斷實踐？
有多少產品經理說：軟體工程那套東西是程式設計師才看的，跟產品經理有一毛錢的關係嗎？
10樓：胡曉東
做了二十年產品了，乙個讓你哭笑不得的經驗就是：大多數的需求分析是白費工夫，因為最核心的需求是基礎體驗！比如說，你乙個做閱讀的至少讓人可以安安靜靜看篇文章看本書吧，你一電商總得讓人正常登入購物流程順暢吧，你乙個遊戲至少把閃退控制好一點吧……然而大多數情況是，這些基於「常識」的基礎需求遠遠沒有做透的時候，就忙不顛兒地搞新需求了，更糟糕的是一些政治正確的領導需求，一些商業正確的運營需求，進入這個迴圈，該產品做到最好也就是平庸了。
不過就我本人而言，遇到這種坑要麼頂、要麼走，讓我認帳門兒都沒有。大概也因為這個原因，雖然屢屢受挫，但總算能夠作出點兒好東西。世間好的產品都是「為人民服務」，平庸的產品往往「同志們辛苦了」，最爛的產品是「首長好！」。
11樓：李大熊
1. 將提煉出的需求按複雜度，區分成Task和Project級別，Task級別一般屬於細節、文案調整類的，繁瑣細節但是占用資源不高，可以快速處理的任務；
2. Project屬於有一定工作量，需要做詳細的需求評審，評估工作量等；
按複雜度區分就是指根據區分的Task和Project，以不同的節奏實施，非緊急情況下的Task需求，根據團隊約定的產品迭代節奏，依序實施迭代優化細節。而Project的實施，則更多的依照專案實施流程，根據優先順序和時間計畫實施。
3. 要設立意外情況方案，當出現緊急情況時，需要有相應的預案快速實施，快速上線；
永遠要記得，人應該handle原則，而不是被原則handle。
需求管理原則
1. 戰略級專案（政治任務）永遠P0，不要試圖強行扭轉老闆的觀點，如果不可行要想辦法從根子上把事兒做成，在底下做事兒永遠要記得，「讓老闆思考細節就是你的失職」，只要方向一致執行上的問題是可以bargain的；
2. 在專案實施是一定要控制需求產出，就像 @曾軼 說的要有Freeze Time，需求的產出一定是無止境的，在專案實施中無限制的加入需求是很多實施失敗的根本；
3. 把握好老闆的心態，明確老闆的目標。控制需求越級下達在於能把握老闆的大旗，能把控產品的節奏和主線，需求的存在有他的合理性，但是時間是要有產品owner說了算；
4. 低優先順序別的需求就好像那些不緊急也不重要的事兒，專案爽完之後沒有人想起；
5. 不要幻想乙個匠心獨具優雅的設計能大殺四方，能大殺四方的永遠只有為使用者帶來的價值；
6. 如果每天為了管理需求各種艱難困苦，從根源講你沒有能力把控這個產品的走向，從而使得你沒有得到話語權。
感謝@曾軼 的回答，以上回答是就著他提的框架將我做專案管理的經驗寫下與大家分享。
12樓：山下哩人
不邀自來。作為一家傳統轉線上的公司，
我還是比較幸運，產品功能流程都是PM決策。需求級別，當然是先解決樣式，然後磨功能。
在沒有樣式調整的時候，才是功能，以快速更迭為方式。因為行業特殊性，大多數功能都通過線下走了……
13樓：
畫乙個大大的導圖，把平時從使用者反饋、老闆反饋、同事反饋的值得思考的問題全部放在裡面，迭代需要需求的時候從裡面挑，然後頭腦風暴該怎麼設計功能，然後花一周時間細化需求，兩周後開發完成--來自現在公司的工作經驗
14樓：萌咔
我覺得在做產品需求的時候，要理清自己的思路。
1.思考這些功能是不是我所必須的，如果不是必須的，那可以放到延後的計畫中、
2.如果幾項都是必須的，那能否精簡，只要能夠讓使用者先體驗到最核心的體驗先。
3.如果其中必須放棄一些功能，那麼可以考慮按照投入回報來排優先順序。
產品經理如何做好需求管理和分析？
海峰 需求管理和分析需要分開。單叢業務季節屬於不同類別。需求管理是需要定製標準的需求管理方案，建立需求分析儲存池子。將蒐集到的碎片化需求通通放入需求池裡面，進行統一分類，設定優先順序，然後細化需求。這部分內容在需求管理中。另外細化需求時可以將多個有關聯的碎片需求集中梳理，繪製流程圖，將大的思路理出來...
作為產品經理，你每天的時間是如何分配的？
10 時間學習 看文章 1 讀書 靜不下心來，在公司容易浮躁，事情多 30 70 開會 只要有會議，一般都能開個半天到一天，但不是每天都開會 60 產品策劃 王大力 在小公司 60 聽老闆突然想到的新創意 我不認為 10 想法辦法打消他的小法，並一五一十做跟他做各種分析 10 爬摸各個角落 15 帶...
作為產品經理，你是如何在工作之餘拓寬人際關係的？
寫字專用小馬甲 分析題主的問題描述 通過拓寬人際關係來提公升自己的視野和綜合能力 這裡可以得到題主的目標是 提公升視野和綜合能力，而拓寬人際關係僅僅是題主認為的一種實現手段而已 先上結論 拓寬人際關係這個手段恐怕沒法幫助題主達成提公升視野和綜合能力的目標 原因如下 1 一般來說能拓展你視野和綜合能力...