项目进度问题一般在一个小团队中不会表现的特别突出，因为这时候团队所有成员的目标都比较一致，并且由于人数较少，沟通成本也较低，对于磨合的较好的团队，这时候可以遵循小步快跑的方式，不断打磨产品。对于刚入门的产品经理来说，这段时间应该是产品生涯里最快乐的时光了。
但当团队规模扩大到二，三百人时，由于系统更加庞大和复杂，任务会被拆分给到更多的人去做，原来的简单沟通模式被无情的拆分，于是人和人的关系变复杂了。这时候，看起来简单的一个小功能很可能会牵一发而动全身，涉及很多的人。于是项目推进就不是靠晚上一起吃个饭能简单的解决了：人太多，你请不起啊。
既然本文是在教产品经理怎么推进项目，那么我们先聊聊项目是怎么运作的。不管是有钱的出钱还是有力的出力，在软件开发这种需要抽象逻辑的脑力劳动面前基本是无效，因为他需要的是专业技术人员不断的共同协作才能完成。而协作的过程其实就和打篮球一样，对于每个人参与者来说就是一个传接球的过程。
你接到了一个球(任务)，运球(做任务)，传球(把任务抛给下一个人)。所以每个项目参与者就做3件事儿，接到任务，完成任务，传给下一个。在完成任务的过程中，如果碰到问题无法继续，就像运球时半路有人拦截，这时候也必须要把球传给能解决这个问题的人。对于项目参与者来说，核心使命就是按时按点的把球传出去，只有传出去了，你的使命才算完成。
需要重点说明的是什么叫传球，所谓传球我们可以理解成交付，也就是上家对下家的一个产出结果的交付。
例如，产品经理对开发以及设计团队的交付是一个说明详尽的产品需求文档，UX/UI对开发的交付就是设计完整的交互稿，视觉稿以及切图。而后端开发人员对前端开发人员的交付就是安全可用的接口以及详细的接口文档，而前后端开发人员对测试人员的交付就是提交到测试环境的代码，测试人员对部署人员的交付就是没有问题的测试结果，而是有问题的测试结果则要交付给前后端开发人员。
当然并不是所有的传球都是一个明显的产出结果交付，也会是一些信息告知，例如，开发人员在开发时碰到了第三方安全证书问题需要产品经理去解决，这时候的传球可能就是一个邮件告知一下产品经理项目遇到障碍，需要产品经理去解决，于是球又传到产品经理手上了。
到这里我们知道了项目的本质就是多人进行的一个传接球过程，每个参与者就是做好3件事儿：
接球–任务
运球–完成任务
传球–交接给下一个
但有时候由于任务的不明确，或者分工的不明确，或其他各类原因会导致球在传递的过程中球一直停在了某个人手中，而无法传到下个环节。怎么办呢？
这个时候，对于产品经理来说其实也只要做3件事儿，
接过球
清理障碍点
把球重新传出去
重新传出去时，也许就不再按原来的传递路径了。有些产品经理在项目进入停滞状态时，会变得很焦虑，会去不断推项目执行者，然而并没有任何效果，因为障碍是事实存在的，不解决是不会真正让项目继续前进，强推的结果只是会让结果失控。
障碍的清除其实也是遵循传接球原则，找到问题点以及可以解决该问题的人，然后把球传过去就可以。但有时候，传球对象不一定好找或明确，就需要你不断的传球试探，直到找到一个可以接球的人。能够顺利清理障碍当然是一件好事情，但是作为产品经理者应该在项目开始前就尽可能的暴露这些障碍点，并尽量做到提前清除障碍，越在后期发现越可能影响项目的进度。
但如果障碍就是清除不了呢？最简单直接的方法就是尽快把球传给你的上级。其实如果你不是最终老板，你总有传球对象的。
对于项目参与者关注三件事儿：
接球–任务
运球–完成任务
传球–交接给下一个
对于产品经理来说，推进项目时只需要关注一件事儿，球(任务)停在哪儿了。
如果发现有障碍，迅速做3件事儿：
接球(接任务）
寻找新的接球人
把球重新传出去
