數(shù)據(jù)需求分析怎么寫？數(shù)據(jù)分析就是寫一些當(dāng)時某個數(shù)據(jù)分析的資料，然后表明什么樣的觀點？數(shù)據(jù)需求分析包括什么？數(shù)據(jù)分析一個寫出系統(tǒng)的任務(wù)和特點。2，功能模塊和要實現(xiàn)的功能。3、系統(tǒng)結(jié)構(gòu)圖四，采用的數(shù)據(jù)庫五

數(shù)據(jù)需求分析怎么寫？

數(shù)據(jù)分析就是寫一些當(dāng)時某個數(shù)據(jù)分析的資料，然后表明什么樣的觀點？

數(shù)據(jù)需求分析包括什么？

數(shù)據(jù)分析

一個

寫出系統(tǒng)的任務(wù)和特點。

2

，功能模塊和要實現(xiàn)的功能。

3、

系統(tǒng)結(jié)構(gòu)圖

四

，采用的數(shù)據(jù)庫

五

，開發(fā)和運行環(huán)境

微信小程序的開發(fā)需求分析怎么寫？

微信小程序需求分析的編寫方法：

微信小程序需求分析可以分三步寫。

1.分析需求，搭建產(chǎn)品框架：創(chuàng)業(yè)者可以整理思路，形成初步的需求大綱，比如詳細(xì)列出一些需要開發(fā)的功能，然后區(qū)分哪些是真實需求，哪些是虛假需求。經(jīng)過確認(rèn)后，他們會消除一些不需要的功能需求，讓它們變得有用。然后確定產(chǎn)品功能開發(fā)順序。這些都做好之后，就可以設(shè)計一個簡單的產(chǎn)品需求文檔，然后就可以構(gòu)造一個簡單的產(chǎn)品框架圖了。

2.需求評審和方案確定：由產(chǎn)品經(jīng)理牽頭召開需求評審會議，向開發(fā)團隊詳細(xì)解釋產(chǎn)品邏輯流程和交互細(xì)節(jié)，評估技術(shù)實現(xiàn)的可行性。對不明確的需求進(jìn)行第二次需求更新；

3.確認(rèn)開發(fā)周期：根據(jù)需求評估結(jié)果，修改設(shè)計最終版本的原型和交互，標(biāo)記原型并編寫產(chǎn)品需求規(guī)格說明書，管理后端數(shù)據(jù)統(tǒng)計等需求，技術(shù)根據(jù)需求文檔反饋各階段的完成時間節(jié)點。

如何做需求分析？

從不同方面入手：

一是用戶需求，挖掘用戶真實需求，看用戶是想造航母還是漁船；

第二，產(chǎn)品本身的客觀需求，客觀需求。目前市場上同類型的產(chǎn)品要進(jìn)行比較和挖掘。比如市面上的產(chǎn)品都是漁船，那么客戶的需求就會減少；

第三，根據(jù)用戶自身的需求來比較用戶的時間、進(jìn)度和預(yù)期結(jié)果是不現(xiàn)實的。比如客戶只給了造船的錢，想造航母。

如何做需求分析？

13360抓住了核心點，不是所有的用戶需求都是需求。

我們每次做項目迭代或者新項目，都要有目的。在需求分析階段，需求收集渠道中的需求往往是分散的、無重點的、無邏輯的。所以我們需要從這些離散的需求中抓住核心，梳理出實際的使用場景來分析問題。所有的核心點都要面向最終目的，并不是所有的用戶需求都是需求。

以我的項目為例。由于歷史原因，自配人員關(guān)系沒有進(jìn)入OA系統(tǒng)，所以只能將自配人員的工資結(jié)算數(shù)據(jù)錄入到自配系統(tǒng)中，相當(dāng)于簡單的考勤記錄。其實系統(tǒng)之前就有這個功能。但是由于之前沒有認(rèn)真整理需求，導(dǎo)致這個功能被浪費了，所以這次我接手幾乎是從做。我覺得比較簡單，就讓一個產(chǎn)品助理先把需求整理了一下。當(dāng)展示原型圖時，發(fā)現(xiàn)它無法解決工資結(jié)算功能。

