征服開發測試的B端PRD文檔是怎樣寫成的

23 評論 24791 瀏覽 317 收藏 13 分鐘

編輯導語:需求文檔的撰寫有助于產品經理更好地理清思路,協助后續項目業務的分析復盤,與此同時,也可以讓團隊人員更好地理解業務需求,推動項目進行。那么,B端產品經理如何撰寫出讓開發測試都能理解且認可的需求文檔?本文作者做了總結,一起來看一下。

一、客觀場景

據調研,開發測試非常反感以下類型的B端產品經理:

  • 業務流程都整不明白,還是開發幫其捋出來的;
  • 講完一個需求,讓開發花幾天或幾周時間梳理其不明確的邏輯點;
  • 已經到了敲代碼階段了,還在多次改需求;
  • 寫的需求來自拍腦袋而不是客觀業務背景;
  • 需求文檔讓測試根本不知道怎樣寫測試用例。

這些問題的解決辦法除了用人情交際手段、扯皮解決,還可以從嚴于律己的角度出發,踏踏實實寫好PRD文檔,寫出能征服開發、測試的PRD文檔,然后宣講需求的時候按照文檔寫的順序宣講就行。

“怎么寫PRD文檔”這常常是培訓機構做的事情,主要給那些將要做產品經理的新人同學看,我講的是“怎樣寫出征服開發測試的B端PRD文檔”,主要寫給已經做B端產品經理2年以上的同學看,目的是讓B端產品經理能通過PRD文檔表達實力、提升能力、征服開發,從而提高產研協作效率和豎立產品經理威嚴。

二、開發測試的訴求

那么到底怎樣才能寫出征服開發測試的B端PRD文檔 ?

首先就得分析開發測試通過PRD文檔到底想知道什么、也就是其需求是什么,然后有效地滿足他們的需求,最后在宣講需求的時候用通俗易懂的話講清楚、讓聽眾聽明白。那么開發測試到底通過PRD文檔主要想知道什么呢?

1. 前端開發

  • 哪些增刪改查頁面要做;
  • 每一個界面交互邏輯;
  • 哪些節點要請求后端哪些接口;
  • 為何要做這個需求。

2. 后端開發

  • 核心和具體功能的業務流程是什么;
  • 前端的哪些交互需要調用我的什么接口;
  • 涉及到哪些表,表之間的數據流向是什么、表結構怎樣設計;
  • 需要其它后端開發配合我聯調什么接口;
  • 為何要做這個需求。

3. 測試

要寫哪些明確的用例。

三、八招征服

那么到底怎樣寫PRD文檔,才能滿足開發測試上面的這些需求呢?

經過6年的ERP、供應鏈相關產品設計實戰,我總結出了“八招”,讀者在使用這八招時需要實事求是一切從實際出發,畢竟難度很大。為了讓讀者理解起來不那么枯燥,我把這8招分開闡述,且配了相關案例。

1. 更新標記

無論是創建一個全新的大需求,還是在已有需求中增刪改需求都要有標記,這樣就可追溯需求。如果不這樣做,有時產品經理自己就會發現之前的邏輯是什么不知道,特別是前任產品離職后如果不交接清楚,你接收后會一臉懵。

我說的標記是只在文檔內容中要有標記,這樣開發測試只需搜索這個標記就知道了“這個需求”涉及哪些,而不是要全文閱讀。就好像你在監控下面干了什么,都被拍下來了一樣,下面我列舉了2個簡單案例。

1)修改字段名稱

2)修改一段邏輯

2. 業務場景

要寫清楚業務上遇到什么了問題,然后你的產品方案是要解決這個問題的,不然開發測試不知道你為何要做這個需求。還要寫清楚這個問題是怎樣來的,是來自實際業務、還是誰拍腦袋的,這樣開發測試就知道了需求的真實性。

如果你還有空的話,可以寫下分析這個問題的過程、以及解決這個問題的多種方案,這樣開發測試就能身臨其境地知道了這個需求的來龍去脈。

3. 方案概述

寫完業務場景就要寫方案概述,主要就是用產品語言概述上面的問題是怎樣解決的,這個需求涉及到哪些業務模塊、涉及到哪些核心邏輯。

這樣宣講需求時開發憑此就可判斷是否與自己有關系了,就不會出現“某開發參加需求評審個把小時卻發現自己不需要做啥,然后耽誤了敲代碼的時間搞的晚上又要加班”。而且開發主管也可以根據這個方案概述就能判斷出來需要給什么樣的開發資源、開發周期。

4. 業務流程

寫完方案概述開發測試只知道要干什么,但是具體怎樣做是不知道的,這時就要開始寫業務流程,最好用泳道圖寫清楚各種判斷邏輯、涉及的用戶角色、業務模塊等。后端開發看這個的時候,腦子里就會想數據流向、需要哪些接口、用哪張表。

