产品经理如何进行项目推进

看着移动端的小伙伴把项目提交到应用商店后,我便回到自己的工位上,回想起整个项目从需求到这一刻,经历的“风风雨雨”,着实令人难忘。在这个项目中,印象最深的不是产品、需求方面的工作,而是整个项目的推进工作,也让我明白了在一个创业团队中,在团队资源有限的情况下,产品负责人项目推进能力的重要性。

下面我就项目推进分为以下6个阶段:

  1. 产品需求评审会
  2. 项目规划
  3. 每日早会
  4. 测试
  5. 上线
  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功能存在问题

接着引申出:为什么会出现现在这种状况?

产品经理作为负责人把目前每个模块存在的问题罗列出来,如下图,是我在阶段总结会议上针对目前团队列出来的部分模块问题,并附上一些从产品经理角度出发的建议:

针对每个存在的问题,大家在会议上进行针对性的讨论,并寻找出解决的方案,然后在后面的工作中进行优化。接着就着重强调优化方案的执行力(因为经历过很多,解决方案仅出现在会议上而已),如果遇到同样的问题,大家就需要马上反应,不然就需要项目经理、产品经理去辅助执行。

对于阶段总结会,最主要的明确几点:

  • 会议目的
  • 说明当前情况
  • 暴露问题
  • 找出问题原因
  • 解决问题
  • 落实执行

项目进度问题一般在一个小团队中不会表现的特别突出,因为这时候团队所有成员的目标都比较一致,并且由于人数较少,沟通成本也较低,对于磨合的较好的团队,这时候可以遵循小步快跑的方式,不断打磨产品。对于刚入门的产品经理来说,这段时间应该是产品生涯里最快乐的时光了。

图片1

但当团队规模扩大到二,三百人时,由于系统更加庞大和复杂,任务会被拆分给到更多的人去做,原来的简单沟通模式被无情的拆分,于是人和人的关系变复杂了。这时候,看起来简单的一个小功能很可能会牵一发而动全身,涉及很多的人。于是项目推进就不是靠晚上一起吃个饭能简单的解决了:人太多,你请不起啊。

图片2

既然本文是在教产品经理怎么推进项目,那么我们先聊聊项目是怎么运作的。不管是有钱的出钱还是有力的出力,在软件开发这种需要抽象逻辑的脑力劳动面前基本是无效,因为他需要的是专业技术人员不断的共同协作才能完成。而协作的过程其实就和打篮球一样,对于每个人参与者来说就是一个传接球的过程。

图片3

你接到了一个球(任务),运球(做任务),传球(把任务抛给下一个人)。所以每个项目参与者就做3件事儿,接到任务,完成任务,传给下一个。在完成任务的过程中,如果碰到问题无法继续,就像运球时半路有人拦截,这时候也必须要把球传给能解决这个问题的人。对于项目参与者来说,核心使命就是按时按点的把球传出去,只有传出去了,你的使命才算完成。

需要重点说明的是什么叫传球,所谓传球我们可以理解成交付,也就是上家对下家的一个产出结果的交付。

例如,产品经理对开发以及设计团队的交付是一个说明详尽的产品需求文档,UX/UI对开发的交付就是设计完整的交互稿,视觉稿以及切图。而后端开发人员对前端开发人员的交付就是安全可用的接口以及详细的接口文档,而前后端开发人员对测试人员的交付就是提交到测试环境的代码,测试人员对部署人员的交付就是没有问题的测试结果,而是有问题的测试结果则要交付给前后端开发人员。

当然并不是所有的传球都是一个明显的产出结果交付,也会是一些信息告知,例如,开发人员在开发时碰到了第三方安全证书问题需要产品经理去解决,这时候的传球可能就是一个邮件告知一下产品经理项目遇到障碍,需要产品经理去解决,于是球又传到产品经理手上了。

需要说三遍:传球才是项目往前进的最重要环节。

图片4

到这里我们知道了项目的本质就是多人进行的一个传接球过程,每个参与者就是做好3件事儿:

  1. 接球–任务
  2. 运球–完成任务
  3. 传球–交接给下一个

但有时候由于任务的不明确,或者分工的不明确,或其他各类原因会导致球在传递的过程中球一直停在了某个人手中,而无法传到下个环节。怎么办呢?

图片6

这个时候,对于产品经理来说其实也只要做3件事儿,

  • 接过球
  • 清理障碍点
  • 把球重新传出去

重新传出去时,也许就不再按原来的传递路径了。有些产品经理在项目进入停滞状态时,会变得很焦虑,会去不断推项目执行者,然而并没有任何效果,因为障碍是事实存在的,不解决是不会真正让项目继续前进,强推的结果只是会让结果失控。

障碍的清除其实也是遵循传接球原则,找到问题点以及可以解决该问题的人,然后把球传过去就可以。但有时候,传球对象不一定好找或明确,就需要你不断的传球试探,直到找到一个可以接球的人。能够顺利清理障碍当然是一件好事情,但是作为产品经理者应该在项目开始前就尽可能的暴露这些障碍点,并尽量做到提前清除障碍,越在后期发现越可能影响项目的进度。

但如果障碍就是清除不了呢?最简单直接的方法就是尽快把球传给你的上级。其实如果你不是最终老板,你总有传球对象的。

对于项目参与者关注三件事儿:

  1. 接球–任务
  2. 运球–完成任务
  3. 传球–交接给下一个

对于产品经理来说,推进项目时只需要关注一件事儿,球(任务)停在哪儿了。

如果发现有障碍,迅速做3件事儿:

  • 接球(接任务)
  • 寻找新的接球人
  • 把球重新传出去

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/833.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息