现在的位置: 首页 > 读书笔记 > 正文
【读书笔记】管理产品
2015年10月01日 读书笔记 ⁄ 共 4149字 【读书笔记】管理产品已关闭评论 ⁄ 被围观 877 views+

“与设计师沟通时千万别这样说:“登录按钮太突出了,减弱一些吧。”也不要这样说:“将‘你最喜欢哪支球队?’这个推广信息移到顶部去吧。”我们要做的事清晰阐述我们的业务目标以及它们之间的优先级,之后将权力交给设计团队,让他们以此为基础进行一系列的优化。”——《谷歌和亚马逊如何做产品》第3章,赢在用户体验

“所有的流程和规范最终都是为了解决实际问题的,不要贸然引入流程,除非已经碰到问题,否则尽量简化流程,提高效率。要交付一个产品,其中最重要的只有3点:1)确定用户需求和预期指标;2)以最小成本实现最主要的需求;3)发布并获得数据反馈,确定下一个迭代目标。”——《谷歌和亚马逊如何做产品》中文版推荐序

“爱因斯坦曾说:“如果不能将事物简单地表达出来,你就没有真正地理解它。”——《谷歌和亚马逊如何做产品》第10章,胜在沟通”

这段时间看过一些书,想了一些事,也做了一些笔记,简单归类发现,近年来所接收的信息和关注的事物,主要集中在几个方面。如果将人的能力范畴大胆分类,下面的框架应该比较显著:

  • 管理型:将获取的信息通过思维加工,形成关于方法的思想。现实中,表现为以文字或语音等传递思想的信息,如果接收者仅凭记忆就可以恢复,这便只是知识;如果接收者可以应景而变,这便是管理思想,即所谓的理解。

  • 知识型:仅凭记忆即可恢复的信息。知识可以沿着深度(某一学科,专业)和广度(跨多学科,见识)两个方向扩展。

  • 技能型:提高任务执行效率的特长。诸如开车、维修、使用某种软件工具执行某项任务。

以上三类能力彼此交织,不分优劣,任何人在任意方向(甚至在某一方向的细分领域)做到极致都是天才。其中,管理型由于抽象度较高,且完全可以混迹于其他两种类型中,所以可以在不被人察觉的情况下影响知识型和技能型的表现,这也使其成为人的核心能力之一。有意思的是,如果世上只有管理而没有知识和技能,人同样一事无成。

以前听人说,经济学和概率论是大学每个专业都应该学习的,现在我发现,还应该包括管理学——总结方法的学科。在此,我试着将管理涉及的范畴进一步分类(我已经知道还需要优化,但我现在还不知道如何优化):

  • 确定问题:《数学沉思录》中有这样一段话:“阿基米德触及了在科学研究中和数学发展史上最重要的一个观点——“找到什么是重要的问题或定理”,通常要比解决那些已知的问题或证明已知的定理更加困难。”就好像比攻击更重要的是瞄准,找到我们真正要解决的问题是最重要的,看来通常情况下这也是非常困难的。

  • 解决问题:管理大师大前研一在《思考的技术》中提出了“假设-验证”的问题解决思路,现实中,时间压力令解决问题变得更加困难,但只有通过不断的解决问题,才能实现我们的计划和目标。

  • 分析反馈:这是对问题解决方案的分析和评估,只有通过不断的反馈(这会形成“经验”),才能不断优化解决方案,推动进步。

  • 沟通表达:“高效沟通、准确表达”始终是我们追求的目标之一,只有这样才能够协调团队,通过合作达成目标(这一条似乎已经包含在“解决问题”中,但是如果这样,所以的问题也都可以是“解决问题”的范畴了)。

