产品经理大产品

No.008 项目管理与敏捷开发

2019-07-30  本文已影响21人  salmond

项目管理

最近真的是超级忙,已经2个月没有更新了。

今天的这篇内容对初级产品经理来讲,没有那么重要,但为了体系的完整,这里也写一下,本文重点是精益创业和敏捷开发。

本文结构如下:

No.008 项目管理与敏捷开发.png

一、产品项目流程

先从项目管理的角度,梳理一下产品开发项目的大体流程。

1、策划阶段(Plan)

1.1 主要工作与交付物

策划阶段主要工作与交付物如下:

(1)用研:根据公司与产品部门定制的产品战略与定位,从一个想法开始,进行用户调研。 目标用户群

(2)用户需求分析

(3)产品原型设计:与UED团队合作

(4)可用性测试

(5)完成整个策划阶段工作

1.2 需求达到的预期KPI

不同的产品有不同的策划,运营,技术实现思路,但都背负着目标,为了达成目标,我们就必须要正确的理解KPI(关键绩效指标)。

根据产品类型、阶段不同,产品,运营,技术在产品生命周期中扮演的角色也不同,不同的阶段,有不同的KPI考核方式,常见的考核的指标有: 访问量、产品的用户数、活跃用户数、忠实用户数、使用率、使用频率、用户创造内容数量、转化率、营收、利润、等等.....

KPI的制定有2种方式:上层决策、团队商议

特别注意:

制定KPI的时候,应该仔细思考产品团队KPI,做到该承担要承担,但是不该承担的时候,也要讲出道理。

现在都是很现实的公司制度,不要去当沙僧,给自己挖坑埋!

2、执行阶段(Do)

2.1 设计阶段

这个阶段主要是要跟设计师们沟通好产品的调性,风格,必要的时候可以找一些比较好的产品提供参考。

2.2 开发阶段

和程序猿们打交道是有趣也很痛苦的事情。

他们对事物和新闻都有自己独到的看法(逻辑性强,善于思考),有的比较死板,思维面比较狭隘。

这个阶段主要注意:

2.3 测试阶段

首先开发会对自己的代码进行单元测试。

然后交付产品初审,产品经理从产品层面检查用户体验、交互流畅度、产品性能等。

详细的测试会交由测试部门负责,基本流程如下:

2.4 上线准备阶段

经过测试后,产品进入上线前的临战状态,此时工作主要为:

团队验收准备,然后确认产品发布时间。

3、检验阶段(Watch)

3.1 数据检验阶段

产品上线后的数据评估,看是否达到KPI目标,重要指标是否达到预定目标。

重点在于找出方法,改进和完善,好不一定真好,差不一定真差,需要锁定当初最好产品策划时候的目标来分析。

之后,产品开始新一轮的策划、迭代。

3.2 策划会议阶段

从定性、定量两个方面估算下一个版本的KPI目标,并思考和提出相应的解决方案。

二、精益创业

1、三种典型的产品开发模式

  1. 从需求到设计到实施到验证到维护, 这是典型的瀑布式开发模式, 这种模式适用于问题已知, 解决方案也已知的情境。

  2. 轻量级、 灵巧, 每个方法和思想做到极限、 做到最好, 基于测试驱动开发, 提倡最简单的设计方式, 现在或最近都根本不需要的就不设计, 需要重构( 灵活性和可扩展性) , 代码集体所有权, 结对编程, 持续集成, 验收测试, 小型发布, 不断迭代。 这是典型的敏捷开发模式, 这种模式适用于问题已知, 但是解决方案未知的情境。

  3. 提倡企业进行“验证性学习”, 先向市场推出极简的原型产品, 然后在不断地试验和学习中, 以最小的成本和有效的方式验证产品是否符合用户需求, 并迭代优化产品, 灵活调整方向。 这是典型的精益开发模式, 适用于问题未知, 解决方案也未知的情境。

2、精益创业的基本原则

精益创业的特征:

精益创业模式虽然强调快速假设, 快速学习, 快速调整, 但不等于可以盲目试错。

精益开发模式不能确保产品或项目孵化一定成功, 只是一个帮助提高成功概率的框架。

精益创业强调走出办公室多与用户访谈和互动, 关键在于研发出来的产品是不是用户想要的, 用户愿不愿意为之付费。

认识误区:

3、精益创业整体流程

精益创业的整体流程主要包括创建画布、 识别风险和系统测试三大阶段, 其中系统测试包括捕捉用户需求痛点、 提出解决方案、 定性检验和定量验证四个阶段。

1) 创建画布:

由于用户需求和解决方案未知, 所以需要跟目标用户进行头脑风暴提出假设, 主要包括目标用户群是谁? 他们有什么痛点? 针对痛点的解决方案是什么? 给用户带来什么价值? 如何将这些价值传递给用户( 市场渠道是什么) ? 如何获取商业价值( 收入模式是什么) ? 获取商业价值的同时需要付出多少成本( 有哪些成本) ? 如何判断产品做得好还是不好( 关键数据指标有哪些) ? 要想持续做好, 需要拥有或构建什么样的竞争壁垒? 这些内容都可以在九格画布上填写, 但是并不是每一个内容都必须填写, 不能确定的内容可以先不填。

