我是乙個從傳統行業5年需求分析師轉型做產品經理的同行，很多人都說需求分析師就是產品經理，產品經理就是需求分析師。對於這個理解我個人覺得是狹義的，在某些方面或者某些公司，需求分析師和產品經理的工作是有重合的，但這並不代表兩者就是一致；
產品經理負責調查並根據使用者的需求，確定開發何種產品，選擇何種技術、商業模式等。並推動相應產品的開發組織，他還要根據產品的生命週期，協調研發、營銷、運營等，確定和組織實施相應的產品策略，以及其他一系列相關的產品管理活動。
需求分析師則負責解決的問題進行詳細的分析，弄清楚問題的要求，包括需要輸入什麼資料，要得到什麼結果，最後應輸出什麼。可以說，在軟體工程當中的「需求分析」就是確定要計算機「做什麼」，要達到什麼樣的效果。可以說需求分析是做系統之前必做的。
那麼說來說去都包含了需求，我們如何確定需求的正確性，來拒絕不合理的需求呢？
有人說產品經理就是在不斷的重複乙個挖坑、填坑的動作，當你在不斷挖坑填坑的過程中有所感悟了，說明你就進步了。
老闆提出重點設想-----大家一起劃定功能界限----產品進行構思畫出原型----與老闆進行需求原型溝通確認，進行相關調整----召集專案經理及相關技術人員進行需求功能評審------調整原型及需求規則-----專案經理確認完成進入開發階段。
這裡想強調一點，需求的完成不是產品經理和老闆確認好就行的，在開發前需求一點需要專案經理介入和最終確認，因為實現完成者需要技術執行。不管你需求把握分析的多麼準確，原型畫的多麼漂亮，技術實現不了，一切都是空想，只有跨部門間溝通確認才能完成。
老闆提出的戰略方向的需求：老闆會站在戰略層的事務，在確定了產品的方向之後，他會對產品的樣子有個大致的想象，有些功能是必須要有的，這時候，他會和大家討論哪些需求建議加上去。
產品經理根據產品方向規劃需求：產品經理需要進行基本的競品分析對比、收集各方面的資料，然後分析得出需求有哪些。
產品運營根據推廣運營活動及使用者訪談提出需求：產品設計出來是給使用者用的，而最接近使用者的是產品運營人員。那麼，不管是乙個產品最初的誕生以及迭代，產品運營人員都應該做使用者訪談，去獲取使用者的痛點，使用者用得不爽的地方有哪些，然後列乙份需求清單給產品經理進行反饋。
其他參與者和關注者反饋需求：這裡包括ui、ue、dve，因為對於這些人來說他們也希望自己做的事情、負責的事情能有成就感，往往他們提出乙個問題，我們應該去思考，而不是一下子否則，最終大家溝通討論從而確認需求，這樣不僅讓他們做的事情有成就感，同時也會讓他們更關注和主動。
我們目前的需求確定方式都是採用tdd記錄需求源。為了保證需求的不遺漏，也為了驗證需求的有效性及改動頻率，我們目前正在做乙個需求管理的小系統，流程如下圖：
一切需求源完成後，我會召集相關人員進行需求確定，這裡的人員包括專案經理，需求提出人、產品經理、老闆等干係人員。
會議上產品經理作為主持人，在介紹完產品背景以及產品戰略上的資訊後，就正式進行需求的評審。
先列出需求，然後先讓提出此需求的人說下提出此需求的原因，然後進行投票：
在思考的過程中，強調給出意見之前，站在你是乙個產品小白使用者的角度上，你會不會有使用這個功能的需求。
如何投票確定需求，打個比方：
會議共有9個人，有個需求進行投票表決，每個人只能投一票。
會議結束的過程中，需要專門有人在旁做會議記錄，把會議過程以及最後的決策記錄下來，會議後**給參會人員，很多時候，記憶總是不如文件來得實在。（我們都會上傳到svn存檔）
有些時候老闆可能由於事情耽誤無法參與需求確認會議，這時候作為產品經理的你需要把老闆提出的需求進行詳細的反饋並發給老闆。
大家可能經常會遇到在進行一些需求確認的時候，一些開發人員總認為這個需求太荒謬，這個需求太不合理，有些可能對老闆提的一些需求直接覺得不靠譜，這時候作為產品經理的你，不僅需要把老闆的需求背景、需求描述、需求**給參會人員進行講解，讓大家都理解的情況下進行投票。如果最終老闆的需求被pass掉了，你需要記錄並把大家的意見反饋給老闆，讓老闆知道具體原因，從而再次確認。
專案經理在需求確認過程中有一票否決權，不管這個需求**於哪個部門角色，甚至**於老闆自己，因為專案經理會站在技術的角度對這個需求進行評估考慮，如果不能實現，大家討論再多都是扯淡，但是需要進行記錄原因，為何不能實現？有何風險？是否會影響進度？
以上是我們目前需求**蒐集、需求確認、需求會議總結的方式和方法，但是在實際過程中我們也遇到了許多問題，表現如下：
1、開發人員質疑這個需求不合理：這個時候作為產品經理的你就需要從自身思考，是否這個需求沒有講述清楚？從而誤導了開發人員？
（這裡切記不要說這是***的需求，我也認為不合理，但是沒有辦法，這樣只會讓開發人員鄙視你，造成你後續的被動，工作越來越難開展）
2、開發人員在實現需求的過程中可能會比較複雜，不願意實現：這個時候作為產品經理的你需要了解這個需求為啥實現中比較複雜，是否和你理解的正確？
（這裡就需求你和技術多多溝通，有些必須實現的需求絕對不能讓步，這種問題當你讓出第一步的時候就會出現第二步，不僅到時候會讓老闆對你有看法，同時也會很被動）
3、開發人員簡單實現一些和規則不符：遇到這種事情你不能直接上去就是指責***，而是要了解下這個需求這種實現是否可以，能否滿足功能要求。開發人員基於啥這樣實現。
（產品經理和開發人員是承上啟下的關係，也是完成乙個需求功能不可缺少的一部分，正確的溝通和理解會讓你在以後的工作中得心應手）
總之我個人認為需求的確認需要大家一起來確認，不是老闆的責任，不是某乙個部門的責任，不是某乙個角色的責任；要適當的學會拒絕，學會溝通，才能讓需求更正確的執行。
在工作中我也會跟開發、ui等相關人員進行激烈的溝通和爭吵，但是都是基於工作需求；任何乙個需求的確認如果只是平平淡淡，沒有一點問題和摩擦肯定會出現問題，只有大家一起溝通確認才能讓需求正確的執行。
學會拒絕不合理需求，學會正確溝通需求，這是作為乙個產品經理最基本的責任；
拒絕不靠譜的需求 怎樣確定需求才是正確的？
我是乙個從傳統行業5年需求分析師轉型做產品經理的同行，很多人都說需求分析師就是產品經理，產品經理就是需求分析師。對於這個理解我個人覺得是狹義的，在某些方面或者某些公司，需求分析師和產品經理的工作是有重合的，但這並不代表兩者就是一致 產品經理負責調查並根據使用者的需求，確定開發何種產品，選擇何種技術 ...
當領導提了不靠譜需求怎麼辦？
當領導提了不靠譜需求怎麼辦？相信每個人都碰到過不靠譜的領導，比較無法保證能一直遇到對的領導，完美的團隊。當我們遇到不靠譜的領導時，該如何對待？背景描述 大多數都會遇見這樣的問題領導隨時都可能乙個 或一句話提乙個需求，然後要求馬上做。更悲慘的是，辛苦做出來以後，說放棄就放棄。問題分析是兩個問題 領導提...
關愛程式猿，拒絕不合理需求
阿里月餅那個事兒，大家都知道個七七八八了吧，不知道的可以點原文去知乎看，我想說個不一樣的角度，這件事也許根本不應該發生 居然做了個月餅系統 為什麼不用 的秒殺系統，而要重 明乙個不太圓的輪子？5 6年前我們就對這個系統的業務規則 比如乙個id限購1件 安全 防作弊做過各種努力了，那會兒搶的是ipho...