▍言職用戶(hù) @Stove SaaS產(chǎn)品經(jīng)理 · 拉勾網(wǎng)
經(jīng)歷了將近半年幾乎不寫(xiě)文檔的小團隊，對這方面稍微有點(diǎn)感觸。分幾個(gè)階段分別來(lái)說(shuō)吧：
一、文檔無(wú)說(shuō)明
項目初期整個(gè)團隊會(huì )一起梳理和確定基本的邏輯和架構（就算是被動(dòng)的也會(huì )參與，畢竟是從無(wú)到有的階段，大意不得），所以對文檔的依賴(lài)性還比較小，產(chǎn)品基本只輸出原型，有問(wèn)題也只是具體的功能問(wèn)題，遇到隨時(shí)問(wèn)就好。
而在產(chǎn)品上線(xiàn)后的一段時(shí)間內，提需求一般也只輸出原型，然后當面講解需求。
個(gè)人感覺(jué)在項目初期，這種方式更敏捷。
不過(guò)如果團隊中的后端不夠強勢或話(huà)語(yǔ)權不夠大的話(huà)，建議產(chǎn)品在梳理基本邏輯和架構的時(shí)候主動(dòng)叫上研發(fā)，并反復向對方講解需求和未來(lái)的規劃。
二、無(wú)文檔有說(shuō)明
沒(méi)有文檔，但在原型旁做需求說(shuō)明。
這種方式在A(yíng)pp上還比較流行，但由于SaaS產(chǎn)品的復雜性遠高于A(yíng)pp，因此從產(chǎn)品角度來(lái)說(shuō)：
1、文字太多，書(shū)寫(xiě)的體驗并不好
2、對厘清思路的幫助較小
而對研發(fā)來(lái)說(shuō)，后端更關(guān)注邏輯，原型 說(shuō)明不如單純文檔來(lái)的簡(jiǎn)潔，前端更關(guān)注視覺(jué)效果，把原型換成設計稿，需求說(shuō)明僅保留和前端相關(guān)的，這樣可讀性會(huì )比較高。
順便說(shuō)下，這種方式是最快被放棄的，但如果有朝一日做C端App的話(huà)，我還是會(huì )繼續嘗試。
三、用例式文檔
為了測試，項目進(jìn)程中也曾花了2天時(shí)間給QA寫(xiě)Word文檔，當時(shí)的思路完全是用例式的：
用戶(hù)XXX，系統XXX。
當時(shí)的感受是：
1、 用例式的文檔確實(shí)能夠幫助產(chǎn)品本身厘清思路，但流程上還是后置于需求整理，甚至畫(huà)原型
2、對研發(fā)來(lái)說(shuō)，并沒(méi)有比傳統Word好多少
我自己分析下來(lái)，大概有2個(gè)原因：
1、Word的儀式感比較強，一打開(kāi)Word整個(gè)人就好像被附體了，特別嚴謹特別裝
2、 用例式的文檔毫無(wú)疑問(wèn)是面向QA的，但對研發(fā)來(lái)說(shuō)，4個(gè)字：不說(shuō)人話(huà)
不過(guò)面向QA輸出PRD毫無(wú)疑問(wèn)是有價(jià)值的：需求的實(shí)現質(zhì)量能夠得到保證。
而面向QA的弊端則是——不說(shuō)人話(huà)只是結果，根本原因是——研發(fā)根本不喜歡看PRD，PRD一長(cháng)串，寫(xiě)的人自己估計都不太想看，更不用說(shuō)惜時(shí)如金的研發(fā)了。
那怎么辦呢？
如果你在大公司，或者已經(jīng)比較成熟的項目，那么請繼續面向QA輸出需求。這并不是不考慮研發(fā)哥哥們的心情，而是面向QA是防止扯皮保證質(zhì)量的最優(yōu)方案。
研發(fā)實(shí)在看不懂咋辦？發(fā)揮產(chǎn)品汪的本色，跪著(zhù)講需求吧。
但如果你在小項目，那么我這有一個(gè)好方法——用Outliner工具輸出需求。
四、 Outliner文檔
這是我最近一段時(shí)間在嘗試的PRD風(fēng)格。
Outliner的首要優(yōu)勢是，它不僅能夠幫助產(chǎn)品本身厘清思路，而且在流程上平行于需求整理，前置于畫(huà)原型。如此的好處是能讓需求方想清楚了再開(kāi)始畫(huà)原型，而不是畫(huà)到一半才發(fā)現問(wèn)題。
最近我在構思需求時(shí)首先打開(kāi)的都是Outliner，寫(xiě)下目標和制約，再隨手記下任何想到的需求點(diǎn)、風(fēng)險點(diǎn)，顆粒度大小、規范等都無(wú)所謂，輸出需求時(shí)再統一整理。
這幾乎完全解決了產(chǎn)品側的問(wèn)題：PRD和需求整理、畫(huà)原型脫節；花費大量時(shí)間死磕文檔，拖慢項目進(jìn)程。
Outliner的魅力不僅如此，由于本身強結構化的特質(zhì)，它還能幫助你根據研發(fā)的思路整理需求。
我的方法是借鑒OPP（面向對象編程）和狀態(tài)機，在輸出需求的時(shí)候將模塊/頁(yè)面按照：權限、數據、能力、狀態(tài)4個(gè)部分來(lái)寫(xiě)（這4個(gè)是最基礎的，每個(gè)Feature還需要根據自己的特性和業(yè)務(wù)場(chǎng)景單獨補充）。
相比于用例式的陳述句，結構化的方式更便于研發(fā)理解需求。
這背后體現了產(chǎn)品和研發(fā)思維的差異性，產(chǎn)品的思維是從目標向下推導，逐漸落地——需求對產(chǎn)品經(jīng)理而言，只是實(shí)現目標的手段。
而研發(fā)的思維則是從最底層的權限、數據存儲逐漸向上，以匹配目標（需求）——既然需求是目標，那么產(chǎn)品變更需求就相當于在變更目標了。
綜上，如果產(chǎn)品在思考需求的時(shí)候能更多從研發(fā)角度出發(fā)，研發(fā)自然能更方便地理解、產(chǎn)出需求。
畢竟作為產(chǎn)品汪，討各方開(kāi)心是一項必備技能啊。
▍言職用戶(hù) @張欣 產(chǎn)品經(jīng)理·中國移動(dòng)
1、為啥要做這個(gè)需求；
2、需求在什么場(chǎng)景下會(huì )發(fā)生；
3、滿(mǎn)足此需求需要新增什么功能；
4、功能的交互流程，圖文描述；
5、功能的業(yè)務(wù)流程，圖文描述；
6、功能有沒(méi)有特殊的約束規則，例如需要用戶(hù)實(shí)名認證；
7、流程中的異常情況描述，例如網(wǎng)絡(luò )不佳時(shí)是否有提示；
8、需求文檔也分為很多種，新增功能類(lèi)、優(yōu)化類(lèi)；
9、需求文檔存在的目的是讓前端、視覺(jué)、后臺、測試都可以圍繞此文檔展開(kāi)工作；
10、對于前端，你的交互流程要清楚，對頁(yè)面元素要精準到字段長(cháng)度；
11、對視覺(jué)，頁(yè)面重點(diǎn)元素要標注，產(chǎn)品風(fēng)格要定好、扁平、清新、喜慶、擬物，不可用高端大氣等形容詞；
12、對后臺、業(yè)務(wù)流程、異常處理、風(fēng)控規則要描述清楚；
盡量讓開(kāi)發(fā)團隊減少對業(yè)務(wù)和交互的思考，要讓他們專(zhuān)注于技術(shù)的邏輯與實(shí)現。
好的文檔能減少團隊的無(wú)效溝通，也能避免產(chǎn)品亂改需求的現象。
▍言職用戶(hù) @馮治文 產(chǎn)品經(jīng)理·nubia
1、目的：滿(mǎn)足什么需求（重要等級9）；
2、目標：如何驗收（重要等級5）；
3、用戶(hù)場(chǎng)景：用戶(hù)用起來(lái)是什么樣的（重要等級8）；
4、詳細描述：first、邏輯圖（重要等級8.5）；
層級1→功能點(diǎn)拆分；
層級2→二級功能點(diǎn)；
層級3→約束條件；
5、非功能性要求、與其它模塊的關(guān)聯(lián)（重要等級6）；
另外，需求文檔不是一成不變的，核心目的在于描述清楚一個(gè)需求，所以在不同場(chǎng)景下可以用文檔、卡片、列表都ok，只要達到目的。
▍以上內容由拉勾網(wǎng) 言職社區 用戶(hù)原創(chuàng )出品，轉載請注明作者及來(lái)源
? 2017 拉勾網(wǎng)保留所有權利
- END -
拉勾網(wǎng)言職社區旨在分享有價(jià)值的知識干貨和職場(chǎng)經(jīng)歷，及時(shí)獲取互聯(lián)網(wǎng)最新動(dòng)態(tài)，更深度的了解一家互聯(lián)網(wǎng)公司。希望你可以留下自己的觀(guān)點(diǎn)，得到有價(jià)值的交流。
查看更多精彩互聯(lián)網(wǎng)職場(chǎng)問(wèn)答，歡迎來(lái)拉勾網(wǎng)言職社區。
聯(lián)系客服