業務流程就好像是開車時使用的地圖導航、就好像是打仗時制定的路線圖,對于B端產品經理來說“無論多么復雜的業務都可以用流程圖表達出來”是基本的能力,這里我就不放按案例圖片了。對于開發來說非常反感的一種B端產品經理就是“一個需求竟然畫不清楚、說不清楚流程”。

5. 前端交互

只有業務流程來表達一件事情的解決過程還是有些抽象,所以此時要用原型頁面來形象表達,這塊UI和前端會重點看需要做哪些增刪改查頁面、哪些交互,后端也會思考需要封裝哪些接口給前端調用。

注意這里不是簡單用原型工具畫幾個頁面把鏈接拋給開發就行,而是要按一定的格式(條件、動作、頁面、結果)寫出每一個交互、每一個字段,具體可看下面案例。

有一種產品經理是非常讓開發測試反感的,就是“需求的輸出方式就是一個原型文件,點開后發現就基本的列表頁、新增編輯頁、詳情頁,其它邏輯靠猜”。

以我這樣的方式寫前端交互有個弊端就是比較花時間,最大的優勢就是可以不漏掉每一個交互邏輯、每一個字段,下面我只是舉了2個非常簡單的例子。

1)列表頁中的每一個字段名稱、排序要寫出來,以免遺漏

2)新增、編輯頁中的每一個交互,用“條件、動作、頁面、結果”這一格式表達

6. 表結構

這塊目前市面上90%以上的B端產品經理都不會寫,因為籠統地覺得這是開發的事情。如果產品經理能把這個需求需要設計哪些表、需要哪些字段、以及每個字段的相關信息都寫出來,那么開發設計表結構的時候就可以借鑒、確認,這樣開發真的會非常佩服你。

這塊的基礎就是產品經理要懂sql的基本查詢語句,如果懂了真的是如虎添翼,寫需求的時候能更加從開發的角度考慮問題了。以下案例中的每一列名稱的使用,需要有一定數據庫功底的產品經理才能掌握。

7. 數據流向

從哪個表取數據插入或更新到哪個表,用什么樣的入參去請求哪個接口返回出什么樣的值,這個開發是非常關心的。

開發敲的代碼操縱的就是表,也就是說在開發眼中功能的本質就是數據的流向,而數據流向的載體是表和接口,數據流向是業務流程的技術理解。這塊需要有一定數據庫和接口功底的B端產品經理才寫得出來。

8. 評審問題

在產品宣講或開發過程中,開發提的一些重要問題的答案這里要記錄下來,這樣就方便其它開發看,也更能明確需求。特別是產品文檔中沒寫的邏輯,在評審時開發發現了然后經過討論后定下來了,就更加要寫到這上面來了。

這塊其實是對需求文檔的一個查漏補缺,如果不記錄那么也許過一段時間又會忘記這些重要邏輯,記錄采取這樣的格式就行“提出人、提出時間、問題、答案”。

四、總結

到了這里就寫完了,這八招是對B端產品經理的高嚴格、高標準,所以在實際應用過程中需要一切從實際出發,畢竟通過口述需求、原型文件、一個PPT、簡單寫一段文字、甚至畫個草圖給開發,開發也是能把需求實現的。

產品經理寫的文檔就相當于是自己的藝術作品,如果你對自己的藝術作品是高標準的,那么我相信假以時日你在開發測試眼中將是一塊金字招牌,都樂于和你合作。

我不會寫一篇虛的文章,每篇文章都是來自多年ERP、供應鏈相關產品經理工作的總結。我不需要任何一個讀者給我鼓掌或者覺得我講的有道理,我需要的是閱讀此文后你能在工作中用得上,這樣就能幫助你更優秀。

 

作者:產品老兵,公眾號:供應鏈產品老兵

