寫文檔是一個產品經理的必備技能。產品經理需要將寫的文檔交給上司，交給開發(fā)，交給設計。但往往產品經理們殫精竭慮寫出長篇累牘的文檔，在開發(fā)那里只是瞅幾眼就扔到一旁了。其實這也不能怪開發(fā)，因為一般在需求評審的時候，開發(fā)已經將產品的整個邏輯了解的差不多了。如果開發(fā)過程中有什么問題，直接和產品溝通的效率也要比一頁頁的翻看文檔有用多了。這個時候產品經理就會很郁悶，我已經在文檔里寫的清清楚楚 ，為什么還要來問我？這個時候，寫出一份開發(fā)喜歡不煩人的文檔就皆大歡喜啦~

我覺得，作為一份開發(fā)喜歡的文檔，應該具備以下幾個特點：

1. 盡量精簡文字，少些套話，將需求和邏輯寫清楚即可；
2. 可以將復雜的需求可以進行拆分。單條邏輯不要過于復雜；
3. 多配合原型圖將抽象的邏輯轉化為具象的可進行操作的行為路徑；
4. 邏輯環(huán)要封閉，不能出現開發(fā)寫著寫著寫不下去的情況。

一、盡量精簡文字，少些套話，將需求和邏輯寫清楚即可

一些剛開始寫文檔的產品經理，為了標榜自己的專業(yè)性，將給開發(fā)看的文檔寫的特別多。一個小小的迭代某個功能的項目就可能寫幾十頁，然而里面有一大部分的內容都是一些數據分析，商業(yè)市場分析或者是用戶行為的一些敘述。并不是說這些東西不能寫，因為一個完整的需求文檔是必然包括這些部分的。但是對于一份要交給開發(fā)的文檔來說，他們接到文檔后看了好長時間發(fā)現和自己一點關系都沒有，就很難有再繼續(xù)看下去的耐心了。

另外，在關于邏輯部分，盡量使用通俗易懂簡潔的語言去敘述。有時候產品經理在寫文檔的時候為了體現自己的專業(yè)性以及嚴謹性，許多的話寫的特別官方、拗口，或者比較啰嗦。比如下面是從網上找到的需求文檔中的一段話：

“系統(tǒng)自動分配：系統(tǒng)跟進客戶申請的地址，自動分配數據，優(yōu)先按縣級分配、若無匹配的縣級服務機構，則按市級服務機構分配，若無市級機構，則按省級服務機構分配，若無省級機構，則進入手動分配，由風控管理人員手動分配信息”

其實這段話描述的邏輯是比較簡單的，我認為完全沒有必要將一個重復的邏輯都寫出來。這段話可以縮減成“系統(tǒng)根據用戶申請的地址，自動匹配到縣級服務機構，若沒有該級機構就向上匹配“市級，省級”。如果都沒有就由風控管理人手動分配信息”

如果我是開發(fā)人員，我可能就會更加傾向于后面這種，即便語言看起來并不是特別官方，但是文字較少同時邏輯也明了的文檔。

二、可以將復雜的需求可以進行拆分。單條邏輯不要過于復雜

產品經理在接手一個比較大的項目的時候，功能和邏輯可能都會比較復雜。這個時候，文檔里面的流程圖以及思維導圖就會比較長，比較復雜。其實這個時候，產品經理無論是在寫邏輯敘述還是畫流程圖的時候，都可以將一個大的流程拆分成幾個小的流程。這樣交付給開發(fā)的話，單個邏輯較為簡單開發(fā)也有看下去的耐心。那么，如何將一個復雜的流程拆分成簡單的流程，我認為有以下幾點：

1、在有判斷邏輯的時候，盡量不要拆分，有跳轉邏輯的時候，可以根據它的一個相關性進行拆分。

比如，在下面的這個流程圖中，我可以將進入初審之前作為一個流程；進入授信之前作為一個流程，其余的作為一個流程。分為三個部分分別寫邏輯，一個是可以降低開發(fā)的心理壓力，另外單個模塊開發(fā)流程的描述也會顯得個更加簡潔。但是，這樣寫的話如果后面的版塊會涉及到前面版塊的邏輯一定要寫清楚，以免開發(fā)在開發(fā)后面版塊的時候再去改動前面的邏輯。

2、閉環(huán)邏輯、雙向邏輯也可以進行拆分。

可以想象，如果開發(fā)看到這樣的邏輯圖后會有什么樣的反應。這是給人看的嗎？算了，還是去問產品吧。如果我們仔細梳理一下這個邏輯圖，發(fā)現它其實并不是特別的復雜。比如到封禁用戶這一塊，與其它的雙向邏輯只有封禁解禁的功能，單項操作只有加入黑名單這樣的一個。我們就可以把它單獨拎出來，作為一個流程。

在我們去掉了僅僅是封禁用戶這一個角度及相關邏輯后，回頭再來看這個邏輯圖，就已經簡化了很多了，同時單獨拎出來的這個邏輯圖也比較簡單。目的性較強，開發(fā)在寫的時候并沒有太大邏輯上的困惑。

三、多配合原型圖將抽象的邏輯轉化為具象的可進行操作的行為路徑

在我們描述某個功能邏輯的時候，單純文字上的敘述并不是十分的具象。這個時候如果我們已經將原型圖畫好了，那么完全可以在原型上將其標注出來，這個時候并不是指要畫出交互線框圖，而是我可以將邏輯寫到我的原型上面。

比如可以在原型上面可以操作的區(qū)域標上①②③，然后在下面寫清楚它的一個邏輯。這樣的話，不僅可以將整體的邏輯拆分為一個個的單獨邏輯，同時圖像傳遞信息的這種方式也要比單純的文字讓人覺得更有看下去的欲望。

四、功能邏輯要把每一種情況都考慮到，不能出現開發(fā)寫著寫著寫不下去的情況

關于最后一種情況，其實并不是為了讓開發(fā)有興趣讀下去。而是出于自身所寫文檔的一個嚴謹性。由于產品經理在接觸到某一項的業(yè)務的時候，首先考慮到的情況是大場景下面以及比較順暢的業(yè)務流程，所以這個時候很多地方的邏輯就會被忽略掉，當開發(fā)寫到這一塊的邏輯時，才發(fā)現之前寫的東西到這一塊已經進行不下去了，這個時候不僅開發(fā)周期延誤，做了許多無用功，而且之前所寫的文檔沒準也需要進行大的改動。所以在寫文檔之前，不要怕麻煩，首先要通過思維導圖軟件，將每一種情況都寫出來，即所謂的窮舉。然后通過其每種情況再寫邏輯，這樣的話可以盡量的避免以上情況的發(fā)生。

上面的分析只是我自己的一些看法，可能有些公司對于需求文檔這方面有著自己嚴格的格式和定義，所以這一套并不是特別的適用。但是如果是我們自己寫文檔的話，通過一些技巧將溝通成本降到最低，減小一些自己和開發(fā)的工作，豈不是皆大歡喜。

作者：執(zhí)迷，公眾號：執(zhí)迷有悟

本文由 @執(zhí)迷 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載