魔方软件后续笔试卷 (2].doc

如果你是一个部门流程规范制定者，为了使得部门之间工作透明并能够有效沟通，并且能够使得新进员工能够尽快入手，请具体制定各部门的开发工作流程（公司性质为大型MMOG研发公司，工种包括策划、程序、美术、测试、市场、运维等） 首先需要说明的是，配合制度的确立，对于流程化的认可，管理层的支持，初级阶段需要奖惩分明，从心理上认识到工业化流程的好处，最大限度提高工作效率，确立会议总结和回馈记录制度 以下工作流程仅为个人经验和体会，当然，只要是符合项目利益，任何合理的改变和建议均是适合流程作用的，本人一直相信，没有绝对的流程制度，只有合理的流程应用 对于会议的建议： 任何会议需要提前准备好商讨问题，并且集中整理后举行，会议议题必须明确，会议必须有商讨结果，并且是可实现的结果，会议结束后，需要回馈会议记录，商讨结果等备忘 当然，会议举行不一定是我建议的工作流程中的节点，需要根据实际情况调整 策划部门： 主要工作流程建议： 第一次会议， 目标：在确立项目立案以后，也就是可以根据市场需要，管理层决议后，确定项目导向和市场需求 产出：项目实施方向议案和会议记录 第二次会议， 目标：项目范围确立 策划部门和相关部门需要商议决定，确立项目关系人，需要增加的关系部门，资助人，市场定位，关键期望等 其次是头脑风暴以确立游戏项目的大概背景方向，游戏类型，核心玩法，看点，特色等 产出：项目范围和实施确认和会议记录 第三次会议，协作部门沟通： 目标：确立好项目关系人，关系部门后，应确认各部门窗口负责人，接口和项目团队个部门的文档管理平台和应用平台 产出：到岗责任制，窗口责任人和会议记录 策划部门在和各部门确认项目实施后，可以根据需要进行小型的团队资源整合，配合原型开发，视原型开发期限，各部门整合资源参与原型开发，根据市场，管理层的项目需求，产出大概的原型文档，该文档的目的仅为能够保证原型的可执行性以及能够突出该游戏的最大特点则可以 产出：原型设计文档 原型开发期间，同样需要各部门相互协调以保证原型项目的顺利完成，因为原型同样是一个项目 原型通过市场，管理层通过后，项目正式进入深入开发 策划部门在此时的主要任务： 根据游戏项目的导向、市场、美术等部门的意见确定游戏背景，故事，剧情，人物，人设，场景，时间，玩法，战斗，系统，平衡性等需求开始生成较为完整的功能，玩法，系统设计 在提交程序开发之前，可能需要和UI,GUI,美术等设计部门沟通商议所需的交互设计，以及图形，图像需求，并且在提交策划设计文档的同时，需要征求和各技术实现部门的技术实现建议，合理的利用策划设定时间，最大限度保证产出的一次性质量和可实现度 第四次会议： 目的：初步细化设计的评审 初步的细化功能设计完成后，建议进行评审会议，需要各技术部门负责人一致确认，并对需要进行修订的细化功能设计概要进行修订和提交 产出：评审通过决议，修订方案 之后则是等于游戏本身各项细化设计的循环迭代，包括具体的游戏模块设计，主要是游戏性方面的，其次是数值平衡的设计 策划设计工作流程中，需要及时更新，维护，通告文档的最新信息，任何需求的变更需要经过各部门信息窗口负责传达和实施，并且保留底稿和确认 在完成策划设计主要工作后，则可以关注设计变更的控制和管理以及用户体验测试用例的制定 用户体验测试，需要尽可能的搜集各部门信息资源，市场同类产品回馈信息，以及个人使用体会等，最大限度的优化和改进不合理的策划设计方案，并且及时提交测试管理平台 循环迭代 在产品面试以后，定期搜集或者获取市场反馈信息，或者根据市场部的需求进行用于可增加收益，提高用户体验感，延长产品生命周期等的策划设计，阶段性工作。 直至项目周期彻底终结 程序部门： 主要工作流程建议： 策划的原型文档接收 根据原型文档的设计开发功能，并且保留不面市功能入口，保证原型可执行性，突出游戏最大特点 策划的细节文档接收 原型通过后，根据策划的细化功能和各种系统设计，重新整合各项资源，深入开发各功能和系统的完善，与美术，动画，音乐等协调 根据开发使用模型决定版本发布周期和版本号规则，以便测试，策划和项目管理者的测试 版本的发布 需要提醒的是，在开发过程中，任何问题和技术困难应首先通过程序本身的负责人负责尝试解决，如果确实有阻碍，需要通过指定信息窗口传达意见和建议，或者申请会议商讨 BUG的修订 根据测试团队所提供的bug级别判定改进时机，根据策划、市场等部门的反馈修订代码或者增加减少功能，需要决定BUG FIX的优先级.比如BUG 1 FIX的版本是1.1，BUG 2 是1.2,需要在测试管理平台里注明 在修订部分BUG后发布新的版本 在新版本的change list里需要大概注明, 那些BUG被修订,又新增加了哪些功能,移除了什么东西等等 循环和迭代 产品面市后，可根据市场，策划等发布