《互联网产品的开发流程》这篇博文是欣网PM团队里成员的作品，下面与大伙分享下：

近期在做项目的时候，发现一个问题，由于客户、部分营销人员并不清楚产品开发的流程，认为在产品的功能模块上进行变动，就像在photoshop上修改图片一样简单，所以今天的需求是这样的，到了明天，可能就又变了个想法，而且认为调整一下也就需要个个把小时。

对于这些不正确的认识，主要来源于对产品开发流程的不了解引起的，因此，本期就产品开发的常见流程进行一个详细的解读。

1.      需求阶段

1.1.   需求产生

需求产生有三种渠道：

a)   业务部门（或根据客户的需求）提出需求，包含行业应用部、市场部、互联网部等部门。

b)   UI（User Interface用户界面）设计师或PD（Product Desiger产品策划）研究市场需要，提出需求，应获得市场策划或市场调研员的认可；

c)   UI或PD研究用户，提出需求。此步骤需提供用户习惯报告，体验目标，用户访谈、调研，流量数据统计等作为依据，不得凭空想象。所有需求需经过PD。不经PD的需求，技术部门有权拒绝开发，也没有人为需求负责。即使不需进行策划和设计，也应提交给PD备案。

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

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

1.3.  需求评审

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

2.      策划阶段

2.1.  PRD（Product Requirement Document产品需求文档）

PRD侧重对产品产品功能和性能的说明，相对于MRD中的同样内容，要更加详细，并进行量化。PRD一般包含流程图、原型图等，使用用例等手段，以准确说明。若无MRD，则PRD需对目标进行说明。PRD为必须经过的步骤，由PD或UI完成。PRD需进行编号，编号规则详见“需求编码”表格。

2.2.  评审

需求方、相关领域的顾问（即有丰富经验者）、PD或UI参与的评审PRD的会议，一般项目经理、PM需参与会议。若项目较大，需邀请总经理参与。会议必须有主持，并在会后出MEMO（备忘）或PRD更新说明。专家评审结束后，PD出设计结果方案，需求方签字确认。程序员接到PRD方案后，需评估完成开发的大致时间，以及任务分解安排。当需要GUI方案作为辅助判断时，需明确提出。

2.3.  交互DEMO

ID（Interaction Designer交互设计师）根据PRD定稿做出交互设计方案，真实再现用户交互过程，并与PD、UI进行内部评审。视情况，PM参与。（因公司没有ID，此步骤由PD与美工，视觉设计师，口头沟通完成）

2.4.  视觉界面

由美工（视觉设计师）设计页面风格、布局、关键界面等，交由PD、UI、ID进行内部GUI（Graphical User Interface图形使用者接口）评审。GUI方案通过后，页面制作师开始切割页面，编写HTML。

3.      开发阶段

3.1.  后台编码

在编码之前，程序员应视其系统需要，进行概要设计、数据库设计，并进行内部讨论和评审，邀请顾问参与。程序员对文档有疑问或不理解，需与PD进行沟通，了解其真实涵义，不得以任何理由私自更改已确定的PRD、GUI方案。确有功能需做调整，程序员需与PD、需求方共同协商完成。改动应出具文档，由需求方、技术经理、PM签字后生效。

3.2.  α（alpha最初）测试

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

3.3.  β（beta第二次）测试

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

3.4.  产品发布

β测试后，PD校验产品。如产品与策划方案相差较大，有权不接受产品，责任由开发部门负责。将产品发布日设为里程碑，以此考核整个项目的运作效率。

4.      校验阶段

4.1.  发布跟踪

产品上线后，PD或市场调研员负责收集用户操作数据，检测各个反馈渠道，筛选数据，出具用户检测报告，检验产品改进是否达到预期目标。立项产品应专门出具报告，非立项改动需在数据分析报告中体现。

以上只是对产品开发的常见流程进行的解读，不同公司，不同项目间会有部分的优先级变动，但大体流程是类似的。因此，了解了大致流程，就会在工作中做到心中有数，不会在与产品、UI、技术、测试人员沟通时出现大的障碍，使得项目可以快速推进。

作者：奶牛

PS:产品经理的博客会不间断的分享一些原创作品，大伙儿可以互相交流。
IT精华社区-QQ群：117908440  (在申请时请填写“公司名称”与“岗位名称”谢谢)欢迎您的到来，一帮IT界的GGMM正在火热讨论着。
www.xiuze.net  分享生活 分享IT