刚开始从事项目管理工作那会儿，对于制定项目计划常常有这种感受：都是开发和测试说了算。他们说需要三天，就三天，他们说什么时候上线就什么时候上线。这种执念一直纠缠着我，有一段时间也曾非常的纠结于这一点，甚至一度觉得非常失落，开始怀疑自己的价值。
项目经理并不是在项目计划上可有可无的角色，也不只是帮大家画个时间线这样的角色，只是项目经理在这上面的作用不是那么显性，但却是不可缺少的。但是随着经验的增加，经历的项目增多，在这一点上渐渐有了些新的体会：在项目计划上，项目经理能做的还有很多。
首先介绍一下，当前笔者所在团队是如何做计划的。需求确定之后，开发会根据需求分解任务，对于不同的任务，进行估算，并且确认提测时间。然后将安排发给测试，由测试补充各任务的测试时间以及回归、兼容性等测试的安排，从而制定出初步的计划(包含上线时间)。
初一看，完美!团队自己就把计划制定出来了!有项目经理什么事儿?!其实不然。下面跟大家分享一下，笔者认为的项目经理能在这过程中起到的作用。
1. 确认版本周期
计划的时间点需要根据开发的工作量评估来确定，但是项目经理需要确定这个版本大概的周期是多久，是一个两周版本还是一个一月版本。在开发开始评估工作量和确认提测点之前，项目经理就要将版本周期情况同步给团队。影响项目经理确定版本周期的因素往往有：
上个版本的情况：如果上个版本刚刚经过一个非常紧张的大版本，有不少小的优化功能未能上线或者大版本上线后用户反馈了一些比较影响体验的问题。那么下一个版本项目经理就有可能考虑发一个较小的版本，将这些优化和问题尽快上线。
运营推广计划：某些版本可能是配合运营推广的计划，那么在确定版本周期的时候就要考虑到这一点，确保移动端通过审核的时间能够满足推广需求。
与其他端的配合：某些版本需要多端协同的，那么确定周期时就需要考虑到其他端的发布安排。
2. 完善和优化团队给出的初步计划
开发和测试给出自己相关任务的时间点，但是对于一个项目来说，这些还不够。这些往往会被团队所忽略的，包括但不限于如下几点：
安排多提测点：刚开始的时候，开发会习惯给出一个最终提测的点，这对尽快交付并不是什么好消息。所以项目经理需要去跟开发一起梳理，是否有一些功能点是可以提前交付的，这样测试就能提前介入，从而缩短研发周期。
需求冻结时间点：几乎在每一个团队中，需求变更总是被开发和测试所诟病。对于需求变更，我们不能完全说不(一来是要应对市场的变化，二来我们也理解在策划阶段总是有一些未知的问题)，但是不是任何时间提出来的需求变更我们都接受的，我们认为在某个时间点之后再提出的需求就会影响版本的顺利上线，那么我们就有可能拒绝。这个时间就是冻结时间点。考虑到这个时间不能太早也不能太晚，太早不切实际，太晚又影响计划。所以我们定义的需求冻结时间点是在最后一个提测点之后的一天。
数据埋点的安排：埋点一直以来都被开发认为是最不重要的工作，无所谓什么时候做，只要在上线前埋一下就行了。但是有一次埋点就埋出了问题。那次是在上线前一天，在最后的版本开发做了埋点的工作，最终导致了软件出现崩溃的问题。自那次以后我们就约定埋点要尽快进行，不能等到最后一天。但是埋点工作也常常在计划阶段被遗忘，所以就需要在计划制定过程中给开发预留一部分工作量用于埋点，同时明确埋点完成的时间节点以及埋点验收完成的时间。
代码冻结的时间点：所谓代码冻结当然就是代码不允许改动了，因