第一篇

接触了几年互联网产品开发工作，今日心有所动，想将开发流程总结一下：

一、创意阶段（以下工作是与分管副总或总经理直接互动的过程）

1、提出构想或提交提案。可以是任何员工，可以是书面也可以是口头，直接向负责产品规划的副总或总经理提议。一般建议采用书面形式，以便领导答复，以免由于这样那样的原因造成没有下文的情况。

2、初次研讨。有价值的提案，副总或总经理召集有关人员进行研讨，主要是分析可行性、必要性，以及完善构想。

3、完善方案。初步讨论通过的提案，转交专人负责，撰写商业计划书。该“专人”一般也就是该产品未来的产品经理。商业计划书先交分管副总或总经理初审。

4、正式立项。领导班子基本通过的商业计划，明确专人负责，也就是产品经理。专项工作将由产品经理领导展开，产品经理就是该产品的虚拟总裁。行政上，当以下发正式立项文件的方式，确立该项目的正式实施。

二、筹备阶段（以下工作均由产品经理召集）

1、研讨完善商业计划书。由市场、技术等有关人员参与，包括必要的市场调查等工作。

2、提交正式报告。报告必须详列项目描述、执行计划、成本预算、预期收益、风险与对策、团队名单等。

3、公司领导班子会审，对项目作出评估与审批意见，包括同意、否决、暂缓、退回补充等。

4、团队组织。对于审核通过的方案，分管副总或总经理牵头召集有关部门联席会议，明确工作职责及配合要求。同时，由产品经理宣布团队名单及分工安排。

三、项目实施（以下工作由产品经理督导项目经理实施）

1、提交产品效果图，交公司分管领导会商、审批。

2、项目经理根据项目计划书及产品效果图组织开发。提出产品架构方案、产品实施方案、程序设计方案、数据库设计方案、开发规程、项目进程控制等。包括概要设计与详细设计。产品经理则负责制作产品帮助文档，监督技术开发。必须强调产品协同开发的日志文档编写习惯与版本控制规则。

3、提交模型。逻辑复杂的工程，有必要先做实验性开发。

4、正式开发、测试、发布。

四、项目发布（以下工作由产品经理负责）

1、产品全面检查。包括bug测试、用户文档检查、版本检查等，更正一切细节性的瑕疵。

2、拟订并实施推广方案。

3、用户支持、帮助。

第二篇

对于稍微大一点的互联网产品都要有精心部署和安排才行，否则项目进行的将会一塌糊涂。

先说一说都有哪些岗位和开发所用的软件：

1. PD（产品策划）：word,visio,Axure

2. PM（产品经理）：EasyMind

3. ID（交互设计师）：Axure, Photoshop

4. VD（视觉设计师）：Phtotoshop, Illustrator

5. WD（前端开发工程师）：Photoshop, Dreamweaver

6. DEV（后端开发工程师）：Dreamweaver, MyEclipse

MRD（Market Requirements Document市场需求文档），MRD

需明确传达产品需求的目的和目标，指出什么样的新产品、方案和服务为什么可以在市场上或者内部取得成功，以及希望取得怎样的成功。MRD说明“是什么”和“为什么”，但不要写“如何”（即不要包含流程图和原型图）。当产品需求为高优先级（即项目立项）时，需求方必须提供MRD文档。产品需求的优先级、权重和是否立项由项目实施委员会确定，日常需求由委员会负责人确定，非常规需求开会确定。

PD（产品策划），PD接到显性需求后，应仔细透彻地分析需求方的真正意图。有时候需求方的想法不一定正确，也有些是突然的想法并不可行，PD需进行判断；当这种情况出现时，PD有权提出自己的解决方法，包括否定需求。因判断失误造成需求冲突、重复开发等情况，责任由PD承担。当发生争执，由PM（Product Manager产品经理）协调解决。PD完成需求评审后，需告知需求方完成PRD的时间、产品开发的预估难度及完成工期。

