36node 团队产品经理招聘
按劳分配和面向交付是冒险者公会秉承的基础原则，产品经理的劳动输出现阶段定义为：原型设计稿，用户故事，产品文档和设计稿，后续这些评估工作会逐步在冒险者平台中体现，使得劳动和分配自动化。36node 团队是冒险者公会的缔造者，我们团队会接一些有标杆性的项目，为冒险者公会的建设提供素材。36node 团队产品经理岗位（ PM ）招聘要求如下：
1. 工作内容
产品工作以里程碑-迭代的方式推进，每个里程碑包含若干迭代，里程碑开始前需要完成所有里程碑产品设计工作，开发周期迭代开始后产品需要负责推进，因此产品工作内容包括以下两点：
- 产品系统设计
- 产品迭代推进
1.1 产品系统设计
里程碑开始前产品人员通过前期客户接洽，收集客户系统需求，能够通过前期沟通获取需求文档中的系统要点，从产品角度快速的分析并定义系统功能点，给出初步的原型图和故事草稿列表（可以仅标题，冒险者公会支持创建故事草稿）；评估后续细化产品设计所需要的时间，以文档的形式向项目 PO 汇报（原型图和产品设计时间后续会陆续做到平台中）。产品设计周期结束需要输出的内容应该包括：
1. 用户故事——完善故事草稿并由领取的 Code Manager 转换而成
2. 产品文档——基于用户故事涉及到的功能点，覆盖完整的产品逻辑
3. 设计稿——如果用户对设计稿要求很高，可以酌情外包给设计师。否则可以由产品输出并酌情计入产品设计时间
产品设计周期要求每天和客户线上视频讨论需求，讨论内容基础应包括：完整的原型稿，已经完善的故事草稿和整理好的部分产品文档。用户故事和产品文档需要按照迭代的方式逐步生成，直到用户，产品和技术对系统的需求和所有内容不再有疑议，再以原型稿，产品文档为基础做统一做设计稿输出。
1.2 产品迭代推进
开发迭代开始后，产品需要组织迭代会议（一般每周一次），前期设计的用户故事（ story ）添加到迭代并负责推进验收，一般的流程是：Code Manager 发布用户故事-Code Manager 代码验收-PM 用户故事验收。验收主要是针对用户故事中提到的验收点和产品文档中涉及的逻辑做正面的功能验收。
2. 报酬形式
- 产品系统设计：以天为单位进行结算
按照前期接洽，得到客户认可的设计周期进行计费，如果与后期实际工作时间有偏差，在得到客户认可的情况下可以酌情调整。一般的计费方式为：设计单价*天数。
- 产品迭代推进：按照用户故事（ story ）/ 缺陷（ bug ）为单位进行结算
产品设计周期输出的用户故事、迭代过程中新增用户故事以及发现的缺陷，一般计费方式为：推进单价*发布的 story/bug 个数。
3. 工作时间
36node 团队是全远程工作，不需要打卡上班，系统设计和迭代推进工作的时间由项目和产品经理双向沟通和选择，因此适合有自主掌控权和能够合理安排时间高效工作的产品人员。由于产品是面向客户和整个开发团队，因此在项目推进期间，沟通工作的时间会比较零碎，可能占据周末或者晚上的时间。
4. 招聘要求
36node 团队为全远程办公团队，同步沟通成本高，因此对文档要求比较高，产品经理除了需要相关产品经验，系统理解和分析构建能力，更需要很强的图文输出能力，包括原型设计稿，用户故事和产品文档，都是后续开发的基础，同时也能帮助客户梳理和对齐需求，达成沟通理解一致。
感兴趣的同学可以发送简历到邮箱： [email protected]
更多资料可以参考 https://adventurer.feishu.cn/wiki/V95awvafGim4WUkbEQscVixlnwh?from=from_copylink
按劳分配和面向交付是冒险者公会秉承的基础原则，产品经理的劳动输出现阶段定义为：原型设计稿，用户故事，产品文档和设计稿，后续这些评估工作会逐步在冒险者平台中体现，使得劳动和分配自动化。36node 团队是冒险者公会的缔造者，我们团队会接一些有标杆性的项目，为冒险者公会的建设提供素材。36node 团队产品经理岗位（ PM ）招聘要求如下：
1. 工作内容
产品工作以里程碑-迭代的方式推进，每个里程碑包含若干迭代，里程碑开始前需要完成所有里程碑产品设计工作，开发周期迭代开始后产品需要负责推进，因此产品工作内容包括以下两点：
- 产品系统设计
- 产品迭代推进
1.1 产品系统设计
里程碑开始前产品人员通过前期客户接洽，收集客户系统需求，能够通过前期沟通获取需求文档中的系统要点，从产品角度快速的分析并定义系统功能点，给出初步的原型图和故事草稿列表（可以仅标题，冒险者公会支持创建故事草稿）；评估后续细化产品设计所需要的时间，以文档的形式向项目 PO 汇报（原型图和产品设计时间后续会陆续做到平台中）。产品设计周期结束需要输出的内容应该包括：
1. 用户故事——完善故事草稿并由领取的 Code Manager 转换而成
2. 产品文档——基于用户故事涉及到的功能点，覆盖完整的产品逻辑
3. 设计稿——如果用户对设计稿要求很高，可以酌情外包给设计师。否则可以由产品输出并酌情计入产品设计时间
产品设计周期要求每天和客户线上视频讨论需求，讨论内容基础应包括：完整的原型稿，已经完善的故事草稿和整理好的部分产品文档。用户故事和产品文档需要按照迭代的方式逐步生成，直到用户，产品和技术对系统的需求和所有内容不再有疑议，再以原型稿，产品文档为基础做统一做设计稿输出。
1.2 产品迭代推进
开发迭代开始后，产品需要组织迭代会议（一般每周一次），前期设计的用户故事（ story ）添加到迭代并负责推进验收，一般的流程是：Code Manager 发布用户故事-Code Manager 代码验收-PM 用户故事验收。验收主要是针对用户故事中提到的验收点和产品文档中涉及的逻辑做正面的功能验收。
2. 报酬形式
- 产品系统设计：以天为单位进行结算
按照前期接洽，得到客户认可的设计周期进行计费，如果与后期实际工作时间有偏差，在得到客户认可的情况下可以酌情调整。一般的计费方式为：设计单价*天数。
- 产品迭代推进：按照用户故事（ story ）/ 缺陷（ bug ）为单位进行结算
产品设计周期输出的用户故事、迭代过程中新增用户故事以及发现的缺陷，一般计费方式为：推进单价*发布的 story/bug 个数。
3. 工作时间
36node 团队是全远程工作，不需要打卡上班，系统设计和迭代推进工作的时间由项目和产品经理双向沟通和选择，因此适合有自主掌控权和能够合理安排时间高效工作的产品人员。由于产品是面向客户和整个开发团队，因此在项目推进期间，沟通工作的时间会比较零碎，可能占据周末或者晚上的时间。
4. 招聘要求
36node 团队为全远程办公团队，同步沟通成本高，因此对文档要求比较高，产品经理除了需要相关产品经验，系统理解和分析构建能力，更需要很强的图文输出能力，包括原型设计稿，用户故事和产品文档，都是后续开发的基础，同时也能帮助客户梳理和对齐需求，达成沟通理解一致。
感兴趣的同学可以发送简历到邮箱： [email protected]
更多资料可以参考 https://adventurer.feishu.cn/wiki/V95awvafGim4WUkbEQscVixlnwh?from=from_copylink
目前尚无回复
Select Language