什么是需求分析(什么是需求，怎么做需求分析)，36創業加盟網給大家帶來詳細的介紹，讓更多的人可以參考:什么是需求分析(什么是需求，怎么做需求分析)。
在互聯網公司里，產品經理現在是需求的代言人，基本言必稱需求。今天老板提了個需求、明天客戶提了個需求、后天拍腦袋了一個需求。
問題是，什么是需求？
“用戶希望打電話的時候，按一下xx按鈕就能實現錄音”
“大促活動時，我們能篩選出來不同的用戶群體，同樣的商品，讓不同的用戶群里能看到不同的價格”
“你給我做個自助取數功能吧，把表里的數據能夠導出來”
“在埋點管理模塊做一個事件序列檢測，在測試數據上報的時候，就可以通過驗證客戶端是否上報了設定的序列來測試是否有bug了”
“用戶提現的時候，為了保證安全性，需要增加一個手機驗證碼的驗證”
以上都是需求，有用戶的、客戶端、運營的、產品經理自己的。但是都有一個共同點，都是明確的要求具體的功能。所以，需求一般是明確的對功能的需要。
按照常見工作流程，就是
上線后發給需求方，所有人kpi完成。
若這是產品經理自己想出來的需求，有些開發還會PK一下，“你這需求不合理，用戶不是這個需求，這個需求沒價值”。很多時候，產品經理直接搬出來用戶的原話、或者后臺留言來明確，這就是客戶的需求，開發也就不說什么直接去做了。
看起來非常正常的流程，基本沒啥毛病。但是，有問題。
“用戶希望打電話的時候，按一下xx按鈕就能實現錄音”，什么人在什么場景下需要打電話錄音？在該場景下打電話錄音是為了解決什么問題？
“大促活動時，我們能篩選出來不同的用戶群體，同樣的商品，讓不同的用戶群里能看到不同的價格”，為什么要不同用戶看到不同價格？是為了提高促銷商品的總銷售額？總銷量？總利潤？。
“你給我做個自助取數功能吧，把表里的數據能夠導出來”，為什么要導出數據？是因為本來數據可視化不好看，需要放到excel里重做？是為了把數據共享給其他人？
“在埋點管理模塊做一個事件序列檢測，在測試數據上報的時候，就可以通過驗證客戶端是否上報了設定的序列來測試是否有bug了”，這個需求想解決的問題是什么？是埋點經常埋錯嗎？還是上線后經常有上報數據的錯誤，需要這里發現？如果是埋點經常會埋錯誤，原因是什么？開發不夠仔細？是一個開發經常埋錯還是所遇開發都經常埋錯？是哪種錯誤？字段名字寫錯還是少開發埋點？
“用戶提現的時候，為了保證安全性，需要增加一個手機驗證碼的驗證”，增加手機驗證要解決的問題是什么？是確保提現操作是擁有該資產的本人的一個驗證。要是手機丟了，驗證碼填寫對了還能保證是本人嗎？
需求不應該是用戶或者客戶提的，提需求的只能是產品經理。正常的工作流程應該是：
產品經理在接到需求的時候，應該弄清楚5W1H：什么人（who），在什么場景下（where and when），遇到了什么問題（what），為什么會有這個問題（why），怎么才能解決這個問題（how）。其中問題是核心。
客戶或者用戶，提出需求，是因為思維上，人們都會普遍按照自己的理解想解決辦法。但是作為產品經理，需要透徹了解到描述的需求后面提需求的人在具體場景上想要解決的核心的問題，然后基于該問題的理解，提出產品經理的需求。
這里的需求分析，主要是指后端或者toB的需求。
分析需求，就是要把握需求的三要素：人、場景、問題。
提需求的是人，但提需求的人往往代表的是一個角色。
場景，是場和景的組合是在一個空間內，由人和物組成的畫面。
問題，是讓人覺得不爽的點，而且是基于持續的問why和how得到的本質的不爽的點。
分析需求，就是分析特定的覺色在特定的時間、空間和人物構成的環境中本質的不爽的點。
覆蓋人數越多，場景越宏大，問題越普遍則需求越有價值。
如微信小程序的場景定位為無需下載，即開即用，用完即走。所有需要臨時使用下的網絡服務，都是小程序的場景。如郵寄個快遞、定個餐、沖個話費、交個電費等等。由于生活中廣泛存在這種低頻次的剛需應用，相對于下載一個app再注冊登錄，使用小程序能為用戶帶來了極大的便利，再基于微信龐大的用戶群，所以小程序爆發出強大的生命力。
屁股決定腦袋，分析需求的時候，首先需要注意的是人，每個人提需求多是為了他自己或者他代表角色的利益。這無可厚非，但是很多個人或者角色的利益訴求與總體利益的最大化是可能存在沖突的，比如，在內容公司里，內容運營團隊總是不太喜歡推薦部門的。
在相對小的公司里面，利益沖突相對好解決，因為老板的管理半徑可能覆蓋到最下面的團隊。一個對公司整體最優的決策是可以在老板的影響范圍之內制定的。當然老板自己拎不清的情況另說了，如果老板自己都拎不清，最好的解決辦法是趕緊換一家公司。
在大廠里，由于層級多，部門多。很多事情的出發點并不是解決生產力問題，而只是為了解決生產關系的問題。比如某個需求提出來，即使分析出來該需求需要解決的問題在你們部門做并不是最合適的，但是主管就想要這塊業務，這時候分析需求的目標就不是人+場景+問題了，而是這事在你們部門做是多么合適，多么成體系以及你們做起來多么有經驗等等。以大廠擁有的資源來說，一個基層產品經理的決策失誤對于資源的浪費并不會對公司整體產生什么影響，浪費掉的資源相對于公司整體擁有的資源來說是九牛一毛。但是你對于部門老大的忠心是能實實在在影響到你的晉升和年終獎。
場景是用戶感受到不爽的時候的時間、空間、關聯的人和物構成的整體的畫面。分析需求的時候，構建場景是為了方便將自己代入到該畫面中去體會和共情。
網上傳言，喬布斯能1秒鐘進入傻瓜狀態，馬化騰需要10秒鐘。這種進入傻瓜的的狀態，就是忘掉自己所有的既有經驗，將自己帶入到普通用戶的場景中去。現在的所謂互聯網“智能”電視，普遍是不怎么智能的，因為普通的老百姓，基本都是自己搞不定的。當前互聯網電視的設計邏輯都是給有豐富網絡使用經驗的人做的。或者設計電視功能的人都是基于自己的網絡水平設計的。比如，看電視要聯網，要配置WiFi帳號和密碼；使用電視過程中，要看電視臺，要切換信號源到HDMI或者HDMI2；主頁巨多tab，讓人不知道怎么切換怎么選。設計電視的人絲毫沒考慮到，全國上過大學的人只占總人口的不到5%，還有剩下的90%以上的人，在買了一個新的高大上的互聯網電視之后，面對不小心切換的信號源，怎么按都找不到原來的畫面的時候的無助。
在toB業務中，考慮場景的時候往往不止需要考慮遇到問題的當前時刻，還需要考慮上下文，也就是業務本身的業務流程。有些時候問題是單個業務點的，有時候問題是整個流程導致的，只有了解整體流程才能提出整體的解決方案。
對于一般的數據平臺什么是需求分析，會分為數據采集、ETL、數據倉庫、數據應用幾個模塊。最典型的應用是BI（Bussiness Intelligence）報表。要做出來BI報表，需要從端上采集數據，服務端ETL后存儲到數據倉庫；數據倉庫中又把數據分為DWD，DWS，DWB，ADS等數據層級，需要數據開發把數據從DWD層一層層開發出上層；最后再使用可視化工具做成BI報表。采集、ETL、數據倉庫和可視化分別有獨立的人來開發和配置。一般這種類型的數據平臺，BI報表的使用方經常會吐槽數據不準，數據有問題。一旦使用方報問題，就需要從報表開始往回一直查到數據采集來定位問題。經過幾次報問題之后，可能發現了端上開發上報的埋點的字段出錯比較多。這時候，由于每次報錯都會讓數據倉庫的開發和ETL的開發查，他們就會開始吐槽，開始提保證埋點質量的需求。產品經理此時針對埋點可以提一對測試工具的需求，然后給端上的開發和測試找一堆活來“保證”埋點質量。貌似也能解決問題。但是從整體來看，BI不準的核心問題是，數據處理鏈路過長且中間大量的人工對接。超長鏈路的的大量人工的非標準接口的對接必然出錯。要解決問題，應該是從優化流程入手，減少流程中的人工處理，固化為程序自動處理。
問題，是讓人覺得不爽的點。
云服務市場潛力很大，在于沒有云服務的時候，哪怕你搭個小網站也需要自己去IDC買機器，裝系統。更不用說在使用過程中還有軟件的bug，甚至硬件的故障都是不可避免的。回來使用過程中還不知道哪天就出了問題了，你還得往機房跑。所以，想做互聯網開發服務的人，在做核心開發的時候，還需要顧及到機器的問題，甚至出問題后花費的精力是讓人崩潰的，相當讓人不爽。所以，這時候普遍的解決方式是招聘專業的運維，來運轉維護機器的正常運行。對于資深的運維，應該都是跑過機房的，在轟鳴的機器中間更換硬件，安裝系統，這事讓運維相當不爽。如果這事讓運維提需求，那么對于運維來說，能遠程監控，遠程安裝系統最好了。dell、惠普等服務器廠商還真的都有這話服務，在服務器上，獨立于你安裝的系統之外，有個嵌入式的系統，給該系統分配ip地址后，你可以遠程管理你的服務器，就像在本地連接了鍵盤顯示器一樣。但是這個產品解決的是運維的問題，并沒有解決做互聯網開發還是需要運維的問題。說明這種解決方式，不夠本質。
總結：以上內容就是什么是需求分析(什么是需求，怎么做需求分析)詳細介紹，如果您對創業項目感興趣，可以咨詢客服或者文章下面留言，我們會第一時間給您項目的反饋信息。
