技能介绍

产研运为什么总对不齐

成长期产品里，「追新功能 vs 搁置用户反馈」「研发路线 vs 运营诉求」「快发版 vs 技术债」往往同时存在，根因通常是：没有统一优先级机制、缺少共同商业化目标、产品阶段判断不清。文档强调一切面向商业化服务，并把用户反馈与产品需求放进同一套标签与池子，而不是各团队各记一摊。

技能里有什么、怎么用

安装后得到的是一套可直接替换占位符（[产品名称] / [项目代号]）的协同框架，核心包括：

两层看板：总 backlog 收拢所有来源的 Issue，再流入带目标描述的迭代看板。
Issue 录入模板：要求可复现步骤、影响评估与标签；同一问题被反馈 3 次以上自动打 severe，最近一个迭代必须处理。
10 天迭代节奏：第 6 天交付可测版本、运营半天内测并出报告，第 7 天产研运对齐范围，第 10 天发布；并明确避免周五/周末发版。
会议机制：每日 15 分钟站会（运营通报投诉热点）、迭代规划/验收会，以及月度 Review。
运营角色：Bug 初筛、优先级建议、验收测试与发布物料；对影响体验或付费转化的 P0 可提议推迟发版。
附录模板：Bug Report、迭代规划会，以及产研运职责边界表。

此外还覆盖内测用户访谈结构、商业化链路指标（获取→激活→留存→付费→推荐）、技术债触发信号与 50/60–20/30–20/30 资源分配建议。

适用边界

这是流程与模板 SOP，不替代你们自己的项目管理工具选型（文档推荐 Linear/Jira/飞书等，需自行落地）。Feature Request 须先进总池并由产品出方案后才能进迭代；重构建议单独建 Project、与常规范迭代并行。团队若无法接受「运营对发版的一票否决」或固定 10 天节奏，需要按阶段表（PMF 1–2 周、增长期 3–4 周等）自行调整，而不是生搬硬套。