接下来就应该是开发人员做PRD（Product Requirement Document产品需求文档），PRD侧重对产品功能和性能的说明，相对于MRD中的同样内容，要更加详细，并进行量化。PRD一般包含流程图、原型图等，使用用例等手段，以准确说明。也就是说从做PRD文档时就是已经进入准备开发阶段，这时MRD文档应该很明确了。

接下来大家开会讨论PRD方案，参与讨论的应该有需求方、相关领域的顾问（即有丰富经验者）、PD或UI，并做好记录。接下来PD出设计结果方案，需求方签字确认。程序员接到PRD方案后，需评估完成开发的大致时间，以及任务分解安排。

ID（Interaction Designer交互设计师）根据PRD定稿做出交互设计方案，真实再现用户交互过程（工作室一般用强大的axure），并与PD、UI进行内部评审。视情况，PM参与，做完后要与需求方反复交流直到需求方满意。

接下来VD（视觉设计师）根据axure做出的原型，进行设计页面风格、布局、关键界面等。和用户交流对页面设计是否满意。

WD（前端开发工程师）根据设计页面切图，编写HTML，CSS，JS源代码。

下面就进入了后台开发阶段，在编码之前，程序员应视其系统需要，进行概要设计、数据库设计，并进行内部讨论和评审。程序员对文档或原型有疑问或不理解，需与PD和ID进行沟通，了解其真实涵义，不得以任何理由私自更改已确定的PRD文档方案。确有功能需做调整，程序员需与PD、需求方共同协商完成。改动应出具文档，由需求方、技术经理、PM同意。每个人写的代码都不可能完全正确，

这样就需要边开发边测试。

* α（alpha最初）测试。在开发小组内部进行，测试的方法也较多，黑盒、白盒、 压力、应力等。此阶段应完成80%以上的需求开发，测试以PRD和原型为准。测试完成后，收集反馈，修复BUG，优化流程。

* β（beta第二次）测试：有选择地请一些最终用户实际使用，将发现的问题反馈，开发者对系统进行最后的修改，之后准备发布最终产品。β测试开发者不在场。产品估算开发时间，以完成β测试为准。

产品上线后可能还存在一些bug，这就需要后期的维护了。等产品稳定后就完成了这次开发

互联网产品实施流程

产品管理流程

2012年8月

目录

产 品 管 理 市 场 分 析

产 品 设 计

产 品 实 施 部 署 & 运 营 市 场 推 广

评 估 管 理

产品管理

? 产品管理是企业或组织在产品生命周期中对产品规 划、开发、生产、营销、销售和支持等环节进行管 理的业务活动

? 产品管理可能包括，但并不完全等同于项目管理、 新产品开发或销售支援

产品管理

? 产品管理关注开始、结果，项目管理关注过程 区 别

项目经理

把事情做正确，把事 情作得完美，在时间 ，成本和资源约束的 条件下完成目标。从 产品需求出发，对产 品开发过程负责

产品经理

做正确的事，其所领 导的产品是否符合市 场的需求，是否能给 公司带来利润的。从 市场或客户需求出发 ，对产品的最终收益 负责

产品管理

? 产品管理阶段

产品管理

市场 产品 产品 部署 市场 评估 分析 设计 实施 运营 推广 管理

目录

产 品 管 理 市 场 分 析

产 品 设 计

产 品 实 施 部 署 & 运 营 市 场 推 广

评 估 管 理

产品市场分析

? 此阶段是产品管理人员决定做与不做的过程

产品市场分析

? 部门职责

? 产品部门

? 收集分析客户需求、市场变化、技术演进、竞争对手等信息， 对既有产品改良和新产品开发进行规划； ? 需求的审核、审批； ? 需求的优先级排序；

? 其它部门

? 提出需求，并内部优先级排序； ? 协助产品部门完成产品需求提炼工作； ? 协助产品部门完成产品市场分析，如产品市场调研分析、竞争 对手分析；

? 相关流程

? 市场需求分析流程

? 产品需求控制流程

产品市场分析

? 文档输出

