人人都是产品经理(version 1.1)pdf

2019年6月4日12:24:38 9 260
摘要

《人人都是产品经理(version 1.1)》书名的由来是因为作者觉得过去几年在做产品的过程中学到的思维方法与做事方式对自己很有帮助,而每个人也无时无刻在思考着同样的问题:”我们为了什么,在做什么事,解决什么人的什么问题?何时,和谁一起做?需要什么能力?”这些正对应了《人人都是产品经理 version 1.1》要说的几大话题:用户、需求、项目、团队、战略、修养。

人人都是产品经理(version 1.1) 内容简介

《人人都是产品经理(version 1.1)》为《人人都是产品经理》的升级版,是写给“1到3岁的产品经理”的书,适合刚入门的产品经理、产品规划师、需求分析师,以及对做产品感兴趣的学生,用户体验、市场运营、技术部门的朋友们,特别是互联网、软件行业。作为一名“4岁的产品经理”,作者讲述了过去3年的经历与体会,与前辈们的书不同,本书就像你走到作者身边,说“嗨,哥们!晚上有空吃个饭吗,随便聊聊做产品的事吧”,然后作者说“好啊”。

书名叫“人人都是产品经理”,是因为作者觉得过去几年在做产品的过程中学到的思维方法与做事方式对自己很有帮助,而每个人也无时无刻在思考着同样的问题:“我们为了什么,在做什么事,解决什么人的什么问题?何时,和谁一起做?需要什么能力?”这些正对应了本书要说的几大话题:用户、需求、项目、团队、战略、修养。

人人都是产品经理(version 1.1) 目录

写在正文之前

为什么会有这本书

本书的产品定位

本书的风格与特色

本书的目录与内容

我与本书的局限性

第1章 写给-1到3岁的产品经理

1.1 为什么要做产品经理

1.2 我们到底是不是产品经理

1.3 我真的想做,怎么入行

1.4 一个产品经理的-1到3岁

第2章 一个需求的奋斗史

2.1 从用户中来到用户中去

2.1.1 用户是需求之源

2.1.2 你真的了解用户吗

2.2 需求采集的大生产运动

2.2.1 定性地说:用户访谈

2.2.2 定量地说:调查问卷

2.2.3 定性地做:可用性测试

2.2.4 定量地做:数据分析

2.2.5 需求采集人人有责

2.3 听用户的但不要照着做

2.3.1 明确我们存在的价值

2.3.2 给需求做一次DNA检测

2.4 活下来的永远是少数

2.4.1 永远忘不掉的那场战争

2.4.2 别灰心,少做就是多做

2.5 心急吃不了热豆腐

第3章 项目的坎坷一生

3.1 从产品到项目

3.2 一切从Kick Off开始

3.3 关键的青春期,又见需求

3.3.1 真的要写很多文档

3.3.2 需求活在项目中

3.4 成长,一步一个脚印

3.5 山寨级项目管理

3.5.1 文档只是手段

3.5.2 流程也是手段

3.5.3 敏捷更是手段

3.6 物竞天择适者生存

3.6.1 亲历过的特色项目

3.6.2 一路坎坷,你我同行

第4章 我的产品,我的团队

4.1 大产品,大设计,大团队

4.1.1 产品之大

4.1.2 设计之大

4.1.3 团队之大

4.2 游走于商业与技术之间

4.2.1 心思缜密的规划师

4.2.2 激情四射的设计师

4.2.3 “阴险狡诈”的运营师

4.3 商业团队,冲锋陷阵

4.3.1 好产品还需市场化

4.3.2 我们还能做什么

4.4 技术团队,坚强后盾

4.5 容易被遗忘的角落

4.6 大家好才是真的好

4.6.1 所谓团队文化

4.6.2 虚无的无授权领导

第5章 别让灵魂跟不上脚步

5.1 触及产品的灵魂

5.2 可行性分析三步曲

5.2.1 我们在哪儿

5.2.2 我们去哪儿

5.2.3 我们怎么去

5.3 做吧,准备出发

5.3.1 敢问路在何方

5.3.2 低头走路,抬头看天

5.4 KPI,KPI,KPI

5.5 本书的源头活水

