數(shù)字世界的數(shù)據(jù)冷冰的擺在那里，意義是被有意識的人、組織所賦予的，場景功能是實現(xiàn)意義的路徑。

一、產(chǎn)品設(shè)計實例，誰說產(chǎn)品經(jīng)理只為用戶負(fù)責(zé)？

1、用戶消費交付的產(chǎn)品，完成自己的交易，進行價值交換；

2、開發(fā)者、測試者消費前期產(chǎn)品概念、產(chǎn)品原型、設(shè)計方案，完成數(shù)據(jù)構(gòu)建+邏輯實現(xiàn)；

開發(fā)者、測試者同樣是消費者，這個層面上來看，他們豈不也是產(chǎn)品經(jīng)理要考慮的用戶？只不過消費的內(nèi)容對象、周期階段差異。

曾經(jīng)處理過一起“設(shè)計事故”（不算大，但就很抓狂），大致的產(chǎn)品意圖是要支持用戶維護一份供應(yīng)商維度的商品采購成本數(shù)據(jù)，以便支撐采購業(yè)務(wù)和數(shù)據(jù)記錄分析。

到達了開發(fā)階段之后，實現(xiàn)模型就走向了真的是“供應(yīng)商維度”，一商品對多供應(yīng)商底層關(guān)系+任一商品檔案更新都按供應(yīng)商維度觸發(fā)下屬全量商品價格的更新邏輯，前述邏輯的結(jié)果就是每次更新都會產(chǎn)生大量的冗余數(shù)據(jù)。

結(jié)果，團隊的全部業(yè)務(wù)線條上線實施不到一半，時間跨度也不到5個月，而數(shù)據(jù)庫產(chǎn)生的歷史價格數(shù)據(jù)量已經(jīng)超千萬級別！假以時日，要面對多少無效數(shù)據(jù)的存儲、cpu每次要過濾多少噪音數(shù)據(jù)，不敢想象啊。

但凡沒這么離譜，我都不會每次閃念這個事情時 就想問一問當(dāng)時的開發(fā)者，豆腐腦兒？？后來一次線上問題，當(dāng)時就覺得這個實現(xiàn)邏輯也太奇葩了吧，為了吃豬肉非得弄個豬圈嗎？

終于一次迭代有精力來親手整理這塊，重新梳理之后，發(fā)現(xiàn)這個鍋真不能給開發(fā)者來背。

當(dāng)初產(chǎn)品第一版的該模塊的底層邏輯不清晰、對象缺乏抽象，從根本上導(dǎo)致一手產(chǎn)品、一手開發(fā)者、一手測試工程師壓根兒就沒明白清晰實現(xiàn)模型怎么和業(yè)務(wù)模型（也就是用戶的心理模型），通過產(chǎn)品模型進行有效而平滑的對接。

于是花費一個小時迅速對原來的邏輯進行梳理，并重新抽象了這個模塊的幾個對象和簡單的數(shù)據(jù)流。

第二天和一位開發(fā)leader一碰頭，大家不約而同，然后根據(jù)資源情況，迅速進行開發(fā)、測試、上線。

Bingo！

到這里我們明白產(chǎn)品文檔的用戶有哪些、以及看到產(chǎn)品文檔在實戰(zhàn)中會起到的作用實例。在之前文章《??產(chǎn)品問題剖析實例及文檔缺失的思考與應(yīng)對》中也討論過2個問題：

1?? 消失的產(chǎn)品設(shè)計/技術(shù)文檔

2?? 為什么重要的東西不見了？

也可以清楚認(rèn)識到文檔的重要性。

但是切記：文檔終歸還是手段，而不是目的。

二、產(chǎn)品經(jīng)理：畫原型、寫文檔是最簡單的好吧！

產(chǎn)品經(jīng)理原型設(shè)計產(chǎn)出的基礎(chǔ)一定是：有了明確的路徑方向、合理的底層架構(gòu)建設(shè)、核心能力抽象、資源排布，到了原型輸出階段，簡單點的可以看作是給機器人添加皮膚。

如果一個產(chǎn)品經(jīng)理沒有需求的透徹分析、沒有清晰的產(chǎn)品/功能定位、演進路徑，甚至連關(guān)鍵的核心矛盾和訴求是否明確都沒有，就開始糾結(jié)交互、表現(xiàn)層的東西，去由表及里或者說是只看到了冰山一角（連冰山上都沒有看全），這絕對是一場事故。