文档名称

MRD/CRD

文档说明

从各渠道收集市场信息进行市场分析,完成 MRD/CRD 发起部门优先级评定后的内部需求清单 审核需求内容,若评估通过则提炼内部需求清单.

负责部门

产品部

负责岗位

产品技术经理

内部需求清单 内部产品需求 紧急需求审批单

需求发起部门 产品部

需求发起人 产品技术经理 产品总监

产品和研发部门负责人均需审批通过,才能实施此紧 产品部 急需求. 产品分类规则的调整;将新产品按照既有产品分类规 产品部 则纳入产品分类表. 分别给各需求打分,再排序. 产品部

产品分类表

产品技术经理

产品研发优先级列表

产品技术经理

目录

产 品 管 理 市 场 分 析

产 品 设 计

产 品 实 施 部 署 & 运 营 市 场 推 广

评 估 管 理

产品设计

? 此阶段是产品管理人员将产品技术化，说明产品的 功能和性能指标

产品设计

? 部门职责

? 产品部门

? 编写PRD，并组织评审

? 其它部门

? 提供编写PRD所需要的支持 ? 参与产品部门组织的PRD评审

? 相关流程

? 产品

需求控制流程

产品设计

? 文档输出

文档名称 文档说明 负责部门 负责岗位

产品技术经理

ROADMAP 产品技术经理编写产品路线图，逐级汇总，更改产品 产品部 （产品、产品线、产品部门） 线、产品部门路线图 PRD/PER 根据需求实际情况,选择编写PRD或PER. 产品部

产品技术经理

PRD评审会签单

产品部门组织需求相关的产品干系人对PRD/PER进行 产品部 评审 编写/修改产品版本控制列表 产品部

产品技术经理

产品版本控制列表

产品技术经理

目录

产 品 管 理 市 场 分 析

产 品 设 计

产 品 实 施 部 署 & 运 营 市 场 推 广

评 估 管 理

产品实施

? 此阶段是将设想细化成产品原型，提交到研发部门 ，研发出相应的产品。

产品实施

? 部门职责

? 产品部门

?UI设计 ?参加需求分析评审、研发正式排期评审、TC评审，上线会签 ?跟踪研发过程中项目情况 ?参与UAT测试工作 ?产品功能验收审批

? 研发部门

?负责产品研发整个过程

? 其它部门

?根据需要，参与需求分析评审 ?运营部署改造

? 相关流程

? 研发流程 ? 运营部署流程 ? 发布流程

产品实施

? 文档输出

? ? ? ? ? ? ? ? ? ? ? ? UI设计需求 产品验收审批单 立项报告 详细项目实施计划 系统需求分析文档 总体、详细设计文档 项目过程状态报告 测试计划、测试用例、测试报告 需求变更申请及审批单 UAT测试计划、UAT测试用例、UAT验收报告 上线验证报告 需求变更申请书及评审会签单

产品实施

? 文档输出

文档名称

功能需求说明（UI设计）

文档说明

描述产品的人机交互、操作逻辑、界面美观的整体要 求

负责部门

产品部

负责岗位

产品技术经理

产品功能验收审批单 项目需求分析 项目实施计划

验收研发结果中是否涵盖了当初需求文档中的重要功能 点,并给出产品功能验收审批结果,以判断是否开始部署 产品部 产品运营工作 根据PRD,明确研发符合产品需求的任务范围 明确项目各工作节点责任人、时间点 技术部 技术部

产品技术经理 研发项目经理 研发项目经理

项目状态报告

研发项目经理定期反馈项目进度

技术部

研发项目经理

测试文档（测试计划、测试 研发测试人员根据需求分析指定测试用例，测试计划 用例、测试报告） 并执行测试，形成测试报告

技术部

研发项目经理 研发项目经理 研发项目经理

UAT验收文档（测试计划、 研发项目经理发起UAT验收，制定UAT测试验收计划和 技术部 用例，做UAT验收，最终形成UAT验收报告 测试用例、验收报告）

