资源描述
1. 如果你是一个部门流程规范制定者，为了使得部门之间工作透明并能够有效沟通，并且能够使得新进员工能够尽快入手，请具体制定各部门的开发工作流程（公司性质为大型MMOG研发公司，工种包括策划、程序、美术、测试、市场、运维等）首先需要说明的是，配合制度的确立，对于流程化的认可，管理层的支持，初级阶段需要奖惩分明，从心理上认识到工业化流程的好处，最大限度提高工作效率，确立会议总结和回馈记录制度以下工作流程仅为个人经验和体会，当然，只要是符合项目利益，任何合理的改变和建议均是适合流程作用的，本人一直相信，没有绝对的流程制度，只有合理的流程应用对于会议的建议：任何会议需要提前准备好商讨问题，并且集中整理后举行，会议议题必须明确，会议必须有商讨结果，并且是可实现的结果，会议结束后，需要回馈会议记录，商讨结果等备忘当然，会议举行不一定是我建议的工作流程中的节点，需要根据实际情况调整策划部门：主要工作流程建议：1. 第一次会议，目标：在确立项目立案以后，也就是可以根据市场需要，管理层决议后，确定项目导向和市场需求产出：项目实施方向议案和会议记录2. 第二次会议，目标：项目范围确立策划部门和相关部门需要商议决定，确立项目关系人，需要增加的关系部门，资助人，市场定位，关键期望等其次是头脑风暴以确立游戏项目的大概背景方向，游戏类型，核心玩法，看点，特色等产出：项目范围和实施确认和会议记录3. 第三次会议，协作部门沟通：目标：确立好项目关系人，关系部门后，应确认各部门窗口负责人，接口和项目团队个部门的文档管理平台和应用平台产出：到岗责任制，窗口责任人和会议记录4. 策划部门在和各部门确认项目实施后，可以根据需要进行小型的团队资源整合，配合原型开发，视原型开发期限，各部门整合资源参与原型开发，根据市场，管理层的项目需求，产出大概的原型文档，该文档的目的仅为能够保证原型的可执行性以及能够突出该游戏的最大特点则可以产出：原型设计文档5. 原型开发期间，同样需要各部门相互协调以保证原型项目的顺利完成，因为原型同样是一个项目6. 原型通过市场，管理层通过后，项目正式进入深入开发7. 策划部门在此时的主要任务：根据游戏项目的导向、市场、美术等部门的意见确定游戏背景，故事，剧情，人物，人设，场景，时间，玩法，战斗，系统，平衡性等需求开始生成较为完整的功能，玩法，系统设计在提交程序开发之前，可能需要和UI,GUI,美术等设计部门沟通商议所需的交互设计，以及图形，图像需求，并且在提交策划设计文档的同时，需要征求和各技术实现部门的技术实现建议，合理的利用策划设定时间，最大限度保证产出的一次性质量和可实现度8. 第四次会议：目的：初步细化设计的评审初步的细化功能设计完成后，建议进行评审会议，需要各技术部门负责人一致确认，并对需要进行修订的细化功能设计概要进行修订和提交产出：评审通过决议，修订方案9. 之后则是等于游戏本身各项细化设计的循环迭代，包括具体的游戏模块设计，主要是游戏性方面的，其次是数值平衡的设计10. 策划设计工作流程中，需要及时更新，维护，通告文档的最新信息，任何需求的变更需要经过各部门信息窗口负责传达和实施，并且保留底稿和确认11. 在完成策划设计主要工作后，则可以关注设计变更的控制和管理以及用户体验测试用例的制定12. 用户体验测试，需要尽可能的搜集各部门信息资源，市场同类产品回馈信息，以及个人使用体会等，最大限度的优化和改进不合理的策划设计方案，并且及时提交测试管理平台13. 循环迭代14. 在产品面试以后，定期搜集或者获取市场反馈信息，或者根据市场部的需求进行用于可增加收益，提高用户体验感，延长产品生命周期等的策划设计，阶段性工作。15. 直至项目周期彻底终结程序部门：主要工作流程建议：1. 策划的原型文档接收根据原型文档的设计开发功能，并且保留不面市功能入口，保证原型可执行性，突出游戏最大特点2. 策划的细节文档接收原型通过后，根据策划的细化功能和各种系统设计，重新整合各项资源，深入开发各功能和系统的完善，与美术，动画，音乐等协调3. 根据开发使用模型决定版本发布周期和版本号规则，以便测试，策划和项目管理者的测试4. 版本的发布5. 需要提醒的是，在开发过程中，任何问题和技术困难应首先通过程序本身的负责人负责尝试解决，如果确实有阻碍，需要通过指定信息窗口传达意见和建议，或者申请会议商讨6. BUG的修订7. 根据测试团队所提供的bug级别判定改进时机，根据策划、市场等部门的反馈修订代码或者增加减少功能，需要决定BUG FIX的优先级.比如BUG 1 FIX的版本是1.1，BUG 2 是1.2,需要在测试管理平台里注明8. 在修订部分BUG后发布新的版本在新版本的change list里需要大概注明, 那些BUG被修订,又新增加了哪些功能,移除了什么东西等等9. 循环和迭代10. 产品面市后，可根据市场，策划等发布补丁或者升级维护11. 直至项目周期结束测试部门：测试部门的介入周期可以根据版本发布而区分主要工作内容ALPHA:游戏会从初期的设计转变为实际的成品.不断会有新功能加入到游戏中,这个阶段主要是测试功能实现是否与需求相符合.其中会包括到例如:控件功能的是否实现,美术资源整合正确与否等等.这个时候会比较关注很多基本的问题,可能不太会注意到细节Beta:对游戏具体细节内容进行丰富.这个事情的工作量最大.如MMO这个阶段会涉及到很多数值的调整.作为测试团队,这个时期要做的事情不光是对需求是否实现的把握,还要涉及到很多合理性的问题.如果一个功能虽然正确按需求实现了,但是在游戏中并不完全合理,这需要策划,开发,测试三方沟通,对这个功能或者系统进行调整.Release：产品推出后，后期的跟踪. 例如补丁,修复遗留问题等主要工作流程建议：1. 首先，要根据策划文档和开始的实现情况指定一个测试需求，根据这个测试需求实现具体的测试用例，比如具体测试的功能点，各种测试情况等，建立和管理测试平台2. 其次，等待程序部门的版本发布，期间需要体检主要测试用例评审，以及预估测试规划和期限安排，资源协调等准备工作3. 根据所获取的版本开始进行测试，不符合策划和测试需求的问题和BUG需要分类，描述所提交的BUG，所有提交的BUG在测试管理平台里面都是OPEN.4. 新版本发布后，测试部门需要根据change list对测试用例作出一些调整(也有可能没变化)，拿到新版本之后, 测试首要任务是回归测试5. 循环迭代6. 直至项目周期结束关于美术，市场和运维方面，我的工作介入不是太多，因为通过观察和总结，本人认为：艺术部门(包括美术，动画，绑定，音乐和音效等)一般需要其负责人制定并且发布工作任务，相对于技术类工种，艺术工作更加抽象和直观一点，直接说是凭感觉做事，而且也是相对独立的工种，很多时候无法完全以项目管理的身份或者非从业人的角度去指定工作流，而且本人参与美术部门的工作流程比较少，所以可能没有更好的想法，毕竟我没有从事过美术部门的具体工作市场部门，网络游戏与单机游戏对市场部门的依赖性各有不同，受众人群也不太一样，信息反馈途径和搜集途径不尽相同，市场部门也是相对独立的工作部门，可能对于项目流程本身的影响相对较小，但市场部门的任何意见和建议：一是需要通过合理的验证和具备可实施性，可操作性二是需要在尽可能合理的时间，用尽可能合理的方式（比如会议，邮件，审批等）与各部门协调和商讨，并且对决议需要备忘运维部门，游戏产品推向市场以后，运营和维护则为主要的负责部门，相对于项目开发周期内的工作流，也是比较独立的团队，本人对运营的工作内容经验尚浅，故不做具体的工作流程制定以上三类或类似部门的工作流程，可能由该部门资深从业人员制定更具说服力，并且执行力可能更有效果关于新进员工的流程化：对于新进员工，各部门负责人有义务对新进员工的以往参与过的流程熟悉程度进行考核，如果必要，可集中进行本公司本部门的员工培训，建立合理的流程化管理和培训机制，当然，在工作中熟能生巧，或者读书百遍，一样可以有利于新进员工对部门工作流程的熟悉和提高，同样，如果开题所述，公司内部员工对于流程化管理的认同度和执行度，很大程度也能决定新进员工对于流程化的熟悉速度和准确度建议制作流程规范书，流程表等纸张阅读材料2. 在各部门工作以及沟通过程中往往会有信息不对等的情况出现，会影响到整体的开发效率项目进度，如果你负责整体的项目进度，将会采取什么措施来规避以上问题出现，如果有以上问题出现如何解决？大致的方向性建议有：1. 信息的文档化管理,更新和编辑以及版本管理，备忘2. 邮件信息的确认，口头确认，确认回函3. 进度定时更新和发布公告4. 当日首尾工作内容确认，工作成果确认5. 集中会议管理，会议记录，确认，备份和回函6. 版本的集中管理，版本号的规则和同步信息7. 工作流接口衔接8. 培训具体的可执行性方法：1. 合作的各部门需要指派专门的联系窗口人负责信息的沟通传达，一般可以是工种中的领队或主管负责人，避免多点沟通2. 高效率的协作工具，共享和同步信息，避免网状的文件、信息传递，避免信息错位。例如 SharePoint的使用，outlook的使用，或者建立team site3. 如果一个部门的产出要被另外一个部门使用，一定要规范产出标准，需要有人审批合适和确立负责人机制产出，最好是使用模板和会议总结最有效的标准定义和文档格式，并且根据所使用的协作工具，及时做好文档管理和维护，通过口头或邮件方式确认阅读，要求反馈和审批4. 跨部门的决策、协作问题的确认需要双重确认和email确认5. 定期项目会议（如周会，晨会，晚会），总结进展和计划，确保参与的各部门信息同步6. 必要的时候请高层参与协调冲突和分歧 （这点慎用）3.网络研发团队的核心为策划、程序、美术、测试；在研发某个版本的过程中往往会出现以下情况：规定时间内开发无法完成指定版本内容，美术和策划的工作内容能够完成，如果延后版本发布日期给与开发足够时间则会导致美术和策划的工作不饱和并且后续测试没有足够的时间进行测试；如果按照版本时间要求程序提交版本则版本质量无法得到保证；如果是你，你会怎么做？1. 从规避的角度讲，规避，需要是从节点前开始规避，需要提前计划风险管理，并且尽可能的产出可预见性和可视性的风险，根据风险级别方案制定风险应对措施，在各项工作节点开展以前，做到心中有数2. 其次，接受和降低损失，面对现实，取舍价值，一个比较好的例子，波斯王子4代的后期开发因为不可预见的开发问题，导致游戏最终BOSS和结局无法再圣诞期间如期推出，衡量圣诞商战的项目利益和延迟发售时间的利害关系后，育碧软件坚持按照原计划推出游戏，改为利用风险反应时间以及游戏发售后的玩家体验时间，良好的市场公关和应对说辞，及时作出补丁，利用PC, XBOX360, PS3的网络下载优势，免费提供下载补丁，较好的将该风险带来的损害降至最低3. 当然，一个项目的所有风险是无法一开始就可以全部预估完成的，但在项目开发过程中，项目结束后不断的总结和学习，针对做得不好的，制定能够预防的措施也是必不可少的具体到可执行的方法上，建议有：1. 考虑开发部分砍掉一些不重要的或者次要的功能，确保发布时间点和版本质量（牺牲项目的功能范围）2. 增加开发人力，确保开发质量并按时提交测试（牺牲项目成本控制）3. 延长开发时间，增加测试人力，确保发布时间点和质量（牺牲项目时间）4. 如果质量、发布时间点、功能范围都无法妥协，也无法增加人力，那么美术策划的工作不饱和可以接受，这相当于使用更多的成本避免了风险（牺牲项目成本控制）5. 如果质量，质量、发布时间点、功能范围、人力成本都无法协商，那则无法完成该题目
展开阅读全文