原型-功能價值評價-底層邏輯-數(shù)據(jù)建模-系統(tǒng)生態(tài)，數(shù)據(jù)是血液、產(chǎn)品更是血肉之驅(qū)+靈魂大腦（這里是包含了策略、算法范疇的概念）。

面由心生，一個產(chǎn)品也是一樣，長什么樣子是由我們想做什么、能做什么、怎么看待什么決定的。為什么這樣想、做、看，又是由我們自身的資源、能力決定的，再往下又是由我們的核心驅(qū)動決定的。

數(shù)字世界的數(shù)據(jù)冷冰的擺在那里，意義是被有意識的人、組織所賦予的，場景功能是實現(xiàn)意義的路徑。宏觀的視野里面，大家各有各的生態(tài)位置，中觀的網(wǎng)絡(luò)中大家彼此關(guān)聯(lián)、依賴、影響，微觀的實現(xiàn)上都朝向核心目標(biāo)和意義。

三、產(chǎn)品經(jīng)理文檔操刀技巧：讓文檔內(nèi)容活起來

文檔在團隊協(xié)作中起著重要的協(xié)同作用，如果你的團隊分工明確、存在網(wǎng)絡(luò)狀協(xié)同場景的話。上述背景下，一份活著的知識圖譜絕對是工作中的得力助手。

在文檔之前一個產(chǎn)品經(jīng)理已經(jīng)完成了產(chǎn)品概念、需求check、方案框架的論證，相信不會真的有人把畫原型當(dāng)作畫布來創(chuàng)作吧（如果是，那可能也只是在細節(jié)的框架、表現(xiàn)層的東西罷了）。

對于產(chǎn)品文檔的用戶也如本文第一部分總結(jié)：研發(fā)、測試、運維、安全、甚至于項目、boss都是用戶。而對于文檔來說，就像需求、代碼一樣，不發(fā)生更新？？不發(fā)生變更？沒有bug？這幾乎是不可能的事情，沒有一個產(chǎn)品設(shè)計文檔是可以直接拿出來就實戰(zhàn)開干的。

經(jīng)常遇到文檔里面相似的功能描述、或者邏輯復(fù)用描述，有時候為了既視感，會復(fù)制粘貼同樣內(nèi)容到不同的頁面、模塊，這樣一來造成個嚴(yán)重的問題就是無法保證各處的一致性。

復(fù)制簡直是魔鬼，我當(dāng)然也吃過因為復(fù)制粘貼的虧，開發(fā)者會認(rèn)為這是你的有意為之（如果出現(xiàn)相似對象，但是更新不一致導(dǎo)致的邏輯/實現(xiàn)差異），我們不能寄希望于每一個開發(fā)者都可以主動的發(fā)現(xiàn)并提出這些問題，我確實遇到過負(fù)責(zé)任的前后端開發(fā)主動反饋的，但這一定不能成為一個產(chǎn)品經(jīng)理不關(guān)注該問題的借口。

產(chǎn)品經(jīng)理理應(yīng)思考如何抽象、提取成為公共的內(nèi)容，甚至于描述的超鏈接。而我在實戰(zhàn)中，通常采用的是提取公共頁面、公共邏輯——并且命名它、公共的外鏈——可以基于外鏈更加方便的工具進行更新，這樣研發(fā)過程中的核心用戶就可以始終看到最新的內(nèi)容。

比如：

• 需要沉淀到團隊知識的梳理內(nèi)容——使用Wiki來記錄并鏈接到原型文檔
• 需要對應(yīng)線上救火的方案——一定會鏈接原始的問題看板事項，確保未來可以知道事件的背景
• 表格類別的梳理——如果是需要協(xié)作的，可以采用企業(yè)微信的在線表格作為外鏈（當(dāng)然可能你的團隊使用飛書、釘釘）
• 流程圖——目前接觸到的原型工具畫流程圖實在拉跨，我的習(xí)慣是在專門的在線流程站繪制后貼圖+鏈接到設(shè)計文檔，一定會在超鏈接上寫一句話，點擊鏈接可以查看最新的內(nèi)容。

當(dāng)然類似的還有很多，我們的目標(biāo)是盡可能提供一份邏輯完整、嚴(yán)密明了、沒有錯誤的文檔給到“用戶”，并使之能夠快速有效的理解。