产品部门工作手册Word格式.docx

产品部门工作手册Word格式.docx

《产品部门工作手册Word格式.docx》由会员分享，可在线阅读，更多相关《产品部门工作手册Word格式.docx（9页珍藏版）》请在冰豆网上搜索。

产品立项&

原型

产品调研结束后，将根据调研结果对产品进行立项，该环节具体的工作方式如下：

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是产品团队内部进行需求管理和任务分配的多人协作工具，好处是使用门槛非常低，可以面向所有岗位协同工作。

它的主要功能是便于任务状态和进度的管理，以及可以对任务进行时间／事件／子任务／负责人／优先级等多维度的划分。

Github

Github是技术团队内部使用频率最高的协作工具，好处是便于对每个技术人员的代码进行版本管理，大大简化了发布流程，避免代码冲突，为时间片式的项目管理提供了非常好的解决方案。

附件

产品功能需求清单

产品排期表

产品BUGLIST