从产品需求评审会、项目规划、每日项目推进、测试以及阶段总结会，整个项目的推进工作很好体现了产品经理的执行能力。
看着移动端的小伙伴把项目提交到应用商店后，我便回到自己的工位上，回想起整个项目从需求到这一刻，经历的“风风雨雨”，着实令人难忘。在这个项目中，印象最深的不是产品、需求方面的工作，而是整个项目的推进工作，也让我明白了在一个创业团队中，在团队资源有限的情况下，产品负责人项目推进能力的重要性。
下面我就项目推进分为以下6个阶段：
产品需求评审会
项目规划
每日早会
测试
上线
阶段总结会
下面将会通过在这个过程中踩过的坑，以及如何从坑中跳出来，来说明产品经理该如何根据团队的情况来进行项目推进。
首先，就是产品需求评审会。
1、产品需求评审会
几乎每个产品在正式开发前的必经环节。项目的相关人员通过需求评审会对产品经理输出的需求和解决方案进行合理性、可行性分析，而且还可以通过需求评审会来理解功能逻辑以及业务逻辑。
由于当时项目时间比较紧，会议后没有给大家太多的时间去理解和思考业务上的逻辑，大家当时也表示没有明显的问题，便根据项目规划进行正式进行开发了。
到了项目的后半段才发现，在项目推进时遗漏了两个重点，第一是我们当时的团队刚成立没多久，大家的关注点都在乎自己的工作；第二是技术小伙伴们不爱看产品需求文档。这样就导致了对产品业务和需求理解不透彻，进而导致开发期间效率低下。
这是项目延期很大的原因。不过经过这件事深刻的认识到，产品经理在产品需求评审会（评审前、评审时、评审后）阶段，需要重视一下3点：
首先是确保需求、业务通过评审，并没有明显错误
确保开发人员对产品需求和业务逻辑有深刻的理解
深刻理解产品的需求、业务和功能后，要对项目开发时间做一个精确的评估，并对这个时间负责
产品评审之后就进行项目规划。
2、项目规划的粒度
其实这部分是属于项目经理的工作，但是由于项目的初期阶段我们还没有项目经理，所以这部分工作也就由产品经理来负责了。当时是开发人员通过功能列表各自评估一下每个功能需要的开发时间，并商讨确定出主要核心模块大概的前后端联调时间，然后我这边就根据大家反馈的时间来汇总，按照MVP模式来制定以功能为粒度的项目开发计划，以周为一个里程碑，然后每周按照功能的优先级完成开发，并且每天会通过每日早会以及日报来把控项目的进度。
当时按照上面的规划进行了两周的开发后，其弊端慢慢浮现。对于每周需要完成的功能，开发人员都会存在一个或两个功能未能完成，或是所有功能都做了，但流程却跑不通。
当时对于这个情况很困惑，问题出在哪里？是不是当前项目规划存在问题？
如果我是开发人员，这样的安排我能不能完成？进行了换位思考后，我发现当时的项目规划执行起来不好下手，虽然每周的目标、优先级都很明确，但是每天的任务却是不确定的。也就是说，出现问题的关键是任务安排的粒度太粗了，需要开发人员有很好的执行力。但是团队在这方面尚有欠缺，所有才出现的这样的情况。
既然问题确定了，那就做优化方案，目标是：通过把任务粒度细化来对项目进行推进，从而使项目能按时顺利完成。那么该如何细化任务？虽然自身有技术背景，但没有接触过后台开发，所以无法对开发那边做出很细的任务安排。正在此时，一个前《今日头条》的项目经理加入了我们团队，与我共同推进项目。
项目经理的加入，恰恰弥补了我在技术统筹方面的不足。所以项目经理加入后的第一周，我们就针对团队的当下情况做了一个优化方案，在大的方向上按照之前的安排，就是项目规划以及以周作为里程碑，而优化的地方就是把每周的目标细化并指定到每天、每人手上，然后通过每日早会来统筹安排当天的工作来把控、推进项目的进度。
虽然每周的进度还是会因为一些不可控的因素导致一些功能的延期，但总体是可控的，整个团队的工作流程也顺畅了很多。
从这件事中也让我明白了：
产品经理在未了解技术管理的情况下进行项目推进时存在一定难度的。需要加强对开发流程的了解。
在项目推进时，任务安排要根据每个人的能力来制定粒度的粗细，这很重要，会直接影响项目的开发进度。
3、每日早会
每日早会，敏捷开发的一个重要环节。
每日早会的主要形式是把团队成员都组织在一起，然后根据由产品经理或项目经理来组织，每个成员过一下昨日工作完成的情况（如果未完成，那未完成的原因是什么？），遇到了什么问题以及今日的任务安排，通过这种方式来把控一下当先的项目进度。
每日早会几乎贯穿了整个项目开发阶段，如果把项目开发阶段比作一条链条的话，那么每日早会就是链条中的节点。每日早会不仅可以让产品经理更好的把控项目的情况以及当前的进度，而且还可以尽早发现问题，对问题进行分析解决。
每日早会是项目推进的有效手段：
注重3个方向，昨日完成情况、是否存在问题、今日任务安排
早会的时间控制在15分钟内，不占用大家过多的时间
4、提Bug的方式
项目开发到了后期，便进入测试阶段。
从现在来看，当时我们的整个测试模块安排的不太规范，主要反映在两个问题上，首先是测试安排的粒度过大，是以MVP中的小版本为单位；第二个问题是我们团队前期没有测试人员，只有产品经理进行辅助测试，所以造成测试的深度不够，后期的版本质量不过关，出现很多细节问题，甚至是流程性的问题。
在项目的后期，我们加入的测试人员，开始着重对产品的第一个版本进行集中测试。对于整个测试的过程，总结下过程中需要注意的地方。
项目后期，后台方面的工作量较少，所以测试出现的bug，如果不是明显的前端后题，应先把bug指派给后台，排除是后台的问题之后再指派给前台。
测试提交的Bug应该置于一个Bug池中，然后由产品经理设置Bug解决的优先级并指派人进行跟进。
Bug池中的Bug修复后，需要让测试再次确认后没问题，才能算正式解决，防止开发因为遗漏，误以为解决的Bug，导致后期再次出现同样的问题。
移动端每天下班前把Bug修复后，需要发一个新的测试版本到内测管理平台中，并更新内测版本号以及修复的内容，这个很重要。在我们项目推进时Android开发小哥就没有这种习惯，导致测试妹子还要去一个个Bug对定位，大大增加了测试的工作量。
5、阶段总结会议
经过一个月的开发时间，我们完成了第一个版本的开发，但是仅限于完成开发而已，功能流程勉强跑通，依然存在着很多问题，这时进行阶段总结会议尤为重要。
会议首先要明确会议的目的：
说明当前情况
暴露问题
找出问题原因
解决问题
然后通过当前版本与计划版本的对比，抛出问题的严重性。把当前存在的主要问题暴露出来，比如说：
iOS上线审核问题
xxx模块未跑通
xxx功能存在问题
…
接着引申出：为什么会出现现在这种状况？
产品经理作为负责人把目前每个模块存在的问题罗列出来，如下图，是我在阶段总结会议上针对目前团队列出来的部分模块问题，并附上一些从产品经理角度出发的建议：
针对每个存在的问题，大家在会议上进行针对性的讨论，并寻找出解决的方案，然后在后面的工作中进行优化。接着就着重强调优化方案的执行力（因为经历过很多，解决方案仅出现在会议上而已），如果遇到同样的问题，大家就需要马上反应，不然就需要项目经理、产品经理去辅助执行。
对于阶段总结会，最主要的明确几点：
会议目的
说明当前情况
暴露问题
找出问题原因
解决问题
落实执行
6、总结
从产品需求评审会、项目规划、每日项目推进、测试以及阶段总结会，整个项目的推进工作很好体现了产品经理的执行能力。虽然在大部分公司中这个阶段的工作是由项目经理负责的，但是产品经理也需要有把控产品的质量和进程能力，真正做到产品的主人，从需求和项目推进的过程中，做到对产品负责。
