产品部门工作手册(完整资料).doc

此文档下载后即可编辑

产品部门工作手册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设计的效果图／原型／切片以及产品经理提供的需求说明来有条不紊地进行开发。这些步骤和流程没有办法更改，有了上一步才能做下一步，这个维度我们称为级联。在任务分配过程中需要意识到级联性，合理地将拆解后的任务按一定的先后顺序分