之前的文章中，我們探討了快速迭代的 3 個發(fā)版策略，為研發(fā)提速提供了易于實操的方法論。
其實，要想實現(xiàn)持續(xù)交付，除了科學(xué)的版本管理外，團隊還可以通過降低熵值去實現(xiàn)。
什么是熵值？熵值，是衡量一個系統(tǒng)混亂程度的量化指標(biāo)。
簡單來說，熵值越高，系統(tǒng)越無序、不確定性越大；熵值越低，系統(tǒng)越有序、可預(yù)測性越強。
在互聯(lián)網(wǎng)公司中，隨著版本的持續(xù)迭代，研發(fā)團隊中的信息差也日益增加，公司系統(tǒng)的混亂程度也越高。
要想持續(xù)保持團隊的高效協(xié)作，如何管理其中的熵值無序增長，成了產(chǎn)品 Leader 的一大難題。
如何有效降低熵值？如果說版本管理是研發(fā)提速的秘籍，那么需求文檔則是對抗信息熵增的關(guān)鍵。
可以說，需求文檔中的每個交付物，都在不同維度降低了團隊信息差，最終實現(xiàn)把老板的一句話需求，轉(zhuǎn)化為可落地實操的產(chǎn)品方案。
初級產(chǎn)品經(jīng)理剛開始寫需求文檔時，特別容易陷入毫無頭緒、繁瑣耗時的問題。
越是這種重復(fù)、繁瑣的工作流程，我們越要花心思去完善和提效，形成自己的一套標(biāo)準(zhǔn)化、流程化、自動化的工作流。
作為一路升級打怪，獨自硬抗過來的野生產(chǎn)品老油條，我分享下需求文檔撰寫中，大幅降低信息熵增的 6 個方法。
原型：視覺熵減
產(chǎn)品經(jīng)理最開始接觸的交付物，一定是原型了。
原型作為產(chǎn)品經(jīng)理的基本功，是一種簡單、直接表達產(chǎn)品方案的溝通方式。
但原型的缺點恰恰也是過于簡單，如果把原型當(dāng)做產(chǎn)品方案的唯一內(nèi)容，那么團隊開發(fā)過程中，一定會遇上各種踩不完的大坑。
數(shù)據(jù)對不上、迭代速度太慢、產(chǎn)品開發(fā)雞同鴨講，那都是家常便飯、小事一樁。
更麻煩的是由于自己的不專業(yè)，方案未考慮數(shù)據(jù)架構(gòu)合理性，導(dǎo)致實際上線的功能完全沒法用。
亦或是產(chǎn)品給的不成熟方案，導(dǎo)致開發(fā)無意埋下了 SHI 山代碼，過幾年等下一個有緣人承接重構(gòu)。
雖說原型缺點真不少，但總歸聊勝于無吧。
它相比老板的一句話需求、個別摸魚產(chǎn)品的競品截圖，對團隊效率提升也算是貢獻不小了，至少這個產(chǎn)品他學(xué)會了動腦。
說明：規(guī)則熵減
說明，一般用于文檔中特定內(nèi)容的詳細解釋。
說明一般有：
數(shù)據(jù)：內(nèi)容所用的數(shù)據(jù)表來源
選項：例如篩選器的默認(rèn)選值、可選范圍等
組件：一般用來指定該內(nèi)容的組件引用，例如說明使用 Element 組件庫的 Cascader 級聯(lián)選擇器
交互：相關(guān)內(nèi)容的交互說明，例如輸入框支持搜索、多選、清空等
算法：相關(guān)數(shù)據(jù)的算法，例如—— 任務(wù)數(shù) = COUNT（任務(wù)表 id）
樣式：部分特殊數(shù)據(jù)的顯示，例如—— 創(chuàng)建時間格式需要為YYYY-MM-DD
排序：組件的排序規(guī)則，例如 id 正序、時間早到晚等
當(dāng)然實際的產(chǎn)品文檔工作中，用到的說明不止這些，我粗略估計有 20+ 個，你可以根據(jù)需要自行規(guī)范相關(guān)寫法。
然而我發(fā)現(xiàn)，不少新手產(chǎn)品很容易陷入只畫原型、不寫說明的經(jīng)典怪圈。
這樣搞法，難道要讓研發(fā)、測試和你一起，在公司加班玩你畫我猜？
大家花幾天時間，猜猜這個功能的數(shù)據(jù)來源、算法規(guī)則，順便幫這個原型仔擦屁股。
一想到這協(xié)作效率，簡直頭皮發(fā)麻。。
更不用說那些拿截圖當(dāng)原型的摸魚仔了，公司遇到這種偽產(chǎn)品建議抓緊優(yōu)化。
組件：效率熵減
什么是組件？
組件是具有特定樣式和用途的內(nèi)容組合。
常見的組件類型有 5 種：基礎(chǔ)、導(dǎo)航、輸入、展示、反饋。
作為新手產(chǎn)品，學(xué)習(xí)組件的核心原因是，快速掌握畫原型的基本套路。
可以說，每個原型頁面，都由若干個組件搭建而成。
即使是再復(fù)雜花哨的 APP 界面，也都是基于幾種組件類型的變體、組裝而成。
當(dāng)你懂了組件的概念，并且找到美觀、稱心的現(xiàn)成組件庫，那么畫原型就像拼樂高那么簡單、有趣。
可能原先每天只能搞 3~5 張，現(xiàn)在用組件庫拼原型，1 天整 20 個都算慢的啦~
任務(wù)：工作熵減
任務(wù)其實很好理解，老板出其不意的一句話需求，就可以看作是任務(wù)的一種。
產(chǎn)品經(jīng)理在日常工作中，真是什么奇葩需求都有。
大到老板要做個淘寶 + 抖音 + 微信，小到業(yè)務(wù)想偷懶的提效需求，或者常見的體驗優(yōu)化、缺陷問題等。
在這過程中，產(chǎn)品一定要快速明確這些需求的優(yōu)先級。
哪些需求無理取鬧、哪些需求能拖就拖、哪些價值巨大但不急、哪些需要立即處理，這些你一定要爛熟于心，區(qū)別對待。
而剛說的任務(wù)，特別適合用來解決需要立即處理的小需求。
例如你可以把多個體驗優(yōu)化、 BUG 修復(fù)打包成小版本，以父子任務(wù)的形式，提交到團隊協(xié)作工具中，來進行版本快速迭代。
初級產(chǎn)品用好任務(wù)的這個小技巧，需求池釋放速度至少翻倍。
這里特別需要注意的是，很多產(chǎn)品容易把顆粒度較大的需求（例如一周上線積分系統(tǒng)），直接以任務(wù)形式讓團隊開發(fā)。
我的建議是，針對復(fù)雜度較高的需求，還是放入需求文檔中說明會更好。
除非你是老板、管理層，公司有開發(fā)大神，或者你 AI 用的賊 6，那當(dāng)我沒說。
否則還是看在績效年終的份上，老老實實板磚吧。。
交互：信息熵減
作為產(chǎn)品經(jīng)理，工作中多多少少都會接觸一些交互設(shè)計。
什么是交互設(shè)計？
在互聯(lián)網(wǎng)領(lǐng)域，交互設(shè)計指的是用戶輸入、系統(tǒng)反饋的一系列人機互動內(nèi)容。這些內(nèi)容一般由組件、頁面等組成。
初級產(chǎn)品在剛接觸交互時，最容易犯的錯誤就是，通過 Axure 鉆研如中繼器增刪改查、轉(zhuǎn)盤抽獎等各種酷炫的動態(tài)交互。
為什么團隊中應(yīng)該禁止動態(tài)交互？交互文檔的本質(zhì)是，通過文檔確定交互效果和細節(jié)，以此指導(dǎo)研發(fā)快速實現(xiàn)功能。
試想下如果你是一個前端，原本一兩個規(guī)則說明的事情，亦或者簡單的靜態(tài)交互即可表達需求。
但公司那閑著沒事干的原型仔，花 3~5 天時間整了十幾頁動態(tài)交互，你需要重復(fù)點擊至少上百次才搞懂交互邏輯，換我也崩潰了。
作為初級產(chǎn)品，如果你能盡早通過靜態(tài)交互代替動態(tài)交互，那么這深坑算是完美避過了。
那什么是靜態(tài)交互？
它是指將這種動態(tài)交互效果，通過一張張頁面、組件鋪開組成交互流程圖，使開發(fā)一目了然、快速抓住交互重點。
靜態(tài)交互的另一個好處是，隨著積累的交互稿越來越多、交互邏輯越來越復(fù)雜時，你可以嘗試將經(jīng)常重復(fù)的交互功能，進行抽象提煉、解耦復(fù)用。
等后續(xù)遇到類似需求時，只需復(fù)制粘貼對應(yīng)的交互邏輯，簡單修改即可，文檔效率直接飆升翻倍。
模版：結(jié)構(gòu)熵減
模版在產(chǎn)品經(jīng)理的工作中，出現(xiàn)的頻率其實很高。
常見的 Axure 元件庫、前端組件庫、功能交互庫、需求文檔模版等，都是模版思維的具體呈現(xiàn)。
那什么是模版？
簡單來說，模版是一種預(yù)先定義好的格式框架，主要用于快速創(chuàng)建特定的標(biāo)準(zhǔn)內(nèi)容。
它的核心價值在于，通過將成功經(jīng)驗封裝成結(jié)構(gòu)化、標(biāo)準(zhǔn)化的可復(fù)用框架，來實現(xiàn)效率提升、模式復(fù)用、結(jié)構(gòu)熵減。
如何在工作中運用模版？
舉個例子，我們可以把文檔撰寫過程中，高頻出現(xiàn)的多個組件說明，進行內(nèi)容封裝為一個說明模版。
又或者我會把日常慣用的需求文檔撰寫方法，完善抽象成通用的需求文檔模版。
我常用的需求文檔模版，主要由 9 個部分組成：產(chǎn)品概覽、產(chǎn)品結(jié)構(gòu)、UML 相關(guān)、流程梳理、文檔相關(guān)、消息推送、原型界面、功能交互、廢紙簍等。
總結(jié)
產(chǎn)品研發(fā)要實現(xiàn)持續(xù)交付，除了合理的版本管理，還可以降低熵值來完成。
熵值代表著系統(tǒng)混亂程度，熵值越高，信息差越大，協(xié)作就越混亂。
而需求文檔，堪稱團隊中降低信息差和熵值的神器。
具體有這 6 大策略：
原型：產(chǎn)品經(jīng)理表達方案最直接的方式，缺點是少了規(guī)則說明
說明：對特定內(nèi)容的詳細解釋，是文檔不可或缺的部分
組件：搭建原型的基本元素，掌握組件讓你效率翻倍
任務(wù)：特別適合解決小需求，用好它能更好地管理需求池
交互：通過設(shè)計合理的靜態(tài)交互稿，讓開發(fā)快速理解交互邏輯
模板：封裝成功的產(chǎn)品經(jīng)驗，實現(xiàn)工作效率的大幅提升
作為產(chǎn)品經(jīng)理要明白，需求文檔中的每個交付物，都是為了在不同維度降低團隊信息差。
最終將老板的一句話需求，轉(zhuǎn)化為可落地實操的產(chǎn)品方案。
看完覺得寫得好的，不防打賞一元，以支持藍海情報網(wǎng)揭秘更多好的項目。
感謝您的支持，我會繼續(xù)努力的!
打開支付寶掃一掃，即可進行掃碼打賞哦
手機直接保存圖片,掃一掃識別二維碼,即可進行掃碼打賞哦
