版本管理
版本延期的原因
- 开发过程中有不断新增和调整的内容。
- 开发完成的功能质量太差，后期花费大量时间修复和优化。
- 沟通不及时，前期策划不主动推动功能进度，后期测试不推动问题修复情况。还有将策划工作分为系统、数值、界面UI几块，但是没有人总负责，所有人都只完成自己部分的工作，甚至配好了数值，都不去实际功能中跑跑的。
- 团队人员变动，核心人员请假或离职。一到发版本就请假出行的主策划。
- 工作量超出预期。
- 前期的工作delay导致影响后续内容。
- 设计文档delay，没有文档就不应列入开发计划，最好设计本身也要跟开发核对评审后才能列入开发计划之中；
- 美术资源的delay，用临时资源替代，策划及早跟进
- 程序开发的delay
- 测试反馈问题不及时，严重bug后期才发现。尽早单服测试，提高集成测试，补充上线测试。
- 优化性能。这个是最难估计时间和方案的。
- 客户端服务端的代码是分成两个代码库进行管理的，有些使用相同的配置文件要分别提交。
- 任务分配不均。
- 不懂得评估重要性，分配优先级。所有人都会觉得自己要做的事情就是最紧急重要的，但实际上整体规划上肯定是有个核心的，只有越接近这个核心的内容才是越重要的。
- 前期策划对资源产出、消耗，历程体验的重视程度不够，觉得这些都是小问题，后面全部内容堆完了再梳理都来得及。却不知道到了后期，内容太庞杂，很多内容交织在一起，甚至有些历史设定都忘记是做什么用的了，改起来总是大动干戈。
- 一些测试新人对功能质量的责任感不强，或者说因为缺乏经验风险意识不强。发现的问题，策划或程序稍稍一解释就觉得以后可能就能按他们所说的那样，没有问题了。
- 策划觉得数值体系设计好了，配置完就是ok了，但实际体验起来会有很多问题。
- 思考不成熟的设计，花了很大功夫做完后，后来又不要了。或者是前期思考设计的时间太长，挤压了开发和测试的时间。
- 修改随口说，不提单，也不修改文档，最终导致设计文档与开发实现不一致。
- 代码重构，UI底层代码框架调整，UI资源换版等，这些都会产生远超预期的工作量。
- 工作懈怠，策划程序都不主动推进自己的工作，只是被动完成他人安排的工作内容，等着别人提问题才动手改。
- 长期无目标性的加班，当所有人都把加班当作一种习以为常的制度之后，磨洋工是必然会伴随而来的一个结果；工作效率高的人早早做完了会发现也还是需要继续陪着大家加班，还不如慢慢做，加上周计划执行不严格，开发进度delay几乎是无法避免的，如果能管控好每周的工作内容，并建立明确的加班规则（按时按量就可以不加班，未完成自己加班），等于是将不加班作为了一种奖励手段，可以鼓励大家提高工作效率。
- 策划验收质量不高，有很多需求尚未实现或实现方式还不确定。
- 有些界面层级或UI适配的问题，在PC上测试无问题，在真机上才有。所以也要尽早进行真机测试。
- 有些功能不配置就不生效，结果有些新增或修改后就很容易忘记配置，导致功能异常。最好是默认有个统一的处理规则，然后有特殊需要的再进行配置。
- 想要做ios和android、pc、web四端混服，这就给发版控制带来很大的难度。ios的审核时间很长，而android的渠道又很多，很难形成统一的更新，大家都进同一个服务端，服务端更新早了，有些平台不能进，更新晚了，有些平台先更新了也不能进。
- 前后端连接时没有做协议是否匹配的检查，只有出错了才说版本不匹配。
有效的管理办法
- 将工作量尽可能分解到周。
- 善用工具，例如用redmine做需求和bug管理，也便于统计整体情况。
- 测试帮忙接手一些服务器环境的搭建和维护。尤其是搭建测试环境时，要尽量与外网正式环境的配置一致。比如外网的服务端架构是有多个server进程，而开发为了方便自己的开发服只启动了一个server进程，结果测试在多个server下发现的某些bug，开发在自己单server服里无法重现。
- 开发和测试环境尽量彼此分开，互不干扰。
- 策划尽早验收体验，如无必要不要随意变更需求，且影响较大的需求应重新列入开发计划。
- 问题分优先级，逐步解决，过程中加强跟进。
- 不要有太多特殊规则的处理。
- 一定要注意将大的版本内容和临时增添的小需求区分开进行管理，主要也是为了区分优先级。
- 要设立明确的阶段性，从时间角度上，有多少准备期可以用于评审文档，评估工作量，完善设计，执行期有多少可以用于开发、联调、配置，验收期有多少时间可以测试、修改bug、优化体验等，最后就是收尾期了，什么时候给到最终上线的产品，并完成上线前最后一轮检查。而从阶段目标来说，准备期要确保人员、设计方案、工作量评估的完成，执行期要确保主要的模块和流程的可用，不是完成，而是可用，缺少的配置可临时替代。验收期就要确保产品无质量问题，不应再有大的修改，而收尾期就是要禁止任何修改，代码库要封闭，切分支等。
容易扯皮的地方
需求的必要性。很多时候策划真的会脑子一热就决定要改点什么或者做点什么，哪怕这些修改听起来是真的在解决问题，但需要注意的是问题本质是什么，会不会解决眼前的问题引发新的问题，或者将解决的方法想的太简单了。还有就是不重要的事情能不做则不做。，千万不要松口说什么时间挤一挤还是能做些低优先级的事情的，作为项目管理者，说出这样的话一定是不负责的。低级的事情做的再多，都比不上一件高级的事情对产品带来的影响大。牢牢记住产品的核心是什么，这在做产品之前，就应该与主策划或者制作人确认沟通过了，所以才能立项做项目。如果后期执行过程中偏离了这个目标，你要能够提醒，必要的时候要进行阻拦。
排期。整个大的版本内容里的排期这不用说了，临时的需求调整，哪怕再小，也要排期，这个排期不是说一定要先排期才能做，重点是在于记录。哪怕修改真的很小，只是改了两行代码，但只要对产品功能产生了改变，都要记录好。如果改变比较大的，一定要先排期，优先把更重要的事情做完后才能做这些。前往不要给策划养成“想改就改”的毛病。我一直秉承一个态度，策划作为设计者，在设计初期就应该将方案尽量想的完美，评审的时候大家也应尽早提出可能存在的问题以及解决办法。如果出现开发过程中较大的变更需求，这就可以说是与“线上事故”相当的“生产事故”，负责设计的策划要承担主要责任，主策划和评审小组要负次要责任，而且一般不会额外安排时间工期，要么功能改期，要么这帮人自己加班加点搞定，不要占用额外的时间。
风险和预期成效。有时候有些问题只是可能存在，但可能存在也要提出来，并准备好一个应对方案。有时还会有策划或运营提出很强烈的修改主张，那么也要提前沟通要这修改可能带来的成效，并进行记录。但凡影响到执行计划的话，都要提前沟通和记录，如果造成延期的，要进行一定的反思。
沟通。首先要目标明确，其次要注意听别人说，重要的信息要通过邮件进行广播通知和备案。先说结果，再说原因。懂得讨价还价，因为作出一些“让步”会让别人觉得受到了尊重，心理上也会有所满足，但原则性的问题一定要提前沟通好，甚至要留下可操作的空间。
管理工具
计划表是整个项目的，然后分解成每个工作要做的内容，于是就有了每个工种自己的进度表。
进度表
需求/bug管理平台：jira、redmine、禅道这些都可以。