一、产品经理为什么要管理项目进度
大公司可能会有专门的项目经理去进行项目进度的把控，初创型的小公司可能是CTO兼任，但是CTO可能在开发的过程中为了尽快上线砍需求，最后做出来的东西质量堪忧。一个项目，有明确的开始和结束时间，有明确的质量监控和要求，有明确的投入和产出预算，这些是项目管理的核心。但也应该是产品经理的责任——如果产品经理不考虑时间，怎么能够按时上线产品?如果他不关注质量，怎么能够推出受用户欢迎的产品?如果他不考虑投入产出比(这个恰恰是很多技术出身的产品经理最不以为然的——好东西要舍得投入)，就有可能浪费公司大量的人力、物力和时间。
二、产品经理如何管理项目进度
1、拒绝业务频繁的更改和插入需求
市场部门今天提出一个需求，过两天感觉成本可能会有点高，需要改一下规则；老板今天冒出一个想法觉得这个不错，需要做一下，明天又有一个新的idea要加上。这个时候你作为产品经理就需要动之以情，晓之以理的说服业务部门。
你可以说：“1、你的一个小小的规则变动可能导致技术之前做的功夫全部白费，打击士气，丧失技术对你的信任，说不好还需要买个人身保险。2、如果这样变化的话，可能会导致整个项目延期，无法及时上线，你看你是否能够接受“。
对于老板插入的需求你可以说：“您提出的这个需求很好，很符合我们的实际，为了不拖延项目进度，可以在下一版本进行规划“；
你还可以用数据来说服老板，暗示他提的这个需求和我们现在的实际情况不符。
总之一个原则就是产品项目进入开发阶段以后就不要再频繁变更和插入需求。
2、可以提前规划一两个版本
产品的迭代是有一条循环的流水线的：需求发掘-版本规划-原型策划-原型评审-UI 设计-开发-测试-发布。一般而言，为了效率最大化，我们都会争取做到相邻的两次迭代之间能够无缝对接。也就是流水线上每一个环节的人在完成了当前版本的工作后，就能立即执行下一个版本的需求。
产品提前规划有个好处就是当你觉得技术在当前版本开发有余量的情况下，可以将之后版本的需求拿到当前版本进行开发。
为什么不提前规划5-6个版本。一般来说一个月迭代两个版本已经算快的了，提前规划5-6个版本，就提前把3个月以后的事情规划了，互联网瞬息万变，这样规划显然是跟不上市场变化的。
3、明确每个版本迭代的目标
每个版本迭代都是有目标的，例如互联网电商产品的目标可以分为：拉新、留存、转化、销售。所以你规划的时候就要考虑你这个版本的主要目标是这四个当中的哪一个。
这样做的好处就是在你项目时间不够，需要做出取舍的时候，能够轻易的做出取舍。例如：资本寒冬的时候，推广成本居高不下，这个时候你下个版本的主要目标是留存，那么当你项目实现不了，需要砍需求的时候，你就可以把不相关的需求砍掉，确保你的项目顺利上线。
4、MVP原则
最小化产品原则需要你在规划版本的时候考虑产品功能的延展性，需不需要在一个版本里面把所有的功能都做完，可不可以分几个版本迭代来实现。例如你规划一个金融社区，前期是不是可以只做用户单点评论功能，在以后的版本再做用户和用户之间的互动。
最小化产品原则不仅可以快速验证市场，同时也能更好的控制项目的开发周期。
5、产品经理不要频繁变更需求
很多时候产品经理在规划产品的时候异常情况没有考虑清楚，很多情况没有没有考虑到，导致在技术人员在开发的时候需要不断的找产品经理确认，无形中增加了沟通成本，延长了开发周期，尤其在沟通不顺畅的情况下。
这就要求产品经理不要急着出文档去开发，一定要深思熟虑，考虑周全。
这样做有两个好处：
1、增加在开发人员心目中的威信，更利于在工作当中的沟通
2、开发过程中你会很轻松，不会有开发人员不断地找您确认需求，有利于项目的快速进行。
6、制定明确的项目管理计划
制定明确的项目开发管理计划。
第一、需要明确目标。项目什么时间封包、什么时间上线要有一个一致的目标。
第二：制定详细计划。有了明确的目标以后就需要制定开发计划。产品出需求需要多久、设计需要多久、开发需要多久、测试需要多久，出一个时间节点。
这样做有三个好处：
1、这样会给各个部门一个压力。
2、同时当你老板问你项目进度的时候你也有地方可查询。
3、你自己对项目进度也有一个大概的了解。