第6章 产品经理的自我修养

6.1 爱生活,才会爱产品

6.2 有理想,就不会变咸鱼

6.3 会思考,活到老学到老

6.4 能沟通,在什么山头唱什么歌

6.5 产品经理主义

附录:它山之石 可以攻玉

别人眼中的产品经理

各种有用的信息

人人都是产品经理(version 1.1) 精彩文摘

3.5.3 敏捷更是手段 2007年夏天,网店版在很长一段时间内保持一周发布两次的快节奏,最 近两年, 很多产品也都保持着平均一两周发布一次的频率。这么快的速度,是为了迅 速响应市 场与用户,这个特点和互联网、软件项目的其他特性杂糅在一起,必然要有 相应的方 法论支撑,所以,从2008年起,作为项目经理的我开始学习体会“敏捷方法 ”。

从书本到实践 在互联网和软件领域中,项目管理理论的发展,和任何知识一样,开始 很混乱, 每个项目自有一套,每个项目经理自有一套。后来人们非常想定出一个统一 的、简单 的流程,以减少人为影响,所以软件工程里的瀑布模型等出现了;再后来发 现瀑布模 型有其局限性,于是提出了敏捷方法。

经典的软件工程方法旨在定义一套完备的过程规范,使软件开发的运作 就像是机 器设备的运转,人在其中则是可更换的零件,不论是谁参与其中,机器都能 运转良好。

这意味着:开发进度的可预见性,流程方法的固化与可复用,人力成本的节 省,人员 的流动不会对软件开发构成影响等。这样的做法对于公司而言,是具有很大 吸引力的。

其背后所隐含的观点则是:软件从业者无须是具备非凡智力的高级人才,人 是一种可 以被任意替代的资源,并且软件的需求从项目开始的时候就是确定的,而且 不会改变。

这显然是不符合事实的。

所以在瞬息万变的互联网、软件行业,大家渐渐体会到敏捷的优势。我 们参考了 几种经典的敏捷模式,按照产品、团队的需要定制了属于自己的敏捷方法, 特点如下: 有计划,更要“拥抱变化”。

随着时间变化,必然有新的信息出现,特别是市场环境、用户情况等瞬 息万变的 互联网业界,所以死守着的项目计划不调整是没有逻辑的做法。并且,项目 估计的不 确定性是会累积的,80%×80%×……以后,能确定的就更少了,所以开始 订的项目计 划,在一个月后很可能已经面目全非,强行遵守是没有意义的,而应该不断 地修正, 当然,在一开始的计划中间就应该留有一些弹性。

迭代周期内尽量不加任务。

敏捷再灵活,也不能容忍毫无控制的变化,“迭代”权衡了变化的成本 和不变的 成本,这是一个将“大项目长期不变”细化为“当前迭代不变,下次迭代待 定”的做 法。此外,如果某次迭代内的任务无法完成,可以为了时间点的要求,移出 一部分任 务到下一个迭代。我们可以把每个迭代看做一个小的瀑布模型,其实Royce 前辈早在 1970年提出瀑布模型时也谈到过迭代的思想,不过经常被后人忽略。所以说 敏捷其实 并没有排斥经典的项目管理方法,只是各种方法都应该用在最适合的场景, 瀑布模型 对于需求固定的项目还是不错的,比如它在管理一个工厂时就非常有效。

集中工作,小步快跑。

项目干系人都在一个区域办公,或者在一间会议室里办公,这样可充分 利用白板 和墙壁。相应地就要求团队较小,一般小于十几人,太多了可分割为多个团 队。同时, 项目有较短的迭代周期,通常是2-4周,我们推崇每日“站立晨会”,会长 小于20分 钟,每个人只能说3个问题:昨天做了什么?今天要做什么?碰到什么问题 ,打算如 何解决,需要什么帮助?集中工作也是为了倡导较少的文档,更多的口头沟 通,其实 这点对团队成员要求很高,特别是对国内的技术人员。

集中办公、团队较小、文档较少等特点让很多创业团队看似敏捷,但其 实他们徒 有其表,并没有领会精髓,存在很多隐患,往往项目前期很快,发现问题的 时候已经 晚了…… 持续细化需求,强调测试。

