中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

一、產品設計實例，誰說產品經理只為用戶負責？

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

2、開發者、測試者消費前期產品概念、產品原型、設計方案，完成數據構建+邏輯實現；

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

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

到達了開發階段之后，實現模型就走向了真的是“供應商維度”，一商品對多供應商底層關系+任一商品檔案更新都按供應商維度觸發下屬全量商品價格的更新邏輯，前述邏輯的結果就是每次更新都會產生大量的冗余數據。

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

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

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

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

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

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

Bingo！

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

1?? 消失的產品設計/技術文檔

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

也可以清楚認識到文檔的重要性。

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

二、產品經理：畫原型、寫文檔是最簡單的好吧！

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

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

原型-功能價值評價-底層邏輯-數據建模-系統生態，數據是血液、產品更是血肉之驅+靈魂大腦（這里是包含了策略、算法范疇的概念）。

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

數字世界的數據冷冰的擺在那里，意義是被有意識的人、組織所賦予的，場景功能是實現意義的路徑。宏觀的視野里面，大家各有各的生態位置，中觀的網絡中大家彼此關聯、依賴、影響，微觀的實現上都朝向核心目標和意義。

三、產品經理文檔操刀技巧：讓文檔內容活起來

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

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

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

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

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

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

比如：

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

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