认同一个说法,先证明能填坑,再挖自己的坑。加入新司的第一个产品,引用技术的评价,是个神坑,贡献了团队一半的bug。此外,2.0版本处于开发阶段,交接人即将离职。这种情况往往方案存在问题,遗漏较多待确认项。可以理解,即将离职,心思难免不在这了,PRD需要极度细心,主动与所有相关方对齐。换做我,也无法维持预期的质量。
所幸开发团队十分nice,讲不清的逻辑,大不了可以请技术看代码。接手后,按照以下内容进行梳理
-
系统定时任务
-
用户反馈/用研资料
-
产品架构
-
业务数据含义
-
数据流
-
问题梳理
-
状态机图
-
埋点数据/分析报告
-
业务/产品分享
-
竞品分析
-
需求规划