全栈工程师?
嗯.....目前并不是!

需求文檔撰寫與合格交付原則

文檔的撰寫與合格交付一直是困擾在許多產品經理心中的一個難題。為了解決這個難題,筆者收集了開發、測試、設計人員多方意見,總結出這一份文檔交付原則。

眾所周知,需求文檔的撰寫與交付是每位產品經理工作中必備的技能,而在筆者寫下這套文檔交付原則之前,筆者所在的產品團隊正面臨著需求文檔混亂、格式不統一、不具備參考性等眾多問題。

筆者在收集了多位開發、測試、設計人員的意見后,綜合了一些較為優秀的PRD需求文檔,最終寫下了這篇文檔交付原則。目前也已經成功投入使用,它不僅僅能告訴你如何寫一份需求文檔,也能告訴你文檔在進入設計、開發流程前你需要做哪些準備工作,衷心的希望這篇原則能給讀者們以啟迪!

一、文檔交付流程

文檔從最開始的需求分析到真正以文本格式投入使用往往需要經歷以下幾個階段——即:需求分析→原型設計→文檔撰寫→內部評審→外部評審。

這也是當今主流互聯網公司大多採用的流程,筆者在本文中會主要介紹:原型設計、文檔撰寫、內部評審三個方面。

二、原型設計

原型繪畫是產品經理的基礎技能,但現在許多產品經理都認為繪畫原型沒那麼重要,所以草草了事。

但實際上,一份好的原型不僅能幫助設計和後端開發較好的理解你的意圖,也能增進團隊之間的和諧。在筆者的產品工作中,設計人員不止一次因為拿到一些不規範的原型設計向筆者抱怨。那麼,一份讓大家都滿意的原型應該滿足哪些要求呢?

筆者認為主要是以下四點:

  • 可點擊的頁面跳轉或頁面流程圖
  • 清晰且與文檔對應的框架結構
  • 美觀且較易於理解的設計草圖
  • 簡單、規範、統一的必要文字說明

“可點擊的頁面跳轉或頁面流程圖”:能夠幫開發更好的理解功能流程,也更利於產品經理在內審時對自己做的功能進行介紹,而且這通過Axure的“屏幕快照”功能可以非常輕鬆的實現。

“清晰且與文檔對應的框架結構”:要求PRD需求文檔功能模塊的名稱要與原型文檔里的名稱對應。

“美觀且較易於理解的設計草圖”:要求產品經理繪畫的原型要至少保證可用性——即有原型且原型交互符合規範。筆者曾遇到過有產品經理在原型設計中將Web端交互放到了移動端,甚至直接給設計人員Web端原型,讓設計人員做一份移動端設計稿的情況。

(移動端原型錯誤的交互設計)
此時的設計人員:“到底你是產品,還是我是產品???”

“簡單、規範、統一的必要文字說明”:因為有些功能點描述在文本中表現可能不夠清晰,所以直接在原型上給予標註,這部分要盡量剋制。

三、文檔撰寫

1. 我們為什麼要寫文檔?

文檔的撰寫目的,筆者認為主要有以下四點:

  • 幫助產品經理梳理思路、流程及細節,完善產品。
  • 減少設計、開發、測試過程中反覆溝通造成的時間浪費和進度延誤。
  • 增強用戶意識及程序思維。
  • 反向通過完整的PRD、原型對產品進行驗收及質量評價。

以上的一、三、四點都比較好理解,主要是為了完善產品經理的產品思維、減少出錯。而第二點可能有很多人會疑惑,做產品本來就需要我們反覆的去跟開發、設計、測試進行溝通,為什麼還要減少呢?

這主要是因為:產品經理與他們之間的許多溝通本來是可以不發生的。

例如:一個Butoon的字段,你在文檔里沒有描述清晰,那麼開發就會過來找你問,如果沒有問你直接照着他的想法做了。最後方向和你想的不一樣,那就悲劇了,要接着溝通怎麼改了。

所以,對於一個產品經理,最好的狀態是當你完成了某個項目的V1.0版本時,你就應該立刻着手準備V1.1版本的迭代與更新了,而不是接着和團隊的其他成員在V1.0版本上扯皮。

請務必記住:“產品經理是帶着團隊跑,不是和團隊一起跑。”

2. 優秀文檔應具有哪些特性?