甘特图进度计划

7、对开发成本有所了解
上面提到产品经理要制定项目管理计划。如果产品经理对开发成本不了解的话很容易被开发忽悠，导致开发的周期过长。同时对技术的了解，有利于和程序员进行沟通，减少开发过程中的沟通成本。同时对技术的了解，有利于在产品规划的时候了解技术的实现成本，做到规划的时候有的放矢。
对开发技术的了解当然越精细越好，如果达不到专家程度，至少也要达到半骨灰级的程度。
8、项目进度的Review
项目进度计划做好以后，把项目分配给每个人，但是你不能保证每个人都能在时间点之前完成任务。产品经理可以每天举行几分钟的站立会议，了解一下项目的进度，是否会有延期。如果延期，原因是什么？如果是不可抗因素，则重新评估开发的进度计划；如果是可抗的因素，则要求在后续想办法赶上原计划的进度。

团队协作视图

如果不实行每天的站立会议，可以分为两次review。第一次review主要看进度是否跟的上，如果跟不上是及时调整还是需要加把劲追赶。第二次review主要是是评估那些问题可以暂时搁浅，那些问题必须解决。
在和他们沟通进度，尤其在他们没有完成的时候不要训斥他们为什么没有按进度完成，要帮助他们解决问题，给他们梳理一个愿景，描绘一个美好的目标。别人尊重你，你就是PM。别人不搭理你，你就只是一个P。
9、敏捷开发的PRD文档
我这里所说的敏捷开发的PRD文档是指原型+标注形式的文档。说实话，你写的冗长的word文档不仅耽误你自己的时间，开发也不一定会看，即使看了，也不方便。开发一般直接照着产品原型来开发，这个时候就需要你有一个敏捷开发的PRD文档。敏捷开发的PRD文档包含版本迭代历史、功能list、异常情况的说明、全局结构图和重要的流程图、第一次出现的名词解释，这些不能少，否则你的PRD不是一个完整的文档。
10、良好的沟通
项目成员包含设计、开发、测试人员。你需要和这些人良好的沟通，和设计人员沟通你要有感性思维，有审美能力。和开发人员沟通，你需要有技术的逻辑思维、测试人员一般比较严禁，和测试人员沟通你需要有严禁缜密的思维。
和他们沟通项目进度的时候，如果你让成员不必为他所说的话负责任，你就能得到负责任的回答。如果把自己和工程师当成上下游的关系，把工程师对工期的估计当作对自己的承诺。“30天才能给你。”“不行，我15天就要。”这不是沟通，这是对立面的谈判。道已错，追求术有什么用？
真正有效的办法，是让彼此间的沟通，永远不会成为日后扯皮时的证据。这样才有利于拿到最真实的信息，方便作为正确的判断。
11、使用团队协作工具
工欲善其事，必先利其器。良好的团队协作工具能够减少团队成员之间的沟通成本。比如说通过统一沟通渠道从而节省时间、避免重复沟通，自动同步信息等等。市场上的团队协作工具不少，找一个适合自己团队目前状况的，团队成员大多数都用过的。因为项目协作工具大同小异，基本上可以满足你的团队协作需求,比如国内比较好的工具 Teambition、进度猫。
12、有变化及时沟通
项目在做的过程中难免会出现变化的地方，变化不可怕，可怕的是变化之后其他成员不知道。你试想你更改一个需求，技术不知道，技术还是按照之前的需求进行开发，等快开发完成以后，技术知道需求变了，会不会有杀人的冲动？
其次能当面沟通就别打电话，当打电话就别发邮件，一切以沟通高效为主。
人少的时候，同步变化其实不是什么困难的事情，但人多的时候就有难度了。虽然很多协作工具都有文档更新通知，或者文档本身就有修改记录。但即便如此，也会有很多人忽略这些变动。在同步变化上，除了确保文档及时修改、告知相关设计师、工程师和测试人员以外，我还会单独召集各平台的 leader 进行简单的站立会议，提醒其确认变更是否已安排执行，同时也相当于交接了监管的责任。
总结：上面就是个人在实践中管理项目进度的一些感悟，管理项目进度不是一朝一夕的事情，需要在项目中反复的实践。