2) 识别风险:

精益创业的风险是比较微观的风险, 主要包括用户风险、 产品风险和市场风险。 用户风险指的是在捕捉用户需求痛点时因不准确而导致的风险。 产品风险指的是提出的解决方案并不是用户想要的而导致的风险。 市场风险指的是不能持续扩大市场规模导致的风险。 精益创业强调学习文化, 旨在通过学习不断降低或消除上述三种风险。

3) 系统测试:

针对画布上的所有假设进行小心求证。 找到目标用户群, 进行需求痛点访谈, 挖掘出需求痛点, 并不断更新画布上关于需求痛点的内容。 针对需求痛处, 提出解决方案假设, 制作产品原型, 招募目标用户群进行访谈和求证, 并不断更新画布上关于解决方案的内容。 接下来是研发出最简单可用的1.0版本的产品, 并招募目标用户群进行访谈和求证, 看用户对产品传递的价值主张是否能接受和认可, 并不断更新价值方面的内容, 这是定性检验阶段。 通过数据统计后台, 分析用户使用行为, 不断学习和调优。 如果数据情况不客观, 需要重新调整方向, 直到研发的产品是用户想要的为止。 如果数据情况非常乐观, 那就进入到最后一个阶段, 定量验证阶段, 识别出产品增长动力引擎, 获取更多的市场份额。

精益创业整体流程如下图所示:

精益创业整体流程.png

4、创建精益创业画布

精益画布其实就是一张纸, 上面有9个空格需要填写, 分别是目标用户细分、 需求痛点、 解决方案、 价值主张、 市场渠道、 收入来源、 成本结构、 关键指标和竞争壁垒

精益画布跟商业模式有什么关系?

商业模式其实指的是创造价值、 传递价值和获取价值的基本原理, 也就是说基本上有三个阶段, 画布中的价值主张对应给用户创造什么样的价值, 市场渠道对应的是如何将创造的价值传递给用户, 收入来源对应的是用户得到价值之后如何让用户付费, 也就是盈利模式。

精益创业画布其实蕴含了商业模式的三个阶段, 即创造价值、 传递价值和获取价值。 商业模式不等于盈利模式。

画布的9个格并不是要求都要填写, 在没有确定之前都可以先空着, 然后通过用户参与之后, 一步一步调整和完善画布。 一般给领导汇报的时候, 不一定要写商业计划书或者商业需求文档, 使用精益创业画布加上产品原型即可。

精益创业画布.png

精益创业画布每个空格的解释在此不再多说。

5、精益创业的3个访谈

精益创业的三大访谈要求跟用户深度访谈, 让用户参与到产品设计中来。 通过不断的学习先实现痛点和产品之间的匹配, 然后再实现产品与市场之间的匹配, 最后是发动增长引擎, 扩张并规模化。

精益开发不等于盲目试错, 所以我们需要花更多的时间来洞悉用户想要的是什么, 虽然通过访谈能发现那些你所不知道的事情, 但是超出用户预期并让用户尖叫的产品才是用户想要的。 产品的尖叫包括功能或内容或机制上的尖叫, 而不是仅仅局限于功能上的尖叫。

5.1 痛点访谈

精益创业提倡走出办公室, 不要闭门造车, 大胆假设, 小心求证, 与目标用户打成一片, 深度访谈, 好好与用户谈一场“恋爱“, 让用户参与到产品从无到有的研发过程中来。 精益创业强调学习, 学习最快的方式是进行深度的用户访谈。 用户访谈就是要发现那些你所不知道的事情。

痛点访谈主要是使用定性方法来检验画布中的第1、 2格中填写的内容。 一般找10个目标用户群。 可能会有人质疑, 做10个目标用户访谈够吗? 这不符合统计学中大数定理。 易用性大师Jakob Nielsen研究结果表明, 5名用户的测试可以发现85%的可用性问题。 如果找的10个用户里头没有一个喜欢你的产品, 这就很有统计意义了。 如果10个用户都喜欢你的产品, 这事就有点靠谱了。

痛点访谈的步骤, 如下图所示。

精益创业-痛点访谈.png

5.2 解决方案访谈

解决方案访谈主要是使用定性方法来检验画布中的第1、 3和6格中填写的内容。 如何进行解决方案访谈? 主要是给用户展示产品DEMO, 越是高保真的产品DEMO访谈的效果越好。 展示的这个DEMO要让用户看得见你的解决方案。

解决方案访谈的步骤, 如下图所示。

解决方案访谈的步骤.png

5.3 MVP访谈

通过痛点和解决方案访谈之后, 将重大发现应用于MVP, 即发布版本号为1.0的产品。