上线验证报告 研发测试人员在系统上线后再做一次系统测试.形成的 技术部 文档

目录

产 品 管 理 市 场

分 析

产 品 设 计

产 品 实 施 部 署 & 运 营 市 场 推 广

评 估 管 理

部署&运营

? 此阶段是产品从研发、验收完成，进入正式运营的 过程

部署&运营

? 部门职责

? 产品部门

? 产品管理部汇总各部门的运营基本规则, 结合产品特点, 输出产品的运营 文档资料 ? 产品培训及考核资料，完成第一次培训 ? 负责产品试运营工作，转入正式运营 ? 日常运营工作

? 其他部门

? 准备各自部门的运营基本规则 ? 运营环境部署 ? 参与试运营成功会签 ? 文档的归档内审 ? 日常运营工作

部署&运营

? 相关流程

? ? ? ? ? 运营部署流程 试运营流程 新产品培训评估流程 产品日常发布管理流程 监控点及更新流程

部署&运营

? 文档输出

文档名称

试运营计划、试运营报告

文档说明

负责部门

负责岗位

产品运营经理

制定试运营计划\落实各部门的运营资源，依据最终版的试运 产品部 营计划,将产品投入试运营, 出具《试运营报告》， 产品部

新产品培训资料、考试题目 制作培训材料,考试题库,完成首次培训

产品技术经理

产品管理部汇总各部门的运营基本规则, 结合产品特点, 输出 产品运营文档 产品的运营文档资料，在持续运营阶段根据出现的问题进行 （商户操作手册、运营操作 更新 手册、产品运营规范、产品 产品部 其他部门提供的文档包括：技术部：《产品接口文档》、 风险点，监控点及处理规则、 《系统操作文档》;结算部出台并更新《产品清结算规则》; 风 FAQ） 险控制部：《产品风控政策和规则》；CRM操作手册等 产品运营报告 运营情况的定期收集和分析.形成运营报告 产品部

产品运营经理

产品运营经理

目录

产 品 管 理 市 场 分 析

产 品 设 计

产 品 实 施 部 署 & 运 营 市 场 推 广

评 估 管 理

市场推广

? 此阶段进行产品的市场化工作，制定产品推广策略 ，准备产品推广过程中所需文档

市场推广

? 部门职责

? 产品部门

?制定市场推广计划 ?发起产品定价、产品合同 ?产品市场营销支持

? 其他部门

?财务部：产品定价 ?法律合规部：产品合同 ?市场部门：执行产品推广计划

? 相关流程

? 产品定价流程 ? 合同制定，使用、审批流程 ? 产品支持流程

市场推广

? 文档输出

文档名称

产品报价单

文档说明

负责部门

负责岗位

依据定价策略给出产品在行业的定价，由产品部发起产品定 财务部 价请求 产品部发起产品相关合同制定流程，形成标准合同 制定产品的推广策略和推广方案 法律合规部 产品部 产品技术经理 产品技术经理

产品标准合同 市场推广计划 产品支持文档

根据其他部门具体需求，

提供相关产品解决方案、产品营销 产品部 策略 产品的市场化工作,包括行业策略、解决方案的制定,竞争分析 产品部 和品牌推广

产品相关分析报告

产品技术经理

目录

产 品 管 理 市 场 分 析

产 品 设 计

产 品 实 施 部 署 & 运 营 市 场 推 广

评 估 管 理

评估与管理

? 此部分的工作贯穿产品正式运营至下线的全过程

评估与管理

? 部门职责

? 产品部门

?收集产品改进意见,评估并跟进落实 ?根据产品运营报告、公司战略等因素,出具产品下线评估报告 ?完成产品下线全过程

? 其他部门

?各部门运营、评估报告 ?提出产品改进意见 ?配合完成产品下线

? 相关流程

? 产品改进流程 ? 运营数据分析流程 ? 产品下线流程

评估与管理

? 文档输出

文档名称 文档说明

