珍惜幸福216 / 计算技术 / 产品经理需要懂的项目管理知识,和你想的...

0 0

   

产品经理需要懂的项目管理知识,和你想的不一样

2017-08-24  珍惜幸福2...


产品经理需要懂的项目管理知识,和你想的不一样

产品经理需要掌握的项目管理技能!

课前问题

1.项目管理具体的工作步骤?

2.项目管理需要用到的工具?

3.产品经理是如何做项目管理的?

这节课重点是讲解了第三个问题,产品经理的项目管理,而不是专业的项目管理知识,所以前两个问题在课程中找不到答案。

所谓术业有专攻,项目管理本来就是项目经理要做的事情,而产品经理只需要具备项目管理的意识与基本知识即可。

课程大纲

本次课程的知识点很多,最重要的知识点就是对敏捷开发的讲解、产品经理如何推进项目进行、以及开发中常见问题的解答。

产品经理需要懂的项目管理知识,和你想的不一样

课程大纲

其实对于产品经理,项目管理其实就是项目推进,你不是管理项目而是推进项目,两者其实是宏观和微观的区别。

要点

1.项目管理基本开发模式与对比

瀑布开发

瀑布开发是传统的开发方式,源头就想好了整个过程,需要输出大量的文档,缺点是周期长,速度慢,风险可预见性差,已经被互联网所淘汰了。

迭代开发

迭代开发就是经典的小步快跑,快速迭代的理论指导,开始的时候可能想得不完成,先做一个MVP模型,然后逐步完善的过程,弥补了瀑布开发的缺点。

螺旋式开发

个人不是很理解,据说是瀑布开发与迭代开发的的结合开发模式,更加强调风险性。

敏捷开发

简单地说,敏捷开发是追求快速产出的一种方法,减少中间过程的内容,例如需求文档。

对比

瀑布开发、迭代开发、螺旋开发是软件开发周期的模型,区分标准是过程的复杂度和最后产品的完善度。

敏捷开发是多种开发方式的集合,它是一种方法,而迭代开发则是一种开发模型。

2.敏捷开发的核心概念

以最简单的方式快速达成目标,并在过程中及时响应外界的变化,做出迅速的调整。

敏捷开发适合小团队,技术产品沟通比较好的团队 ,能够减少时间上的成本。

3.产品经理与项目经理的差异

产品经理需要做正确的事情,追求的是结果。而项目经理需要把事情做对,追求的是过程。

4.项目流程

产品经理需要懂的项目管理知识,和你想的不一样

流程

5.产品经理需要重点关注的关键事件

需求评审会

需求评审会需要明确的要点:

目标

明确需求背景,项目立项,目标沟通。

参与角色

与项目有关的所有人等,包括开发、产品、ui、运营等等。

基本原则

严格把控事件,效果把握。

评审内容

背景,为什么做,怎么做,做到什么程度,谁等。

场控

不纠结细节,不扯远话题。

测试用例评审会

测试用例评审会的意义在于细化需求点,体现异常逻辑,如果没有测试用例,那么需要产品经理把需求做得更详细一些。

产品体验与测试

产品体验是开发完成后,产品经理需要做的事情,目的是验证产品功能是否符合预期。

产品测试则是测试人员需要组ode,目的是保障产品的可用性。

6.各类沟通工具的使用

邮件

一般需要留底的内容,比较正式的内容都需要用邮件进行沟通,主要包括以下内容:

  • 审批内容

  • 评审内容

  • 评审结果

  • 需求定稿

    ...

IM即时通讯工具

一般适用于日常沟通,不紧急的事情,主要包括以下内容:

  • 聊天讨论

  • 资料传输

  • 咨询

  • 破冰

    ....

电话

电话沟通常用于紧急的事情,包括以下内容:

  • 急需决策

  • 紧急故障

  • 就等不会

  • 适合口头说的事情

    ....

面谈

面谈适用于复杂的内容,包括以下内容:

  • 复杂内容

  • 重要事件

  • 距离很近

  • 拉近距离

    ....

7.各个阶段的沟通重点

项目管理的核心其实就是沟通,是项目顺利进行的关键,产品经理的项目管理其实就是沟通管理。

需求阶段

  • 明确需求目标

  • 明确时间点,里程碑

  • 明确产品方向

开发阶段

  • 了解每日进展

  • 明确开发难度

  • 减少需求变更

  • 多体验保证需求预期

发布阶段

  • 运营支持沟通

  • 数据反馈沟通

  • 用户沟通

8.风险管理要点

预期管理

预期管理其实就是目标管理,而目标的来源就是市场分析,在前期应该加强分析,尽量让分析更全面,看得更透,预期就更加正确。

过程管理

项目开始之前,要合理预估完成时间,阶段性目标等等,需要重复了解自身团队的能力,做好工作量评估。

项目开始之后,尽量减少需求的变更,避免不必要的返工。同时要把握进度,如出现问题要及时解决。

风险发生后

风险总是无可避免,我们能通过不断的实践避免重复犯过的错,风险出现之后也要采取适当的行动来补救:

  • 根据实际情况适当地延期

  • 及时向有关领导反馈问题

  • 及时复盘,分析原因

课后思考题

在敏捷开发中,还需要文档吗?

真正的敏捷开发有一个特点,就是去文档化,把所有的需求通过沟通进行传达,省去了做文档的时间。

我是不认同去文档化的,原因很简单:不能因为追求效率,而加大风险。

首先,写文档能够让我们思路更加清晰,想得更加完善。写文档其实就是产品经理自我对话的过程,把脑海中对需求的理解写出来,可以清楚看到自己存在哪些误区。

其次,言语表达,容易误解。口头表达的内容往往是一闪而过,留给接受者的思考时间不多,此时可能会造成误解,导致开发出的功能根本不是产品经理需要的功能。

最后,文档能一直保存,及时回顾。好记性不如烂笔头,文档能够方便开发与测试在需要的时候查看,而不需要再次询问你相关的细节。同时对于产品经理,也是验证需求的基础,也方便进行及时的复盘。



    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。如发现有害或侵权内容,请点击这里 或 拨打24小时举报电话:4000070609 与我们联系。

    猜你喜欢

    0条评论

    发表

    请遵守用户 评论公约

    类似文章
    喜欢该文的人也喜欢 更多