MVP访谈非常重要, 因为这决定产品的方向是否需要调整。 那么通过这种方法如何证明研发的产品是用户想要的? 最直接的衡量标准就是看用户是否愿意为MVP付费买单。

若是用户愿意为产品付钱, 那就证明产品的方向没问题; 否则, 就说明还需要不断学习和调整, 直到产品是用户想要的为止。 MVP主要检验画布中第4、 5、 6格中的内容。

MVP访谈的步骤,如下图所示。

MVP访谈步骤.png

MVP访谈主要是产品的可用性测试,根据MVP访谈过程中用户的反馈进行MVP的调优。

实施完痛点、 解决方案和MVP三大访谈之后, 需要根据访谈过程中得到的重要发现更新到画布中。

二、Scrum敏捷开发

1、Scrum敏捷开发介绍

传统的开发方式是瀑布式开发,具体的大家可以百度,啊,呸,大家可以Google。

互联网这个行业是一个快鱼吃慢鱼的行业,除了竞争激烈之外,其产品服务模式也具有鲜明的特色。

互联网的产品往往是面向海量用户的服务,它非常关注用户的行为和反馈,一切以用户价值为核心是互联网产品最核心的特点。这一特点也决定了互联网产品研发具有如下4个关键特性:

敏捷开发的核心理念刚好与互联网产品研发特色相吻合,因此,敏捷开发的理念正不断给互联网公司研发部门所接受。

1.1 Scrum敏捷开发的理念

敏捷开发的四个理念:

1.2 Scrum敏捷开发原则

坚持通过持续的迭代为为用户提供有价值的产品与服务。

即使到了后期,也欢迎改变需求

阶段性的经常交付可用于工作或测试的产品,交付时间短平快。

项目开发期间,业务人员与开发人员必须天天工作在一起

个人的战斗力决定团队战斗力

讲究当面沟通

以用户可用为衡量工作量的标准

保持长期恒稳的开发速度

不断关注能提升敏捷开发的优秀技能,人才,和设计。

简单化是根本

最好的团队架构,需求和设计都是来源于团队而不是管理者

2、Scrum敏捷开发流程

2.1 敏捷开发简易示意图

敏捷开发简易示意图.png

2.2 三个角色

产品负责人:

项目经理:

研发团队成员:

2.3 三个物件

2.3.1 产品Backlog

产品Backlog(工作清单)指根据初始需求分解出的任务列表,包括:

用于研发人员进度管控的需求列表清单:

Backlog:

Backlog.png
2.3.2 Sprint Backlog

随着项目冲刺的进行,生产出可发布的产品增量,客户对产品的直观认识也会随之加深,他们可以据此建议更改或者添加产品Backlog中的任务。

在Sprint计划会议上,产品负责人为产品Backlog中的任务确定优先级,并向Scrum团队描述这些任务。Scrum团队随后根据团队整体情况,确定他们能在这个即将到来的Sprint中完成哪些功能,并把它们挪到Sprint Backlog中去。

说白了,之前的产品Backlog就是一个总纲,用比较人性化的方式,来表述要做的事情,但一些事情,往往需要由很多个小事情组成,而这些小事情,就是Sprint Backlog。

举例:

sprint backlog举例.png

例如ID1中的注册,就有可能存在的Sprint Backlog,该功能需要分块完成(举例):

1.填写注册信息中用户ID注册态验证

任务编号 1-1 负责人:sammi 工作量:3小时 状态:未开始 备注

2.验证码

任务编号 2-1 负责人:jack 工作量:1时 状态:已开始 备注

有人要问,我应该用什么工具和什么方法来只做Backlog 和 Sprint Backlog呢?

我的回答:用你团队看得懂的,且感觉专业的方法来做,没有固定的方法,简单,容易,明确即可。

有团队有专门的系统来管理,如:jira等。

2.3.3 燃尽图
燃尽图.png

Y:工作量 X:工作日期表

2.4 四个会议

2.4.1 Sprint会议
2.4.2 每日例会
2.4.3 Sprint评审会议
2.4.4 Sprint目标回顾会议

全体成员参与

每个Sprint都要做,时间不应过长

总结前一阶段Sprint的优缺点,总结优点,并找到解决缺点的可行方法

2.5 Scrum价值、误解和总结

2.5.1 Scrum敏捷开发价值
2.5.2 Scrum敏捷开发误解

1.1.1.2 Scrum敏捷开发误解

2.5.3 Scrum实施常见问题

角色变化大,人员流动大。

会议效率低

任务拆分不够细致

团队成员积极性不高

过分关注短期目标

信息沟通不对称

小结

今天的内容就讲到这里,主要都是一些概述性的东西。

下一节讲运营,依旧是概述性的东西,但我们之后会对运营工作中一些特别的点进行十分详细的讲解,比如渠道运营、数据运营体系、用户分层等。

上一篇下一篇

猜你喜欢

热点阅读