标签:des blog http io os 使用 ar 数据 div
对于稍微大一点的互联网产品都要有精心部署和安排才行,否则项目进行的将会一塌糊涂。
先说一说都有哪些岗位和开发所用的软件:
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,这就需要后期的维护了。等产品稳定后就完成了这次开发
标签:des blog http io os 使用 ar 数据 div
原文地址:http://www.cnblogs.com/stephen-init/p/4025542.html