这是一则读书笔记,但上述内容确是由《谷歌和亚马逊如何做产品》引发的思考,本书中也充斥着各种管理思想,而所谓的管理根本不是肤浅的“管人”,而是——产品经理的管理对象是产品、项目经理的管理对象是项目、工程经理的管理对象是工程、设计经理的管理对象是设计……稍微延伸一下,我发现真正令人感兴趣的其实不是产品经理(只是优秀的产品经理在这方面确实表现卓越),而是管理思想,这种思想完全可以延伸到研发、市场、销售、行政、教育、科研等等领域。

以下是原书中的一些被我标记过的零散问题——可能是阅读时有感而发,我相信确定并回答这些问题的过程并不像所记录的这样简单——背后的管理思想却可能惊人地一致。当然,如果我只是将其这样记下来,那就只是知识——掌握所有知识的人,江湖人称“百晓生”。

一、如何构建卓越的使命?

卓越的使命需要完全符合以下三点要求——只有这三点:

  • 1.能够唤起人们的兴趣。

  • 2.提供言之有物且能指明方向的原则。

  • 3.适合印在T恤上。

二、什么是策略?

策略是指在竞争对手的压力下,利用公司的独特优势来争取目标用户的粗略计划。

三、如何评估用户体验设计?

如果需要负责交付一套卓越的用户体验,你就必须问以下六个用户体验问题。你还需要理性、思虑周全地回答,以确保答案合情合理。若能做到,你将最终收获一个设计精良的产品。记住在每次检查原型或设计时都要问这些问题。

  • 该用户界面要求用户完成的最重要的任务是什么?

  • 这是最简单的解决方案吗?

  • 信息是否组织得当?

  • 设计是否易用且一目了然?

  • 标准是否一致?

  • 能否减少用户点击次数?

四、什么是SHE框架?

前田约翰在他的《简单法则》中提出SHE框架:简化(simplify)、隐藏(hide)和附加(embody)。前田主张“简化特性”,让用户只做他们必须做的。然后“隐藏”那些偶尔使用或者次重要的高级特性。其中一个隐藏这种复杂性的方法是把那些针对高级用户的特性放入一个叫做“高级选项”的对话框中,或者使用带收起展开箭头或“+/-”符号的选项框把它们收起来,不过要记住它们在界面中必须是可发现的。

如果一些特性可以用更简单的东西表达出来,你应将这个东西“附加”到特性中去,让它们并行展示。例如:在T恤颜色选择器中,比起以文字选择的文本下拉框,为每个选项附加一张该颜色T恤的图片会更直观。

五、如何处理bug?

  • 1.基于频率、严重性和解决成本对bug进行分级。

  • 2.每天与开发主管和测试主管碰一次,评审新增的bug。

  • 3.不断施加压力以减少新的阻碍发布的bug出现。如果不这么做你就永远到达不了零bug率(零bug率是指没有任何阻碍发布的bug再被引入)。如果到达不了零bug率,你就永远发布不了。

六、如何从容地掌握产品开发过程?

原书第九章“胜在技术”,你需要了解四个S:服务器(server)、服务(service)、速度(speed)和扩容(scaling)。

七、什么是系统的三层架构?

通常情况下系统是一个三层架构:

  • 展现层:JavaScript,CSS

  • 业务逻辑:Java,C++

  • 数据:SQL,S3

数据层一般是一个数据库,客户记录等数据都放在里面,你可以使用一些类似SQL(Structured Query Language,结构化查询语言)语法的语言来检索数据。如果曾经较为深入地使用过Microsoft Access,你就应该接触过SQL了。

业务逻辑是运营的大脑。所有复杂的运算都发生在这层,IF(Charlie said no;)THEN(kill Charlie;)这样的语句也在这层执行。你的工程师将使用Java、C++或其他类似语言来构建这一层。

展现层通常是HTML和JavaScript。它将你的业务逻辑输出的数据按照一定的版式展现出来,这样数据会比较美观。JavaScript允许用户进行实时交互。

八、如何写好邮件?

  • 像记者写新闻一样写邮件。

  • 使用精确增量表达法。

  • 分点阐释原因。

  • 立即停笔,你已经写完了这封邮件。

  • 设法用建议取代质疑。

  • 考虑受众的感受。

