认领task的同学，前期可能并没有深入参与讨论和思考。task分配了，才开始发起一些很底层的讨论。意味着co-build基础不牢固，可能需要反复沟通，影响整体协作节奏。 不想回到中心化的方式，但也感觉后续有必要约束一下。有阶段性关门时间，讨论过的需求确定后不可以轻易挑战，极个别不修改会导致严重后果的除外。
我感觉来参加核心任务认领的 必须得参加上一次的会
明天周会说一下这个事情 尽管有点晚了 但还来得及 有必要的话 可以再讨论一次poap v2底层逻辑，再关门。
| 阶段 | 人员范围 | 产出 | |
|---|---|---|---|
| 需求搜集/讨论 | 社区成员 | 需求搜集大讨论page | |
| 提出方案 | 产品公会core member | 一个或多个方案 | |
| 方案讨论 | 产品公会成员 | 选定一个方案，或多个方案结合。 | |
| 确认connector | |||
| 拆分task | connector | 将整体方案拆分成多个具体产品设计任务 | |
| task认领 | 1. 需获得产品公会PM身份(积分要求？) |
@Adazz ： 推荐 @JIX 分享figma协作体验，负责原型协作规范
@JIX 其实我觉得这还蛮难的，如果是设计团队的话可以用非常体系化的方式去制定协作和设计规范，但产品团队可能不好像设计那样用这么专业的方式去做，毕竟原型只是产品的附属能力之一，它和设计稿承担的作用也完全不一样， 我可以试着找到一个平衡点，既能让大家形成某种程度的规范，又不会破坏大家的创造力，以及尊重专攻不同领域的PM在原型设计上的差异，
Onboard新人的时候常常遇到新人反映”不确定怎么参与“、”不敢参与“、”先观望“的状况，可不可以在项目里开放类似“见习PM”的位置，配合认领task的主PM做一些小任务，形成以mentorship方式帮助新人融入的产品创造的流程。
@Adazz