有朋友正在转型，从乙方商业化产品的交付经理转向新公司的产品经理。原本得心应手的思维方式和工作习惯，遇到了巨大挑战。以前只需依据已有产品的功能出解决方案，能做就能做，不能实现就是不能实现，到某个时间交付什么功能很明确，考核是以交付签字为准。现在需要面对各方需求，自己想明白用户真正的问题是什么，最终要交付的价值是什么，没有一个实体的谁来签字，只有不断地迭代。

借鉴领域驱动设计，可以采用以下方法。简单描述的话，是一个点、一个圈再加一个箭头线，是不是有点像丘比特？

一个点，指的是用户核心价值。这是最关键的一条，基本上只能靠自己想明白。想，不是闭门造车式的苦思冥想，可以是已有的领域经验，可以从书本中学习，可以是大家的各种吐槽，可以是自己从旁边观察用户的实践，还可以是自己变身为用户的实践。有些人会纠结点想的对不对，迟迟不敢动手。其实一开始想得对不对不是那么重要，关键是要有这点，然后快速到市场上验证，根据反馈再调整。

一个圈，指的是围绕核心价值划出的范围，即领域驱动设计中的限界上下文。产品经理面临的一个现实是，各种人都会给你提需求，只要他们觉得和你有关，还时不时来问什么时候可以实现。需求轰炸之下很容易焦虑，不光自己焦虑，所有的利益相关者都会焦虑。依据核心价值，框出需求范围，在和各方交流过程中可以有一种确定性，减少焦虑，利于行动。大家（不光是研发团队，也包括其他需求方）就能明白，哪些和当前核心价值密切相关我们优先考虑；哪些与核心价值有关但它不在我们的范围内，属于其他团队需要他们协助；哪些有关系，但目前没想清楚价值大不大并且代价可能很高建议先搁置。范围不是一成不变，它随着时间会发生变动，所以我们不要追求固定，只要保证在某个时间段内，大家一致认同即可。

一个箭头，指的是实现路径，箭头指向核心目标（核心价值）。目标（核心价值）和范围描绘的是终极，而从现实到终极还有很多路要走，可能的路径还有很多条。我们需要琢磨怎么走更稳当，怎么走代价比较低，路上关键的里程碑是什么。路径对不对其次，重要的是思考过程，可以把关键点需要交付的价值、需要支持的资源等等梳理清楚。

以上

产品文档缺失，文档缺失，代码日志也没有，更不说单元测试没有。代码结构混乱，到处都有相同业务的特殊逻辑。原始架构依稀可见但早已面目全非。

更要命的事产品经理离职，剩下一些只言片语的PRD。和其他兄弟部门的对接报文，只能扣代码😂

解决：1.先加日志和性能监控
2.整理流程图（参考代码，PRD以及仅有的几个元老同事口述）
3.适度重构
4.重写系统。搞清业务边界，有序整理分类合并业务入口，优化程序处理流程以及性能。

在此过程还在接新需求