互联网发布流程

实际上，为了保证产品发布工作能够更有效率的进行，需要用规范的流程进行保障~~

• 最接近标准的互联网发布流程：需求 → <b>需求分析</b> → <b>概要设计</b> → <b>产品需求文档</b> → UED → 研发 → 内测 → 预发布环境 → 线上环境 → 线上测试 → 反馈信息 → 优化方案 → 下次需求

• 最简产品发布流程：需求分析 → 产品需求文档 → UED → 研发 → 内测 → 线上环境

需求及需求分析

1. 需求的定义
   <i>需求就是用户所需所指向的最终目的，而功能的本质上就是给用户解决的问题，一般来说，用户的需求相对稳定，最终的解决方案及用户期许随着时代的发展不断的变化。</i>

2. 需求获取方式

在他身边，为他设计

• 问其话
• 查其言
• 观其行

3. 需求分析

• 真需求 - 提供的功能，大多数用户都会使用
• 假需求 - 场景没有真实且普遍发生；

• 是否是目标用户的普遍需求
• 分析需求表象
• 挖掘需求根源
• 关注需求背景

4. 需求管理
   通过需求池管理需求，根据产品的商业价值决定需求的顺序

5. 需求规划

从宏观的层面去规划和联结各种资源和服务

• 贯通：内部或现有的资源进行打通
• 打桩：产品的基础，三端+功能
• 连片：各有联系的功能联结以及资源的联结
• 筑墙：核心竞争力，竞争壁垒
• 延伸：功能/服务的延伸、用户群体的延伸、盈利模式的延伸

概要设计

产品流程图 + 以下问题思考

1. 你所理解的，为什么做产品设计，出发点和目的，重要的体验目标是什么
2. 产品需要满足用户的什么需求，用什么功能满足用户的需求
3. 产品在系统的众多功能中，设计重点有哪些，重要性的先后顺序是什么
4. 这个产品在系统中和其他产品的关联点是什么，需要其他产品如何进行配合
5. 该产品需要做的统计点有哪些？这些数据可以说明什么？

产品需求文档

产品需求文档（PRD）是研发和测试的唯一书面依据，研发依据此进行系统的设计和编程，测试依据PRD编写测试用例和测评，项目经理依据PRD进行项目管理，产品经理本身也需要依据PRD回顾产品设计思路。

1. PRD 编写

• 功能简要描述
• 角色
• 前置流程（用户在哪个流程进入功能）
• <b>流程图</b>
• <b>用户界面</b>
• <b>主要流程</b>（文字描述）
• <b>分支流程</b>（文字描述）
• 后置流程
• <b>商业规则</b>

3. 产品需求评审（针对当前实际工作体会做了删减）

• 新需求及需求变更均需要做需求评审，要求各环节相关同事都要参与，总人数控制在10个人以内。
• 需求品审会之前，产品经理最好分别单独沟通，以提高上会效率。
• 产品经理尽量用数据和事实阐述需求分析思路。
• 针对用户体验要求高的产品版本，建议可以分为两次评审，第一次把业务逻辑定义清楚（包括流程图、主要流程、主要交互原型）；第二次把所有详细的细节都给出来，包括PRD和交互稿件
• 不要频繁的需求变更，原则上，通过需求评审后，需求变更次数控制在3次内，而且产品经理 ，研发，项目经理最好做需求变更评审，评审通过后，相关文档要第一时间做及时的更新。
• 建议进行需求变更评审，之后决定是否进行变更，并且参与的人员包括产品经理，项目经理，研发经理，测试负责人。能够有效的降低因需求变更而给产品带来的风险

项目管理

1. 工作分解
   将工作落实到项目成员每天具体的工作内容,基本是将项目计划细分成各个功能或小功能落实到具体的开发人员身上，同时约定任务开始时间及完成时间，多个开发人员并行开发时注意调整任务之间的先后顺序及时间安排。

2. 项目进度表<i>（详见附件表一）</i>

3. 责任落‘单’
   每个项功能或任务，需要明确具体负责人；多人同时进行开发，指定其中一人负责项目，时间及进度需要在项目进度表中体现。

敏捷开发的技巧

1. 产品负责人由产品经理担任
   产品经理应当是产品的负责人，因为产品是所有业务的接口人，最熟悉业务，也最了解用户需求，并且需要与研发团队保持频繁密切的沟通，协助监督开发进度，以及及时解决出现的问题

2. 做好产品的功能规划
   开发在进行第一期功能开发时，产品经理就需要给出第二第三期的需求，保证有足够的时间进行产品需求分析以及对实现方式进行探讨。

3. 让研发决定迭代周期
   让研发充分的参与的项目过程中有利于产品经理从琐碎的项目推进工作中解脱出来，更专注的思考产品本身。

4. 每天review一次进度
   站会形式，防止‘偷懒’

5. 项目进度表 <i>（详见附件表二）</i>

6. 需要做到无缝沟通
   文档记录+当面沟通会

产品管理

1. 特约用户 （详见表三）

最好的产品管理的方法就是把产品做出来

2. 114原则

• 尽可能通过 ‘1’ 个需求接口人来反馈BUG等紧急需求
• 需求跳过需求接口人，第 ‘1’ 时间反馈给需求接口人和产品经理
• 超过 ‘4’ 小时未反馈，且与下一任务发生优先级重叠式，请需求接口人调配资源，解决问题

<b>老师所讲的更多的都是现实工作中经验和案例，在实际的产品工作中很受用。</b>

附件

表一

| 任务名称|工期|开始时间|完成时间|资源名称|前置任务|
| :------------- | :----------
| | | | | | | |

表二

| 功能点 | 计划产出物 |计划开始日期|负责人|当前进度|风险与对策|说明|
| :----- | :--------- |:-------- |:------- |:------ |
| | | | | | | | |

表三