需求唯一不变的特征就是“不断变化”,项目与产品都要小步快跑,用 不着在需 求阶段纠缠。有些需求在开始的时候是提不出来的,或者说没法细化的,所 以试图一 次性完成需求分析的工作会存在“过度需求”的问题,是浪费时间的行为, 到后来多 半还是要改。

我们在开发和测试过程中完善需求,而且特别看重测试驱动项目,更早 的测试, 重度的测试。这需要有很强很严谨的测试人员,TC编写、TC评审,甚至测试 执行的 过程可以用来补充和细化需求,比如业务逻辑里的一些限制条件、异常流程 等,往往 都是测试人员提出来的。

不断发布,尽早交付。

让需求方不断地、尽早地看到结果,并给予反馈,当然需求方代表要有 话语权, 不然半途杀出个老板说三道四是令人极其郁闷的。这点也要求需求方充分投 入,包括 集中办公、参与验收测试等。我们的“冒烟测试”、“每日构建”就符合“ 尽早交付” 的概念,可以让需求方尽早看到最新的产品。不断地发布也是为了把大问题 分而治之, 先解决最核心的,风险最大的部分。我们会先完成最重要的功能,所以说敏 捷的里程 碑是功能驱动的。

说到这里,我提一下,我们公司的项目发布时间通常是周二和周四晚上 。这是因 为周一大家刚回来工作,状态不佳;周五又归心似箭,并且发布后有问题的 话第二天 没人上班,不适合;安排在周三的话就会有连续两天发布,时间周转不过来 ,而且可 能在精力体力上吃不消。所以公司渐渐形成了每周二、周四为发布日的惯例 ,如果需 要额外的发布,则要特别提出申请,毕竟很多部门要相互配合。当然如果每 周只有一 次发布的话,周三也是个合适的选择。

以上各点之间也存在着千丝万缕的联系,比如说固定的迭代周期可以保 证不断地 发布,较轻量级的文档降低了持续细化需求的成本等。

项目中的敏捷沟通 “无论最终发现什么,我们必须理解并完全相信:每个人在其当时所处 情况下, 在其能力范围中,做了最大的努力。” 这是敏捷里让人很温暖的一句话,让我们互相理解,又能激发团队力量 。在此基 础上,更顺畅的沟通成为可能。接下来说说我亲历的团队在真实的项目中是 如何沟通 的,不妨起个名字叫做“敏捷沟通”。

我们的每个项目,项目经理都会建立一个即时通信的IM群,我们用的是 阿里旺旺; 一个临时的邮件列表,把项目干系人全部加入。IM用于实时沟通,比如发了 重要邮件 要大家赶紧收、文档有重要更新、测试环境正在构建暂时没法访问等,都可 以在群里 吼。旺旺有群公告,我们会贴上项目各种文档、资料的Wiki地址,以及一些 测试环境 的地址等公共信息。项目相关的第一封邮件,会把大家的E-mail收集齐,在 此邮件最 后说明“本项目干系人以此封邮件为准,大家的项目邮件可以直接回复全部 并修改邮 件名称和正文”,我们可以通过此邮件建立项目的邮件列表。当然,之后有 人员变化 也可以随时增删。

我们坚持着经典的每日站立晨会,对于典型周期为2-4周的项目,控制 粒度到“天” 很有必要,“项目看板…视情况而定,举例如下。

图书网:人人都是产品经理(version 1.1)pdf

  • 我的微信
  • 扫一扫加好友
  • weinxin
  • 微信公众号
  • 扫一扫关注
  • weinxin

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

目前评论:9   其中:访客  9   博主  0

    • leyang leyang 2

      想下载,学习学习!

      • 78787878 78787878 0

        资源看看,学习学习!

        • tangtzh tangtzh 1

          很好的额资源,学习学习!

          • 清风明月tzh 清风明月tzh 1

            资源看看,学习学习!

            • ivan ivan 0

              不一样的UI设计师

              • recalls_love recalls_love 0

                非常好

                • spooy spooy 0

                  很好的额资源

                  • yandavi yandavi 0

                    富强

                    • renzaijianghu renzaijianghu 0

                      文明