项目启动
一个项目启动，首先是要有发起人，发起人确定产品形态，然后跟相关人员（比如股东等）确定需求是否接受（是否好玩）才确定是否要做。
之后如果可以需要做市场调研，确定需求是否能被玩家接受。是否有玩家公认的不合理的玩法，然后调整产品形态，这相当于第一次市场调研
人员集合
所有确定可行后，需要首先确定策划，美术，程序的负责人。理论上策划要先找到，然后找美术和程序。
demo阶段
策划需要细化细节，把核心点确定好，包括策划文案，数值，交互，体验，然后程序需要确定技术选型，根据策划的需求选择合适的技术方向，策划产品形态出来和确定想做的美术风格后再根据所需要的风格招主美。主美到了后需要做一些美术原型以及跟策划敲定角色场景相关。
之后要跟主策，主程，主美确定demo时间。排具体的期限，具体到天。
时间管理
时间上基本有预研时间，逻辑开发时间，ui拼接时间，性能优化时间，自测时间，合并时间，corereview时间，管理buff时间。
如果有要预研的技术需要有预研时间，预研ok后，可接受后就要确定逻辑开发时间，ui拼接时间，性能优化时间，自测时间，合并时间，corereview时间，管理buff时间。所有时间都要有具体的天。
制作demo
晨会
每日晨会确定昨天做的内容和今天要做的内容，并把晨会内容记录下来发邮件给大家。跟之前的时间比较，如果是小时间变更或任务顺序变更那也记下来并调整进度表。如果是需求变更或大的delay就需要走需求变更了。需求变更需要跟相关方确定这样做是否可行，是否能接受delay，是否要加人力之类。
周会
每周周会可以做个周总结，总结这周出现的问题，和可以优化流程或技术的方案。记录下来发邮件。相当于一个小复盘会。这样可以不用等迭代出问题了才来调整。
demo初步形成
在上面的流程下完成demo完成后，需要跟相关方确认产品是否可行，是否达到预期。如果没有是否要优化方案，给到优化方案建议，继续上面的demo开发过程。
如果可能最好也做一份小范围市场调研（注意保密），看看demo是否可接受。
直到达到相关方预期，并且市场调研结果可接受。说明这个产品已经有价值了，就需要加大投入进行产品迭代开发了。
产品迭代期
进入产品迭代期，策划需要先行确定产品具体需求，比如要哪些系统，增加什么玩法，商业化方案，跟相关方确认了需求没问题，要做的是正确的后。开始细化到细节，输出文档。程序或技术美术需要制作一份美术规范给美术做日后的输出规范。
需求评审
然后拉上美术程序测试等等一起开需求评审会，需求评审会是对需求细节的评审，策划描述需求的细节和为什么要做这个需求，然后程序和美术如果有疑问或难点需要提出来，策划再确定是否要修订。
时间确定
需求确认无误后程序和美术需要确定完成时长，然后项目经理需要根据任务开始时间，完成时长，任务依赖来确定完成时间，时间的敲定同样遵循预研时间，逻辑开发时间，ui拼接时间，性能优化时间，自测时间，合并时间，corereview时间，管理buff时间。
时间吻合度
项目经理需要确定所有任务的完成时间和相关方的时间是否吻合。汇报给相关方，如果时间线不吻合则要有两个选择，一是修改需求，修改成可以接受的范围，也就是减少一些开发的需求或简化需求。另一个做法是压缩需求开发时间，加班解决（当然是在特定紧急情况下才用比较好，人员反感度比较高）
正式执行
美术和交互设计，他们需要先行根据策划需求完成美观体验。然后跟策划确定这个美术和交互可不可以，可以了就可以输出给程序或交互开发。
同时程序需要确定逻辑和ui，逻辑可以先行开发（跟界面无关的内容），跟交互相关的需要等交互确定后才能开始。这样也可以让程序更多想着逻辑表现分离，更合理。
然后项目管理还是按照晨会周会进行项目管理。
产品初步确认
程序完成后或在产品有形态后要及时跟策划交互，多确定是否是想要的东西，然后不断的做调整，无论是程序调整还是策划调整，如果出现问题比较大或没考虑到的内容要做大变更需要拉会议跟主策主程主美运营等确认是否接受。
测试阶段
完成需求后就要给到测试去测了，测之前需要做测试用例的分析会（这个会可以在开发到快结束时做而不需要等到完全好了再做），需要程度测试一起确定要测试的内容有没出入还有有没遗漏的内容。
到测试阶段就是测试系统的测试需求，走各种流程来验证玩法，并且不断用自动化去跑。测试也可以分几个测试内容，玩法测试，系统测试，流程测试，性能测试等。最终输出测试报告，确定现在项目的bug情况，跟策划和相关方确定现在这些未解bug是否可以接受，可以接受的话就进入运营阶段
运营阶段
运营除了自身要做的运营工作外还需要把包发到指定平台上，上线时间之类的运营决定。包括线上bug收集，线上玩家反馈之类的收集都需要做。
体验服
当然这里遗漏了一点就是如果有很大的技术调整或觉得有风险的需求之类的不确定性内容，最好能建一个体验服，体验服让玩家知道就是可能有bug的用来给玩家尝鲜的服。然后发到这里去验证玩法和技术是否有问题，收集玩家的反馈。
需求池
另外项目应该有个需求池，这个池子存的是相关的策划需求，运营需求，老板需求，技术需求，美术需求等等。然后有个完成时长和优先级。
主程序需要根据需求和当前项目的状况，确定是否要加技术需求，比如预研，性能优化，工具开发等技术需求，美术需要提出美术修改需求。
丢到需求池，需求池根据需求优先级排列，和这期版本需要上线的时间确定要做的需求。每个迭代从需求池中拿需求进行开发。
及时复盘
如果有重大问题，一定要及时复盘，让问题尽早从流程或技术上解决。
总结
开发项目风险是必然存在的，我们需要的是控制风险到最低程度，所以流程就很重要了，上面其实就是一个项目的流程控制。还有任何变更都是存在风险的，都要谨慎对待。