當(dāng)我們接到一個新需求點時,應(yīng)遵循的需求分析步驟有哪些?

19 評論 45816 瀏覽 471 收藏 7 分鐘

不要接到一個任務(wù),內(nèi)心就有一種莫名的沖動,想要馬上完成。我們應(yīng)該靜下來慢慢規(guī)劃,想清楚,才是最重要的。需求亦是如此。enjoy~

當(dāng)我們接到一個新需求點時,應(yīng)遵循的需求分析步驟有哪些?

首先,要根據(jù)需求設(shè)計功能,就要做到理解需求的來龍去脈。為此,需要搞清楚以下問題:

1. 為什么會產(chǎn)生這個需求?

當(dāng)需求方向你闡述完某個需求后,向她詢問:提這個需求的目的是什么?即為什么會產(chǎn)生這個需求?這個問題幫你完全理解需求,幫你辨別需求的真?zhèn)巍?/p>

2. 什么場景下會使用這個需求?

即搞清楚什么人在什么情況下會用到此功能。只有明白了這個,才知道如何更好地設(shè)計功能來滿足需要。

3. 是否有可能衍生出新的場景?

為了避免設(shè)計的功能因擴(kuò)展性不足,后期推翻重來,在一開始,就應(yīng)該做盡可能全面的考慮。通過需求方的場景,擴(kuò)展思考,是否存在衍生的場景。思考的過程,也是幫助你抓住和理解需求本質(zhì)的過程。

4. 技術(shù)層面如何看待這個需求?

接到需求,并充分理解了需求后,跟架構(gòu)師或技術(shù)負(fù)責(zé)人花幾分鐘時間討論一下,聽聽他從技術(shù)上對需求的考慮。通過此過程,你們基本會對需求點及實現(xiàn)方式達(dá)成共識,在后期正式開發(fā)時,阻礙會小得多。

5. 是否可納入backlog?

確認(rèn)需求為真實需求后,將其納入到backlog中,并大致描述需求邏輯,方便項目組成員對待開發(fā)工作心里有數(shù)。(應(yīng)注意backlog是已明確并經(jīng)過去偽存真的需求,是指導(dǎo)項目組掌控項目的工具,而不是產(chǎn)品經(jīng)理的備忘錄。同時粒度不宜過細(xì),否則非常不利于維護(hù)和溝通使用)

?

backlog表頭及說明

6. 開啟版本迭代,細(xì)化需求

當(dāng)要開啟一個版本的規(guī)劃時,我們從backlog中挑出高優(yōu)先級的若干個需求,并細(xì)化需求、制定迭代計劃。

細(xì)化某個需求點時,需要做的事情如下:

A. 版本功能列表說明

在版本功能列表中交代清楚需求在此次版本中的優(yōu)先級(高:必須做;中:進(jìn)度緊張時,可不做)、類型(新增:此前沒有,需重新開發(fā)的功能;修改:功能已有,需做調(diào)整的功能;刪除:不再需要,刪除的功能)、描述(交代邏輯)、詳情(鏈接到對應(yīng)的頁面):

附在PRD文檔中的當(dāng)前版本功能列表說明

B. 業(yè)務(wù)流程說明

若需求點story較大,有涉及業(yè)務(wù)的流轉(zhuǎn),則需首先梳理業(yè)務(wù)流程。流程的梳理不僅幫助項目組成員理解需求,也是幫助自己梳理思路。

C. 設(shè)計頁面和交互

流程清楚以后,就可以著手設(shè)計原型了。此時,如下幾點要素是必不可少的考慮因素:

(1)頁面的名稱是什么?

設(shè)計一個頁面相當(dāng)于創(chuàng)造了一個從來沒有的新東西,為了與其他東西進(jìn)行區(qū)分,總要給他一個標(biāo)識。故,每做一個頁面,應(yīng)先給它命名,且這個名稱是獨一無二的。既然是名字,那么名詞或動名詞是最合適的,但貴在語義表達(dá)準(zhǔn)確,即讓閱讀者看到頁面名稱,就能八九不離十的了解到這個頁面是用來做什么的?

(2)頁面由哪些功能組成?

系統(tǒng)功能由一個個頁面承載。每個頁面分擔(dān)完成功能中的若干個功能點,因此一個網(wǎng)頁就是由一個個的功能點組成的。當(dāng)設(shè)計一個頁面的時候,就要構(gòu)思好,這個頁面應(yīng)包含的功能點應(yīng)該有哪些?如“寫文章”這個頁面,大致應(yīng)有:文字編輯、圖片插入、文章發(fā)布、文章歸類等幾個功能點。

(3)完成功能需要哪些操作?

完成每個功能點,用戶需要在系統(tǒng)上進(jìn)行若干步操作。因此在設(shè)計一個功能的時候,應(yīng)交代清楚用戶使用這個功能,需進(jìn)行哪幾步操作?如完成“文字編輯”這個功能點,需要先點擊操作“寫文章”,再完成“書寫”,完成“插入圖片”,最后“保存”。