筆者認為,優秀的文檔主要具有以下特性:

  • 邏輯性:內容有層次,描述可遞進,文檔中的結論要有客觀事實來說明。
  • 敏捷性:文檔的內容要儘可能精簡,切勿長篇大論。
  • 完整性:在保證文檔內容精簡的同時,也不能缺三少四,重要的模塊不能丟。
  • 可讀性:盡量避免使用二義性的語句,這容易造成使用人員曲解你的想法。
  • 規範性:每份文檔盡量保證格式相同或類似,減少使用人員的適應成本。
  • 一致性:在需求分析模塊的劃分和命名上與原型文檔保持一致。

3. 優秀文檔應該包含哪些模塊?

上文提到:一個好的需求文檔應該做到完整性——即包含所有的重要模塊,不能缺三少四。

那麼又有哪些模塊是重要的呢?

筆者在仔細分析了團隊正在做的產品業務后,總結了優秀文檔所需要包含的23個重要模塊,其中有11個模塊是必備的。

筆者相信,這也同樣適用於大部分其他產品的業務。


筆者簡單解釋一下,上圖中各個模塊應包含的內容和存在意義。

(1)版本修訂記錄(必備):主要包含現有版本的版本號、主要更改內容、更改原因等,它在產品出現問題,追根溯源時可以起到巨大作用。同時,也便於使用人員梳理邏輯。

(2)產品目標(必備):可以是功能或者產品上線后想要達到的效果。

(4)需求方及背景(必備):簡述需求產生背景以及原因,需求面向哪些人群?一定要有事實或者數據作為佐證,開發吐槽產品經理亂提需求也不是一天兩天了。

(5)預估收益(必備):最好能用數字量化產品或功能開發產生的收益,也就是ROI,對收益的正確評判也是產品經理的一項重要能力。這裡舉個例子,如“優化公司內部系統某流程,預計耗時13人天,完成後預計可以為公司其他部門每年節省35人天”。這樣的描述,清晰且可信。

(6)風險描述:簡要概述產品或功能開發過程中可能會遇到的內部風險和外部風險,例如:新項目遷移可能遇到未知問題,這就是內部風險。前端開發缺人,項目撞車,這就屬於外部風險。

(7)目標用戶(必備):簡要描述一下產品或功能上線后服務的人群,有群體特徵的最好也寫上。

(8)使用場景:簡要描述一下產品或功能上線后使用的場景。

(9)參與人員(必備):記錄產品或功能從孵化到上線過程中負責的工作人員,這樣的好處是某個環節一旦出了問題,可以快速的定位到相關的負責人,提高效率,特別是翻看歷史記錄的時候。

(10)項目周期:主要是方便使用人員進行時間規劃,同時可用於進行項目管理,如果所在團隊項目的時間管理已經足夠好,那麼這個模塊可以不寫。

(11)名詞解釋:對使用人員可能不了解的名詞進行註釋。

(12)功能流程(必備):這是PRD需求文檔里最重要的一個模塊,所以在保持簡潔的同時要做到儘可能的詳細。

流程圖的作用不必多說,邏輯清晰的流程圖可以幫助使用者快速的理清業務邏輯,提高效率,減少出錯。而在“交互流程”中,我建議產品經理可以直接用Axure生成的HTML網址進行表示,方便且快捷。

接下來是“頁面及彈窗”,這部分對前端開發意義很大,能有效的避免漏掉某些重要頁面。

最後便是“功能及說明”,這部分主要對產品的每個功能進行詳盡的描述。

以Web端的一個頁面舉例,我們需要介紹這個頁面的操作路徑,頁面上的操作形式,數據的來源,額外的說明等。

具體的示例,筆者在下面用圖片展示:

(13)權限&角色:簡要描述一下使用這個產品或功能的不同特徵人群的權限,舉個例子,企業做一個自己的日報系統,老闆和員工的使用權限肯定是不一樣的。

(14)性能需求:簡要描述一下產品對性能的要求,如QPS、請求訪問時長等。

(15)營銷&運營需求:這部分主要是面向C端產品,寫出方向性就可以,是與運營聯動的一個模塊。

(16)安全需求:不同產品或功能對於安全的要求往往不盡相同,例如“支付功能”的安全需求比大多其他功能都要高,這個模塊建議寫上產品或功能安全等級的高低,應該做好哪些預防。

(17)法務需求:主要是專利著作權、版權等可能遇到的法務風險,大多產品或功能不存在這個問題。

(18)異常情況(必備):簡要描述一下用戶使用產品或功能時可能碰到的異常情況,例如突然斷網等。