业务运营:《业务运营报告》 财务：《产品的成本效益分析报告》; 风控：《风险管理部的运营报告》 《各行业的产品风险评估报告》; 结算：《清结算运营报告》; 法律合规：《产品合规评估报告》; 系统运维：《系统运维报告》; 银行合作：《银行运维报告》; 收集外部门运营评估报告形成产品运营报告 收集外部门和本部门产品改进意见,评估并跟进其落实 产品部 产品部 产品运营经理 产品技术经理 产品运营经理

负责部门

负责岗位

各部门运营评估报告

产品运营报告 产品改进意见 产品下线评估报告

根据产品运营报告结合公司战略等因素,出具产品下线评估报 产品部 告 管理层作出产品下线决策后,制定下线计划 产品部

产品下线计划

产品运营经理

互联网产品开发流程

互联网新产品设计开发流程

方法/步骤

1. 1

战略规划

作为一些产品的负责人，钥匙从没有参与战略方向的制定，仅有幸以旁听的形式进行过极少的战略讨论，这些讨论会与其说是战略讨论会，不如说是公司领导极力说服大家朝某个战略方向走，也就是战略思想灌输。看过很多同行朋友的说法，似乎对于产品经理来说这是一个普遍现象，也不难理解，一个产品要有大的投入，做与不做甚至做成什么样都是老板非常关心的问题，因此产品经理在战略制定的时候能起到的作用很小。 不过战略规划也是需要总结和分析的，虽说互联网行业瞬息万变、时不我待、快马加鞭、紧赶慢赶~~~ 但是要开拓一个新产品还是需要完成这个产品的简单分析和战略的描述。

2. 2

前期分析

产品的前期分析不分高低贵贱都要做，大到一个完整意义上的产品，小到一个新功能，前期的分析都是非常关键。这个前期分析首先是要了解这个产品，以及产品相关服务的生态系统（ecosystem），一个产品经理在这个阶段所要做的就是了解整个领域的情况，竞争对手，用户，甚至需要关注一下国家政策。其次在这个阶段需要给产品一个定位，要回答的问题诸如“用户是谁？”，“满足用户的什么需要？”，“我们应该提供哪些功能（内容）满足他们？”等等，当然了，这些问题在这个阶段我们只需要一个定性的分析就可以了。

3. 3

用户研究

用户研究包含的范围很广，《赢在用户》这本书有经典的描述，从前期的用户访谈到可用性测试直到上线后产品运营时对数据的分析，都属于用户研究的范畴，这里仅仅讨论产品开发前期的用户研究。在前期首先要对整个业界这个方向产品的情况做调研，收集情报，这期间有很多方法，土一点的比如从CNNIC、IResearch等处寻找调研结论直接Copy，好一点的选取目标用户进行访谈、发放问卷、寻找专家进行访谈等等。

钥匙想说的是，想要做好一个用户研究需要花费的精力很多，尤其是在一个没有专门用户研究人员的互联网公司里，能给你这么多时间与资源来做这件事实在是一个奢侈的想法，不过在有限的投入下获得最大的成果是决定产品经理能力高低的体现，所以也没什么可怨天尤人的。在这个阶段需要搞清楚一些问题，比如“我们的用户到底是谁？”“他们有什么样的需求？”“如何才能有效的实现他们的需求？”。

4. 4

概念设计

概念设计是一个产品的灵魂体现，这部分的实现产品经理可以要求UED与你一同完成，不过很多公司可能没有专门的UED做这件事，所以只能自己撸起袖子干的。简单的把概念设计分为三个阶段：

第一个阶段：需求概念。概念设计的开始往往伴随着头脑风暴会，选出一些靠谱的功能（内容）的设计，然后由产品经理给出一个功能范围定义，最好能附上部分核心功能的交互流程。这时最好开一个会议，会议内容就是找上老大们敲定下来我们的功能范围，这点非常重要，一定要有记录，否则会出现项目进行中老大跳出来要改方向的事故（当然，有记录老大也可能会跳出来，但是如果这样你能争取到对应的自由度）。

