這是Kevin的第 803?篇原創(chuàng)瘾婿，

持續(xù)日更滞伟，做產(chǎn)品經(jīng)理的創(chuàng)業(yè)斜杠青年萌朱。

一個(gè)ideal到最小化產(chǎn)品的實(shí)現(xiàn)落地過程中狠毯，我們喜歡叫做MVP版本產(chǎn)品。這個(gè)最小化產(chǎn)品實(shí)現(xiàn)中靴拱，前期的投入和預(yù)算總是非常謹(jǐn)慎的垃喊。所以起初要么是創(chuàng)業(yè)團(tuán)隊(duì)，要么是一個(gè)大廠下的小項(xiàng)目組袜炕。

市面上的小團(tuán)隊(duì)比不上大廠的項(xiàng)目組本谜，在產(chǎn)品經(jīng)理、開發(fā)偎窘、運(yùn)營(yíng)乌助、測(cè)試人員資源數(shù)量、和職位等級(jí)上都不如大廠陌知。

在大廠里他托，存在小項(xiàng)目是團(tuán)隊(duì)成員“兼職”方式加入，比如本身處于在A業(yè)務(wù)線仆葡，但卻臨時(shí)去支援某個(gè)項(xiàng)目赏参。

和創(chuàng)業(yè)一樣，在大廠的小團(tuán)隊(duì)里也面臨著生死攸關(guān)的問題，但獲得的風(fēng)險(xiǎn)也低許多登刺。比如項(xiàng)目遲遲沒有達(dá)到預(yù)期指標(biāo)籽腕，項(xiàng)目就會(huì)下架直接原地解散，但這創(chuàng)業(yè)的小團(tuán)隊(duì)來說纸俭，這樣的損失成本可謂是最低的皇耗。

當(dāng)然了，如果成功了揍很，所獲的收益也是比不上創(chuàng)業(yè)團(tuán)隊(duì)的郎楼。

因?yàn)檫@類風(fēng)險(xiǎn)，小團(tuán)隊(duì)里每個(gè)人工作就有點(diǎn)特別了窒悔，基本上會(huì)身兼數(shù)職呜袁。比如產(chǎn)品經(jīng)理還上要能夠搞定商務(wù)、市場(chǎng)简珠，下要搞定產(chǎn)品功能需求調(diào)研阶界、同時(shí)還要扮演測(cè)試角色助力產(chǎn)品上線。

小團(tuán)隊(duì)在技術(shù)架構(gòu)的選型聋庵、和研發(fā)流程上都和成熟產(chǎn)品十分不同膘融。比如在架構(gòu)設(shè)計(jì)上是選擇快速的單應(yīng)用、微服務(wù)祭玉、還是選擇成本高的分布式服務(wù)氧映？

小團(tuán)隊(duì)寧可選擇單應(yīng)用實(shí)現(xiàn)業(yè)務(wù)，后期重構(gòu)脱货，也不會(huì)早期做復(fù)雜的架構(gòu)設(shè)計(jì)和投入岛都。

對(duì)于一個(gè)產(chǎn)品經(jīng)理來說，市面上所傳播的各種需求文檔規(guī)范不盡其數(shù)振峻，但在工作一定要要按某一個(gè)模版來嗎臼疫？

實(shí)際上不是的，同樣需求文檔也不是越復(fù)雜越好扣孟。

比如對(duì)于一個(gè)產(chǎn)品經(jīng)理多矮，可能一份標(biāo)準(zhǔn)的需求文檔是下面這樣

登錄注冊(cè)的需求文檔

上面這個(gè)模版，包含了該頁(yè)面的測(cè)試用例哈打、交互塔逃、前置條件、后置條件料仗、字段規(guī)范湾盗，但實(shí)際上這類PRD文檔完成時(shí)間需要非常長(zhǎng)的。對(duì)于每一個(gè)需求都這樣立轧，那產(chǎn)品經(jīng)理估計(jì)有加不完的班了格粪。

但或者至少也有這樣的

簡(jiǎn)單的需求描述

對(duì)于小團(tuán)隊(duì)躏吊，速度、和快速驗(yàn)證是第一使命帐萎。產(chǎn)品經(jīng)理的需求文檔是可以更加應(yīng)該在這小團(tuán)隊(duì)里簡(jiǎn)化的比伏。上面2種文檔是極其笨拙的，所需要的范圍疆导、撰寫成本都高赁项。