所以，當(dāng)時我就跟小哥說，你剛倒班，但是倒班的目的是結(jié)算工資，不能滿足需求。所以我跟他強調(diào)，這個要求的目的是考勤，要提供請假、值班、加班小時數(shù)、隔日加班等數(shù)據(jù)。其實他的第一版原型并沒有完全理解我們?yōu)槭裁匆鲞@個調(diào)度功能，所以在理解需求的過程中沒有抓住核心點，導(dǎo)致需求不清晰。

:制定規(guī)則和改進(jìn)復(fù)雜流程

我上一家公司是做互聯(lián)網(wǎng)電商的。其實在我看來，電商和O2O有一個很大的區(qū)別，就是在目前盛行的情況下，電商已經(jīng)變得非常有規(guī)律了。顯示在主頁、產(chǎn)品列表頁面、詳細(xì)信息頁面、訂單頁面等上的信息。也很不一樣，而O2O就不一樣了。一方面，O2O只興起了差不多13年，至今(15年)還沒有一個標(biāo)桿行業(yè)。另一方面，O2O與日常生活聯(lián)系過于緊密，導(dǎo)致業(yè)務(wù)流程復(fù)雜。以上是to C產(chǎn)品的規(guī)則和流程，流程在to B產(chǎn)品中尤為明顯，最經(jīng)典的例子就是公司的后臺系統(tǒng)。

無論是a to C產(chǎn)品還是a to B產(chǎn)品，我們都要考慮用戶的使用場景。PM需要把自己當(dāng)成用戶，充分考慮用戶在各種情況下的思維，才能設(shè)計出符合用戶需求的產(chǎn)品。在這里，我們不只是迎合用戶?；ヂ?lián)網(wǎng)用戶都知道，一個業(yè)務(wù)不規(guī)范，很難用產(chǎn)品滿足用戶，所以我們有必要制定規(guī)則，或者優(yōu)化不完善，流程復(fù)雜。

規(guī)則。

先說制定規(guī)則。其實統(tǒng)一規(guī)則有利有弊。比如滴滴打車訂單是搶的，優(yōu)步打車訂單是系統(tǒng)自動配送的。滴滴的做法可以提高司機的積極性和自主性，司機可以選擇高價值訂單，但這種做法也會影響用戶體驗。比如以后沒有補貼，我只是一個起步價，有些司機不愿意接單，要等很久；另一方面，優(yōu)步制定了自動分配規(guī)則，首先分配離乘客最近的空閑司機。他不接，就分配到下一個。這個能不能讓用戶滿意我就不說了。我只說這個規(guī)則簡化了訂購過程。司機和乘客只有兩個選擇，接不接，坐不坐。如果司機不接，不知道下一單是什么時候，訂單金額是多少。雖然降低了司機之間的主動性和自主性，但是對于用戶來說體驗是非常好的。

制定完規(guī)則，再來說說流程的改進(jìn)。我上面說了，這種精簡流程在to B產(chǎn)品中尤其明顯。很多人都有一個觀點，后臺系統(tǒng)反正是自己人或者其他企業(yè)人員用的，完成功能就ok了。沒必要做得這么方便細(xì)致。其實不是的。優(yōu)秀的PM在這方面總能完成的很好，因為在他們眼里，一點點的產(chǎn)品優(yōu)化或者流程優(yōu)化就能給企業(yè)帶來很多收益。對此我有切身體會。

我之前做過很多項目，有兩個是我在做需求的時候，發(fā)現(xiàn)業(yè)務(wù)部門在實際操作中是思維定勢或者每天重復(fù)做他的工作，但是他們沒有發(fā)現(xiàn)這其實是低效的。在沒有人觀察到流程有問題的時候，業(yè)務(wù)部門已經(jīng)形成了一個規(guī)范，但是這個規(guī)范并不是最優(yōu)的。PM在做需求分析的時候，需要仔細(xì)觀察他們部門或者個人的工作內(nèi)容，思考它為什么要這么做，有沒有其他的方案來提高它的工作效率。

