起点学院课程

项目管理:产品经理如何进行项目管理?

7 评论 1万 浏览 115 收藏 23 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

在产品迭代中,产品经理要负责相关产品开发周期和进度的把控,进行跨部门协调和沟通,最终保证新版本按时上线,这就需要产品经理具有项目管理能力。今天,我们就来聊一聊项目管理。

本文结构如下:

产品经理的自我修养(项目管理)

项目管理不单单是在产品开发过程中进行,在对一个项目进行管理时,开发前的需求传达,项目排期,以及开发中的跟进开发,都是非常重要的,做好以上几点,版本按时上线也就不难了。

一、需求传达

由于程序猿们没有经历需求筛选,需求分析等步骤,因此当产品经理决定上一个新功能时,一定要和程序猿们进行完整的需求传达。在需求传达时,我们可以按照项目背景以及功能流程进行介绍。

1. 项目背景介绍

在进行项目背景介绍时,我们要清楚的告知程序猿这个新功能所针对的目标用户是谁,使用场景是什么,以及这个项目解决了用户什么需求,总结下来就是5w1h:who、when、where、what、how、why(谁,在什么时候,在哪,解决什么问题,如何解决的,为什么去解决)。

为了形象而具体的讲述以上几点,我们用讲故事的方式为程序猿进行讲解,假设这次增加的是线上减肥课程的功能,我们可以这样来描述:

“小明是一个26岁的白领,每天到了公司就是开会、敲键盘、赶项目,典型的脱发人群。小明每天下班就已经不早了,再加上地铁和走路的时间,经常很晚才到家,长期劳累且缺乏锻炼的生活使他体重上涨,为了健康,也为了找女朋友,小明痛下决心要减肥。

但是由于小明每天下班晚,回家的路程又远,没有整块的时间去健身房,自己在家练吧又找不对方法,这使得小明非常苦恼。

而我们这次上的新功能呢,就是帮小明这种没有时间去健身房,也不知道该如何减肥的人完成瘦身目标。你看:小明下班到家后,只需要打开手机app,选择适合自己的减肥教程,然后跟着教程进行训练就好了,训练完后还可以将系统生成的图片进行分享,发送到朋友圈中让大家来监督他减肥。所以我们这个功能不仅帮小明节省了往返健身房的时间,还帮他免去了请私教的钱,是一个真真切切服务用户的功能。”

用讲故事的方式来描述项目背景的好处是,可以更好地把对方带入到使用场景之中,从而能感同身受的理解用户的痛点。最后在说新功能好处的时候,可以稍稍夸大一点,这样可以激发程序猿的工作热情,让程序猿觉得自己在做一件非常有意义的事。最好我们讲的故事能让程序猿产生“跃跃欲试”的心理。

2. 功能流程介绍

项目背景介绍完了,程序猿们对项目也有认同感了,接下来的就是功能流程介绍了。

功能流程介绍分为业务流程介绍和数据流程介绍,业务流程介绍是站在用户的角度上来展示用户是如何使用的,按照用户的操作顺序,对照流程图进行讲解。比如:小明到家后打开APP,根据自己的需要选择相应的课程类别,选择类别后出现属于该类别的课程列表,然后再选择具体的课程进行训练,训练结束后系统将生成的图片供用户分享。

如下图所示(已忽略所有异常情况):

产品经理的自我修养(项目管理)

业务流程介绍可以简短一些,只要让程序猿了解功能点和页面都有哪些就可以了。

需要详细介绍的是数据流程,毕竟程序猿是天天跟数据打交道的,在介绍的时候要按照逻辑,以数据流为主线进行介绍,让程序员们知道每一个数据都是哪里来的。比如首先要在服务器存储相关的课程数据,在用户进入app选择课程类别时,前端向服务器索要有关课程类别的数据并进行展示,这里用UML序列图展示:

产品经理的自我修养(项目管理)

在我们在按照数据流讲解完之后,程序猿就能比较清楚的知道自己要做一个什么功能了。到这里,需求传达就已经基本完成了,其实需求传达属于需求评审中讲解的内容,需求评审结束后,我们就要着手准备项目排期了。

二、项目排期

