寫文檔是一個(gè)產(chǎn)品經(jīng)理的必備技能。產(chǎn)品經(jīng)理需要將寫的文檔交給上司，交給開發(fā)爬坑，交給設(shè)計(jì)。但往往產(chǎn)品經(jīng)理們殫精竭慮寫出長篇累牘的文檔涂臣，在開發(fā)那里只是瞅幾眼就扔到一旁了妇垢。其實(shí)這也不能怪開發(fā)，因?yàn)橐话阍谛枨笤u審的時(shí)候，開發(fā)已經(jīng)將產(chǎn)品的整個(gè)邏輯了解的差不多了闯估。如果開發(fā)過程中有什么問題灼舍，直接和產(chǎn)品溝通的效率也要比一頁頁的翻看文檔有用多了。這個(gè)時(shí)候產(chǎn)品經(jīng)理就會很郁悶涨薪，我已經(jīng)在文檔里寫的清清楚楚 骑素，為什么還要來問我？這個(gè)時(shí)候刚夺，寫出一份開發(fā)喜歡不煩人的文檔就皆大歡喜啦~
我覺得献丑，作為一份開發(fā)喜歡的文檔，應(yīng)該具備以下幾個(gè)特點(diǎn)：
盡量精簡文字侠姑，少些套話创橄，將需求和邏輯寫清楚即可；
可以將復(fù)雜的需求可以進(jìn)行拆分莽红。單條邏輯不要過于復(fù)雜妥畏；
多配合原型圖將抽象的邏輯轉(zhuǎn)化為具象的可進(jìn)行操作的行為路徑；
邏輯環(huán)要封閉安吁，不能出現(xiàn)開發(fā)寫著寫著寫不下去的情況醉蚁。
一、盡量精簡文字鬼店，少些套話网棍，將需求和邏輯寫清楚即可
一些剛開始寫文檔的產(chǎn)品經(jīng)理，為了標(biāo)榜自己的專業(yè)性妇智，將給開發(fā)看的文檔寫的特別多滥玷。一個(gè)小小的迭代某個(gè)功能的項(xiàng)目就可能寫幾十頁，然而里面有一大部分的內(nèi)容都是一些數(shù)據(jù)分析巍棱，商業(yè)市場分析或者是用戶行為的一些敘述罗捎。并不是說這些東西不能寫，因?yàn)橐粋€(gè)完整的需求文檔是必然包括這些部分的拉盾。但是對于一份要交給開發(fā)的文檔來說，他們接到文檔后看了好長時(shí)間發(fā)現(xiàn)和自己一點(diǎn)關(guān)系都沒有豁状，就很難有再繼續(xù)看下去的耐心了捉偏。
另外，在關(guān)于邏輯部分泻红，盡量使用通俗易懂簡潔的語言去敘述夭禽。有時(shí)候產(chǎn)品經(jīng)理在寫文檔的時(shí)候?yàn)榱梭w現(xiàn)自己的專業(yè)性以及嚴(yán)謹(jǐn)性，許多的話寫的特別官方谊路、拗口讹躯，或者比較啰嗦。比如下面是從網(wǎng)上找到的需求文檔中的一段話：
“系統(tǒng)自動分配：系統(tǒng)跟進(jìn)客戶申請的地址，自動分配數(shù)據(jù)潮梯，優(yōu)先按縣級分配骗灶、若無匹配的縣級服務(wù)機(jī)構(gòu)，則按市級服務(wù)機(jī)構(gòu)分配秉馏，若無市級機(jī)構(gòu)耙旦，則按省級服務(wù)機(jī)構(gòu)分配，若無省級機(jī)構(gòu)萝究，則進(jìn)入手動分配免都，由風(fēng)控管理人員手動分配信息”
其實(shí)這段話描述的邏輯是比較簡單的，我認(rèn)為完全沒有必要將一個(gè)重復(fù)的邏輯都寫出來帆竹。這段話可以縮減成“系統(tǒng)根據(jù)用戶申請的地址绕娘，自動匹配到縣級服務(wù)機(jī)構(gòu)，若沒有該級機(jī)構(gòu)就向上匹配“市級栽连，省級”险领。如果都沒有就由風(fēng)控管理人手動分配信息”
如果我是開發(fā)人員，我可能就會更加傾向于后面這種升酣，即便語言看起來并不是特別官方舷暮，但是文字較少同時(shí)邏輯也明了的文檔。
二噩茄、可以將復(fù)雜的需求可以進(jìn)行拆分下面。單條邏輯不要過于復(fù)雜
產(chǎn)品經(jīng)理在接手一個(gè)比較大的項(xiàng)目的時(shí)候，功能和邏輯可能都會比較復(fù)雜绩聘。這個(gè)時(shí)候沥割，文檔里面的流程圖以及思維導(dǎo)圖就會比較長，比較復(fù)雜凿菩。其實(shí)這個(gè)時(shí)候机杜，產(chǎn)品經(jīng)理無論是在寫邏輯敘述還是畫流程圖的時(shí)候，都可以將一個(gè)大的流程拆分成幾個(gè)小的流程衅谷。這樣交付給開發(fā)的話椒拗，單個(gè)邏輯較為簡單開發(fā)也有看下去的耐心。那么获黔，如何將一個(gè)復(fù)雜的流程拆分成簡單的流程蚀苛，我認(rèn)為有以下幾點(diǎn)：
1、在有判斷邏輯的時(shí)候玷氏，盡量不要拆分堵未，有跳轉(zhuǎn)邏輯的時(shí)候，可以根據(jù)它的一個(gè)相關(guān)性進(jìn)行拆分盏触。
比如渗蟹，在下面的這個(gè)流程圖中块饺，我可以將進(jìn)入初審之前作為一個(gè)流程；進(jìn)入授信之前作為一個(gè)流程雌芽，其余的作為一個(gè)流程授艰。分為三個(gè)部分分別寫邏輯，一個(gè)是可以降低開發(fā)的心理壓力膘怕，另外單個(gè)模塊開發(fā)流程的描述也會顯得個(gè)更加簡潔想诅。但是，這樣寫的話如果后面的版塊會涉及到前面版塊的邏輯一定要寫清楚岛心，以免開發(fā)在開發(fā)后面版塊的時(shí)候再去改動前面的邏輯来破。
2、閉環(huán)邏輯忘古、雙向邏輯也可以進(jìn)行拆分徘禁。
可以想象，如果開發(fā)看到這樣的邏輯圖后會有什么樣的反應(yīng)髓堪。這是給人看的嗎送朱？算了，還是去問產(chǎn)品吧干旁。如果我們仔細(xì)梳理一下這個(gè)邏輯圖驶沼，發(fā)現(xiàn)它其實(shí)并不是特別的復(fù)雜。比如到封禁用戶這一塊争群，與其它的雙向邏輯只有封禁解禁的功能回怜，單項(xiàng)操作只有加入黑名單這樣的一個(gè)。我們就可以把它單獨(dú)拎出來换薄，作為一個(gè)流程玉雾。
在我們?nèi)サ袅藘H僅是封禁用戶這一個(gè)角度及相關(guān)邏輯后，回頭再來看這個(gè)邏輯圖轻要，就已經(jīng)簡化了很多了复旬，同時(shí)單獨(dú)拎出來的這個(gè)邏輯圖也比較簡單。目的性較強(qiáng)冲泥，開發(fā)在寫的時(shí)候并沒有太大邏輯上的困惑驹碍。
三、多配合原型圖將抽象的邏輯轉(zhuǎn)化為具象的可進(jìn)行操作的行為路徑
在我們描述某個(gè)功能邏輯的時(shí)候凡恍，單純文字上的敘述并不是十分的具象志秃。這個(gè)時(shí)候如果我們已經(jīng)將原型圖畫好了，那么完全可以在原型上將其標(biāo)注出來咳焚，這個(gè)時(shí)候并不是指要畫出交互線框圖，而是我可以將邏輯寫到我的原型上面庞溜。
比如可以在原型上面可以操作的區(qū)域標(biāo)上①②③革半，然后在下面寫清楚它的一個(gè)邏輯碑定。這樣的話，不僅可以將整體的邏輯拆分為一個(gè)個(gè)的單獨(dú)邏輯又官，同時(shí)圖像傳遞信息的這種方式也要比單純的文字讓人覺得更有看下去的欲望延刘。
四、功能邏輯要把每一種情況都考慮到六敬，不能出現(xiàn)開發(fā)寫著寫著寫不下去的情況
關(guān)于最后一種情況碘赖，其實(shí)并不是為了讓開發(fā)有興趣讀下去。而是出于自身所寫文檔的一個(gè)嚴(yán)謹(jǐn)性外构。由于產(chǎn)品經(jīng)理在接觸到某一項(xiàng)的業(yè)務(wù)的時(shí)候普泡，首先考慮到的情況是大場景下面以及比較順暢的業(yè)務(wù)流程，所以這個(gè)時(shí)候很多地方的邏輯就會被忽略掉审编，當(dāng)開發(fā)寫到這一塊的邏輯時(shí)撼班，才發(fā)現(xiàn)之前寫的東西到這一塊已經(jīng)進(jìn)行不下去了，這個(gè)時(shí)候不僅開發(fā)周期延誤垒酬，做了許多無用功砰嘁，而且之前所寫的文檔沒準(zhǔn)也需要進(jìn)行大的改動。所以在寫文檔之前勘究，不要怕麻煩矮湘，首先要通過思維導(dǎo)圖軟件，將每一種情況都寫出來口糕，即所謂的窮舉缅阳。然后通過其每種情況再寫邏輯，這樣的話可以盡量的避免以上情況的發(fā)生走净。
上面的分析只是我自己的一些看法券时，可能有些公司對于需求文檔這方面有著自己嚴(yán)格的格式和定義，所以這一套并不是特別的適用伏伯。但是如果是我們自己寫文檔的話橘洞，通過一些技巧將溝通成本降到最低，減小一些自己和開發(fā)的工作说搅，豈不是皆大歡喜炸枣。
作者：執(zhí)迷，公眾號：執(zhí)迷有悟
