独立游戏小发发
工作这么多年，遇到很多开发者会遭遇项目做不完的问题。复盘下来以后，会发现很多时候是因为缺乏项目管理的意识造成的。所以就想总结一下我遇到的开发者，以及我个人工作中学到的经验，跟大家分享一些比较基础，但是应该可以提升项目管理能力的技巧。
首先要声明：
本文里的建议通用且基础，需要根据团队实际情况调整。不同团队的构成不同，团队里成员性格不同。所以我这边能给的建议是非常基础的，具体要怎么操作和安排，还得大家根据自己的实际情况去思考，我无法直接给出通用并且有效的详细解决方案。
如果你还完全没有做出过游戏，也没有经历或者参与过任何的完整项目，建议你先不要考虑项目管理的事情。你先试试看参加game jam。或者用一些简单的引擎，自己搓一个非常非常简单的小游戏再说。因为做项目管理其实需要对各种不同的工种以及工种之间的协作流程有概念，对于一个完全不了解业务的纯小白来说，讨论项目管理是没有什么意义的。
本视频内假设是团队内的制作人或者主策来兼任项目管理工作。因为一般来说，在独立游戏的团队里，由于项目规模没那么大，并且人员也有限。所以是不太可能出现一个全职的项目经理的，那么大概率是由整个项目的制作人或者主策等业务能力最突出和全面，并且沟通能力强的人负责做项目管理的工作。
在分享心法之前，第1个问题是：
为什么我们需要项目管理？
省流：有了项目管理意识以后，游戏才比较容易被做出来。
有的开发者可能会觉得我又没有老板或者投资人需要我隔三差五去跟他们报告，我干嘛要浪费时间做项目管理，那不耽误我自己的开发时间吗？
那这点我同意，如果说你有这样的一个上级需要汇报的话，由于他们并不能天天盯着你的项目，所以他们就会需要你提供一些项目管理的证据，来让他们认为自己了解了你项目的进展，从而降低他们的焦虑。
但是撇开这一点的话，项目管理本身对于开发其实是有真真切切的帮助的。
首先最重要的就是——通过项目管理，能够让各位在有限的资源下把游戏做出来。
大家作为玩家可能没感觉，但是作为开发的话可能会发现——游戏其实是永远开发不完的，永远都有bug可以修，永远都有地方可以优化，永远都有新的玩法和功能可以更新。所以换言之，其实在开发者眼里永远不存在一个完美到的再也无法改动一丝一毫游戏。
不论各位的目的是确实想通过游戏赚钱，还是只是业余时间随便玩玩图一乐。共同的目标肯定是要把游戏给做出来。
如果说各位没有项目管理意识的话，可能就会走一步看一步，对于游戏完整版应该会是什么样的体量缺乏思考。就好像在跑一场你都不知道终点在哪里的长跑一样，要么累死在半路上，要么会中途放弃。
但如果说各位早早的树立项目管理意识，那么从一开始就可以对项目整体有更好的规划，从而增加这个项目被完成的概率。
那有人可能会觉得我做过game jam，我没有项目管理意识，但也也把游戏都做出来了呀，所以项目管理并不重要。那这个我觉得要具体情况具体分析，首先非常多开发者在game jam上无法完成一个游戏，如果一个团队能完成的话，其实这团队还挺厉害的，已经具备制作独立游戏的基础能力了。
但是game jam毕竟时间比较短，在时间比较短的情况下，就算没有项目管理意识也能把游戏做完并不奇怪。但是！没出问题不等于真的没问题，可能只是这个问题没被暴露出来。
我见过一些开发团队已经成功发布了好几款游戏，按说已经是很成熟的团队了。但是真的跟他们交流了以后就会发现，可能他们之前的某些成功是有非常多机缘巧合存在的，使得他们游戏整体很成功。而由于游戏整体成功了，所以大家只想着庆功，没想着复盘。因此也就没有意识到其实之前是有隐患的。然后他们带着这个隐患开始做下一个项目以后，到时候没有了那样的机缘巧合，那时候问题就会逐渐显露出来，然后他们就会发现产品做不下去了。
项目管理所需的意识
明确这个项目的规模
不论是为了兴趣爱好，还是赚钱。大概率开发游戏的时候都不会是game jam那样子短时间内冲刺的工作节奏。所以要考虑到游戏开发的时间可能会横跨几个月到几年不等。面对这样一场持久战，就需要给自己画一个终点线，不然就会像我前面说的那样，要么累死，要么半途而废。
而这个终点线就是项目最终的规模预计是什么样的。最好是找一个体量上可以对标的参考游戏，给自己一个更好的概念。
比如说一个20万字的视觉小说，里面大概有多少角色，多少cg。预计游戏时长有多长时间。
比如一个单局流程在10分钟左右的卡牌肉鸽游戏，预计需要多少角色，多少敌人之类的。
明确你能花多少资源在这个项目上
定好上面的目标以后，再来考虑一下你有多少资源是可以花在这个项目上的？
这个资源包括你的金钱成本，时间成本，以及我觉得还应该包括你们团队的干劲。毕竟如果干劲没了，那就算你还有钱和时间，这个项目其实也很难做下去了。而且干劲这个资源是很抽象的，不像时间和金钱是只会流逝，而是会起起伏伏的。
我一开始说了，建议各位自己做过一个小游戏，或者参与过游戏开发流程以后再考虑项目管理的事情。所以这边就到了，需要大家应用自己开发经验的时候。
比如说根据各位预期的规模，这是个20万字的视觉小说，并且你自己又能画图又能写字，可以算一下你自己如果要画图画一张图得多久？然后你自己如果在灵感爆发或者灵感枯竭的时候写字，一天能码多少字？
这样计算过后，建议整体预估的时间至少再翻个倍甚至翻三倍。毕竟不可能一气呵成全部做完，中间必然会卡壳，修改，放假，摸鱼等等。
那算上这些时间以后也许你会发现——什么？！这个游戏我如果一个人做的话要做10年？！然后你非常清楚，你不可能有那么多干劲。所以你觉得得把这个时间缩短到一年才比较靠谱。那对应的就是要么缩减项目规模，降低工作量。要么花钱雇人，或者找合伙人一起来分摊工作量。哪些资源值得花钱，也是需要去前期调研一下估个价的。然后再考虑一下，你能不能支出这么些个金钱成本。如果不能的话，你是愿意牺牲质量，还是进一步缩减工作量。
制定里程碑，定期评估游戏
有了整体的时间框架和项目规模以后。最好还要制定一些里程碑，通过里程碑的完成情况以及里程碑版本的表现，决定要不要调整后续的计划。
比如各位可以制定一个每月开发里程碑。假设游戏整体的剧本有20万字。一共10个月的开发时间。其中7个月用来开发，3个月用来优化和打磨。那么7个月写20万字的剧本，差不多就是每个月要完成3万字的剧本量。对应的可能会有一些配表或者素材图等方面的其他工作。
然后每个月回顾一下，看看有没有完成这3万字的剧本量。如果很明显延期的话，那么整体的开发计划可能就要调整，再次提出之前的问题——是要砍内容，还是要延长工期？
并且不要光看完成数量，还要看质量。如果发现质量很差，玩起来真的就是毫无乐趣。此时要考虑的就是这个项目是不是应该砍掉了。
砍项目可能会让人觉得浪费了很多成本，很可惜。但是如果作为项目组自己的人，在理应能够顺着当前的版本去想象完整版游戏体验的情况下都觉得这个游戏很不好玩，那么尽早砍项目止损，反而是一个综合来看亏损更少的方案。
我们见过很多开发者在开发者大会复盘失败项目的时候，表示早期的版本他们给朋友玩，得到的反馈是不好玩，但是想着往里面填内容就可能能改善了。于是整个团队硬着头皮填内容，不断对自己说，只要再加一些内容，可能游戏就会变好玩了，结果到最后也没有变得好玩。但是此时的沉没成本却已经变得更高了，让大家更加不敢下手砍项目。
你无法把100%的时间投入在研发上，最终还是要为测试、验收、出包预留时间
有了成本压力以及项目规模这几个要素来回切磋碰撞以后，你慢慢的就会预估出一个更加可行的方案……吗？
事实是，你是不可能把100%的时间都用于写代码，画图，写文，作曲和配表上的。非常多开发者会忽视的就是qa测试和整体验收。不论开发是自己做qa测试还是找玩家或者qa外包。那也都需要预留时间，而且需要提前出版本。
而且如果qa测试或者验收之后发现体验不好，其实还要花时间去修bug和优化游戏，甚至大改设计，会花费大量计划外的时间。
如果有人头自信说我就不做测试直接上，而各位的游戏确实如愿爆火的话。那很有可能游戏刚发售就会面临大量bug所带来的差评。然后影响游戏初期的口碑和发售期间的转化。就变成了开发要在游戏发售期这段时间每天疯狂加班修bug。并且要争分夺秒，尽快把更新发布出去，来挽回发售期里的玩家口碑。
对于任何突然冒出来的，不知道该谁来干的活，那就是项目管理者的活
游戏开发过程中可能会面临各种意外，比如你突然发现一个插件不维护了跟不上最新的引擎版本。突然发现一个游戏比赛值得参加需要花时间准备报名资料等等。
一般来说面对这种突然冒出来的意外，就是需要人拍板的。而有能力和权力拍板的人，大概率也只能是此时正在做项目管理工作的制作人或者主策。并且这些意外可能会影响整体项目的计划，所以也确实应该让项目管理这个把控整体项目开发进度的人来决定。
一些项目管理工具
用git，svn等工具来管理工程
如果大家是线下game jam做游戏的话。很有可能就那一个程序，然后是其他美术和音乐等人通过qq或者微信之类的，把所需的素材直接丢给程序，去合进工程里。
这种做法在game jam这种着急的情况下是可行的。但如果说大家仍然是团队作业并且要长时间开发游戏的话，还是建议要通过工具来管理工程。一方面是方便查看历史记录，另一方面就是，如果工程只存在于一台本地电脑里，而你们的开发周期又非常长，万一这台电脑出了什么幺蛾子怎么办？
用teambition，trello或者飞书多维表格来管理开发工作
游戏开发过程中是有很多很琐碎的工作的。除非团队里的人极少，沟通又非常积极频繁，而且每个人记忆力都是过目不忘的级别。不然我都建议各位通过项目管理工具写单子，把要做的工作记下来。
之所以推荐这几个工具，是因为可以设置逻辑以不同的分组方式来清晰展示工单。而且这几个工具使用起来很方便，拖动也很灵活。项目管理还是要尽可能方便的好，不然如果项目工具本身就让人觉得用起来很复杂很缓慢的话，就会非常影响大家共同参与到项目管理工作中的积极性了。
在展示工单方面，比如可以按照职能划分，什么程序策划美术。策划这边单子做完了，就把单子拖到美术的泳道里，让美术对应去做图，然后美术图做完了以后，再把单子拖给程序，去把图导入工程里。
或者是按照功能开发情况，比如什么未开发，正在开发，等待验收，验收完毕等待测试，测试完毕等。
有这样一些清晰的工单，大家就能更好的量化自己的工作，目标感和成就感都会更强。也比较利于大家恢复干劲。
那以上就是项目管理的一些基本注意点。如果各位此前完全没有做过项目管理的话，可能会觉得这些事情有些无从下手。这个时候就请大家回想起项目管理的根本目的是为了各位能把游戏在有限的资源内做出来。
只要能实现这个目的，各位不论用什么稀奇古怪的招数其实都可以。大家可以怎么舒服怎么来。
但总之一定要有项目管理的意识。哪怕后来发现项目计划定的还是不合理，对于工作难度的预估仍然不准确也没关系，其实这非常正常。毕竟我工作这么多年，跟那么多开发者合作下来也发现了——就算是工作十几年的老兵，他们也估不准的，只能说可能可以比上次准一点而已。
但是只要每次都能比上次更准一点，那整体就会越来越准，对成本的把控就会越来越清晰，然后就能在同样的资源限制里，尽可能做出更多的内容。让各位的开发成本花得更值。