在进行项目排期前,我们一定要提前把原型和文档等资料交给程序猿们,最好在需求评审之前就开始让程序猿们提前熟悉,这样可以尽快的明确开发工作量。

1. 明确工作量

在这个阶段我们的主要任务就是和项目经理进行沟通,确认什么时候可以进行项目排期。因为在需求评审后需要给程序猿们一段缓冲期,程序猿们会利用这段缓冲期更仔细的了解需求,并思考开发方法;缓冲期结束后再进行项目排期。缓冲期的时间尽量让项目经理来定,我们不要太多的干预,程序猿对需求研究的越透彻,思考的越全面,在后面的开发中才会越顺利。

在经过缓冲期后,程序猿们基本已经对项目的工作量了然于胸了,这时程序猿往往会提出一些建议,出现最多的情况有以下两种:

  1. 程序猿希望对需求提出异议(比如页面交互,以及部分流程);
  2. 程序猿希望砍掉部分需求。

针对第一点,我们一定要耐心听完程序猿修改需求的理由,千万不要觉得需求分析是自己的职能,他们提建议是在多管闲事,想把一件事做到面面俱到是很难的,有时候程序猿提的点子正好是你没想到的地方。当出现这种情况时,不要着急给答复,回去将程序猿给出的方案和之前自己的方案仔细对比一下,选出一个最优的。如果你觉得程序猿给出的建议更好,那么就采纳程序猿的建议,同时更新文档并告知其他团队人员。

如果是第二点,那么就要分情况讨论了,如果是不那么重要的需求,可以放在下个版本,如果是自己本身也模棱两可的需求,那么直接砍掉就好了。但如果是核心需求,那么坚决不砍,绝不让步,核心需求是下个版本最重要的部分,是万万砍不得的。

当把工作量弄清楚以后,下一步就是确认开发顺序和开发时间。

2. 确认开发顺序

这里主要需要确认的就是先开发哪些功能模块,后开发哪些功能模块,这里注意,有了开发顺序才能进行项目排期。

在确认开发顺序的时候,我们仍然要和项目经理进行充分沟通,明确本次开发中有溢出风险的模块,也就是说出了问题会严重影响其他模块乃至整个产品上线的地方

举个栗子:假如我这次做的是一个智能穿戴设备的APP,那么最有溢出风险的模块是哪个呢?

不是注册登录,也不是数据显示,而是设备与手机进行蓝牙连接的模块:注册登录我们可以用第三方登录来解决,如果数据展示因为工期问题做不完,我们也可以砍掉部分展示数据以保证按时上线。但蓝牙设备连接是不可能砍的,这是智能穿戴设备功能的基础。

所以说,蓝牙设备连接就是有溢出风险的模块,在开发顺序中一定要放在前面,这样我们就可以先对蓝牙连接模块进行测试,这样出现问题时可以提前解决,不会影响其他功能。

3. 确认开发时间

当确定好开发顺序后,我们就可以根据开发顺序来确认每个模块的完成时间了,用甘特图是一个不错的选择,制作甘特图的时候,我们需要定任务,确职责。所以在表中我们要写明任务,负责人,起止时间,以避免后期的扯皮。

而在开发过程中,前端在进行框架选取及页面开发的时候,是不需要后端提供数据的,在后端进行数据库设计以及编写接口的时候,也是不需要UI设计师切图的。因此前端开发和后端开发是可以并行的,如下图所示:后端的横向柱状图空缺的部分,是留给他们进行接口调试和bug修改的。

产品经理的自我修养(项目管理)

上图这张甘特图只是举例,在实际的工作中,可以按每个模块来划分,将核心的、高风险的模块向程序猿重点说明,在开发的过程中也要更细致的跟进

如果项目有明确的截止时间,那么我们就根据截止时间来倒推每个模块的完成时间,如果时间实在不够,砍需求吧,程序猿们会感激你的。

三、项目跟进

经过前期的工作,我们终于把事情推进到开发阶段了,那么产品经理在开发过程中会很轻松么?当然不是,我们要对产品的结果负责,当然要对项目进行跟进。

1. 鳟鱼和桥梁

在项目跟进的过程中,我们虽然对敲代码没有发言权,但是我们要时刻清楚地知道项目动态,并作为程序猿们沟通的桥梁,遇到问题时要协调相关人员进行沟通,像鳟鱼一样提高团队的积极性和效率。