(19)測試要點(必備):這部分非常重要,產品經理需要在這個模塊介紹產品或功能在上線前有哪些重點功能是需要反覆測試的,有哪些異常邏輯是需要注意的。因為測試人員在一些細節的把控上可能沒有產品經理來的仔細,如果一些重要的點沒能被測試到就直接Pass,在後續的開發中就可能會惹上大麻煩(回爐重造等),從而導致項目延期。

(20)數據埋點及統計需求:寫清楚應該在產品中的哪些維度進行數據埋點,和與之對應的統計需求。

(21)上線前準備(必備):分點敘述上線前需要完成那些事件,例如把Bug狀態都變為“已解決”。

(22)上線后工作(必備):大多數產品或功能不是上線就結束了,往往需要後續的跟進,例如進行回歸測試,對用戶進行意見調研、實際收益評估等。

(23)設計規範:針對有交互原則的團隊。

(24)補充說明:其他不屬於以上22個模塊的解釋描述。

四、需求評審

1. 評審的主要流程

  • 自評清單,自評通過再內審。
  • 內審評價,內審通過再外審。
  • 外審評價,外審通過進入開發。

2. 如何做好內審?

內審是評審的第一步,如果沒有卡好內審這門關卡,隨意的讓項目通過,會導致外審時項目出現諸多紕漏,浪費團隊其他人員的時間,所以內審一定要足夠謹慎。

針對內審,筆者總結了六條原則:

  1. 至少應有3人參與內審;
  2. 內審必須邀請項目管理者參與;
  3. 要提前給定好內審預計所需要的時間;
  4. 基礎測試一旦沒有通過,內審必須當即中斷;
  5. 評審結束后,相關人員應該在幕後形成相關的結論;
  6. 每次內審需做內審會議紀要,紀要包括內審的結論和問題。

這六條原則應該都是比較通俗易懂的,但關於基礎測試,筆者要額外解釋一下:所謂基礎測試其實就是需求或功能流程,如果在內審當中,因為產品經理個人的靈光乍現或者是他人異議發現原定流程中有一段已經完全行不通了,那此時的內審也就沒有意義了。產品經理應立刻停止內審,回去重新思考並修改流程,但如果僅僅是某一個節點需要修改,影響較小,則可以繼續進行。

3. 評審需要符合那些標準?

  • 合理性:成本、收益、用戶、痛點、風險等評估要合理。
  • 完整性:角色是否完整、狀態是否完整、功能是否完整。
  • 可行性:技術的可行性,是否觸碰到已知邊界。
  • 一致性:保持相同的視覺風格、交互方式和情感傳達。
  • 邏輯性:流程是否清晰便於其他人理解。
  • 準確性:字段、數據源、數據計算方式、異常狀態等。
  • 易用性:用戶使用成本是否足夠低,路徑足夠簡潔。
  • 復用性:是否考慮復用已有產品、框架、設計。
  • 創新性:是否能夠儘可能發揮創新的能力。

以上標準既適用於內審,也適用於外審。

總結

文檔的撰寫與合格交付一直是困擾在許多產品經理心中的一個難題。現在許多的人都建議直接用Axure來同時進行原型與PRD文檔的製作,這種方式的確非常節省時間,但要注意這個時間只是節省了寫文檔的時間,在接下來的設計、開發、測試過程中,由於前期文檔內容不夠詳盡,耗費的時間實際上是大幅度增加了。

在筆者寫下這篇原則之前,所在團隊也是採取Axure原型和文檔一起做的模式,但實行起來效果並不好——前端、測試、設計飽受這種不規範文檔之苦。所以,依舊建議大家用文字表達。

這套原則因為是第一版,且筆者作為一個實習生還沒有太多的產品工作經歷,所以在部分模塊細節上可能仍然有許多疏漏。特別的,可能因為從事的業務相關,這套原則不能完全的適用於其他團隊產品的工作模式,不過筆者相信它依舊能給你們以啟發。

至於這套原則的下一步,筆者目前所考慮的是協同文檔,WIKI、石墨等等,如果大家有好的建議或者是看法,也歡迎在評論中提出,筆者都會認真聆聽並虛心接受,謝謝!

 

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《需求文檔撰寫與合格交付原則》
文章链接:https://www.pmbear.com/%e9%9c%80%e6%b1%82%e6%96%87%e6%aa%94%e6%92%b0%e5%af%ab%e8%88%87%e5%90%88%e6%a0%bc%e4%ba%a4%e4%bb%98%e5%8e%9f%e5%89%87/
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们