在做數(shù)據(jù)統(tǒng)計的時候，發(fā)現(xiàn)業(yè)務(wù)部門的一個同事每天都要導(dǎo)出所有新用戶的電話、訂單號、餐廳金額、訂單金額等數(shù)據(jù)，來檢查配送人員和用戶的滿意度。但是她每天導(dǎo)出的數(shù)據(jù)，其實需要另外兩個同事使用，但是他們都很死板。他們?nèi)齻€每天導(dǎo)出一個完整的數(shù)據(jù)，然后篩選條件，組合成自己的數(shù)據(jù)。這種工作其實沒必要，我們每天都可以為他們做。

再比如財務(wù)結(jié)算物流人員工資時，很多計算公式都是相互關(guān)聯(lián)的。比如，A=B C，D=A*E B-C，然而，不管他們所在部門的管理流程如何，都是按照D=(B C)*E B-C來計算的。但是PM遇到這樣的業(yè)務(wù)流程，可以考慮是否可以結(jié)合產(chǎn)品設(shè)計精簡流程，實現(xiàn)產(chǎn)品設(shè)計的初衷，同時也簡化流程。

:離散需求集成

在與業(yè)務(wù)部門打交道時，發(fā)現(xiàn)他們的思維邏輯可能略差。PM在了解需求的時候，業(yè)務(wù)人員或者用戶是沒有因果的，就是沒有邏輯的。這時候如果PM不提問，就很容易被帶坑。合格的PM在這種情況下應(yīng)該轉(zhuǎn)過身來，再次說明問題。如果PM稍微強一點，要指出剛才的說法是錯誤的。

也有業(yè)務(wù)部門的工作人員在你溝通的時候搶著講產(chǎn)品改進(jìn)或者新的需求思路。這時候PM要認(rèn)真聽，記錄需求點，千萬不要給他們這個功能什么時候?qū)崿F(xiàn)或者推出的答案，因為系統(tǒng)永遠(yuǎn)是不完善的，需求永遠(yuǎn)是無止境的，資源是有限的。你的回答不能意識到別人會有不好的看法。優(yōu)秀的PM需要大局觀，能和團隊一起評估需求。

43360技術(shù)人員參與需求分析階段

現(xiàn)在很多互聯(lián)網(wǎng)公司基本都是產(chǎn)品驅(qū)動，很難說是技術(shù)驅(qū)動，因為產(chǎn)品團隊才能知道用戶想要什么。在我參與需求分析的時候，業(yè)務(wù)部門的技術(shù)總監(jiān)喜歡跟著我去了解需求，這是我在之前的工作組里沒有遇到過的。現(xiàn)在他參與需求的時候，我發(fā)現(xiàn)整個產(chǎn)品需求都是亂七八糟的，阻礙了我需求分析的進(jìn)度，因為他總是從技術(shù)角度考慮這樣實現(xiàn)的難度。由于負(fù)責(zé)技術(shù)，他有很強的邏輯思維能力。每當(dāng)他聽說不需要添加一個條目來維護(hù)這個數(shù)據(jù)的時候，他就會站出來說為什么要這么做，然后說服業(yè)務(wù)部門說這個數(shù)據(jù)不能提供，所以不能先做。

但是從產(chǎn)品的角度來說，既然選擇了這個項目，就應(yīng)該從產(chǎn)品的角度來設(shè)計。在一套完整的產(chǎn)品方案出來后，精簡功能是一個很好的方法。在其他情況下，當(dāng)一個好的想法產(chǎn)生時，技術(shù)人員首先會考慮它是否能實現(xiàn)，以及實現(xiàn)的復(fù)雜程度。如果有一點難度或者現(xiàn)場無法給出一個技術(shù)上可行的方案，這個功能就暫時擱置，可能會提出另一個沒有錯但不是最好的方案，于是技術(shù)人員參與需求。綜上，我的理解是技術(shù)人員暫時不要參與需求分析階段，技術(shù)團隊在產(chǎn)品團隊內(nèi)部討論后再參與評審，可能會達(dá)到事半功倍的效果。