經(jīng)常被研發(fā)、運(yùn)營懟?你需要掌握需求實(shí)現(xiàn)前的8大步驟
從需求分析到需求評(píng)審,筆者總結(jié)了需求實(shí)現(xiàn)前的八個(gè)步驟以及其中的要點(diǎn),希望對產(chǎn)品經(jīng)理們有所幫助,避免經(jīng)常被研發(fā)與運(yùn)營懟。
經(jīng)常有產(chǎn)品經(jīng)理和我吐槽,辛辛苦苦做的需求,得到的卻得不到團(tuán)隊(duì)和需求方的認(rèn)同。在和研發(fā)溝通的時(shí)候,差不多就是跪著講的,上線之后需求方還來吐槽,說也預(yù)期還是有一些差距的。
先描繪一個(gè)場景,看看里面有沒有你的影子:
- 你接到一個(gè)需求的,立刻去想怎么解決這個(gè)問題,想的差不多就開始畫原型,很快就畫好原型拿給領(lǐng)導(dǎo)看,領(lǐng)導(dǎo)劈頭蓋臉的指出一系列的問題。
- 經(jīng)過幾輪的修改,終于進(jìn)入需求評(píng)審階段,在需求評(píng)審會(huì)議上,方案被研發(fā)、運(yùn)營挑戰(zhàn),直接在評(píng)審會(huì)議上開撕,一個(gè)需求評(píng)審會(huì)議,要進(jìn)行 1-2 個(gè)小時(shí),最終還要進(jìn)行二次評(píng)審。
- 上線之后,業(yè)務(wù)方反饋說,其實(shí)這個(gè)和他們想要的,還是有一些差距的。你感覺心好累,不被理解。
如果你身上也有類似的事情發(fā)生,按照下面的步驟進(jìn)行,會(huì)極大減少這種場面的發(fā)生。
01 需求分析
當(dāng)我們接到需求,不要馬上去想怎么來實(shí)現(xiàn),先問需求方幾個(gè)問題:
- 這個(gè)需要要解決什么問題
- 解決之后,能給你們帶來什么價(jià)值
- 如果不處理,那會(huì)有什么影響?
問了這幾個(gè)問題之后,你大致就清楚這個(gè)需求的來龍去脈,以及需求的優(yōu)先級(jí),如果需求方連這幾個(gè)問題都回答不了,那需求可以拒絕了。
舉個(gè)例子:運(yùn)營同學(xué)說我們的登錄系統(tǒng)不滿足現(xiàn)在需求,希望系統(tǒng)能支持微信登錄。按照上面 3 個(gè)問題,我們來和需求方溝通,需求方說:
“下個(gè)季度我們的重點(diǎn)是做微信粉絲購買轉(zhuǎn)化,但現(xiàn)在賬號(hào)系統(tǒng)只支持“郵箱登錄”和“手機(jī)號(hào)碼”登錄,幾輪運(yùn)營測試下來,發(fā)現(xiàn)未注冊的粉絲購買轉(zhuǎn)化很低,很大程度上卡在注冊環(huán)節(jié),不愿意填寫手機(jī)號(hào)碼,怕收到騷擾短信。支持微信登錄后,會(huì)極大增加粉絲的付費(fèi)轉(zhuǎn)化效果?!?/p>
了解到需求方的使用場景“微信體系場景下粉絲快速登錄”,不做會(huì)影響轉(zhuǎn)化,是必須要做的事情了。接下來要進(jìn)入第二個(gè)環(huán)節(jié)「手繪線框圖」
02 手繪線框圖
做這件事的目的是整理這個(gè)需求有哪些功能模塊,以及模塊之間的關(guān)聯(lián),產(chǎn)出物可以是紙上涂鴉。這時(shí)候要做的事情:
- 是拿上手繪圖,去找研發(fā)負(fù)責(zé)人,討論一下方案的可行性,避免踩不懂技術(shù)的坑。
- 同時(shí)也讓研發(fā)同學(xué)參與進(jìn)來,知道接下來產(chǎn)品要做什么事情,解決什么問題。
舉個(gè)例子:拿上你畫好的登錄流程手繪圖,和研發(fā)同學(xué)講清楚要解決什么問題,研發(fā)同學(xué)看了之后,說需求問題不大,但你要考慮一下,已經(jīng)注冊過的用戶,用微信登錄后賬號(hào)如何關(guān)聯(lián)在一起。
和研發(fā)同學(xué)溝通完畢之后,你再增加了一個(gè)“新老用戶關(guān)聯(lián)”線框圖。
接下來進(jìn)入「產(chǎn)品結(jié)構(gòu)」整理階段。
03 結(jié)構(gòu)圖整理
整理好手繪圖,那我們來進(jìn)一步梳理產(chǎn)品結(jié)構(gòu)。這階段的產(chǎn)出物,是模塊的定義,或者說這個(gè)模塊解決了什么問題。
舉個(gè)例子:上面支持微信登錄的例子,涉及到的功能模塊有:
- 新「用戶登錄」,支持微信賬號(hào)登錄即注冊。
- 「新老用戶關(guān)聯(lián)」,解決「老用戶」用微信賬號(hào)登錄后,與原來賬號(hào)綁定或解綁問題;
- 涉及到「修改密碼」模塊優(yōu)化:要關(guān)注只有微信登錄的用戶,是無法修改密碼的;
- 原來賬號(hào)系統(tǒng)中,支持手機(jī)驗(yàn)證碼登錄模式有安全漏洞,增加「手機(jī)號(hào)碼注冊限流」。
完成了結(jié)構(gòu)圖,就要開始模塊之間的流程整理。
04 流程圖
目的要定義角色,在核心功能模塊的邏輯規(guī)則、分支條件和最終結(jié)果。也防止我們遺漏場景。這時(shí)候可以做兩件事:
- 拿著流程圖,找你 leader 講一下,看下流程有沒有問題;如果業(yè)務(wù)比較復(fù)雜,可以和需求方溝通下,看有沒有需求遺漏;
- 和研發(fā)同學(xué)提前溝通下,讓研發(fā)同學(xué)也了解整個(gè)模塊的流程是什么。
舉個(gè)例子:
05 結(jié)構(gòu)圖細(xì)化
每個(gè)功能模塊,要細(xì)化到字段,避免信息遺漏,前后臺(tái)數(shù)據(jù)要保持一致。
舉個(gè)例子:還是上面講的微信登錄場景,用戶第一次用微信方式登錄,要獲取到用戶的 userid、手機(jī)號(hào)碼,如果手機(jī)號(hào)碼不存在,那還要生成用戶名(username)。把所有關(guān)鍵字段羅列出來,對產(chǎn)品思路重新進(jìn)行梳理。
06 原型交互設(shè)計(jì)
以上 5 步完成之后,那產(chǎn)品 80%的思考已經(jīng)完成??梢愿鶕?jù)團(tuán)隊(duì)習(xí)慣,確定交互的細(xì)致程度,如要求高保真原型,那就把交互做的更完善一些,有交互的地方做好標(biāo)記,有邏輯的地方標(biāo)明規(guī)則。這里不討論如何畫交互原型,如果有需要,可以留言溝通。
完成原型交互設(shè)計(jì),拿給你的 leader 看下,組織一次小規(guī)模的需求方評(píng)審,看看是不是解決了需求方的問題。
工具推薦:Axure、墨刀。
07 需求文檔
和需求方溝通之后,就開始寫需求文檔。關(guān)于需求文檔,有的團(tuán)隊(duì)要求寫成doc 文檔,有的只要求在原型處標(biāo)記就好。
我比較傾向于寫成 doc 文檔,因?yàn)樾枨笪臋n是產(chǎn)品產(chǎn)出的再一次檢查和梳理。需求文檔的第一讀者是產(chǎn)品經(jīng)理,然后才是研發(fā)、測試等小伙伴們。
文檔中幾個(gè)關(guān)鍵點(diǎn)要注意:
- 首先是按模塊寫文檔,要明確每個(gè)模塊的背景和定義,
- 當(dāng)需求較多(超過 3 個(gè))時(shí),要標(biāo)注優(yōu)先級(jí)(P0、P1、P2),確保核心功能優(yōu)先處理。
- 注意不要造名詞,同一個(gè)內(nèi)容前后保持一致。
完成以上,就可以進(jìn)入需求評(píng)審階段了。
08 需求評(píng)審
現(xiàn)在我們要重新認(rèn)識(shí)下「需求評(píng)審會(huì)」,它不是一個(gè)PK 工作量的會(huì)議,而是與研發(fā)、測試等團(tuán)隊(duì)小伙伴信息同步,宣告這個(gè)項(xiàng)目的開始,更多的工作是要前置到評(píng)審會(huì)議之前。
需求評(píng)審也是有流程的:
- 需求文檔提前 1 天發(fā)給團(tuán)隊(duì)中的小伙伴,讓大家提前了解下需求情況。
- 正式的需求評(píng)審會(huì)議上,先講和大家同步,這次需求,我們?yōu)槭裁匆鲞@個(gè)需求,解決了什么問題;更高階一點(diǎn)的可以講此次需求,能給業(yè)務(wù)或團(tuán)隊(duì)帶來了什么價(jià)值。
- 要先講結(jié)構(gòu)圖和流程圖,這兩個(gè)講解完畢,團(tuán)隊(duì)小伙伴們基本上了解此次需求的重點(diǎn)是什么了,然后著重講一下邏輯判斷。
- 最后,要有一個(gè)時(shí)間計(jì)劃表,然后團(tuán)隊(duì)小伙伴填寫,確保團(tuán)隊(duì)合作的節(jié)奏,如果有 deadline,團(tuán)隊(duì)小伙伴會(huì)更合理安排時(shí)間。
最后:需求評(píng)審只是一個(gè)宣講,重點(diǎn)都在線下。希望以上能給你帶來一些幫助。
#專欄作家#
司馬特小隊(duì),公眾號(hào):司馬特小分隊(duì),人人都是產(chǎn)品經(jīng)理專欄作家。8年+互聯(lián)網(wǎng)資深產(chǎn)品經(jīng)驗(yàn),多年B端產(chǎn)品管理經(jīng)驗(yàn)。具有多個(gè)從0到1的大型B端產(chǎn)品的孵化、重構(gòu)、迭代經(jīng)驗(yàn);主要教授產(chǎn)業(yè)互聯(lián)網(wǎng)產(chǎn)品相關(guān)的硬核知識(shí)點(diǎn)。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議。
除了沒寫doc的需求文檔?;旧鲜沁@樣做了。 ??
幫大忙啦
我是UI,團(tuán)隊(duì)里的產(chǎn)品出的原型邏輯都走不通,還經(jīng)常強(qiáng)調(diào)沒時(shí)間讓我趕快做,這種情況應(yīng)該怎么處理
在需求評(píng)審的階段,要指出問題,并確定修改完成時(shí)間。產(chǎn)品邏輯不完整,需求變更的概率會(huì)很大,除非方案非常簡單。為避免做無用功,還是勇敢的要求產(chǎn)品經(jīng)理提供完善的方案。
需求評(píng)審認(rèn)真。認(rèn)真。認(rèn)真。產(chǎn)品說不清楚和邏輯,喊他滾。
樓主寫的挺詳細(xì)的,但是實(shí)際工作中也是盡量往這方面靠
文章給剛?cè)腴T的小白是很友好了??
實(shí)際工作中做不到這么細(xì)致,如何取舍?