产品开发流程1) 需求阶段a) 需求产生。需求产生有三种渠道:一,UI(User Interface用户界面)设计师或PD(Product Desiger产品策划)研究市场需要,提出需求,应获得市场策划或市场调研员的认可;二,业务部门提出需求,包含总经理、研究部、内容编辑部、客服部、展业部、市场部等部门。三,UI或PD研究用户,提出需求。此步骤需提供用户习惯报告,体验目标,用户访谈、调研,流量数据统计等作为依据,不得凭空想象。所有需求需经过PD。不经PD的需求,技术部门有权拒绝开发,也没有人为需求负责。即使不需进行策划和设计,也应提交给PD备案。
b) MRD(Market Requirements Document市场需求文档)。MRD需明确传达产品需求的目的和目标,指出什么样的新产品、方案和服务为什么可以在市场上或者内部取得成功,以及希望取得怎样的成功。MRD说明是什么和为什么,但不要写如何(即不要包含流程图和原型图)。当产品需求为高优先级(即项目立项)时,需求方必须提供MRD文档。产品需求的优先级、权重和是否立项由项目实施委员会确定,日常需求由委员会负责人确定,非常规需求开会确定。个别小修改甚至不需PRD,可由PD与技术部门直接沟通完成。
c) 需求评审。PD接到显性需求后,应仔细透彻地分析需求方的真正意图。有时候需求方的想法不一定正确,也有些是突然的想法并不可行,PD需进行判断;当这种情况出现时,PD有权提出自己的解决方法,包括否定需求。因判断失误造成需求冲突、重复开发等情况,责任由PD承担。当发生争执,由PM(Product Manager产品经理)协调解决。PD完成需求评审后,需告知需求方完成PRD的时间、产品开发的预估难度及完成工期。此步骤必须。
2) 策划阶段a) PRD(Product Requirement Document产品需求文档)。PRD侧重对产品产品功能和性能的说明,相对于MRD中的同样内容,要更加详细,并进行量化。PRD一般包含流程图、原型图等,使用用例等手段,以准确说明。若无MRD,则PRD需对目标进行说明。PRD为必须经过的步骤,由PD或UI完成。PRD需进行编号,编号规则详见需求编码表格。
b) 专家评审。需求方、相关领域的顾问(即有丰富经验者)、PD或UI参与的评审PRD的会议,一般项目经理、PM需参与会议。若项目较大,需邀请总经理参与。会议必须有主持,并在会后出MEMO(备忘)或PRD更新说明。专家评审结束后,PD出设计结果方案,需求方签字确认。程序员接到PRD方案后,需评估完成开发的大致时间,以及任务分解安排。当需要GUI方案作为辅助判断时,需明确提出。
c) 交互DEMO。(Interaction Designer交互设计师)根据PRD定稿做出交互设计方案,真实再现用户交互过程,并与PD、UI进行内部评审。视情况,PM参与。(因公司没有,此步骤由PD与美工,视觉设计师,口头沟通完成)
d) 视觉界面。由美工(视觉设计师)设计页面风格、布局、关键界面等,交由PD、UI、进行内部GUI(Graphical User Interface图形使用者接口)评审。GUI方案通过后,页面制作师开始切割页面,编写HTML。
3) 开发阶段a) 后台编码。在编码之前,程序员应视其系统需要,进行概要设计、数据库设计,并进行内部讨论和评审,邀请顾问参与。程序员对文档有疑问或不理解,需与PD进行沟通,了解其真实涵义,不得以任何理由私自更改已确定的PRD、GUI方案。确有功能需做调整,程序员需与PD、需求方共同协商完成。改动应出具文档,由需求方、技术经理、PM签字后生效。
b) α(alpha最初)测试。在开发小组内部进行,测试的方法也较多,黑盒、白盒、 压力、应力等。此阶段应完成80以上的需求开发,测试以PRD为准。测试完成后,收集反馈,修复BUG,优化流程。开发者在场。
c) β(beta第二次)测试:有选择地请一些最终用户实际使用,将发现的问题反馈,开发者对系统进行最后的修改,之后准备发布最终产品。β测试开发者不在场。产品估算开发时间,以完成β测试为准。
d) 产品发布。β测试后,PD校验产品。如产品与策划方案相差较大,有权不接受产品,责任由开发部门负责。将产品发布日设为里程碑,以此考核整个项目的运作效率。
4) 校验阶段a) 发布跟踪。产品上线后,PD或市场调研员负责收集用户操作数据,检测各个反馈渠道,筛选数据,出具用户检测报告,检验产品改进是否达到预期目标。立项产品应专门出具报告,非立项改动需在数据分析报告中体现。
a) 需求产生。需求产生有三种渠道:一,UI(User Interface用户界面)设计师或PD(Product Desiger产品策划)研究市场需要,提出需求,应获得市场策划或市场调研员的认可;二,业务部门提出需求,包含总经理、研究部、内容编辑部、客服部、展业部、市场部等部门。三,UI或PD研究用户,提出需求。此步骤需提供用户习惯报告,体验目标,用户访谈、调研,流量数据统计等作为依据,不得凭空想象。所有需求需经过PD。不经PD的需求,技术部门有权拒绝开发,也没有人为需求负责。即使不需进行策划和设计,也应提交给PD备案。
b) MRD(Market Requirements Document市场需求文档)。MRD需明确传达产品需求的目的和目标,指出什么样的新产品、方案和服务为什么可以在市场上或者内部取得成功,以及希望取得怎样的成功。MRD说明是什么和为什么,但不要写如何(即不要包含流程图和原型图)。当产品需求为高优先级(即项目立项)时,需求方必须提供MRD文档。产品需求的优先级、权重和是否立项由项目实施委员会确定,日常需求由委员会负责人确定,非常规需求开会确定。个别小修改甚至不需PRD,可由PD与技术部门直接沟通完成。
c) 需求评审。PD接到显性需求后,应仔细透彻地分析需求方的真正意图。有时候需求方的想法不一定正确,也有些是突然的想法并不可行,PD需进行判断;当这种情况出现时,PD有权提出自己的解决方法,包括否定需求。因判断失误造成需求冲突、重复开发等情况,责任由PD承担。当发生争执,由PM(Product Manager产品经理)协调解决。PD完成需求评审后,需告知需求方完成PRD的时间、产品开发的预估难度及完成工期。此步骤必须。
2) 策划阶段 a) PRD(Product Requirement Document产品需求文档)。PRD侧重对产品产品功能和性能的说明,相对于MRD中的同样内容,要更加详细,并进行量化。PRD一般包含流程图、原型图等,使用用例等手段,以准确说明。若无MRD,则PRD需对目标进行说明。PRD为必须经过的步骤,由PD或UI完成。PRD需进行编号,编号规则详见需求编码表格。 b) 专家评审。需求方、相关领域的顾问(即有丰富经验者)、PD或UI参与的评审PRD的会议,一般项目经理、PM需参与会议。若项目较大,需邀请总经理参与。会议必须有主持,并在会后出MEMO(备忘)或PRD更新说明。专家评审结束后,PD出设计结果方案,需求方签字确认。程序员接到PRD方案后,需评估完成开发的大致时间,以及任务分解安排。当需要GUI方案作为辅助判断时,需明确提出。 c) 交互DEMO。(Interaction Designer交互设计师)根据PRD定稿做出交互设计方案,真实再现用户交互过程,并与PD、UI进行内部评审。视情况,PM参与。(因公司没有,此步骤由PD与美工,视觉设计师,口头沟通完成) d) 视觉界面。由美工(视觉设计师)设计页面风格、布局、关键界面等,交由PD、UI、进行内部GUI(Graphical User Interface图形使用者接口)评审。GUI方案通过后,页面制作师开始切割页面,编写HTML。 3) 开发阶段 a) 后台编码。在编码之前,程序员应视其系统需要,进行概要设计、数据库设计,并进行内部讨论和评审,邀请顾问参与。程序员对文档有疑问或不理解,需与PD进行沟通,了解其真实涵义,不得以任何理由私自更改已确定的PRD、GUI方案。确有功能需做调整,程序员需与PD、需求方共同协商完成。改动应出具文档,由需求方、技术经理、PM签字后生效。 b) α(alpha最初)测试。在开发小组内部进行,测试的方法也较多,黑盒、白盒、 压力、应力等。此阶段应完成80以上的需求开发,测试以PRD为准。测试完成后,收集反馈,修复BUG,优化流程。开发者在场。 c) β(beta第二次)测试:有选择地请一些最终用户实际使用,将发现的问题反馈,开发者对系统进行最后的修改,之后准备发布最终产品。β测试开发者不在场。产品估算开发时间,以完成β测试为准。 d) 产品发布。β测试后,PD校验产品。如产品与策划方案相差较大,有权不接受产品,责任由开发部门负责。将产品发布日设为里程碑,以此考核整个项目的运作效率。 4) 校验阶段 a) 发布跟踪。产品上线后,PD或市场调研员负责收集用户操作数据,检测各个反馈渠道,筛选数据,出具用户检测报告,检验产品改进是否达到预期目标。立项产品应专门出具报告,非立项改动需在数据分析报告中体现。