需求文檔你怎么寫?為什么這么寫?如何寫一份好的需求文檔?
很多產(chǎn)品新人,入門產(chǎn)品時(shí),最想先了解的都是如何畫原型,如何寫需求文檔,這很奇怪。就像在平臺(tái)上可以搜到很多關(guān)于需求文檔的文章(截至當(dāng)前,通過搜索關(guān)鍵詞“需求文檔”,有610條搜索結(jié)果),告訴大家需求文檔要怎么寫,卻很少有說為什么這樣寫的?
大家把關(guān)注點(diǎn)都在放在如何實(shí)現(xiàn),如何呈現(xiàn),卻沒有關(guān)注為什么這么寫?像很多大咖常說的術(shù)與道,術(shù)重要,道更重要,知其然更要知其所以然。
一、萬物起源
碰到任何問題,最長(zhǎng)見的思維方式即為:?jiǎn)栴}三要素——是什么、為什么、怎么做。這是幾乎所有行業(yè)、所有人群面對(duì)事情時(shí),最常見的思維方式。
筆者認(rèn)為基于最經(jīng)典、高效、實(shí)用的思維方式的基礎(chǔ)上,可以每個(gè)人針對(duì)不同的知識(shí)體系、思考方式、經(jīng)驗(yàn)總結(jié)等維度,總結(jié)出自己的思維方式。
筆者常使用的方式為多年前從社會(huì)經(jīng)濟(jì)學(xué)老師那里學(xué)來的,做了補(bǔ)充和優(yōu)化,分享給大家:
在特定的時(shí)間、特定的地點(diǎn)、特定的人群因?yàn)樘囟ǖ脑蚨隽颂囟ǖ氖录?。達(dá)成該特定事件前,有哪些預(yù)期,實(shí)際達(dá)成的效果是什么樣的,中間有怎么的落差,以后處理該類事件時(shí),如何優(yōu)化方式。
按照上述思維方式,我們將要寫的需求文檔當(dāng)做一個(gè)特定的事件,通過剖析該特定事件被觸發(fā)的前置條件、后置補(bǔ)充內(nèi)容,來實(shí)現(xiàn)對(duì)需求文檔的分析。
二、什么是需求文檔?
筆者將需求文檔定義為:用于闡述產(chǎn)品,滿足協(xié)同人員開發(fā)的內(nèi)容文檔。該定義中有兩個(gè)重要點(diǎn):
1. 闡述
即為說明要開發(fā)的產(chǎn)品是什么。此處的“是什么”區(qū)別于產(chǎn)品說明文檔,產(chǎn)品說明文檔類似于商品說明書,用于告知使用者我的產(chǎn)品該怎么使用。
而此處的“是什么”是告知該產(chǎn)品的相關(guān)人員,該產(chǎn)品有哪些功能,這個(gè)功能要怎么呈現(xiàn),該怎么實(shí)現(xiàn)。具體包含以下幾個(gè)方面:
(1)為什么要做這個(gè)產(chǎn)品?
該產(chǎn)品是來自哪里的需求,是內(nèi)部版本迭代優(yōu)化、Bug修復(fù)、新增功能點(diǎn),還是來自業(yè)務(wù)部門的需求,或者來自用戶的反饋需求。
必須交代清楚做該產(chǎn)品的項(xiàng)目背景,一方面有利于開發(fā)人員更好的了解整體項(xiàng)目,從而更順利地制定項(xiàng)目計(jì)劃、項(xiàng)目進(jìn)度、項(xiàng)目達(dá)成;
另一方面,產(chǎn)品開發(fā)完成后存檔的文檔,有助于后續(xù)對(duì)該產(chǎn)品的復(fù)盤、版本迭代,Bug問題溯源,甚至對(duì)出現(xiàn)人員異動(dòng)時(shí),有助于接盤人員快速了解項(xiàng)目,熟悉產(chǎn)品整體的前因后果。
(2)該產(chǎn)品要解決哪些沖突?
需求來自于用戶的沖突,用戶在使用中遇到了什么困難、疑惑、焦慮等不可調(diào)和的問題等待被解決。
在與用戶開展調(diào)研、訪談等溝通時(shí),充分了解用戶的沖突,及急需解決的痛點(diǎn),有助于產(chǎn)品經(jīng)理在產(chǎn)品規(guī)劃階段,更精準(zhǔn)地把握好方向,做出更符合用戶訴求的產(chǎn)品。
同時(shí),在了解沖突的溝通中,除了精準(zhǔn)獲取到用戶的核心訴求,還會(huì)得到很多非核心訴求,這些來自于用戶潛意識(shí)中的需求,為以后產(chǎn)品的發(fā)展提供了很好的幫助。
將這些需求羅列出來,整理到需求池,有助于以后與用戶、業(yè)務(wù)進(jìn)行再次溝通時(shí)作對(duì)比,從而去偽存真,對(duì)需求池中的需求做好優(yōu)先級(jí)排序,并根據(jù)實(shí)際業(yè)務(wù)發(fā)展階段和公司整體要求,劃分好產(chǎn)品階段,對(duì)需求池中的需求進(jìn)行實(shí)現(xiàn),從而促使產(chǎn)品朝向更好的方向發(fā)展。
(3)該產(chǎn)品實(shí)現(xiàn)了哪些目的?
任何產(chǎn)品的實(shí)現(xiàn),不僅僅要滿足用戶的需求,更要在解決沖突時(shí)達(dá)成更多的目的。而這個(gè)目的分為物質(zhì)層面和精神層面兩個(gè)維度。
1)物質(zhì)層面
產(chǎn)品的上線,解決了公司業(yè)務(wù)層面的流程,滿足了業(yè)務(wù)需要,滿足了用戶的使用,這是產(chǎn)品首要,且是最核心的目的。
而在滿足最核心目的之后,是否有一些延伸的產(chǎn)品需求——減少了操作步驟、優(yōu)化了交互流程,為實(shí)現(xiàn)公司層面的獲客、激活、留存、轉(zhuǎn)化、二次推廣等各環(huán)節(jié)起到促進(jìn)作用。
2)精神層面
產(chǎn)品的上線,解決了用戶的困難、疑惑和焦慮,解決了業(yè)務(wù)部門無法正常使用過程中的煩躁不安,這是產(chǎn)品最核心的目的在用戶心里的反饋。
同時(shí),在解決用戶優(yōu)先級(jí)最高的負(fù)面情緒的前提下,使得用戶對(duì)產(chǎn)品的感官,對(duì)企業(yè)品牌的好感度提升,是產(chǎn)品上線所能達(dá)成的最好效果了。
2. 滿足協(xié)同人員
即該需求文檔是給哪些協(xié)同人員看的。此處的“協(xié)同人員”不僅僅是開發(fā)人員,而是產(chǎn)品從交付原型至最終上線,過程中所涉及的所有參與者。
這些協(xié)同人員基于各自崗位和職責(zé),對(duì)需求文檔的要求也是不一樣的,這是所有產(chǎn)品經(jīng)理在編寫需求文檔時(shí)應(yīng)尤為注意的點(diǎn)。
以筆者當(dāng)前的公司為例,協(xié)同人員包括以下群體:
- 產(chǎn)品經(jīng)理:大部分公司都會(huì)有不止一個(gè)產(chǎn)品經(jīng)理。每個(gè)產(chǎn)品經(jīng)理在負(fù)責(zé)自己的產(chǎn)品線時(shí),所輸出的需求文檔對(duì)其他產(chǎn)品經(jīng)理的工作是有必要性的。
- 設(shè)計(jì)師:以做靜態(tài)頁面、gif圖、交互設(shè)計(jì)等視覺體驗(yàn)的專業(yè)人員。
- 前端開發(fā):以輸入靜態(tài)頁面、交互動(dòng)效為主,包含各類判斷邏輯,最終以HTML為輸出樣式的專業(yè)人員。
- APP開發(fā):用戶能看到的APP的頁面樣式、交互樣式、邏輯輸出的專業(yè)人員。
- 后臺(tái)開發(fā):后臺(tái)建表、設(shè)定邏輯規(guī)則,接口傳輸數(shù)據(jù)、字段的專業(yè)人員。
- 測(cè)試工程師:檢測(cè)產(chǎn)品在常規(guī)環(huán)境、非常規(guī)環(huán)境,檢測(cè)所有存在因素及隱患的專業(yè)人員,是確保產(chǎn)品上線無Bug的最后一道防線。
3. “闡述”與“滿足協(xié)同人員”間的關(guān)系
凡事的存在,皆存在因果。滿足協(xié)同人員,此為因,而為了滿足協(xié)同人員,輸出的需求文檔,即為果。因果之間互相作用,促成了產(chǎn)品最終的交付及上線。
三、需求文檔的意義是什么?
把正確的東西交給正確的人,滿足協(xié)同人員的訴求,即是需求文檔存在的意義。
如何寫出滿足協(xié)同人員訴求的需求文檔?首先,需要觀察不同的協(xié)同人員具體的工作場(chǎng)景,基于他們工作場(chǎng)景中的沖突,發(fā)現(xiàn)他們的需求,從而輸出的解決方案,就是最好的需求文檔。
1. 產(chǎn)品經(jīng)理的訴求
(1)產(chǎn)品部門的版本需求討論、需求評(píng)審會(huì)。
在版本任務(wù)的討論中,在與其他產(chǎn)品經(jīng)理講述所規(guī)劃的功能時(shí), 版本記錄、項(xiàng)目背景、項(xiàng)目框架圖、流程圖,可以快速讓其他產(chǎn)品經(jīng)理了解整體項(xiàng)目,并根據(jù)項(xiàng)目背景,給出意見。
(2)與其他產(chǎn)品經(jīng)理所負(fù)責(zé)的內(nèi)容有交叉點(diǎn)。
當(dāng)一個(gè)完整項(xiàng)目,每個(gè)產(chǎn)品經(jīng)理負(fù)責(zé)部分內(nèi)容的時(shí)候,各自負(fù)責(zé)部分功能的需求文檔有助于其他產(chǎn)品經(jīng)理從文檔中發(fā)現(xiàn)交叉點(diǎn)中的銜接是否合適,各功能模塊的整體融合性。
(3)Bug處理。
再厲害的程序員也不敢保證產(chǎn)品上線后不出現(xiàn)任何問題,當(dāng)產(chǎn)品上線后出現(xiàn)問題,需求文檔有助于產(chǎn)品經(jīng)理快速找到規(guī)劃的初衷,根據(jù)之前的情境給出精準(zhǔn)的解決方案。
(4)版本迭代。
當(dāng)產(chǎn)品在不同時(shí)期,做不同的版本迭代時(shí),之前的需求文檔尤為重要,有助于負(fù)責(zé)該項(xiàng)目的產(chǎn)品經(jīng)理快速熟悉往期規(guī)劃的初衷、目的和當(dāng)前的效果及不足,并在迭代版本中對(duì)往期問題進(jìn)行修復(fù),在新的規(guī)劃中避免不必要的坑。
(5)人員異動(dòng)。
如果出現(xiàn)人員異動(dòng)(人員項(xiàng)目變更、人員離職等),有助于新接手的產(chǎn)品經(jīng)理快速熟悉項(xiàng)目,確保項(xiàng)目規(guī)劃不會(huì)因個(gè)人經(jīng)驗(yàn)、個(gè)人喜好、習(xí)慣等原因,出現(xiàn)太大的偏差。
基于以上場(chǎng)景和目的,其他產(chǎn)品經(jīng)理對(duì)需求文檔的訴求需要得到的信息:誰、在什么時(shí)間、因?yàn)槭裁丛?,做了什么?nèi)容,滿足了什么人的需求,變動(dòng)內(nèi)容及節(jié)點(diǎn)、階段性規(guī)劃。
2. 設(shè)計(jì)師的訴求
設(shè)計(jì)師是項(xiàng)目實(shí)施階段的第一步。確定版的需求在落地執(zhí)行時(shí),首先是由設(shè)計(jì)師開始制作設(shè)計(jì)圖。項(xiàng)目的整體功能有哪些、基于什么背景、未來的規(guī)劃方向,需要在文檔中給出建議和說明,有助于設(shè)計(jì)師按照產(chǎn)品經(jīng)理的設(shè)想,設(shè)計(jì)出符合或高于期待的產(chǎn)品設(shè)計(jì)圖。
基于上述場(chǎng)景和目的,針對(duì)設(shè)計(jì)師角色,產(chǎn)品經(jīng)理在編寫需求文檔時(shí),需要告知的信息:因?yàn)槭裁丛?,給什么特點(diǎn)的群體,做什么圖,當(dāng)前競(jìng)品什么情況、公司什么情況、市場(chǎng)什么情況,想達(dá)到什么效果,后期發(fā)展方向(業(yè)務(wù)、功能、設(shè)計(jì)方向等)。
3. 開發(fā)人員的訴求(前端、APP、后臺(tái)、測(cè)試)
- 前端開發(fā):開發(fā)過程中,側(cè)重了解涉及前端部分的頁面功能、交互效果、交互邏輯;
- APP開發(fā):開發(fā)過程中,側(cè)重了解頁面元素、頁面樣式、功能、與后臺(tái)間的接口參數(shù)傳遞;
- 后臺(tái)開發(fā):開發(fā)過程中,側(cè)重了解功能、這些功能在后臺(tái)的數(shù)據(jù)結(jié)構(gòu)搭建、如何建表、功能邏輯、與前臺(tái)兼的接口參數(shù)傳遞;
- 測(cè)試工程師:在產(chǎn)品實(shí)現(xiàn)過程中,側(cè)重從產(chǎn)品規(guī)劃中了解整體功能,從而寫測(cè)試用例,以及產(chǎn)品上線前根據(jù)設(shè)計(jì)圖的樣式、文檔表述的功能規(guī)則,做功能測(cè)試。
基于刪除場(chǎng)景,產(chǎn)品經(jīng)理在編寫需求文檔時(shí),需要告知開發(fā)人員的信息:因?yàn)槭裁丛?,針?duì)什么項(xiàng)目,做什么功能,包含哪些頁面元素、頁面樣式、交互邏輯、實(shí)現(xiàn)效果。
4. 注意事項(xiàng)
盡信書不如無書。各公司的組織架構(gòu)、部門角色劃分、業(yè)務(wù)開展的推動(dòng)因素、公司發(fā)展所處的階段均不相同,雖大道同源,但總有差異化表現(xiàn)。
需要產(chǎn)品經(jīng)理針對(duì)協(xié)同人員做好分層、分類,切實(shí)與相關(guān)人員深入溝通,了解他們的習(xí)慣,了解他們的認(rèn)知,輸出他們需要的需求文檔,才能夠確保信息的透明化,保證開發(fā)人員全面了解規(guī)劃的內(nèi)容。
同時(shí),輔助以良好的溝通機(jī)制和技巧,則有助于開發(fā)效率的提高和產(chǎn)品上線的進(jìn)度保障。
四、如何寫需求文檔?
1. 寫文檔先看人
需求文檔與產(chǎn)品經(jīng)理前期做用戶調(diào)研時(shí)的用戶畫像很相似。
在做用戶畫像時(shí),通過與目標(biāo)群體各種方式的溝通,獲取用戶的基本信息、興趣、習(xí)慣、家庭情況、對(duì)產(chǎn)品相關(guān)業(yè)務(wù)的了解程度、接受程度、煩惱和期待等等,從而建立用戶檔案,輸出用戶的判斷結(jié)果。
在寫需求文檔前,面對(duì)我們的用戶——相關(guān)協(xié)同人員,產(chǎn)品經(jīng)理需要去了解他們。了解他們的工作方式、工作習(xí)慣、工作態(tài)度、工作認(rèn)知、工作能力等與工作相關(guān)的內(nèi)容,同時(shí),對(duì)他們與人相處的方式、生活習(xí)慣、興趣愛好等等的了解,有助于產(chǎn)品經(jīng)理更全面的了解,從而建立更加立體的用戶畫像。
在輸出判斷結(jié)果時(shí)會(huì)更準(zhǔn)確,寫需求文檔會(huì)更有側(cè)重點(diǎn)——哪些是他們需要知道的,哪些是他們需要特別詳細(xì)表述的,哪些是需要特殊標(biāo)注的,哪些是省略表述即可的。
2. 文檔規(guī)范
(1)版本記錄
- 誰:該文檔是誰編寫的,便于快速找到對(duì)應(yīng)的負(fù)責(zé)人員,同時(shí),后期有助于在需求文檔庫(kù)中建檔分類。
- 時(shí)間:什么時(shí)間編寫的該文檔,旨在告知該功能是什么時(shí)間要開始做,便于后期溯源時(shí),快速定位。
- 事件:針對(duì)什么產(chǎn)品、什么功能做的規(guī)劃,其實(shí)就是文檔標(biāo)題。
- 版本號(hào):便于記錄產(chǎn)品不同版本的節(jié)點(diǎn)做了什么內(nèi)容及調(diào)整,同時(shí),針對(duì)不同的系統(tǒng),有助于使用統(tǒng)一的版本號(hào)做管理。
- 上線計(jì)劃:依據(jù)上線計(jì)劃倒推測(cè)試周期、開發(fā)周期、設(shè)計(jì)周期,從而給參與該項(xiàng)目的協(xié)同人員約定好時(shí)間,便于更好的把控項(xiàng)目進(jìn)度。
- 評(píng)審及修改:項(xiàng)目完成后的需求評(píng)審建議和結(jié)果,針對(duì)初稿內(nèi)容做了哪些修改。此處一定要詳細(xì),后續(xù)調(diào)整內(nèi)容時(shí),評(píng)審建議和修改事項(xiàng)是很重要的可參考的細(xì)節(jié)點(diǎn)。
(2)版本說明
- 項(xiàng)目背景:清楚地寫出為什么要做該項(xiàng)目,誰要求做的。
- 核心需求:為了解決什么沖突。
- 預(yù)期目的:想達(dá)到什么結(jié)果,后續(xù)有什么進(jìn)一步的規(guī)劃。
詳細(xì)的項(xiàng)目背景有助于所有參與人員快速地了解項(xiàng)目是怎么回事。
(3)設(shè)計(jì)規(guī)范
設(shè)計(jì)規(guī)范來源于產(chǎn)品經(jīng)理對(duì)該產(chǎn)品的整體了解:在做完市場(chǎng)分析、行業(yè)分析、競(jìng)品機(jī)構(gòu)分析、用戶調(diào)研之后,針對(duì)自己要做的產(chǎn)品,產(chǎn)品經(jīng)理會(huì)形成自己的整體構(gòu)思和產(chǎn)品走向模型。
而這個(gè)構(gòu)思就是需要表達(dá)給設(shè)計(jì)師的理念——要做一款什么樣的產(chǎn)品,要達(dá)到什么效果。
關(guān)于設(shè)計(jì)理念的表達(dá),不同的公司有很大的差別,以及整個(gè)行業(yè)對(duì)這塊內(nèi)容都沒有統(tǒng)一的觀點(diǎn)。
一種觀點(diǎn)認(rèn)為,產(chǎn)品經(jīng)理只需要輸出黑白灰原型圖即可,其他的都交給設(shè)計(jì)師處理,給設(shè)計(jì)師足夠的發(fā)揮空間;
另一種觀點(diǎn)認(rèn)為,設(shè)計(jì)師對(duì)要做的產(chǎn)品,不了解緣由,直接去設(shè)計(jì)會(huì)有偏差,最終交付的產(chǎn)品大部分都不符合;
還有種觀點(diǎn)認(rèn)為,要看設(shè)計(jì)師的水平再來決定,水平高的不需要產(chǎn)品經(jīng)理說什么,都可以交付足夠讓人驚艷的設(shè)計(jì),水平低的說再多,也做不出效果,而大部分公司都屬于第二種情況。
綜上所述,崗位不同、職位不同、個(gè)人認(rèn)知的不同,以及最重要的信息接收到處理個(gè)人間都是有差異的,最終呈現(xiàn)在產(chǎn)品上的內(nèi)容就會(huì)有很大的差異。
而規(guī)避這類問題,最好的方式還是溝通。充足且有效的溝通,確保產(chǎn)品經(jīng)理與設(shè)計(jì)師間的已知信息達(dá)到一致,雙方的理念、想法、建議等越碰撞越容易做出更好的產(chǎn)品。
主要對(duì)接的內(nèi)容包含兩個(gè)部分:
- 信息與意向:傳遞產(chǎn)品信息,告知設(shè)計(jì)師關(guān)于該產(chǎn)品的設(shè)計(jì)原因、行業(yè)情況、要做的產(chǎn)品對(duì)標(biāo)競(jìng)品是哪些,以后對(duì)產(chǎn)品的規(guī)劃是什么、產(chǎn)品經(jīng)理的意向是什么。
- 基礎(chǔ)設(shè)計(jì)理念:產(chǎn)品主題、整體色調(diào)、各樣式的字號(hào)、色號(hào)、全局頁面的建議等。
(4)功能列表
功能列表為產(chǎn)品經(jīng)理在經(jīng)過足夠多的調(diào)研和分析,從匯總的產(chǎn)品需求池中篩選出的當(dāng)前應(yīng)處理需求列表。
功能列表的作用為便于相關(guān)人員全面了解產(chǎn)品的功能,從而評(píng)估項(xiàng)目周期、處理優(yōu)先級(jí)等。
功能列表主要表述都做什么功能,哪些重要且緊急。列表參數(shù)包含:
- 模塊
- 功能點(diǎn)
- 功能點(diǎn)描述(詳細(xì))
- 優(yōu)先級(jí)(高、中、低)
(5)角色列表
角色列表為表述清楚該產(chǎn)品上線后,參與到該產(chǎn)品中的群體有哪些。列表參數(shù)包含:
- 角色名稱
- 職責(zé):在產(chǎn)品參與中的簡(jiǎn)要說明
- 備注:特殊情形
(6)框架圖
框架圖為該產(chǎn)品包含什么內(nèi)容:模塊、功能。便于開發(fā)人員快速、便捷的了解產(chǎn)品全局。
框架圖沒必要做的很高大上,高大上固然很好,會(huì)讓使用的人賞心悅目。但是,功能介紹簡(jiǎn)單易懂和開發(fā)人員能看懂、看明白更重要,千萬不能舍本逐末。
(7)流程圖
流程圖分兩個(gè)部分:
- 整體流程圖:整體流程為將產(chǎn)品各大模塊之間的交互流程,一般做正向流程居多,輔助以部分判斷流程和異常處理機(jī)制
- 功能流程圖:功能流程為涉及到具體的功能點(diǎn)的交互流程,包含:正向流程、規(guī)則、判斷流程、異常流程。
(8)功能需求
功能需求為具體的各功能點(diǎn),是需求文檔的核心。主要是詳細(xì)的分解各功能點(diǎn),包含兩個(gè)方面:
- 前端:針對(duì)前端部分,頁面如何來、頁面元素、各功能點(diǎn)的規(guī)則、交互、跳轉(zhuǎn)規(guī)則、非常規(guī)流程的頁面元素、交互、跳轉(zhuǎn)規(guī)則等等。
- 后臺(tái)部分:前端功能的實(shí)現(xiàn),依靠后臺(tái)的哪些邏輯和數(shù)據(jù),是否需要做新功能模塊、新功能模塊的內(nèi)容、數(shù)據(jù)的調(diào)用、存儲(chǔ)、接口數(shù)據(jù)傳值等等。
(9)非功能需求
非功能需求為用戶常規(guī)操作產(chǎn)品時(shí)的極端情況,涉及很多內(nèi)容,以下列舉幾個(gè)比較重要且常規(guī)規(guī)劃中需要考慮的點(diǎn):
- 產(chǎn)品性能:產(chǎn)品對(duì)用戶操作的響應(yīng)、對(duì)群體操作的并發(fā)預(yù)防等。
- 安全性:公司數(shù)據(jù)、用戶信息的保密性處理,不同角色的權(quán)限設(shè)置、使用中的限制等。
- 可靠性:用戶操作中出現(xiàn)異常情況,是否可繼續(xù)操作,遇到異常情況時(shí)數(shù)據(jù)或使用狀態(tài)是否可被恢復(fù)等。
- 拓展性:拓展性主要針對(duì)公司內(nèi)部而言,產(chǎn)品完成后,無論是設(shè)計(jì)師、開發(fā)人員,還是測(cè)試人員,針對(duì)產(chǎn)品所做的工作,是否可以被復(fù)用到其他地方。用戶在產(chǎn)品中的使用情況是否可被系統(tǒng)獲取后用作不同維度的分析等。
五、多說一句
需求文檔中,對(duì)于功能的表述是尤為重要的,針對(duì)各功能點(diǎn)考慮的越詳細(xì),越有利于開發(fā)人員評(píng)估實(shí)現(xiàn)難度、評(píng)估時(shí)間、順利達(dá)到所要的效果。
六、最后一句
需求文檔不是越詳細(xì)越好,很多沒必要的說明,不用耗費(fèi)大量時(shí)間去編寫,最核心的依舊是:讓自己公司的相關(guān)人員能快速看懂,全面了解。
盡信書不如無書,各公司均不一樣。產(chǎn)品經(jīng)理應(yīng)更多的站在自己公司的角度,在對(duì)相關(guān)協(xié)同人員充分了解后,輸出他們需要的需求文檔。
本文由 @kuang 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
不愧是你,寫的真好
那寫給甲方客戶看的B端后臺(tái)產(chǎn)品需求文檔也是按照這個(gè)方法寫嗎?
可否提供我們一個(gè)需求文檔的模板來學(xué)習(xí),想看看目錄結(jié)構(gòu)以及各目錄是什么內(nèi)容
同
寫的真好,很細(xì)節(jié)學(xué)習(xí)了
有使用呢想要一份脫敏的prd不知道方不方便
有用~
一個(gè)產(chǎn)品一個(gè)需求文檔,看了這么多文章,就沒有一個(gè)需求文檔是統(tǒng)一的,這是為什么?我覺得可能還是要根據(jù)需求的實(shí)際情況以及當(dāng)時(shí)開發(fā)緊急程度來定需求文檔的合理格式以及是否使用需求文檔會(huì)比較好。不管怎么講需求文檔作為一款產(chǎn)品的傳承文件,非常重要。
你好~請(qǐng)問如果想去面試智能產(chǎn)品的產(chǎn)品經(jīng)理助理崗位,我該帶一份什么樣的作品去面試較好呢?
看了文章感覺會(huì)了,一去寫我……,我文檔的語言組織能力確實(shí)太差了
考慮邊際條件 我覺得是對(duì)一個(gè)產(chǎn)品經(jīng)理基本功最好的證明了
期待的搓手手,能有一份需求文檔學(xué)習(xí)學(xué)習(xí)。
你好,特想得到您的一份需求文檔來進(jìn)行觀摩學(xué)習(xí)
贊一個(gè),這段時(shí)間正好要寫PRD文檔,苦于不知如何下手,真是及時(shí)雨 ??
謝謝??
最后一段寫的好!
謝謝??
有些地方感覺語音和文字對(duì)不上
可能是語音工具對(duì)斷句上的解析,整體情景的把控上有點(diǎn)小問題吧~ ??
很棒!
謝謝~中秋快樂~ ??
如果有范文就更好了
也在考慮如何在避開公司的一些數(shù)據(jù)層面的內(nèi)容,整理個(gè)東西出來,我再研究研究 ??
??????
中秋快樂??
????????
中秋快樂??
6
中秋快樂??