Skip to content

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

《程序员必读之软件架构》——本是朋友买的书,却将电子优惠券送给了我,于是,我顺手买了此书的电子版。当这本书的前半段几乎磨损尽我的耐心时,终于在后半段发现了所谓的干货,以至于我认为有必要整理成一则笔记。

一、软件系统的结构:

“假设一个软件使用了面向对象的编程语言,我喜欢用如下方式来思考它的结构:软件系统由多个容器构成,容器又由多个组件构成,组件由一个或多个类实现。大多数软件系统都可以用这种简单的逻辑结构单元的层级关系来建模。”

1.抽象结构:

  • 类:对我们大多数人来说,在一个面向对象的世界里,类是软件系统的最小结构单元。

  • 组件:组件可以想象成一个或多个类组成的逻辑群组。比如,其他组件可以使用审计组件或认证服务,来确定对特定资源的请求是否放行。组件通常由多个类在更高层次的约束下组合而成。

  • 容器:容器是指一个在其内部可以执行组件或驻留数据的东西。它可以是从网络或应用服务器直到富客户端应用或数据库的任何东西。作为整个系统的一部分,容器通常是可执行文件,但未必是各自独立的流程。比如,我把每个Java EE网络应用或.NET网站都看作一个独立的容器,不管它们是否运行在同一个物理服务器流程中。从容器的角度理解一个软件系统的关键在于,任何容期间的通信可能都需要一个远程接口,比如SOAP网络服务、RESTful接口、Java RMI、Microsoft WCF、报文,等等。

  • 系统:系统是最高的抽象层次,代表了能够提供价值的东西。一个系统由多个独立的容器构成,例如金融风险管理系统、网络银行系统、网站等。

2.静态视图:

  • 语境:设定场景的高层次图,包括关键的系统依赖和参与者。

  • 容器:容器图显示了高层次的技术选择,容器如何分担指责、如何通信。

  • 组件:组件图可以让你看到每个容器的关键逻辑组件及之间的关系。

  • 类:这是一个可选的细节层次。如果想解释某个模式或组件将(或已经)被怎样实现,我会画少量高层次UML类的图。促使我给软件系统的部分分类画图的原因包括软件的复杂性,团队的规模和经验。我画的UML图通常会是草图而非综合性的模型。

*由上述4部分构成的软件架构图被作者称为C4。原书后面对于语境图、容器图、组件图的详解,以及“软件文档即指南”的思想,条理清晰,层次分明,对于项目管理工作非常有帮助。例如:软件指南中可以包含的内容:语境、功能性概览、质量属性、约束、原则、软件架构、外部接口、代码、数据、基础设施架构、部署、运营和支持、决策日志。

二、风险风暴:

与“软件系统的结构”一样,本书用作风险识别的方法:“风险风暴”也是一种可以被其他行业所借鉴的方法,至少在我看来,这种方法是相当有趣的——我们完全能够以此建立一种“风险识别模型”。

“风险风暴是一项快速、有趣的技术,提供了一种识别和可视化风险的协同方法。另一方面,这种技术可用于任何能够可视化的东西:从企业架构到业务流程和工作流。它可以在一个软件开发项目的开始阶段使用,也可以一直使用,或者在迭代计划或回顾中使用。”

步骤1:画一些架构图

第一步是在白板或大张的活动挂图纸上画一些架构图。C4是一个很好的起点,因为它提供了一种获得一组抽象层次各异的图的方法,其中一些可用来标出架构中的不同风险。图越大越好。

步骤2:分别识别风险

风险可以是主观的,所以请团队中每个人(架构师、开发者、项目经理、业务人等)都站在架构图前,各自写下他们能够识别的风险,一个风险用一张便利贴。此外,请他们根据概率影响量化每个风险。理想情况下,用不同颜色的便利贴来表示不同的风险优先级。你可以将这部分练习划分为5~10分钟的时间段,以免拖延,这一步应该保持沉默,每个人收好各自的便利贴。这里是一些要寻找的风险的例子:

  • 第三方系统的数据格式意外变更;

  • 外部系统不可用;

  • 组件运行过慢;

  • 组件无法伸缩;

  • 关键组件崩溃;

  • 单点故障;

  • 数据被破坏;

  • 基础设施故障;

  • 磁盘填满;

  • 新技术未按预期工作;

  • 新技术使用过于复杂;

  • 等等。

