从产品感知层见底层资源构建；
从产品设计方案见一代产品经理心路历程；
就差告诉程序员怎么写代码了！！！
一个没有人敢动手的线上问题
2023年8月的一个工作日 ，被一个产品（支撑供应链采购业务的算法系统）线上问题闹得哭笑不得。
五手开发说自己没有改过，还说看过这里的代码逻辑复杂，说程序逻辑存在现状本就会导致问题。可是，就是不知道问题出在哪里？（搁谁身上不来气就算你赢）
消失的产品设计/技术文档
怀念一手开发、一手测试，可惜走的走、散的散，就连产品团队自己也不清楚了。另外一个现状就是，作为算法产品，其实有很多逻辑构建+数据构建的模型存在，这两部分从领域划分上其实要算到开发、技术团队，但是开发/技术团队向来不喜欢做文档沉淀的，而这个过程产品团队没有同步参与对齐，自然在产品相关的过程文档中也看不到丝毫的踪迹。最重要的结果就是，现在已经没有人能够说得清楚当时的逻辑到底是什么，也没有文档可以翻出来查看。
看清产品：由表及里，从里至外
无奈作为这个产品的四手产品经理（1.0版本已经是四五年前的事情了，负责的产品经理换了好几个），只好从产品的感知层开始（看交互界面的信息结构设计、往下再看结构层的业务逻辑）一层一层往下推测勾勒数据结构，然后和数据库进行假设验证（拿到数据库的查询权限，在测试环境验证上层的逻辑和数据的过程对应），确保推演逻辑没问题。费老大力气，终于勾勒出来产品核心对象的大致数据结构和关联，几个关键对象怎么构建、更新，自然也就标定出来了问题点对象。
但是面对五手开发，程序员自己对代码逻辑毕竟不熟悉，结果依然是：不敢动！
好在又翻到历史一次上线记录出来，以前不是动过这里一次嘛！（上一次改动这个地方是这个程序员改的）轻车熟路，再来一次。这下开发有了信心，搞定✌️
为什么重要的东西却不见了？
往往面对上述这种历史问题，处理过程中是非常依赖到过去的文档的，但正如上文所说，文档往往也稀释掉了很多冰山下内容：比如核心对象的核心数据如何构建？比如关联对象间的数据关联和更新逻辑？等等。虽然偏技术范畴，但个人认为和产品设计文档能够结合在一起的话，对于一个敏捷团队来说绝对是功在千秋、利在当代。
至于为什么会出现产品技术文档、设计文档的内容缺失，个人认为有两个方面可以去尝试思考：
第一点是个人习惯问题，不排除负责某个产品的产品经理和开发者，包括测试大家对所有细节都了然于胸，但是却没有人愿意去把这些内容用文字、用流程图，甚至用一个简单的图形的方式沉淀记录下来；
第二点就是作为产品文档的维护者、设计者可能根本没有意识到、没有参与到、或者说没有思考到当然也不会介入到产品底层的数据和关键对象的构建逻辑。这就一定会为未来产品也在维护过程中埋下隐患，造成业务团队、产品团队和开发团队之间的脱节。这种脱节往往会可能直接影响到业务，打破敏捷的这种开发节奏，增加大家的沟通、协作成本，影响到其他项目项目的一些正常进度，更为可怕的是，打击产品相关人员的信心，导致没有人愿意或者敢去介入动这个产品，包括未来的升级，那么所有人都会倾向于找到时机，重新投入资源去重构这个产品，可我们明明知道 这无疑就是资源的浪费。
如何正确对待产品文档管理？
关于文档的管理可以参考之前两部分的分享：
1、明白文档的用户有哪些：产品设计实例，谁说产品经理只为用户负责？
2、文档的日常管理技巧：产品经理文档操刀技巧：让文档内容活起来
—————-（手动分割线）—————-
题外话，往往我们透过文档，看一份文档的写作风格、逻辑表述、与关键技术实现互为支撑的要求与预留，其实也窥探一二文档创作者当时的心路历程，妙不可言。
