针对于第三方对接，记录自己给自己挖的坑。
现在的情形仍然是这种情况，针对于这种情况，解决办法只能是遇到问题，解决问题，解决不了的，相对解决问题。
第一次自己负责项目的时候...
产品经理坑ing....
K1.在做产品（需要第三方对接）的时候没有详细看接口文档
做法：当时由于什么都不知道，就直接参照竞品的字段进行设计了，导致了开发实际在过流程阶段，数据大量缺失，逻辑有问题。
后果：整天慌慌张张，匆匆忙忙的解决问题，只针对问题解决问题，没有提前预见，说话也不硬气，哈哈哈~
K2.异常流：数据获取不到时候的情况
异常流原则：重要的字段，看影响范围，范围不大，可以设置为空
异常流解决方案：遇到数据获取不到的情况，要提前设想解决方案，针对于普通字段，判断是否重要，不是特别重要的话，可以设置为空，如果重要的话，可以让用户重新查询
K3.字段定义没有一个文档去管理
问题：没有统一一个文档去管理，责任划分不开、不能清晰明确的复盘
解决方案：通过文档去管理，文档模板可以在网上找，也可以自己写，随着自己的需要，逐渐增加字段，自己可以更好的理解
K4.原型（页面、字段、交互）的更改没有变更记录
后果：
原型没有变更记录，导致了团队成员间的信息不对称，做出来之后才发现工作成果是无效的
无法甩锅，因为时间过了好久了，自己都不知道当时说的是啥，尴尬了
这也不是一个好的习惯，自己对项目没有一个完成的把控
自己心虚，没法做复盘，进步看不见（所有的东西就只剩的“终板”）
没法输出（没法记住所有的细节）
K5.原型画的垃圾（需求文档描述不清楚）
后果：在开发的过程中会遇到各种各样的问题，导致了需求会更“轻易”的变动，在需求评审过后，正常情况下，就不会在变更需求了，如果发生上述情况时，你也左右不了
K6.工作中未定短时规划
后果：没有短时的规划，可能会造成突然不知道要做什么事情了，有造成了慌张，每做一件事情就是为了把工作做好，做的事情全部都在自己把控中
k7.流程或逻辑有问题
后果：后果真的是太大了，更改需求会使项目的工期大大的延长，并且也有了甩锅的理由，所有的锅都变成了产品经理自己的，很难受，在大厂如果发生这种情况的话，那问题就更大了，可能会引起被迫辞职的后果，所以，为了避免发生这种情况，那就在设计好了之后，如果是数据字段展示，那就依据接口文档，把每一个数据自己跑一遍，让自己心里有一个预期，如果是流程性的业务，那就把自己当做一个普通用户进行测试，查看所有流程是否能走通，一切的行为都是为了让产品更好的出生。