軟件類互聯(lián)網(wǎng)產(chǎn)品，小團(tuán)隊(duì)往往就是一個(gè)產(chǎn)品經(jīng)理澈段、前端開發(fā)悠菜、后端開發(fā)、UI設(shè)計(jì)師構(gòu)成败富，如果還要再繼續(xù)精簡(jiǎn)悔醋，那就是一個(gè)產(chǎn)品經(jīng)理、一個(gè)后端開發(fā)兽叮、一個(gè)前端開發(fā)即可芬骄。

團(tuán)隊(duì)雖小，但是要做的事情卻一個(gè)不能差鹦聪，我們可以羅列出每個(gè)人會(huì)牽涉到的工作職能账阻。

成員分工

麻雀雖小，五臟齊全椎麦。

在團(tuán)隊(duì)成員每個(gè)人都在多線程的工作狀態(tài)下，產(chǎn)品經(jīng)理顯然要選擇最簡(jiǎn)易的需求文檔撰寫方式材彪，既可以減少需求輸出時(shí)間观挎、還能夠達(dá)到快速研發(fā)的目的。

這種方式有一個(gè)前置條件：需要有至少3年以上的工作經(jīng)驗(yàn)產(chǎn)品經(jīng)理才能勝任

理由很簡(jiǎn)單：越是簡(jiǎn)單的需求文檔撰寫段化，就越需要只關(guān)注重要的部分嘁捷；而不是花時(shí)間在其他無(wú)用的需求上。

簡(jiǎn)易需求文檔撰寫模版

我建議小團(tuán)隊(duì)（10人以內(nèi)的研發(fā)團(tuán)隊(duì)）显熏，需求文檔用簡(jiǎn)易方法撰寫雄嚣，注意下面模版不是以文檔的結(jié)構(gòu)開始的，而是列舉了文檔的必要部分

1.前置條件說明

說明了當(dāng)前操作是需要依靠前置條件的喘蟆，比如在Pmtalk下的活動(dòng)報(bào)名H5頁(yè)面缓升，需要用戶的賬戶完成注冊(cè)，在微信授權(quán)登錄-手機(jī)號(hào)綁定-信息填寫后才能選擇支付蕴轨。

前置條件是非常重要的港谊，比如IOSapp是否能提供游客身份、以及用戶體系分層都是前置條件最常見描述的橙弱。

2.字段類型長(zhǎng)度

字段類型長(zhǎng)度其實(shí)需求文檔出現(xiàn)的頻率最高的歧寺，因?yàn)槊總€(gè)頁(yè)面都會(huì)有字段燥狰。人數(shù)、時(shí)間斜筐、價(jià)格龙致、產(chǎn)品名稱、文章標(biāo)題等顷链，都需要一個(gè)規(guī)范定義目代。

3.計(jì)算規(guī)則

計(jì)算規(guī)則并不是業(yè)務(wù)邏輯，比如在下面的阿拉丁小程序榜單里涉及到了應(yīng)用榜單排名蕴潦。背后就是對(duì)應(yīng)的算法規(guī)則

小程序排名

小程序排名計(jì)算規(guī)則

當(dāng)然這類計(jì)算規(guī)則越到后期肯定是希望系統(tǒng)來完成像啼，人工的參與度降低。所以在后面也會(huì)有對(duì)應(yīng)的AI算法潭苞、數(shù)據(jù)修正忽冻。但在早期產(chǎn)品經(jīng)理必須說明清楚

4.文案說明

文案并不是等于內(nèi)容運(yùn)營(yíng)，而是指的是對(duì)應(yīng)產(chǎn)品的按鈕此疹、頁(yè)面僧诚、其他樣式下的文案。尤其是做微信生態(tài)下的產(chǎn)品類型蝗碎，這類文案和轉(zhuǎn)化率湖笨、訪問量、傳播數(shù)據(jù)直接相關(guān)蹦骑。

比如微信小程序的分享

比如H5的分享提示文案

3.圖片尺寸和大小

圖片無(wú)論是由后臺(tái)上傳還是前端展示慈省，都需要給出對(duì)應(yīng)的尺寸說明，否則就會(huì)造成用戶閱讀變形眠菇，體驗(yàn)極差边败。