(4)執(zhí)行某個操作的條件是什么?

系統(tǒng)上的每個操作,需要滿足某些條件才可觸發(fā)。否則,系統(tǒng)功能無法形成體系,處于紊亂的狀態(tài)。如“當(dāng)文章內(nèi)容發(fā)生變化時”,才可做“保存”的操作。

一個需求從提出到設(shè)計實現(xiàn),應(yīng)該遵循特定的生命周期,否則極易出現(xiàn)遺漏、混亂的情況,極其不利于項目的質(zhì)量和整體把控。

特別應(yīng)注意的一點是,不要聽到一個需求,內(nèi)心就有一種莫名的沖動,想要馬上實現(xiàn)此需求。靜下來慢慢規(guī)劃,想清楚,才是最重要的。

 

本文由 @小麻雀?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 太棒了!有舉例的教程讓新人特別容易理解!

    來自廣東 回復(fù)
    1. 謝謝肯定~

      來自廣東 回復(fù)
  2. 請問,story point具體是什么?能舉個例子嘛

    來自俄羅斯 回復(fù)
    1. 可以按大的流程節(jié)點為粒度來抽取
      比如商家入駐是一個story,下面又可以拆成很多細(xì)小的需求點

      來自廣東 回復(fù)
  3. “第三點,是否可能衍生出新的場景”存在疑問,這個要考慮一個需求的所有可能性,但可能性并不代表要設(shè)計的功能都要滿足,如何區(qū)分哪些可能性是需要cover的,哪些是可以去除的?如果是通過市場調(diào)研來判斷,還是有點難度的,希望能回復(fù)。

    來自北京 回復(fù)
    1. 這個的意思是設(shè)計功能的時候 要考慮的長遠(yuǎn)一點或者說功能設(shè)計的要靈活一點 這樣后期有變化的時候 可擴(kuò)展性比較高 不然設(shè)計的太死 后面要有一點點改動 整個功能要大改甚至要推翻重來 就不好了~
      舉個最簡單的例子,比如OA中的審核流,設(shè)計的時候就要考慮到,這個審核流是有可能變化的(現(xiàn)在是三級,有沒有可能變成四個、五個),那這里是不是設(shè)計成配置的 而不是代碼寫死
      類似這樣的,這只是個最簡單的例子,意思差不多是這樣, ??

      來自廣東 回復(fù)
  4. 寫的太棒了,讓我這個剛接手項目的小白有點自己的思路了,期待你的后續(xù)文章,也希望能和你溝通交流~~

    來自廣東 回復(fù)
    1. 謝謝!
      我也是在摸爬滾打 ??
      有問題一起探討哦

      來自福建 回復(fù)
    2. 我覺得我們可以和樓下的小白組個群 哈哈哈

      來自廣東 回復(fù)
    3. 你可以加下這個群。群主不是我哦,我也是學(xué)員 582507167

      來自福建 回復(fù)
  5. 666,小麻雀加個微信?

    來自廣東 回復(fù)
    1. ??好 你的微信給我 我加你吧??

      回復(fù)
  6. 需求調(diào)研階段確實挺難的,尋找溝通的目標(biāo),引導(dǎo)需求方傳達(dá)有效信息,還要時刻分辨信息的真?zhèn)?,確實很重要的產(chǎn)品階段

    回復(fù)
    1. “引導(dǎo)”這個詞是精髓;好的引導(dǎo)能幫自己從對方口中獲得最有效的信息。
      是的,一個項目,需求調(diào)研不清楚,范圍蔓延、方向偏離幾乎是百分百會發(fā)生的事。
      我一直覺得,需求跟實現(xiàn)是2-8法則,但很多時候好像被顛倒過來了。
      這時候產(chǎn)品就要幫項目組把好這道門了,不要讓不清楚的問題進(jìn)入影響實現(xiàn)。
      ??

      來自福建 回復(fù)
  7. 能不能再詳細(xì)些?

    回復(fù)
    1. 你覺得哪里有問題嗎?可以一起探討下~
      1.其實一個需求你能添加到backlog中,并且對應(yīng)的列都能寫明白,說明這個需求你已經(jīng)清楚了;
      2.剩下的就是在迭代的時候,把這個需求用原型也好、文字也好 表達(dá)出來;
      3.當(dāng)然這只是我在操作中,找到的適合自己的最佳實踐 ,但不一定適合大家;
      4.我想,每個人都應(yīng)在工作中去尋找適合自己和團(tuán)隊的最佳實踐,并把它們總結(jié)出來,按著這個去做,會發(fā)現(xiàn)項目都在把控之中。

      來自福建 回復(fù)
  8. 回復(fù)