第二个阶段：概念原型。此时就要体现产品经理资源整合的能力了，最理想的状态是拉来一个人帮你完成一个高保真的功能原型，钥匙见过比较牛的是找一个Flash牛人，做一个纯粹的Flash实现的高保真原型，那叫一个真！往往伴随着高保真原型的出现，会重复上面说到的用户研究，但不论怎样这东西最终的目的是给公司老大们汇报，让老大们看看这东西原来就长这个样子，同时也让老大们用一用，敲定产品的一些具体实现。如果上第一阶段是设计产品的骨架，那么这一阶段就是给骨架上添点肉了。

第三个阶段：完成 MRD（市场需求文档）。这个阶段主要是总结一下上两个阶段东西，拼凑成一个完整意义上的MRD，这里就是考验产品经理画饼的功力了，以文档和原型的方式告诉公司领导层你要做的这个东西是什么样子，为什么做成这个样子，能解决用户的什么问题，这样做了再市场竞争对手间有什么优势，未来有什么样的发展预期，当然，最最重要的是你通过这个阶段的汇报，能为你争取到多少资源。

5. 5

需求确定

这部分内容应该是业内大部分的产品经理都在做的事情，有了上面的积累一个产品的样子已经在产品经理的脑袋里鲜活的出现了，产品经理所要做的就是撰写一系列的文档将这个鲜活的影像记录下来，所谓PRD和UI详细设计就是这个阶段的产出物。此时你的产品已经放在了纸面上，你要把他小心的交给项目经理了，再由项目经理分解你的需求写成一个FSD（功能详细说明文档）这个文档是给开发人员看的，他们可以拿到这样的文档直接开始开发。

需要注意的是，很多互联网公司往往没有项目经理，或者有也是在管理开发团队无数个项目的项目进度的监管员。钥匙的经验是要么会有一个架构师来分解你的需求，要么直接拿你的需求给开发，伴随着开发不断的骚扰和自由发挥把项目完成。

钥匙遇到的一般是有一个项目进度监管员，且无人帮你分解需求的情况，这种情况只能是产品将PRD写的尽量的细致，除此之外，还要在脑海里有一个非常完整，非常细节的情境，在开发针对你PRD中某部分有疑问的时候清清楚楚的告诉他这里应该是什么样子的。

6. 6

项目预算

这部分暂时不涉及财务问题，仅仅从项目管理的角度看，我们需要由一个WBS（工作分解结构），一个甘特图，一个资源直方图，这是最少的配置，可以清晰的显示出你的项目进度与所需资源的关系。这项目管理方面内容理论较多，在这里不做赘述。

7. 7

实施开发

开发的过程比较考验你前面的工作，基本上你在甘特图上应该有不止2个的检查点，到时检查项目的进度是否符合预期，如果出现了问题也要想办法保证进度。如何保证呢？基本上有加班和砍功能两种办法，砍功能这点是开发痛快，产品痛苦的事情，而加班正好相反。不论你最终选择了什么方法，最最核心的就是记住你这个产品所服务的用户是谁？他们是不是用不到你想砍掉的功能。

8. 8

产品上线

我所经历的产品上线都是悄悄的上线，并没有大张旗鼓的做市场活动，我想这是大部分互联网产品上线的情况吧。悄悄上线是好处多多的，由于互联网产品逻辑复杂，流程多样，所以在没有大量的用户使用并做几次迭代改进前，很难说会存在哪些问题。在这方面钥匙有一次惨痛的教训，记得有一次钥匙负责的一个产品上线，上线成功的信在公司内部研发中心群发，信里感谢了一堆的同事，搞的特别煽情，结果是大家感兴趣的上网一看，哇塞！随便点点就发现一堆的BUG，群情激奋的同事们立马用发信表达自己的不

满，看到那些两位数的关于产品BUG的信，钥匙当时我只有一个愿望，就是切腹自~ 这个惨痛的经验让我明白了，谁都不能为你的产品负责，即便有强大的测试团队告诉你你的产品OK，完全达到上线的指标，也要自己在上线前狠狠的测试一下，毕竟没有那个测试人员比你还了解产品&用户。