有了软件开发评估,根据人们的经验,他们对风险的看法可以是主观的。如果你计划使用一种新技术,但愿团队中有人能识别出相关的风险。另外,有人可能会对使用新技术的风险量化得比较高,而其他人如果已经用过同一种技术,可能感觉就不一样。各自识别风险让每个人都可以为风险识别流程作出贡献。你将更好地了解团队感知的风险,而不仅仅是那些设计软件或领导团队的人的看法。

步骤3:汇总图中的风险

接下来,请大家把自己的便利贴贴在架构图上,邻近风险被识别出的区域。举个例子,如果你识别出一个组件会有运行过慢的风险,就把便利贴贴在架构图中那个组件的上方。

这种技术的这个部分是视觉的,一旦完成,你就能一眼看到风险最高的区域在哪里。如果有人识别出类似的风险,随着大家想法的汇总,图的上方会贴满便利贴。

步骤4:对风险设定优先级

现在你们可以拿下每一张便利贴(或一堆便利贴),就如何量化已识别的风险达成共识。

  • 单张便利贴:问识别出风险的人他们的理由是什么,并就其概率影响达成共识。经过讨论,如果概率或影响是“无”,就从架构图上把便利贴拿下来,但别扔掉它(确保你保留了识别风险的记录,包括那些后来被认为概率或影响是“无”的)。

  • 成堆的便利贴:如果每张便利贴的概率和影响都相同,那就完成了。如果不是,则需要用与规划扑克或推广德尔菲法环节中相同的评估方法,就如何量化风险达成共识。看看哪些与众不同,并相应地了解人们量化风险背后的根据。

  • A.傲慢易怒、不近人情、性格怪癖、不擅社交、素食主义、说服力强、“天才”/“笨蛋”二元论、也许还有不常洗澡、自私自利、常说假话……

  • B.品味卓越、崇尚简约、意志坚定、相信直觉、尊敬艺术和创意、设计天才、营销专家、完美主义……

以上是沃尔特·艾萨克森所著《史蒂夫·乔布斯传》中,乔布斯复杂性格的一些特征,有意思的是,在乔布斯被赶出苹果前,A组表现鲜明,当乔布斯再次回归苹果后,B组开始成为主流。

难道说,乔布斯在离开苹果期间,他的性格发生了某些改变?很可能不是,仅仅是作者所选择的表现内容不同,乔布斯仍然是乔布斯,他没有改变,也不会改变。只是,后来的成功让他显得更加完美,其实,他一直都有自己的缺点。

既然我们所读到的内容是由作者筛选出来的,那么,我们也就不能仅仅通过一本书来判定乔布斯以及他的成功。事实上,要确定乔布斯的成功与他的性格是否有关,就需要明确定义乔布斯的成功,然后识别各个特征的关系,并且计算相关系数——显然这些都不容易。