本文由 @供應鏈產品老兵 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 這個表結構我真覺得有點兒過了,放心開發不會喜歡,反而背后罵你,技術開發他們就是要理解業務需求自行產出相關文檔,作為一個PM直接剝奪了人家的部分價值,鳩占鵲巢的意味很明顯,而且作為產品來說工作的邊界是不是過于模糊

    來自北京 回復
    1. 分公司吧,產品這樣干,梳理邏輯什么的,開發會喜歡這樣的,因為省事,是要搬磚就行了,到時候背鍋也是產品去背,一切按照文檔來操作,有寫就寫沒寫就沒寫,一切都是按照文檔操作的。我曾經就被開發懟過:”這個校驗我做不了,因為這個數據的值我拿不到,你告訴我要怎么校驗?要不代碼給你,你來寫?“
      對于技術上的東西多少得懂點,不然開發回懟的是啞口無言,不考慮怎么實現邏輯的話,開發也會罵的

      來自上海 回復
    2. 同意,表結構和數據流向這兩部分確實過分了。不只是鳩占鵲巢,而是產品考慮的肯定是不全面、甚至是錯誤的。
      首先表結構產品側考慮的肯定不全面,這個圖里,就缺少了技術側一般需要的gmt_createtime這種字段。 所以既然考慮的不全面,那就應該讓技術側產出,不要給這種半吊子的產出。

      來自北京 回復
  2. 杰哥,您文中截圖的那個交互說明,是用什么做的啊?word文檔中插入的表格放不下頁面圖片吧

    來自黑龍江 回復
  3. 如果PM要做的這么讓開發省心,如何體現開發的能力呢?畢竟大家工資差不多。 建表和接口理解需求不是開發的本職工作嗎對不。
    公司有很多種,有的PM服務于開發,有的服務于市場和老板,而我認為PM就是個中間角色,各方都要服務也要懟,引導各方從產品角度去做事情,注重用戶,才有利于公司長遠發展,他的精力也不應該只放在如何讓開發舒服省心,也不需要過于糾結原型的某個常用操作要不要做高保真,糾結雞毛蒜皮的東西就發揮不出PM的深層價值,建立于開發團隊的人際關系和工作默契度才是軟實力。

    來自重慶 回復
    1. 你好,你的觀點我理解且不否定,畢竟如我在文章里有寫“在實際應用過程中需要一切從實際出發,畢竟通過口述需求、原型文件、一個PPT、簡單寫一段文字、甚至畫個草圖給開發,開發也是能把需求實現的?!?/p>

      來自湖南 回復
    2. 對的

      來自廣東 回復
    3. 我贊同你的觀點。首先PM就分很多種,有偏市場方向,有偏研發方向,文中所述的方法可能更適合于偏研發方向的PM使用。不過PM過于專注于研發,對于更高層面的市場調研、需求分析、功能規劃、功能設計等肯定難以兼顧好,而這我認為恰恰是對于一個PM來說更重要的工作?,F在開發都卷得不行了,PM去摻和開發的事情,搶開發的活,開發會認為PM這是鳩占鵲巢,不干正事。PM更重要的是保證每一個需求合理有價值,也就是說PM要做正確的事情。正確地做事情還是交給開發吧。

      來自北京 回復
    4. 說的真實哈

      來自廣東 回復
    5. 現實情況是很多中小型公司領導層對PM的重視度不夠,或者中高層在參與PM的策劃工作,但又沒有PM專業,不給夠PM話語權和建議權,把PM困于與開發團隊做項目這種執行事務中,也會埋沒一些人才吧~PM最大的價值在于:站在公司或產品角度為公司和產品做正確的選擇少走彎路,在對的節點做對的事情,為企業降本增效且盈利,為目標用戶提供價值,使產品在未來市場站穩腳跟且長遠發展。PM的確是最接近CEO的人,至少且應該是一個公司的智囊團的重要人物。
      雖然這是理想狀態,現實殘酷,但理想總是要有的,共勉!

      來自重慶 回復
    6. 產品頭兩年也經常陷入這樣的糾結中,非技術出身,在技術溝通方面本身存在弱勢,尤其是技術不懂業務價值的時候,要實現某個需求,簡直就成了扯皮。作者所陳述的方法論,也只適用于某些公司某些階段罷了。但對于產品經理來講,我覺得確實不需要做到這個程度,只需要懂的是否可以實現,大致如何實現,實現難度幾何。這樣便足矣。產品經理不需過分糾結于此,如果每天都要做這些工作,那么自己的發展也不是產品的正向發展路徑,產品這個崗位價值,更多的還是更高維度的產品價值層面。

      來自上海 回復
    7. 不同階段:對產品及開發的要求也是不一樣的。拋開產品規劃的視角不說:從產品如何更好的執行落地視角下:應該是怎么效率高怎么來

      來自湖南 回復
  4. 求個脫敏的模板或者案例~
    謝謝大佬~
    郵箱:2827259340@qq.com

    來自上海 回復
    1. 你好,模板的格式和內容在word和excel中都寫不下、所以我也就無法發你,如果需要更進一步交流可以關注我公眾號:產品老兵中杰。

      來自湖南 回復
  5. 把代碼也寫了,開發更佩服

    來自廣東 回復
    1. 1

      來自上海 回復
    2. 1

      來自廣東 回復
    3. 開發丟飯碗了

      來自廣東 回復
    4. 所以就有的開發去轉產品了

      來自上海 回復
  6. 產品菜雞同求模板,郵箱:13081753661@163.com,給大佬上茶

    來自江蘇 回復
  7. 同求個模板
    郵箱:626754602@qq.com
    謝謝大佬

    來自湖北 回復
  8. 同求大佬模板hhh

    來自上海 回復
  9. 寫得好,求個脫敏的模板~

    來自廣東 回復