一份開發喜歡的文檔，應具備的4個特點

每周91公開課，91風暴，全員參與，實際案例實際分析

問題答疑，你提問題我解答

行業專場，互聯網金融，電商，新媒體運營等專場

各地分站交流

資源及人脈共享

其他的。。。。

歡迎各行業互聯網運營達人加入我們91運營大家庭，會運營的人都來這裡了！

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

正文

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

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

可以將複雜的需求可以進行拆分。單條邏輯不要過於複雜；

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

邏輯環要封閉，不能出現開發寫著寫著寫不下去的情況。

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

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

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

「系統自動分配：系統跟進客戶申請的地址，自動分配數據，優先按縣級分配、若無匹配的縣級服務機構，則按市級服務機構分配，若無市級機構，則按省級服務機構分配，若無省級機構，則進入手動分配，由風控管理人員手動分配信息」

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

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

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

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

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

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

2、閉環邏輯、雙向邏輯也可以進行拆分。

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

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

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

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

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

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

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

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

作者：執迷，公眾號：執迷有悟

據說，只有打賞的才是真粉絲哦，8塊8請小編喝杯咖啡吧，長按二維碼勾搭小編微信（yueyingzheng88)加入91運營社群，全年100多場免費公開課，定期問題答疑等著你，會運營的人都在這裡了！

歡迎關注91運營網旗下垂直賬號：

91產品：（微信ID：chanpin91）

致力於為產品新人、產品經理等廣大產品愛好者打造一個全方位的學習交流平台，分享產品設計、交互設計、產品運營幹貨。

專註於互聯網產品運營幹貨，聚焦互聯網產品策劃，電子商務，網路營銷，移動互聯網，融資創業等領域經驗分享。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！