当前位置:首页 > 家装 > 装修设计 > 文章正文

若何精确对待产品文档治理?

编辑:[db:作者] 时间:2024-08-25 08:36:09

2、开拓者、测试者消费前期产品观点、产品原型、设计方案,完成数据构建+逻辑实现;

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

若何精确对待产品文档治理?

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

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

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

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

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

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

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

第二天和一位开拓leader一碰头,大家不谋而合,然后根据资源情形,迅速进行开拓、测试、上线。

Bingo!

到这里我们明白产品文档的用户有哪些、以及看到产品文档在实战中会起到的浸染实例。
在之前文章《产品问题阐发实例及文档缺失落的思考与应对》中也谈论过2个问题:

1️⃣ 消逝的产品设计/技能文档

2️⃣ 为什么主要的东西不见了?

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

但是牢记:文档终归还是手段,而不是目的。

二、产品经理:画原型、写文档是最大略的好吧!

产品经理原型设计产出的根本一定是:有了明确的路径方向、合理的底层架构培植、核心能力抽象、资源排布,到了原型输出阶段,大略点的可以看作是给机器人添加皮肤。

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

原型-功能代价评价-底层逻辑-数据建模-系统生态,数据是血液、产品更是血肉之驱+灵魂大脑(这里是包含了策略、算法范畴的观点)。

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

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

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

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

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

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

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

复制切实其实是妖怪,我当然也吃过由于复制粘贴的亏,开拓者会认为这是你的故意为之(如果涌现相似工具,但是更新不一致导致的逻辑/实现差异),我们不能寄希望于每一个开拓者都可以主动的创造并提出这些问题,我确实碰着过负任务的前后端开拓主动反馈的,但这一定不能成为一个产品经理不关注该问题的借口。

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

比如:

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

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

本文由 @Kris_3zzz 原创发布于大家都是产品经理。
未经作者容许,禁止转载

题图来自 Unsplash,基于CC0协议

该文不雅观点仅代表作者本人,大家都是产品经理平台仅供应信息存储空间做事

本站所发布的文字与图片素材为非商业目的改编或整理,版权归原作者所有,如侵权或涉及违法,请联系我们删除,如需转载请保留原文地址:http://www.baanla.com/lz/zxsj/198242.html

XML地图 | 自定链接

Copyright 2005-20203 www.baidu.com 版权所有 | 琼ICP备2023011765号-4 | 统计代码

声明:本站所有内容均只可用于学习参考,信息与图片素材来源于互联网,如内容侵权与违规,请与本站联系,将在三个工作日内处理,联系邮箱:123456789@qq.com