九、为什么要开会?

开会有三大目的:解决问题、收集信息、传递信息。一般会议都只为其中一到两个目的。视会议的现场情况,开会的目的也是可以改变的。

十、如何做好演示?

  • 将演示时间控制在15分钟内。

  • 永远传达且只传达一个信息。

  • 讲故事。

  • 制作“综述单页”。

  • 重点演示用户体验。

  • 极度专注倾听。

十一、为什么每次会议只传递一个信息?

第一,试图传递两个信息可能导致彼此混淆。你的听众也许很聪明,但他们刚从一个毫不相干的会议出来,接下来还要去另外一个毫不相干的会议,所以他们一时半会难以完成场景的转变。如果你能让听众们轻松一些,他们会喜欢你的。

第二,在讨论过程中你的脑海中会有两个想法左右互搏。一方面你会下意识地让听众们分清你带来的两个议题的主次关系,一方面你有希望他们能专注于你的内容,而不是排定主次(如同《计算机是怎样跑起来的》第5章介绍的“哨兵算法”,不论人还是计算机,同时处理两件事情都会占用太多本可以节约的计算资源。)。兼顾两个信息的传递还会让你难以掌控会议。

第三,也可能是最重要的理由,你需要将演示时间控制在15分钟内,不过因为你是这方面的专家,你可以将时间控制在10分钟。而在10分钟内传递两个信息的可能性在0到-1之间,简而言之,你没有时间传递两个信息。

十二、如何避免产品过于复杂而无法发布?

将不属于绝对最小化可行特性集的所有特性放到V2。监测这种特性的方法是:“这样的软件做出来后用户能完成他们的基本任务吗?”如果用户不需要这个特性也能完成任务,那么即便任务完成得再糟糕、再丑陋,你也可以把这个特性放到V2。你必须坚持进行检测,因为每行代码(除了单元测试)都会降低你发布的可能性,而没有发布,卓越发布就无从谈起。

十三、如何确保交流的客观性?

  • 不说“你”或“我”:例如,谷歌的晋升委员会成员都不能说“我觉得……”,而应该说“晋升材料说明了……”。

  • 聚焦在角色模型上,而不是人上。

  • 使用客观指标。例如:可用性测试和决策矩阵。

十四、好的“新闻稿”要包含哪些要素?

  • 产品命名

  • 发布时间

  • 目标客户

  • 解决了什么问题

  • 如何解决(务必简明扼要)

  • CEO的公开赞辞

十五、产品单页/演示文稿需要包含哪些内容?

  • 产品名称

  • 目标客户+数量有多少

  • 解决了什么问题+这个问题对于目标客户来说有多大价值

  • 解决方案+这个解决方案类似线上哪个产品,为什么你的方案能让竞争对手在长时间内斗无法模仿

  • 何时交付+主要的里程碑有哪些?

  • 团队背景(仅针对VC)

十六、功能规格文档包含哪些内容?

功能规格文档的读者一般为你的工程团队、设计团队、偶尔还有市场营销团队。一般包含如下九部分:

  • 简介(使命和策略)

  • 目标与非目标

  • 用例或用户场景

  • 原型图或线框图

  • API

  • 负载规划

  • 依赖

  • FAQ和开放问题

  • 关键事件

十七、如何定义产品?

产品定义的过程主要分为十步:

  • 1.撰写新闻稿。

  • 2.创建并不断更新FAQ文档。

  • 3.绘制线框图或流程图。

  • 4.撰写产品单页或10分钟的演示文稿。

  • 5.在FAQ中添加API文档。

  • 6.撰写功能规格文档(产品需求文档、市场需求文档)。

  • 7.邀请设计团队和工程团队主管参与产品评审。

  • 8.找客户测试产品理念。

  • 9.命名、定价以及预测收益。

  • 10.向管理层汇报。

抱歉!评论已关闭.

×