9. 9

产品运营

以前有位老大曾经说过，互联网产品是一个萝卜一个坑，一个新产品开起来了，一个人砸下去就一直在这个坑里挖了，挖的深了还得多拉几个人下水，如果想再开一个新产品只能找另一个人来挖坑。这句话可以体现大多数互联网产品的情况，也说明了产品运营的重要性，在整个产品生命周期里绝大多数的时间都是在做运营。

说到做运营钥匙感慨良多，各种类型的互联网产品之间的运营方式千差万别，而且每种产品的运营都有很多技巧在里面。比如新闻类产品，Sohu的首页新闻是每五分钟观察一下点击数据，点击差的就往下撤，同时运营人员也以点击量为考核目标；再比如论坛类产品，运营的工作主要是和人打交道，论坛的斑竹、分类的管理员、总管理员，层层的组织都要有运营老大建立，建立完毕了还需要自己在里面用马甲发帖，顶贴直到找到一些不错的意见领袖，形成一个良好的讨论氛围，论坛类产品的考核目标是UV和PV/UV双重指标；再再比如钥匙做过最多的搜索引擎的运营，不停的订指标，写规范，做评估，最后推动开发改进，搜索类产品的指标就不单是PV、UV这么简单了，各种性能都有自己的指标，根据产品所处阶段衡量指标不同。

总而言之，运营才是一个产品能否成为优秀产品的核心！

互联网产品设计流程

互联网产品设计流程http://www.of?dea.com/

互联网产品设计流程.html

1.认识 ?Understanding

1.1 ?需求是什么？ ?定位、概念

1.2 ?需要做什么？ ?负责

1.3 ?解决了什么？ ?目的、好处

1.4 ?还能做什么？ ?扩展性考虑、需要预留哪些

2.分析 ?Analysis

2.1 ?数据分析：用户是谁？年龄？男女比例？现有产品的各项数据指标 ?(百度数据中心，数据魔方及各种互联网数据)

2.2 ?竞品分析：国内同类产品怎么做？国外又有哪些产品？它们的优劣势？

2.3 ?逻辑流程: ? ?整个产品的逻辑流程解析

3.原型 ?Prototype

3.1 ?低保真原型: ?绘制产品主流程，最小可能原型(MVP)，忽略细节的原型 ?(工具: ?纸原型, ?草图, ?Visio, ?Mac用户可考虑使用 ?Axure ?或 ?Omnigraffle ?)

3.2 ?沟通: ?邀请需求方,开发团队共同探讨及确认产品框架

3.3 ?改进: ?根据沟通会后的沟通进行改进，再进行确认

3.4 ?高保真原型: ?在低保真的基础上面细化原型，并建立交互流程(工具: ?Axure)

3.5 ?评审会: ?根据高保真原型完整演示下产品&功能和项目相关人员（产品，设计，前端，研

发）确认

3.5 ?说明文档: ?对交互原型&细节进行说明,方便开发&界面设计&前端实现

4.界面设计 ?UI ?Design

4.1 ?情绪板: ?利用情绪板(Mood ?Board)方法制定风格颜色

4.2 ?风格: ?根据设计师自己对产品的判断进行风格设定（2-4稿）

4.3 ?视觉设计: ?根据高保真原型完成设计稿

4.4 ?评审会: ?对视觉设计稿进行最终的确认

4.5 ?页面标注: ?标注页面关键地方的颜色,元素的尺寸,距离 ?(工具: ?MarkMan ?)

4.6 ?UI规范: ?撰写UI元素使用规范文档

4.7 ?路径图: ?描述用户在产品内部的路径

5.上线 ?On-line

5.1 ?数据观察: ?观察上线后的产品&对比数据指标，看是否符合设计的目标

5.2 ?上线总结报告: ?简单介绍前期设计思路，产品和分享下上线的数据对比

