如何正确对待产品文档管理？

一、产品设计实例，谁说产品经理只为用户负责？

1、用户消费交付的产品，完成自己的交易，进行价值交换；

2、开发者、测试者消费前期产品概念、产品原型、设计方案，完成数据构建 逻辑实现；

开发者、测试者同样是消费者，这个层面上来看，他们岂不也是产品经理要考虑的用户？只不过消费的内容对象、周期阶段差异。

曾经处理过一起“设计事故”（不算大，但就很抓狂），大致的产品意图是要支持用户维护一份供应商维度的商品采购成本数据，以便支撑采购业务和数据记录分析。

到达了开发阶段之后，实现模型就走向了真的是“供应商维度”，一商品对多供应商底层关系 任一商品档案更新都按供应商维度触发下属全量商品价格的更新逻辑，前述逻辑的结果就是每次更新都会产生大量的冗余数据。

结果，团队的全部业务线条上线实施不到一半，时间跨度也不到5个月，而数据库产生的历史价格数据量已经超千万级别！假以时日，要面对多少无效数据的存储、cpu每次要过滤多少噪音数据，不敢想象啊。

但凡没这么离谱，我都不会每次闪念这个事情时 就想问一问当时的开发者，豆腐脑儿？？后来一次线上问题，当时就觉得这个实现逻辑也太奇葩了吧，为了吃猪肉非得弄个猪圈吗？

终于一次迭代有精力来亲手整理这块，重新梳理之后，发现这个锅真不能给开发者来背。

当初产品第一版的该模块的底层逻辑不清晰、对象缺乏抽象，从根本上导致一手产品、一手开发者、一手测试工程师压根儿就没明白清晰实现模型怎么和业务模型（也就是用户的心理模型），通过产品模型进行有效而平滑的对接。

于是花费一个小时迅速对原来的逻辑进行梳理，并重新抽象了这个模块的几个对象和简单的数据流。

第二天和一位开发leader一碰头，大家不约而同，然后根据资源情况，迅速进行开发、测试、上线。

Bingo！

到这里我们明白产品文档的用户有哪些、以及看到产品文档在实战中会起到的作用实例。在之前文章《🔍产品问题剖析实例及文档缺失的思考与应对》中也讨论过2个问题：

1️⃣ 消失的产品设计/技术文档

2️⃣ 为什么重要的东西不见了？

也可以清楚认识到文档的重要性。

但是切记：文档终归还是手段，而不是目的。

二、产品经理：画原型、写文档是最简单的好吧！

产品经理原型设计产出的基础一定是：有了明确的路径方向、合理的底层架构建设、核心能力抽象、资源排布，到了原型输出阶段，简单点的可以看作是给机器人添加皮肤。

如果一个产品经理没有需求的透彻分析、没有清晰的产品/功能定位、演进路径，甚至连关键的核心矛盾和诉求是否明确都没有，就开始纠结交互、表现层的东西，去由表及里或者说是只看到了冰山一角（连冰山上都没有看全），这绝对是一场事故。

原型-功能价值评价-底层逻辑-数据建模-系统生态，数据是血液、产品更是血肉之驱 灵魂大脑（这里是包含了策略、算法范畴的概念）。

面由心生，一个产品也是一样，长什么样子是由我们想做什么、能做什么、怎么看待什么决定的。为什么这样想、做、看，又是由我们自身的资源、能力决定的，再往下又是由我们的核心驱动决定的。

数字世界的数据冷冰的摆在那里，意义是被有意识的人、组织所赋予的，场景功能是实现意义的路径。宏观的视野里面，大家各有各的生态位置，中观的网络中大家彼此关联、依赖、影响，微观的实现上都朝向核心目标和意义。

三、产品经理文档操刀技巧：让文档内容活起来

文档在团队协作中起着重要的协同作用，如果你的团队分工明确、存在网络状协同场景的话。上述背景下，一份活着的知识图谱绝对是工作中的得力助手。

在文档之前一个产品经理已经完成了产品概念、需求check、方案框架的论证，相信不会真的有人把画原型当作画布来创作吧（如果是，那可能也只是在细节的框架、表现层的东西罢了）。

对于产品文档的用户也如本文第一部分总结：研发、测试、运维、安全、甚至于项目、boss都是用户。而对于文档来说，就像需求、代码一样，不发生更新？？不发生变更？没有bug？这几乎是不可能的事情，没有一个产品设计文档是可以直接拿出来就实战开干的。

经常遇到文档里面相似的功能描述、或者逻辑复用描述，有时候为了既视感，会复制粘贴同样内容到不同的页面、模块，这样一来造成个严重的问题就是无法保证各处的一致性。

复制简直是魔鬼，我当然也吃过因为复制粘贴的亏，开发者会认为这是你的有意为之（如果出现相似对象，但是更新不一致导致的逻辑/实现差异），我们不能寄希望于每一个开发者都可以主动的发现并提出这些问题，我确实遇到过负责任的前后端开发主动反馈的，但这一定不能成为一个产品经理不关注该问题的借口。

产品经理理应思考如何抽象、提取成为公共的内容，甚至于描述的超链接。而我在实战中，通常采用的是提取公共页面、公共逻辑——并且命名它、公共的外链——可以基于外链更加方便的工具进行更新，这样研发过程中的核心用户就可以始终看到最新的内容。

比如：

• 需要沉淀到团队知识的梳理内容——使用Wiki来记录并链接到原型文档
• 需要对应线上救火的方案——一定会链接原始的问题看板事项，确保未来可以知道事件的背景
• 表格类别的梳理——如果是需要协作的，可以采用企业微信的在线表格作为外链（当然可能你的团队使用飞书、钉钉）
• 流程图——目前接触到的原型工具画流程图实在拉跨，我的习惯是在专门的在线流程站绘制后贴图 链接到设计文档，一定会在超链接上写一句话，点击链接可以查看最新的内容。

当然类似的还有很多，我们的目标是尽可能提供一份逻辑完整、严密明了、没有错误的文档给到“用户”，并使之能够快速有效的理解。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！