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

12 评论 1.6万 浏览 170 收藏 23 分钟

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

本文结构如下:

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

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

一、需求传达

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

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协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 你好,我们转载这篇文章在我的公众号吗?

    回复
  2. 基本流程和笔者写的相同,大体细节没有笔者考虑周全,感谢,非常好的一篇文章

    回复
  3. 感谢分享,写很生动

    回复
  4. 请问一下,跟程序员更好沟通至少需要掌握编程语言到什么程度呀?

    回复
    1. 入门级就可以啦

      回复
  5. 刚负责一个项目,看了大佬的分享,其中很多都需要我去自己去学习实施的,谢谢大佬!

    回复
    1. 加油

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

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

    回复
  8. 真好 棒棒哒

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

    回复
    1. 谢谢鼓励 😉

      回复