不管是傳統(tǒng)的瀑布模式開發(fā)，還是時(shí)下比較火的敏捷開發(fā)，調(diào)研需求，分析需求，這些最基本的工作都是離不開的。

敏捷開發(fā)

在敏捷開發(fā)里面，先不談敏捷開發(fā)的思想，單說產(chǎn)品經(jīng)理要做的事：
第一：用戶故事

這個(gè)是肯定要寫的，但是寫的依據(jù)是什么呢，那就是調(diào)研需求和分析需求，只有先了解需求，知道用戶想要什么，才能把這個(gè)用戶故事寫出來。

第二：原型和先關(guān)輔助文檔、流程

到底是先寫用戶故事還是先畫原型，這個(gè)問題，在實(shí)際工作中還存在一點(diǎn)爭議，有的產(chǎn)品經(jīng)理比較傾向先出原型，他們認(rèn)為原型是所見即所得，原型出來了，用戶故事也就是出來了，有的產(chǎn)品經(jīng)理則傾向先寫用戶故事，他們則認(rèn)為，用戶故事出來之后，原型這個(gè)東西其實(shí)就無所謂了。不管是誰先出，誰后出，反正這兩件事，咱們產(chǎn)品經(jīng)理都得做。 備注：一般情況下，敏捷開發(fā)，都會(huì)使用jira這個(gè)系統(tǒng)。

第三：團(tuán)隊(duì)開會(huì)過方案了

討論一下你的原型或者用戶故事，大家集思廣益。方案沒問題的話，剩下的就是舉牌，評(píng)估故事點(diǎn)了。

第四：拆分任務(wù)

產(chǎn)品經(jīng)理的方案通過，故事點(diǎn)也確定之后，剩下的就是由項(xiàng)目經(jīng)理或者技術(shù)經(jīng)理，根據(jù)產(chǎn)品經(jīng)理撰寫的用戶故事，拆分成，技術(shù)上的任務(wù)，然后分派給下面的研發(fā)工程師進(jìn)行開發(fā)。

傳統(tǒng)的軟件開發(fā)

很早以前，在沒有原型以及用戶故事這個(gè)概念之前，研發(fā)工程師，都是以需求規(guī)格說明書即PRD為準(zhǔn)。那個(gè)時(shí)候，調(diào)研需求，分析需求的人，不能叫產(chǎn)品經(jīng)理，應(yīng)該叫需求工程師，或者需求分析師。需求工程師調(diào)研完需求之后，可能先會(huì)出一個(gè)需求調(diào)研的報(bào)告

1是用做工作的匯報(bào)

2是記錄第一手需求調(diào)查的資料，做存檔備份。（在這其中也會(huì)伴隨著大量的文檔，不同的項(xiàng)目，根據(jù)項(xiàng)目的量級(jí)，文檔的數(shù)量以及種類，會(huì)有所區(qū)別。這個(gè)咱們也不需要特別費(fèi)心去搜集需求分析師到底要寫多少種文檔，甲方作為需求方，要求什么文檔，作為最后的驗(yàn)收材料，甲方會(huì)提的，需求分析師，根據(jù)甲方的標(biāo)注寫就行）

拋去其他的輔助文檔，作為乙方的需求分析師，最為重要的，也就是一個(gè)需求規(guī)格說明書了，這個(gè)文檔將是最為開發(fā)的指導(dǎo)性文檔，研發(fā)人員將按照這個(gè)文檔里面呈現(xiàn)的業(yè)務(wù)流程和功能細(xì)節(jié)，進(jìn)行開發(fā)。當(dāng)研發(fā)人員，對(duì)你這個(gè)文檔不明白，有意義的時(shí)候，最為需求分析師（或者也可以理解為現(xiàn)在的產(chǎn)品經(jīng)理）要及時(shí)的給予研發(fā)以支持，以保證開發(fā)能夠順利進(jìn)行。所以，即便是需求分析師的文檔（PRD）寫完了，也仍舊需要跟進(jìn)研發(fā)，跟進(jìn)測試，等等
如果將需求分析師的工作內(nèi)容映射到產(chǎn)品經(jīng)理上，那么自然也需要跟進(jìn)UI、跟進(jìn)運(yùn)營，等等。


以上內(nèi)容，節(jié)選自大餅老師與學(xué)員的溝通答疑（僅供參考學(xué)習(xí)）