绕了一圈,其实我们仅仅通过这本书看到了乔布斯的一面——显然,这令这本书的读者价值大打折扣。(哪本自传类型的书又不是呢?更何况,结合这本书的有关内容,我认为乔布斯养父母为他所创造的成长环境还是值得借鉴的。

另一方面,这本书能够多角度展现乔布斯的优缺点,并且注重于事实和观点的罗列,而不掺杂自己的看法,又让人明显感觉到,这是一个真实的乔布斯!

那么,既然你认可主人公的真实性,也就不可避免的受到这本书潜移默化的影响。对我而言,最大的感受则是:我看到的乔布斯不是一个人,他用自己的性格魅力和“现实扭曲力场”的能力影响着周围一群天才!

  • 斯蒂芬·沃兹尼亚克(史蒂夫·沃兹尼亚克):技术极客,性格天真,如果没有他的“蓝盒子”(盗打电话的装置)、AppleⅠ、AppleⅡ,你很难想象乔布斯会在早期成功。沃兹尼亚克是典型的技术型天才,比起乔布斯,我更喜欢他的性格。(这一时期的乔布斯表现出杰出的销售能力,忙着赚钱——生活无忧才能追求理想吧?)遗憾的是,最后他和乔布斯分道扬镳(沃兹尼亚克离开苹果创立新公司后,乔布斯竟然不允许他使用苹果公司的合作资源)。

  • 比尔·阿特金森:开发麦金塔电脑的技术天才,他设计了窗口覆盖的功能、圆角矩形图标等。同样,安迪·赫茨菲尔德、伯勒尔·史密斯等技术人才也为乔布斯实现麦金塔的设计做出了杰出贡献。项目完成后,三人陆续离开了苹果公司——和乔布斯一起工作可能真的很费人。

  • 约翰·拉塞特:皮克斯动画的创新主力,乔布斯慧眼识人,发现了他,拉塞特的确非常卓越,他设计了经典的“顽皮跳跳灯”形象,并且提出了《玩具总动员》的构想,后来随着迪士尼对皮克斯的并购,最终加入了迪士尼。其实,整本书读完,我最感兴趣的就是皮克斯。

  • 乔纳森·艾弗(乔尼·艾弗):苹果设计团队的主管,乔布斯的回归打消了他离职的念头,而且,他是少数能与乔布斯合拍的人,两人都崇尚艺术,追求简洁,但是,与乔布斯倾向直觉的判断不同,艾弗倾向于分析。在iPhone、iPad等产品中,艾弗都发挥了重要的作用。

  • ……

一、“苹果营销哲学”:

迈克·马库拉是苹果早期发展的重要人物,他不仅帮助乔布斯完成了商业计划书,而且为苹果公司提供了高达25万美元的信用贷款,更重要的是,他制定了“苹果营销哲学”:

  • 1.“共鸣”:紧密结合顾客的感受——“我们要比其他任何公司都都更好地理解使用者的需求。”

  • 2.“专注”:“为了做好我们决定做的事情,我们必须拒绝所有不重要的机会。”

  • 3.“灌输”:“人们确实会以貌取物……我们也许有最好的产品、最高的质量、最实用的软件等等,如果我们用一种潦草马虎的方式来展示,顾客就会认为我们的产品也是潦草马虎的;而如果我们以创新的、专业的方式展示产品,那么优质的形象也就被灌输到顾客的思想中了。”

如果用一个时髦的词,上面这三点内容就是所谓的“干货”,这种“苹果营销哲学”始终贯穿在这本书和乔布斯的产品设计/营销理念中:他懂得帮助用户发现需求;他专注于包含大量细节在内的产品设计;他精心打造产品的包装和展示。

二、几个特别的章节:

这本书厚达500多页(41章),但是从阅读的角度来讲,有的内容引人入胜,有的内容只需泛泛而读。我觉得有几个章节比较特别,所以将感受写在下面:

  • 第11章:现实扭曲力场,揭示了乔布斯独特的说服能力。有意思的是,乔布斯不擅长社交,却有着杰出的演讲才华和说服能力,遗憾的是,这本书没有专门介绍乔布斯演讲的章节,我觉得真应该找一本专门的书来看看!至于乔布斯不擅长社交的表现:傲慢、易怒、认为对方不是“天才”就是“笨蛋”等,最后的第41章给出了解释:他只是比较诚恳,毫不掩饰而已(我觉得是完全可以理解的)。

  • 第31章:爱音乐的人,本章专门围绕乔布斯的音乐爱好展开,遗憾的是,我仅仅能感受到他的疯狂,却没有太多阅读的兴趣,这章可能是写给懂音乐的读者的吧。

  • 第32章:皮克斯的朋友,我发现这本书让我喜欢上了皮克斯!皮克斯的动画富有想象力和感染力,能够浸润在如此充满创造力、挖掘创意的团队里该是多么幸福的事情!我正在找一本专门介绍皮克斯的书。

  • 第41章:遗产,这是全书我最喜欢的一章,不仅是因为作者对乔布斯给予了一定的评价,更重要的是附了乔布斯自己的一大段总结,在这段总结里,乔布斯再次强调,他追求的是创新,制造伟大的产品!打造传世的公司!而不是像个商人那样仅仅是为了赚钱,贪图利润。

二、一些摘录的段子:

有人说,苹果公司的图标是为了纪念伟大的计算机科学家阿兰·麦席森·图灵(图灵吃了沾染氰化钾的苹果自杀),这本书中,乔布斯否认了这种说法。(我清楚记得,虽然不记得是在哪一章节了)

但是,“你是想卖一辈子糖水呢,还是想抓住机会来改变世界?”这个经典的段子得到了约翰·斯卡利的确认(前百事高管,当时,乔布斯向他提出了这个令人无法释怀的问题)。

此外,我还在阅读过程中摘录了一些其他的段子,发在微博上,现在全部整理到下面,我发现,有的段子读起来很有意思,有的则能给人启发,还有的值得让人深思。

  • 109页:根据苹果设计师特里布尔的说明,乔布斯就像高压交流电一样善变,如果你告诉乔布斯一个新想法,他通常会告诉你他认为这个想法很愚蠢。但之后,如果他真的喜欢上了这个想法,一个星期后,他会找到你,然后把你的想法再提出来,就好像是他自己想出来的一样。

  • 162页:施乐公司推出施乐之星电脑时,苹果和微软团队在一个周五共进晚餐,乔布斯问盖茨,施乐之星卖了几台?盖茨回答说600台。第二天,乔布斯全然忘了盖茨刚刚告诉大家施乐之星售出了600台,当着盖茨和整个团队的面,说施乐之星卖了300台。

  • 165页:乔布斯指责盖茨的Windows抄袭苹果,盖茨反驳道:“好了,史蒂夫,我觉得我们可以换一种方式来看待这个问题。我觉得现在的情况更接近于这样——我们都有个有钱的邻居,叫施乐,我闯进他们家准备偷电视机的时候,发现你已经把它盗走了。”

  • 223页:乔布斯就卢卡斯影业电脑部门的收购问题谈判时,该影业的CFO发现乔布斯傲慢又易怒,于是计划:将包括乔布斯在内的所有人聚集在一间会议室,自己晚到几分钟,以体现自己的级别。但是,乔布斯在这位CFO缺席的情况下按时开始了会议,当CFO进来时,乔布斯已经掌握了会议控制权。

  • 366页:为创立“iTunes商店”,乔布斯向五大唱片争取数字音乐销售权,这些公司担心定价模式和专辑拆分,乔布斯把苹果电脑的市场份额小作为优势来说服这些公司。乔布斯告诉他们, “iTunes商店”只会在麦金塔电脑上使用,只占有5%的市场,即使失败了,也不会造成太大损失。

  • 372页:发布会上,乔布斯针对盗版音乐谈到了iTunes商店的优势:不必担心质量问题,99美分的售价还不到一杯星巴克拿铁咖啡的一半。他强调,从Kazaa(免费)下载一首优质歌曲需要15分钟,iTunes只要1分钟,为省4美元而花费1小时——你赚的比最低时薪还低……而且,用iTunes下载不是偷窃。

  • 448页:癌症治疗期间,乔布斯很气恼不能控制局面,即使几乎失去知觉时,他强悍的人格依然存在。有一次在他深度镇静时,医生要给他戴面罩。乔布斯扯掉面罩,嘟囔说讨厌这个面罩的设计,他命令医生拿来五种不同的面罩让他选择一个喜欢的。

  • 460页:乔布斯和广告公司的文森特就ipad的广告开始争执。文森特喊到:“你得告诉我你要什么。”乔布斯回道:“你得给我展示一些东西,等我看到我想要的东西就知道是什么了。”文森特回道:“噢,太棒了,让我把这记下来,发给我的创意人员:我看到我想要的东西就知道是什么了。”

  • 515页:多克托罗在“我为什么不会买iPad”中写道:“它的设计中融入了很多周到的想法和精巧的元素,但是也有对其主人显而易见的轻蔑……给你的孩子们买一部iPad并不会使他们认识到世界是要你们去剖析和重组的。它会告诉你的后代,即使是换电池这样的事情你也必须要留给专业人员去做。”

因为发现自己使用的博客主题有点小bug,于是,我翻阅有关主题架构的资料后,临时又拿出那本简洁深刻的《用户体验要素》来看——第二次阅读这本书,由于经历经验的增长和知识结构的变化,我又领悟了一些新的东西。因为,这本书除了介绍有关用户体验设计的五个层面(战略层、范围层、结构层、框架层、表现层)及某些设计方法、准则,还促使我重新思考一个问题——产品经理(PM)是做什么的?

既然产品经理(PM)是为产品负责的,那么,他至少一头连接产品的来源——“需求”,另一头连接专业的执行团队——“各种设计师”,所以,我相信产品经理(PM)至少包括两个重要的职责——其实这也可以从另外一个角度概括书中的分层思想和设计方法:

  • 一. 高效沟通:如果产品经理自己不能做完所有的事,那么他就要能够高效率、高质量地组织起一个团队,来实现产品的生产。
  • 二. 创造构想:发掘产品需求,创造产品构想。

先说第一条:

一个极端的情况是:如果产品经理可以做完所有的事,这种情况下,他的大脑就是“指挥中心”,手脚就是“执行单元”,“指挥中心”和“执行单元”之间依靠神经网络进行通信——速度快、信息量大(简直就是光纤通信)。

但是现实中,产品经理做不完所有的事情——这也是社会化分工的必然,所以,产品经理自己就是“指挥中心”,“执行单元”则是诸如交互、程序、视觉设计师等同事——相对于自身的神经网络,这种同事之间的通信速度就慢很多、传递的信息量自然也少(就好象是拨号上网)。

于是,如何优化通信效率,以最简洁、最高效、最合理的方式将必要的信息准确传达给交互、程序、视觉设计师,就成了产品经理如何提高整个团队效率和生产质量的首要问题。《用户体验要素》这本书中所涉及的许多方法都是为了解决这个问题。例如:产品战略规划文档、功能规格说明文档这些内容,如果写出来却没人看,那就是没有意义的;同样,如果一位程序设计师不看设计文档,始终要和产品经理当面沟通,那就说明如果不是文档写的有问题,就是这种“通信方式”不合理——也许产品经理需要用交互式的视频替代文档。

以上内容,都是为了说明,产品经理所写的全部文档,都不应该拘泥于某种形式——文档甚至不是必须的,提高团队的沟通效率——“高效沟通”才是真正的目标,产品经理应该寻找与具体的交互、程序、视觉设计师等人最佳的沟通方式,以此来确定自己产品思想的表达方式。由于产品特点的不同、各种设计师自身的差异,所以,始终致力于最优化团队沟通效率就成了产品经理首要的职责——只有这样,整个团队才能更好更快地实现产品构想。

再说第二条:

第一条实质反映的是沟通,是使产品经理能将自己的产品构想(或者说产品思想)实现的环节。一旦解决了沟通问题,产品经理和其他设计师构成的团队就成为了一台实现产品的机器,但是,沟通的前提是要有产品的构想——创造出清晰而有条理的构想(可以是通过与别人沟通形成,但自己必须清晰且有条理),才能与设计师们有效沟通。对于产品经理而言——这一条其实是比第一条更重要的职责,要求也更高(否则,整个产品设计团队根本没有可沟通的内容)。

通过战略层中包括产品目标的制定、用户需求的发掘,就成为了使产品经理有产品构想的必要条件,从这一点上而言,产品经理需要具备杰出的洞察力、逻辑分析能力、对产品需求的控制能力和条理清晰的思想结构,同样,创造力、渊博的知识和眼界也是创造优秀产品构想必不可少的能力。

由此看来,人人都可以是产品经理,但是,如果想成为优秀的产品经理,不但需要付出艰辛的努力,往往真的还需要某种天分,这不是能靠后天努力就可以获得的——“天才是百分之一的灵感加上百分之九十九的汗水,当然,没有那百分之一的灵感,世界上所有的汗水加在一起也只不过是汗水而已!”

·······················

最后,挖掘用户需求,为新产品的设计寻找灵感,这是考验很多产品经理的地方——产品经理也许是天生的,因为,只有设计出伟大的产品,才是产品经理的最高荣誉。但是,如果不能解决沟通中的问题,深陷文档泥潭的产品经理,根本没精力去构思优秀的产品,这是对迷恋于规范文档和流行工具的产品设计人员的提醒——也包括曾经的我。

现在看来,产品经理终其一生在寻找并加工“需求”,从而形成产品构想的原型,同样,也需要针对各类设计师的特征应用最高效的沟通方式(这种方式也包括给予设计师合理的自由度,从而充分发挥他们的才智),而这一切,也都是相互作用、不断反馈的。从另一个角度,对产品经理而言,如果说“需求”是指引产品努力的方向,那“沟通”就是实现产品构想的方法。

前些天,受人委托帮忙设计个美容网站,两天就要。我也算跌跌撞撞做过点产品,为了对产品了解更多也看过不少书,刚好用这个机会锻炼。但是实践下来,还是最关键的问题——对需求的把握。既不熟悉美容行业,也没时间和精力调研,只能翻翻类似网站,文档中的功能和架构草草带过,赶快整个原型来看吧。打开Axure,和当年使用的PROTEL长得很像,由于内容实在空洞,索性以此实现“注册/登录”吧!本文,也是离开北京当天最后一篇文章了……

原型如下:可完成注册/登录/忘记密码等功能。

整理制作过程中的部分问题&心得如下:

  • 1.两个radio button实现二选一时,直接将两个按钮选中,然后右键点击操作,选择“grouping”中的group即可。(百度到此操作之前,本人试图用各种动作和事件实现相同目的,失败~)
  • 2.将register页面中的用户名/密码/邮箱通过全局变量,直接传递到home页面,即可进行后续操作。(没找到密码域控件,只好显示明文密码了……有机会上线翻翻Axure的组件库,应该会有收获。)
  • 3.用户登录后,右上角的“注册|登录”选项替换为相应的用户名和退出功能。原本是通过放置小动态面板,设定两种状态来实现,但是很快发现一个问题:case操作选项中,使用变量替换文本在动态面板中失效。无奈,索性撤销动态面板,直接用超链文字实现,通过判断一个全局变量标志“是否登录”,将“注册|登录”文字用“用户名变量”和“退出”替代。遗留没来得及解决的问题就是:如果点击logo刷新home页面,被替代的文字效果失效,又得重新登录,@@。(另外,更合理的交互是,用户注册完毕就刷新直接登录。)
  • 4.弹出登录框时,背景中的所有项目应该不能操作,或者说,全部为diasble状态,但是项目实在太多,没法挨个设定,加一个透明灰色面板置于仅次于弹出框的第二层,在出现弹出框时该面板显示,即可实现对背景中其他操作的屏蔽。
  • 5.页面加载时,可以设定相应的变量值和动作。需要留意的是,倘若页面中已经对变量值做出修改,此时的页面再被刷新,变量值又会被重置,相信动作也要重复。本来想偷懒,借此直接设定初始变量值,然后测试登录功能,最后放弃,专门又做了一个register页面。
  • 6.最后,我应该先画个交互流程图的……

*补充说明:如此“厚重”的页面在加载时可能会比较耗时,所以,在此之前需要对整体的页面结构进行规划——即是“结构层”的设计(更抽象的还有“范围层”、“战略层”,具体请参见《用户体验要素:以用户为中心的产品设计》一书),上述各个导航类目下的页面,做成独立的页面也许是一个省时的选择。

————————

总结,Axure的功能还有待完善,本人的经验也有待丰富。但是一般意义上讲,这个软件的操作性还是很强,也比较容易上手。基本的操作结构如下:

  • 1.窗口中间的设计区就是用元件拼图,每个元件右键都有各自的个性菜单,窗口右侧可以针对各种事件设定动作和条件(还可以添加各种描述,据说对生成word产品文档有用),条件无非就是if语句搭配and和or。
  • 2.窗口的下面则是针对整个页面事件的动作和条件设定(同样可以设定各种描述)。
  • 3.窗口右侧则是网页结构和元件库,貌似还可以自行设计元件。
  • 4.全局菜单中有变量的管理,各种产出的生成管理,对于项目组开发,还可以实现项目共享和管理。

放眼望去,似乎互联网遍地都是PM(product manager)~

已经记不得是哪位说过,“PM不是manager。”好像的确如此,PM一多,M就要贬值了,呵呵~

看到过那么多对PM的要求:会做数据分析,会做竞争分析,会做交互设计,会做项目管理……要求的还真多啊~

不过,不论是体验还是读书,我正在形成自己对PM的看法,也开始理解火车头的重要性:

战略->产品->营销。

嗯,就这么简单,从产品入手就是狭义的PM,不论怎么做,把一个具体的产品做出来,相对而言操作执行层面上的东西比较多。

而真正的PM,其实力首先表现在战略或营销层面,尤其是战略,方向走对了,后面的产品和营销要轻松,听起来好像是句废话,呵呵~战略——是理想情况下最重要的因素;其次,末端的营销则是现实条件下最重要的因素;居中的产品,则相对更容易被人模仿,从而难以表现出足够的差异性。

最后,战略和营销更容易表现出抽象的跨行业同一性。