當(dāng)然還有簡(jiǎn)單粗暴的方法交給系統(tǒng)進(jìn)行對(duì)應(yīng)固定尺寸的裁剪和處理。

同樣對(duì)視頻捎废、其他類型的文件也要說在需求文檔中給出對(duì)應(yīng)的格式笑窜、尺寸、大小登疗，方便在系統(tǒng)進(jìn)行存儲(chǔ)排截、同時(shí)提供給用戶展示。

這類一般需要有經(jīng)驗(yàn)的前端開發(fā)或UI設(shè)計(jì)師進(jìn)行問題處理辐益，否則產(chǎn)品經(jīng)理自己拍腦袋給出的尺寸很容易不適用断傲。

4.操作交互

交互說明要區(qū)分終端設(shè)備和產(chǎn)品形態(tài)2個(gè)緯度。

比如終端設(shè)備可以分為PC端智政、移動(dòng)端艳悔、還有穿戴設(shè)備等領(lǐng)域

在產(chǎn)品形態(tài)上可以分為客戶端、小程序女仰、web猜年、H5形式類型抡锈。

上面小程序的hover、loading加載交互乔外，提升了用戶體驗(yàn)床三。

交互說明既要建立在終端設(shè)備上、還要建立在產(chǎn)品形態(tài)上杨幼。

比如在PMTalk里撇簿，我們最常在需求文檔描述的是按鈕的點(diǎn)擊、條件判斷2類狀態(tài)樣式差购。

當(dāng)然了四瘫，如果團(tuán)隊(duì)里有資深的前端、客戶端開發(fā)工程師欲逃，這類交互的描述即使沒有找蜜，也能夠帶來非常細(xì)膩的用戶體驗(yàn)。

畢竟做的多了稳析，自然就知道好的產(chǎn)品需要什么洗做。

5.需求背景

需求背景是為了同步給對(duì)應(yīng)上下游同事，告訴當(dāng)前需求的作用彰居。不能簡(jiǎn)單認(rèn)為給任務(wù)他們就應(yīng)該做诚纸，讓團(tuán)隊(duì)得參與感、榮譽(yù)感也是十分重要的陈惰。所以搞清楚需求背景畦徘，讓大家清楚現(xiàn)在的問題和優(yōu)先級(jí)

為什么做，當(dāng)前需求解決了什么問題抬闯，預(yù)計(jì)階段規(guī)劃

6.版本號(hào)&更新時(shí)間

更新時(shí)間也是需求文檔極為重要的一環(huán)節(jié)井辆，版本號(hào)還是同理，表明了當(dāng)前文檔的有效性画髓。在文檔中寫明需求更新時(shí)間掘剪，同時(shí)如果是線下文檔還要標(biāo)明文檔的版本里

7.業(yè)務(wù)邏輯圖

業(yè)務(wù)邏輯圖是為了講述需求背后的業(yè)務(wù)邏輯平委，只有團(tuán)隊(duì)成員清楚了業(yè)務(wù)邏輯奈虾，才能著手進(jìn)行開發(fā)。畢竟需求文檔里的文檔描述廉赔，是不能保證100%描述齊全肉微，同時(shí)還存在閱讀者可能沒有仔細(xì)看完。有時(shí)候還因?yàn)槲臋n的排版問題蜡塌，開發(fā)或設(shè)計(jì)直接遺漏了某部分需求碉纳，導(dǎo)致功能缺失。

業(yè)務(wù)邏輯

業(yè)務(wù)邏輯既可以讓系統(tǒng)開發(fā)中保證串起來馏艾。

同時(shí)團(tuán)隊(duì)成員還能明確知道當(dāng)前需求的定位劳曹。業(yè)務(wù)邏輯圖可以用時(shí)序圖奴愉、泳道圖、UML圖等表示铁孵。但要想實(shí)現(xiàn)簡(jiǎn)單需求文檔的實(shí)現(xiàn)锭硼，最快的方法還是用時(shí)序圖。

8.詞匯表

和文案不同蜕劝，詞匯表收集了通用的功能名稱檀头、字段命名。比如PMTalk在早期有簽約作者岖沛、專欄作者暑始，但實(shí)際上背后是一個(gè)邏輯。所以為了避免~混淆婴削，就統(tǒng)一更改為專欄作者廊镜。

好，今天的分享就在這馆蠕。我的微信是574319420期升，歡迎添加我的微信進(jìn)行交流