项目动态我们可以用每日站立会的方法来进行,站立会表面听起来是开会,但是实际上我们不需要拘泥于开会的地点和形式,我们可以在每天早晨刚到公司的时候和程序猿沟通,也可以午休后在工位上进行,甚至一起上厕所的时候也可以。

开会的内容主要是昨天都做了什么,今天要做什么,遇到或者可能会遇到哪些问题。然后我们要积极的去协调,来帮助程序员解决问题。最好在程序猿开发某个模块之前与他进行需求再确认,以确保最终开发出来的东西是我们心中所想的那样。

在这个过程中,需要我们自身有主人翁意识,灵活而又勤快的去推动项目的进行。

2. 异常情况处理

虽然做足了准备,但还是经常会有异常情况出现,可能出现的异常情况有:

(1)程序员对需求理解有偏差

在项目的开发过程中,经常会出现这个问题,但这不能怪程序猿,毕竟写的再详细的文档,不同的人看也可能会产生不同的理解,还有可能是我们的文档写的不够详细。

针对这个问题,我们应该把主要精力要放在预防上面:

在程序猿开发某一个小模块前,尤其是新出现的或者是重点模块,主动去找程序猿进行需求再确认,再和程序猿讲明需求,也可以让程序猿口述一下需求,我们来听。最终目的就是要确认程序猿已经完全理解了需求,避免后续的更改与返工。

如果在开发过程中仍然出现了对需求的理解问题,比如前端和后端对接口的理解不一,如果你此时不去协调,那么这个问题可能会被搁置,后期还是会爆发出来。还有可能是理解错误的一方将另一方说服,从而造成后期的返工和改动,这是很伤的。

当发现双方有理解上的偏差时,一定要把双方叫在一起讨论,确保前端和后端都能正确的理解需求,再进行开发。在项目开始前一定和程序猿讲明,对需求有任何分歧一定要找你,大家商议解决,而不要私下讨论。

(2)出现需求变更

需求变更,无论是产品经理还是程序猿,看到这个词都会觉得头疼。

出现需求变更的原因主要有三个:

  1. 产品经理自己没有思考全面,比如对异常情况的处理不够细腻等等。我们应该尽量避免这种情况的发生,如果总出现这个问题,说明我们的工作是有疏忽的,程序猿也会对你产生不信任感。如果因为这个原因出现了需求变更,去找程序猿大爷说明吧,回来后对自己进行充分反思,并争取在下一次做得更好。
  2. 老板要求改需求,这种情况我们看似无能为力,但实际上也是有操作空间的。对于老板的要求,我们首先要仔细的思考利弊,如果仍然觉得之前的方案好,拿出证据向老板说明。如果老板的方案更好,那么我们就要有技巧的向程序猿说明。同样可以利用讲故事的方式,向程序猿说明更改需求的原因与必要性。这时就是考验你和程序猿关系的时候了,没事的时候记得和程序猿们打好关系哦。
  3. 自己脑袋中突然灵光一闪,觉得某个功能点有更好的方案。如果是这种情况,哪怕这个方案真的好,哪怕它能提升50%的转化率,我还是建议放在下个版本进行优化,如果我们站在程序猿的角度上想:“需求是你定的,我代码都写一半了,你突然有了更好的点子,然后就让我删除自己辛辛苦苦敲出来的代码,凭什么?”

人非圣贤,谁也不能保证自己第一个方案就是完美的,当有了更好的点子时,我们不妨再增加一个优化版本,反正版本上线后我们也要收集用户反馈,把这个点子放在优化版本里不是更好么?

(3)项目进度延期

当发现项目进度已经落后的时候,我们首先要分析原因,根据原因来寻找解决办法。可能的原因有以下几个:

①团队沟通不畅

如果前期做好了预防,一般是不会出现这个问题的。但真出现了这个问题怎么办呢?此时我们就需要找到沟通不畅的当事人,询问原因,是成员之间不能正确理解对方的意思呢,还是互相不认可对方的观点。

如果是沟通不畅的双方没有办法正确理解对方的意思,那此时我们要做双方的“翻译机”,确保成员之间理解统一;如果是互相不认可对方的观点,那么此时,抓上项目经理或开发主管,一起来商量谁的解决办法更好。总而言之,一定要确保团队成员对项目理解的统一,大家带着同一个目标前进。