5.3 ?迭代: ?发现问题,持续改进

互联网产品开发流程

互联网产品开发流程

对于稍微大一点的互联网产品都要有精心部署和安排才行，否则项目进行的将会一塌糊涂。 先说一说都有哪些岗位和开发所用的软件:

PD(产品策划):word,visio,Axure

PM(产品经理):EasyMind

ID(交互设计师):Axure, Photoshop

VD(视觉设计师):Phtotoshop, Illustrator

WD(前端开发工程师):Photoshop, Dreamweaver DEV(后端开发工程师):Dreamweaver, MyEclipse

再说说MRD(Market Requirements Document市场需求文档)吧，MRD需明确传达产品需求的目的和目标，指出什么样的新产品、方案和服务为什么可以在市场上或者内部取得成功，以及希望取得怎样的成功。MRD说明“是什么”和“为什么”，但不要写“如何”(即不要包含流程图和原型图)。当产品需求为高优先级(即项目立项)时，需求方必须提供MRD文档。产品需求的优先级、权重和是否立项由项目实施委员会确定，日常需求由委员会负责人确定，非常规需求开会确定。

接下来就是PD的事情了，PD接到显性需求后，应仔细透彻地分析需求方的真正意图。有时候需求方的想法不一定正确，也有些是突然的想法并不可行，PD需进行判断;当这种情况出现时，PD有权提出自己的解决方法，包括否定需求。因判断失误造成需求冲突、重复开发等情况，责任由PD承担。当发生争执，由PM(Product Manager产品经理)协调解决。PD完成需求评审后，需告知需求方完成PRD的时间、产品开发的预估难度及完成工期。

接下来就应该是开发人员做PRD(Product Requirement Document产品需求文档)，PRD侧重对产品产品功能和性能的说明，相对于MRD中的同样内容，要更加详细，并进行量化。PRD一般包含流程图、原型图等，使用用例等手段，以准确说明。也就是说从做PRD文档时就是已经进入准备开发阶段，这时MRD文档应该很明确了。

接下来大家开会讨论PRD方案，参与讨论的应该有需求方、相关领域的顾问(即有丰富经验者)、

PD或UI，并做好记录。接下来PD出设计结果方案，需求方签字确认。程序员接到PRD方案后，需评估完成开发的大致时间，以及任务分解安排。

ID(Interaction Designer交互设计师)根据PRD定稿做出交互设计方案，真实再现用户交互过程(工作室一般用强大的axure)，并与PD、UI进行内部评审。视情况，PM参与，做完后要与需求方反复交流直到需求方满意。

接下来VD(视觉设计师)根据axure做出的原型，进行设计页面风格、布局、关键界面等。和用户交流对页面设计是否满意。

WD(前端开发工程师)根据设计页面切图，编写HTML，CSS，JS源代码。

下面就进入了后台开发阶段，在编码之前，程序员应视其系统需要，进行概要设计、数据库设计，并进行内部讨论和评审。程序员对文档或原型有疑问或不理解，需与PD和ID进行沟通，了解其真实涵义，不得以任何理由私自更改已确定的PRD文档方案。确有功能需做调整，程序员需与PD、需求方共同协商完成。改动应出具文档，由需求方、技术经理、PM同意。每个人写的代码都不可能完全正确，这样就需要边开发边测试。

α(alpha最初)测试。在开发小组内部进行，测试的方法也较多，黑盒、白盒、 压力、应力等。此阶段应完成80%以上的需求开发，测试以PRD和原型为准。测试完成后，收集反馈，修复BUG，优化流程。

β(beta第二次)测试:有选择地请一些最终用户实际使用，将发现的问题反馈，开发者对系统进行最后的修改，之后准备发布最终产品。β测试开发者不在场。产品估算开发时间，以完成β测试为准。

产品上线后可能还存在一些bug，这就需要后期的维护了。等产品稳定后就完成了这次开发

转载请注明出处范文大全网 » 互联网产品的开发流程