缘起

认领task的同学，前期可能并没有深入参与讨论和思考。task分配了，才开始发起一些很底层的讨论。意味着co-build基础不牢固，可能需要反复沟通，影响整体协作节奏。 不想回到中心化的方式，但也感觉后续有必要约束一下。有阶段性关门时间，讨论过的需求确定后不可以轻易挑战，极个别不修改会导致严重后果的除外。

我感觉来参加核心任务认领的 必须得参加上一次的会

明天周会说一下这个事情 尽管有点晚了 但还来得及 有必要的话 可以再讨论一次poap v2底层逻辑，再关门。

提议

1. 产品流程：

2. 有参与“方案讨论” | 确认task交付标准和时间 | | | task build | 认领task的PM、connector | 沟通过程沉淀在notion | 1.推荐异步沟通，必要时发起临时会议 2.周会同步 | | task验收 | connector、core member | task初步验收(线框图/PRD) | | | PRD文档协作 | 认领task的PM | 完善PRD准备交付 | | | 后续流程跟进 | 认领task的PM | 配合UX UI RD QA.. | |

@Adazz ： 推荐 @J 分享figma协作体验，负责原型协作规范

@J 其实我觉得这还蛮难的，如果是设计团队的话可以用非常体系化的方式去制定协作和设计规范，但产品团队可能不好像设计那样用这么专业的方式去做，毕竟原型只是产品的附属能力之一，它和设计稿承担的作用也完全不一样， 我可以试着找到一个平衡点，既能让大家形成某种程度的规范，又不会破坏大家的创造力，以及尊重专攻不同领域的PM在原型设计上的差异，

• 一是在Figma里做个组件库，后续我会从大家的原型中抽离出一些通用性比较强的组件（导航/表单/表格/弹窗/标注等等），自己去按照某种规范重新画一遍，在Figma中创建成组件，大家后续做图时可以在[Assets]中选取组件，直接拿着现成的用，每做完一个版本就沉淀一些，磨合几个版本组件库就能有个雏形，组件库会主要集中在本身规范性就很强的B端，C端比较灵活，组件用得多可能会限制大家的想象力；
• 二是在组件库的基础上会有一个简单的设计规范（由于是原型，只做推荐并不强制） 大概会涉及字体，字号大小，画布大小，画布命名规范等等；
• 三是考虑到很多PM可能对Figma不熟悉，组件的创建/使用方法、常用快捷键、好玩的插件等到时候也会做个介绍，如果有需求也会找些教学视频帮助大家学习（其实我figma用得也不多，只有偶尔背着公司偷偷出去干活的时候才会用，毕竟它真的很适合分布式协作）；

1. 一个题外话的提议（from 负责onboarding的 KC)

Onboard新人的时候常常遇到新人反映”不确定怎么参与“、”不敢参与“、”先观望“的状况，可不可以在项目里开放类似“见习PM”的位置，配合认领task的主PM做一些小任务，形成以mentorship方式帮助新人融入的产品创造的流程。

1. 产品的负责人定期发起产品ama（from Tg）

@Adazz