产品部门工作手册

产品部门工作手册产品部门工作手册 v1 0 部部门门工作目工作目标标 创客星球产品部门的主要工作目标是在充分调研 考察市场发展环境和趋势 了解公司资源及人力部署情况的前提下 提供符合公司利益的产品方案并促使 方案顺利落地执行 阶段性地解决用户和公司的需求 工作流程工作流程说说明明 产产品品调调研研 在需求未定或者需求还不是非常清晰的情况下 需要针对产品形态和方向进行 产品调研 调研步骤如下 1 找需求提出方充分了解清楚问题所在和核心诉求 2 竞品调研 找在这方面做得好的和不好的竞品进行研究 总结优势和劣势 3 需求可行性调研 和技术人员沟通讨论需求可行性 产产品立品立项项 原型原型 产品调研结束后 将根据调研结果对产品进行立项 该环节具体的工作方式如下 1 和需求方讨论 提取核心需求并确定需求实现方案 将对产品设计的构想按照 模版写成产品功能需求清单 2 需要用可被理解的方式 草图 原型 截图 配合产品功能需求清单和 UI 设计 师沟通产品效果图设计需求 UI 设计设计 交互交互设计设计 在该环节根据一定的 UI 设计原则进行产品整体的 UI 界面设计 需要考虑需求 功能实现和其他的例如断网 缺省 数据刷新等关系到人机交互体验的页面设计 和动效设计 该环节最终结果的呈现方式是 UI 效果图 高保真原型 UI 效果效果图验图验收收 1 使用 UI 效果图 高保真原型 产品功能清单进行跨部门讨论 务必使所有和 产品功能相关的人员清楚明白地了解产品最终效果和功能点 并开会讨论优化 修改建议 2 使用 UI 效果图 高保真原型 产品功能清单进行技术研讨会 务必使所有相 关开发人员充分了解产品功能点 实现程度 需求优先级 从技术角度提出建 议和方案补充 3 根据讨论结果修改 UI 效果图 验收无误后进行 UI 切片并将最终效果图 加尺 寸标注 和切片群发全体开发相关人员 技技术术方案方案设计设计 排期排期 技术开发人员根据产品需求评估项目难度 针对产品功能需求清单中的内容进 行细化 补充 修改 预估开发周期 并根据需求优先级进行功能排期 针对特 定产品功能进行任务拆分 结合自身的实际情况制定开发方案 各自明确任务分 工 产产品功能开品功能开发发 开发阶段 技术开发人员需要每日更新开发进度 根据开发排期表来制定每日开 发目标并及时完成 该阶段的任何需求方面的问题以产品功能需求清单中的作 为标准 以高保真原型中的交互设计作为参考 开发过程中任何需求上存疑的地 方需要第一时间向产品经理确认 测试测试 产品功能需求开发完成后 将测试包 测试链接发送给测试人员 测试人员根据 产品功能需求清单和高保真原型进行测试 主要测试的内容包括和产品功能需 求清单中描述不符的和常见的 BUG 如 APP 黑屏闪退等 最后所有的测试结果 汇总到 BUGLIST 中 技术开发人员根据 BUGLIST 中列出的问题按优先级逐一 解决 BUG 产产品打磨品打磨 验验收收 产品打磨阶段主要用于在当前产品的基础上提出一些优化产品体验的细节 让 产品的用户体验更棒 这里的产品打磨不是指提出新的功能需求 而是指停下新 功能的开发 花较短的时间来优化产品中的细节体验 将开发前没有直观感受到 的瑕疵修改掉 该流程一般用于重大版本的迭代中 发发布上布上线线 对于 PC 端产品 发布上线是指将测试站修改后的代码迁移到正式站上 对于客户端产品 发布上线分两个部分上线 一部分是服务端将接口代码迁移到 正式站 另外一部分是将 APP 发布到应用商店并审核上线 数据跟踪数据跟踪 迭代迭代 产品上线后 根据产品中的数据埋点监测功能使用情况和用户行为 根据数据分 析出产品中存在转化或者流程不通畅的部分 为产品迭代优化提供可靠的数据 支持 岗岗位工作位工作说说明明 产产品品经经理理 产品经理在整个团队中的主要角色和任务是确定好需求 把明确的需求交付给 UI 设计和技术开发 协同设计 开发 运营等多部门共同完成产品目标 产品调研 在进行较大的功能改动前 应该首先对该类产品做一些竞品调研 观察竞品优劣 和自家产品做对比 另外 还需要从前线运营同事处充分了解到产品存在的不足 之处和盲点 从核心用户群中了解到产品体验中的问题 将问题拆解 转化 过 滤成实际的功能需求 以需求清单的形式 如果是较小的功能需求 我们目前使用 teambition 进行需求的统一记录和管理 产品调研阶段的功能需求 统一存放在 teambition BUG 跟踪记录 需求整理 列表下 产品经理需要每周定期对该列表中的内容进行梳理 确定每周需要调研 的内容 Tips 问题不等于需求 需求是将问题转化提炼成产品语言后的表述方式和解决 方案 需求管理 对需求进行队列式的管理 需求管理包括收集问题 确认需求方案 分配需求 优先级 根据排期监测需求完成情况等工作 需求管理是产品经理最重要最核 心的工作 所有经过立项确认要实施的需求统一存放在 teambition BUG 跟踪 记录 需求待评审 列表下 产品经理每周需要花大部分时间对待评审的需求进 行管理和产品方案设计 具体的需求管理工作一般会从几个维度展开 1 任务拆解 有的需求比较简单 只需要和特定模块的开发人员说明清楚就可以 比如 APP 中某个页面的文字描述需要修改 这类小需求就直接和技术人员沟通即 可 但是大部分核心需求是存在功能模块设计环节的 参与的人员是产品经 理 UI 设计 技术开发 所以这类需求是需要任务拆解的 把整体需求拆解 成一个一个相对独立的任务模块 通常情况下 产品经理每周五分别和设计 负责人与技术负责人开需求评审会确定下周的设计任务和开发任务 并在 teambition 中将这些待评审的需求分配到 UI 原型设计列表和技术方案设计下 在需求评审会前 产品经理需要在需求待评审列表下的需求拆分成一个个的 子任务 2 级联 产品开发注定是个需要多人协同的工作 一个需求在不同状态下由不同的人 负责执行 这就是需求的级联性 也可以说是关联性 比如说一个 发布视频 的功能 在立项后需要由产品经理将功能拆解成一个个的小模块 拆解完成 后由 UI 设计师对小模块进行设计和切片 然后技术才能对照着 UI 设计的效 果图 原型 切片以及产品经理提供的需求说明来有条不紊地进行开发 这 些步骤和流程没有办法更改 有了上一步才能做下一步 这个维度我们称为 级联 在任务分配过程中需要意识到级联性 合理地将拆解后的任务按一定 的先后顺序分配到不同的岗位 3 时间 要实现快速迭代 必须对需求中的每个环节有相对严格的时间控制 每周五 开需求评审会时 除了让技术负责人和设计负责人评估需求的实现难度和实 现方式外 还需要对需求做时间评估 分配 story 时间片 一个 story 代表 2 个小时 给每个需求 这是为了让产品线下的每个人充分了解自己的短期工 作内容和 deadline 在 teambition 的技术方案设计和 UI 原型设计列表下的所 有需求原则上都带有时间片分配 4 优先级 只要拆分得足够细 所有的需求都是带有优先级的 原则上每周五需求评审 会上的需求就是优先级最高需要马上执行的需求 如果中间有更高优先级的 需求插入 则需要另外开会和相关负责人沟通协调 讨论如何修改排期 需求 的优先级有三种 普通 紧急 非常紧急 产品经理在 teambition 的需求待审 核列表下就分配好优先级 以便设计和开发两端在技术方案设计和 UI 设计 时根据优先级和时间片进行时间排期 产品验收 产品功能开发完成后进行测试 测试完成后由测试人员将测试内容交付给产品 经理 由产品经理做最后的验收 验收结束后 由产品经理将验收无误的需求移 入到上线部署 回归测试队列中 技术负责人每周将会对一周内验收无误的需 求进行代码的合并以及部署上线 上线后通知产品经理和测试人员 产品经理和 测试人员对发布上线的新功能做一下回归测试 UI 设计设计配合配合 UI 设计的职责是配合产品经理完成产品规划 并配合完成产品开发中的切片 页面尺寸标注等需求 效果图设计 UI 设计师直接使用 sketch 进行效果图的设计 参考的内容是产品经理提供的功 能需求清单和草图 原型 截图等 高保真原型交互设计 效果图设计稿经过产品经理确认后 开始针对效果图进行动效设计 将 sketch 中 的图片导入到 flinto 中 对效果图添加动态交互效果如点击跳转等 技技术术配合配合 技术方案设计 技术负责人对产品需求进行评审后 针对现状做相对合适可行的技术方案设计 并将技术方案拆分成 story 分配给对应的技术人员 确保开发工作量和开发效率 可控 根据需求优先级来制定对应的开发排期表 技术开发 技术人员按照开发排期在本地完成开发需求 并将代码推送到测试站点供测试 人员进行测试 测试 测试人员根据产品功能需求清单和高保真原型来做功能测试 要求在满足功能 和需求一致的情况下不出现基本的 BUG 发布上线 测试人员测试无误后由产品经理进行验收 验收无误后由技术负责人进行常规 发布或者紧急发布 协协同工具使用同工具使用 teambition teambition 是产品团队内部进行需求管理和任务分配的多人协作工具 好处是使 用