②程序猿能力不够

之前也遇到过这种问题,程序猿小A难以完成分配给他任务,这时我们就要叫上技术的大佬,然后让程序猿小A去叙述他遇到了什么难题,让大家一起解决,解决问题的方法我们就不掺和了,做好团队之间的桥梁就好。

③程序猿因为生活上的事导致情绪低落,开发积极性低

我们都是人, 是有情感的动物,难免会因为生活上的的事情影响到工作,这时候,我们要从同事的身份中脱离出来,作为朋友,带着程序猿去吃点小菜,喝掉小酒,聊聊人生,看看美女,没事再给程序猿买点零食,送点温暖。此时对待程序猿要向对待自己女朋友一样温柔,帮他从情绪低谷中走出来,重新振作开始工作,这样无论是对于团队,还是对于他自己,都是有好处的。

④对工期预估过于乐观,项目排期出现了问题

项目排期,其实也是一个预估的时间,谁也不能保证一定可以准时完成,如果是项目排期出现了问题,一般项目经理会让大家用出神技:加班!!

当然此时我们也不能眼睁睁的看着程序猿们加班,我们可以发挥自己的价值:砍!需!求!虽然心很痛,但是看着程序猿们日益稀疏的头发,还是咬咬牙把需求砍掉吧,找机会再加。

如果砍无可砍,赶紧重新评估时间并向老大报告,避免因为自己项目的延期影响到整条产品线。

总结

目前我个人对项目的理解就是这些了,在最后做个总结,要想做好项目管理,产品经理要有以下几个意识:

(1)主次意识

在一个项目里,一定要分清主次,知道哪些是主要的、核心的,要时刻关注的,哪些是可有可无的,可以砍掉的。

(2)风险意识

在项目开始前,我们就要知道哪些模块是有溢出风险的,或者可控性不强的,比如想做智能穿戴设备,如果不打通蓝牙模块,后面的检测心跳,记录步数等各功能都是没有意义的。再比如我们把一部分外包给其他公司,这就属于可控性低的情况下。

因为我们自己公司可以通过加强沟通,加班等方式来解决的问题,可能外包项目就解决不了,出现问题时双方的沟通效率就是比自己公司内部低。如果到项目结尾才开始验收外包部分,此时出了问题很大可能会影响项目的按时上线。

对于高风险部分,我们应该提前做好预案,并在项目过程中对有风险的部分多加关注,将问题杀死在萌芽状态。

(3)时间意识

项目管理,无非就是通过资源的调动来达成目标。资源可以是人员,也可以是时间,而作为重要资源的时间,我们必须时刻关注,一旦失控可能会造成连锁反应。

在时间的管控上面,我们不仅要做好项目时间管理,同时也要做好自己的时间管理,这样我们才能在项目中游刃有余的去应对难题。

(4)沟通意识

其实沟通在本文已经出现很多次了,我们要做团队沟通的桥梁,就要站在对方的角度,用对方能理解的方式和他进行沟通,多用举例进行说明,很多事情直接说可能说不明白,举个例子大家就很容易懂了。

(5)主人翁意识

在项目推进中,是需要我们产品经理和项目经理一起牵头的,我们要把自己当成老板,出现意外时多向下想一步,思考一下表象下真正的原因,然后去解决。

我的诀窍就是:先假设这个问题不是偶然问题,然后站在更高层次去思考解决办法,这样就可以避免日后再发生此类问题。

经常问一问自己:“这是问题的真正原因么?这样去解决以后还会发生么?”要尽自己最大努力,去做好团队中的“发动机”。

 

作者:撒野的氧气,公众号:产品汪的成长路

本文由 @撒野的氧气 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 刚负责一个项目,看了大佬的分享,其中很多都需要我去自己去学习实施的,谢谢大佬!

    回复
    1. 加油

      回复
  2. 学习了,感谢大佬分享

    回复
  3. 写的很好,学习了

    回复
  4. 真好 棒棒哒

    回复
  5. 非常有营养的文章,赞赞赞~!!!!

    回复
    1. 谢谢鼓励 😉

      回复