【8030】产品,你理解对了么

一句话点评:Marty说,产品 = 用户的整体体验 = 功能 + 设计 + 盈利 + 内容,那么产品经理这条路走下去,还真是个业务Leader啊。

Marty Cagan发表于20101123日,原文链接,译者:姜沈励/ 审校:唐丰能 林航

在大众消费品行业,当你提到产品一词时,大部分人脑中会浮现出一个非常清晰的实体,例如一块肥皂或是一把剃须刀。但在互联网行业,产品一词就显得格外抽象:首先,互联网上的产品通常是指软件,而不是实物;其次,这些软件通常并不安装在你的电脑里,而是直接运行在远端服务器上,甚至是运行在抽象的里。

因此,大部分网络公司由于网站体型过于庞大,需要我们人为地将其拆分成许多小产品。大型网络公司的网站一般被拆分成许多(通常是几十个)小产品,这种组成结构只是为了适应内部组织需求(organizational needs),而普通用户是察觉不到的。

在早期的文章中我提到过把大型网站拆分成多个可管理模块的关键点。现在,我想谈谈对产品的看法:当我们提到产品时,我们到底指的什么?这里的产品可以指整个网站也可以指其中一个模块。

我觉得今天讨论的对象相当重要。我认为,大部分团队只是凭直觉工作他们定义产品和组织团队的方式不合理,直接造成了好产品难产。在采访过这类团队后,我觉得,让大家意识到什么是产品,也许能改善这种现状。

我这样定义典型的网络公司产品:

产品 = 用户的整体体验 = 功能 + 设计 + 盈利 + 内容

功能是指产品可以干什么。

设计是指交互设计、视觉设计和工业设计(对物理设备而言)。

盈利是指盈利模式。可能是各种形式的广告、捐赠或者交易。

内容可以是自己原创的、由用户提供的,或者两者相结合。

虽然看似简单,没有火箭制造技术那么高深神秘,但对我来说,还是存在两个关键点:

1.产品的外观和功能不可分割,它们应该被视为一个整体。

2.网站的产品负责人必须平衡好功能、设计、内容与盈利之间的关系。

例如:

如果设计师不是和产品经理、工程师工作在同一战线,那么每个人的工作都不好开展。

如果强行将网站员工划分为两个团队,一个团队负责开发为用户提供价值的产品;另一团队负责营销推广,你会发现很难优化整体的用户体验,甚至会引起两方的利益冲突。

如果只专注于功能开发,而忽略了内容的创造,你就无缘感受整合带来的好处。

提示:

在一个电子商务中,对产品的定义除了上述四点外,还包括订单履行(fulfillment)、商品包装、客户服务、退换货策略。并且,我们常常把网站上出售的货物叫做商品,避免和这里所提到的产品相混淆。

在传媒公司,编辑就是内容的缔造者,而内容是产品的一个组成部分。

与此同时,公司还需要有专业化的产品团队(具体内容见后续的文章),并且团队的性能通过产品积分卡(Product Scorecard,具体内容见后续的文章)来衡量。

作为互联网行业的产品经理、设计师或者开发者,如果你能用系统的眼光来看待产品功能、设计、盈利和内容,必将受益匪浅。

本文节选自《启示录:打造用户喜爱的产品》一书作者的博客。该书从人员、流程、产品三个角度介绍了现代软件(互联网)产品管理的实践经验和理念。特此感谢Marty Cagan先生授权。

【8026】如何与异地的开发人员沟通

本文节选自《启示录:打造用户喜爱的产品》一书和作者的博客,并发表在《程序员》杂志1105期,作者Marty Cagan是享有世界声誉的产品管理专家,曾经担任网景副总裁、eBay产品管理及设计高级副总裁。译文由七印部落出品,原文太长,这篇是第三部分,也是最后一坨了。除了讲述“如何与异地的开发人员沟通”,还讲了当“程序员想重写代码”时,我们应该怎么办。

如何与异地的开发人员沟通?

如今产品经理与开发团队各处一方的情况很常见。除了印度软件外包业务,大型公司的分支机构之间,以及公司与被收购的子公司之间,都可能出现这种情况。

如果开发团队不在你身边,沟通和执行的难度将进一步放大。异地开发出现的问题常常导致团队士气低落,有人甚至公开质疑异地开发能否真正节约成本。

提高与异地开发团队之间的沟通效率,我有三条建议。

  • 开发团队距离越远,语言、文化、时差带来的沟通难度越大,确定完善的产品说明文档就越重要。如果产品经理不确定开发什么样的产品(或者反复改变想法),异地开发团队只能疲于奔命,白费力气。这简直就是一场灾难,丝毫不亚于医生开错方子。如果你与开发团队相隔很远,无论是沟通产品文档的内容,还是讨论修改产品设计,一定要借助高保真原型进行交流。阅读文档毕竟不轻松,如果文档是非母语的,或者阐述不清楚,那沟通效率就更低了。
  • 本地的开发团队很容易发现和解决各种冲突(比如,两个管理者给出相互抵触的指导意见)。异地开发团队则会发生很多意想不到的情况,往往过了好几个月才发现问题。这是因为异地开发人员不得不揣摩各种不同的意见(但经常揣摩错)。因此,必须有人在本地负责与异地团队的协调工作。这并不是说所有沟通工作都必须经过此人,而是应该明确异地开发团队只接受他的命令。这项工作可以由本地的项目经理、资深开发人员或者其他主管担任。
  • 如今商业沟通手段很丰富,除了电子邮件和即时消息外,还有视频会议可供选择,此外,语音电话业务(VoIP)大大降低了国际长途通话费用支出。尽管如此,当面交流的优势依然不可替代。每个季度,产品经理至少应该前往异地与开发团队见一次面,与软件架构师、管理者当面交流。面对面交流有助于改善(合作)关系,提高沟通效率。此外,交换人员也是一种有效的沟通方式,可以让主程序员来本地与产品经理共同工作一段时间,或者让产品经理到异地工作一段时间。

按照我介绍的方法与优秀的开发团队合作是一种特别的享受。如果是与印度外包团队合作,那么由于时差的原因这种合作会让人觉得更加惬意。每天早晨上班时,对方的项目进展已经摆在面前。你可以用白天(对方的夜晚)检查、测试代码,反馈信息,显著缩短项目的循环周期。

请注意,如果是在异地开展与产品原型相关的工作,由于循环周期非常短(一天迭代好几次),你必须随时准备处理对方的问题,投入更多的精力。

解决异地开发问题的另一种方式是在异地聘请产品团队。这种趋势正在兴起,我相信这种模式会被更多的公司采用。你大可不必为此担心。我们曾经用了10年时间在异地培养专业的开发和测试人员,培养专业的产品经理和设计人员很可能还要再花10年时间。

程序员想重写代码?

产品经理最担心听到开发人员这样抱怨:不能再增加功能了!我们得停下来重写代码。代码库一团糟,就像纸糊的老虎,根本应付不了持续增加的用户。我们维护不下去了!

这一幕在很多公司上演过,现在依然在不断重演。1999eBay遭遇这一幕时,公司濒临崩溃的情形超出所有人想象。Friendster几年前也 发生过这种情况,当时他们正在向MySpace开放社交网络用户。网景与微软展开浏览器大战时,也发生过类似的事情,最后的结果大家都知道。事实上,没几家公司能渡过难关。

一旦公司陷入这种困境,开发团队往往沦为替罪羊。经验告诉我,这类问题通常是由产品管理失误引发的。因为产品经理一直迫使开发团队满负荷工作,开发 尽可能多的功能。所有软件架构都存在功能极限,如果忽视产品的基础技术构架,一旦系统越过崩溃的临界点,就会造成无法挽回的结果。

在重写代码的过程中,用户无法看到产品的任何改进。你可能认为重写代码至多也就几个月,但是实际花费的时间无一例外要多得多。你只能坐在一旁,眼睁睁看着用户投奔竞争对手,而这个时候,竞争对手恰恰在不断地改进产品。

如果你还没有遇到这样的情形,未雨绸缪很有必要——你需要预留一定的研发技术能力,在eBay被称为余量(headroom)。很多因产品迅速膨胀产生的问题都与扩展规模有关,余量意味着避免触及技术能力的上限,为用户数量的增长预留空间,为事务增长预留空间,为新增功能预留空间,保证产品的基础技 术构架能够满足团队的要求。

与开发团队合作应该遵循以下原则:在产品管理上为开发团队预留20%的自主时间,让他们自由支配。开发团队可以利用这些时间重写代码、完善架构、重构代码库中有缺陷的部分,或者更换数据库管理系统,提高系统性能,避免我们需要停下来重写代码的情形发生。

如果你的糟糕处境已经初现端倪,应该拿出至少20%的资源进行调整,而我担心有些团队连20%都不愿意拿出来。如果你已经身陷重写的困境,说明公司危在旦夕,这里给出一点建议供你参考。

第一步,针对开发团队确定的产品修改目标并制订切实可行的计划和时间表。通常,有经验的开发团队估计的开发时间八九不离十,但是重写代码是个例外,因为多数团队都没有重写代码的实际经验,估计往往过于乐观。你必须审时度势,仔细检查每处细节,确保计划切实可行。

第二步,只要有可能,最好把重写目标分成几大块,实现递增修改,让用户感受到产品的改进,哪怕会因此把9个月的工作时间延长至2年,也一定要采用这种方式。重写代码时,保证让用户看到功能的改进——即使会占用少则25%,多则50%的开发资源——对保持产品(尤其是互联网产品)的市场占有率至关重要。

第三步,由于开发用户可见功能的资源有限,必须谨慎选择正确的产品特性,并确保产品定义的正确性。

eBay起死回生后,我们发誓绝不重蹈覆辙,马上开始新一轮的代码重写,把危机甩在身后。事实上,由于发展迅速,eBay已经重写了三次代码,最后一次采用了完全不同的编程语言和架构。开发团队花了几年时间,大规模地改写了几百万行代码,同时在不影响用户群的情况下,开发了大量新功能。这是我知道的最惊心动魄的中途重建网站的故事。

临渴掘井不如未雨绸缪,为防患于未然,别忘了预留20%的余量。如果你从未与开发团队谈过这件事,今天就去找他们吧。

七印部落送给大家的《启示录》

《启示录:打造用户喜爱的产品》当当卓越京东china-pub都开卖了,我也该交上去年10月就承诺的作业了,即,把这本书的诞生过程,作为一个案例记录下来。开始吧。

2010107日,因为《人人都是产品经理》而认识的编辑徐同学找到我,说华中科技大学出版社刚刚引进了一本书,叫《Inspired: How To Create Products Customers Love》,问我有没有兴趣翻译。

启示录:打造用户喜爱的产品
启示录:打造用户喜爱的产品

谨慎起见,我各处查了一下作者的背景和这本书的评价,才意识到其NB。比如,Amazon上的英文版78个评价者中71位给了五星(截止20114月)。很明显,这事儿很符合我的胃口,但有三个问题:一是没时间,工作太忙精力有限;二是没能力,英文实在太久没用而生疏;三最关键,没动力,再做一本书,我实在不知道目的是什么。所以,我问了徐同学一个问题:

“我自己可能没时间精力做这个事情,可以帮你找找有没有合适的人,需要么?”

答案,显然是肯定的。

接下来,我在各种渠道发布了召集令,出乎我意料的是,响应者很多,完全超出了我“帮编辑找几位潜在译者,然后看样章试译质量,决定最终译者”的想法。

于是,我在想是否有更好的方式来做这件事情——“你们是否考虑团队协作翻译呢?就是有很多译者,还有负责协调语言风格的等等,有点像字幕组的协作模式。”

一开始徐同学是不太愿意的:“可以,不过译者不宜太多,我觉两个人左右比较好。这本书不厚,240页。”

但随着志愿者的增多,我的想法越来越坚定,开始想做这个产品了,这本书的意义不止在于其内容,更在于它的生产过程。我不想自己上阵,而想做一次尝试,叫“众包”也好,叫“民主试验”也好,我希望发挥团队力量和群体智慧,和编辑同学一起,只通过制定一系列的规则,凝聚一群人来完成这本书。日后我看了《失控》的翻译后记,才发现那本书更早的做出了这样的尝试,呵呵。

“今天应该又有些人联系你吧,再考虑下我的建议呢,呵呵,多人翻译,这本书40节,找到20个人每人两节,然后由几个强一点的人顺全篇,20多个人还是能找到的,这样会快很多,呵呵”

徐同学不是被我打动,而是被志愿者的热情打动,试想有三五十位跃跃欲试,你如何拒绝他们?于是,我们一起来想具体的做法。

“保证大家都有活干。志愿者中强一点的,可以来翻译,有些人文字表达弱一点,可以负责校对,检查,试读。”

我们很激动,一次实践互联网时代合作方法的绝佳机会,就在手中。

安全起见,我和更多的朋友沟通了这样的想法,支持的、反对的都很多。我其实挺坚定的,只是记下了反对的意见,并想办法各个击破。比如很多提到“光是术语就很难统一,大家会翻得不一样”,我的对策是“建立一个术语表文档,每个人把自己翻译中碰到的术语都更新到表中,这样只要大家对术语表都认可,那么全文术语就统一了”。

然后,我们开始讨论用什么平台协作,希望是把整个过程都在线化,大家随时看到每个人的进度,互相督促,互相检查质量。一开始想到了Google Docs,后来因为你懂的原因,放弃了,最终采用了一款叫“百会”的在线文档系统,以及它的论坛。

接下来,我们就把讨论好的规则贴在了论坛里:

1. 征集志愿者截止后,所有人试译同一短篇;

2. 依据试译结果,确定正式译者若干,其余的志愿者作为试读者。

3. 正式译者确定的方式:把所有人的稿译都公开,所有人投票选出较好的。因为担心效率,这条最终未能操作,还是由出版社确定了正式译者;

4. 公开讨论译者报酬方式,因为人多,每个人的太少,比较麻烦,所以征求大家意见是否愿意拿赠书,当然,可以邮件单回,如果要钱,绝对给;试读者的付出也是有价值的,我们建议拿出全部金额的1/8,以赠书的方式回馈。另外,所有人的名字和工作都会详细记在书的序言里;

5. 译者任务认领,自愿选择、协商确定每人翻译的章节。令人惊喜的是,实操中是24小时内完成这步的;

6. 翻译过程中,维护统一的术语表,在论坛里共同讨论难点的词句、段落;

7. 初稿完成,译者交叉审校,即每位译者审读其他译者的章节,提出修改意见,通过这种方式让文风尽量统一;

8. 一轮交叉审校完成,试读者参与进来,自愿确定试读章节,我们宏观调控,确定每个章节试读人数差不多;

9. 译者依据试读者的意见、建议修改;

10. 邀请专家审读全书,到了这步,回到了现在出书的正统流程上。我在这时邀请一些业内名人来试读,也是为了借力营销。

因为对出版行业的浅薄了解,期间我表达了一个顾虑——“全书参与人数太多,可能很难控制电子版的外泄,影响实体书销量。”这其实是对出版社的顾虑,我当然是不怕外泄的,我做这事儿本来就纯公益了,呵呵。好在徐同学声明大义——“呵呵,这个我到不是特别担心,好的书上市以后马上就有人做电子版,这个是拦不住的。相反这到是营销的方式。”

确实在过程中,我们发现这只翻译团队,也成了营销团队,不断的对外散发出有关这本书的各种消息。大家的各种讨论也非常热烈,比如自发出现了“翻译技巧的讨论”,“如何通过增加每个人的点评,为书增值的讨论”等等,都让我充分体会到群体智慧的力量。

不但是这个团队的群体智慧,我们更借助了潜在读者的智慧,《启示录:如何打造用户喜爱的产品》书名的确定,就是团队先提出了几个候选,然后我召集了投票,最后再微调确定的。

而翻译团队的名称,也是大家讨论的结果——七印部落,上帝造人用了7天,人有7宗罪,欲望及需求来源于此,木有错!我们就是来拯救大家的,从欲望和需求出发,呵呵,有点神秘感,也有点使命感,当然,和书名——“启示录”也很配。

真正意外的惊喜,是这个团队,她并没有随着书的完成而消失,大家又自发翻译起了国外各种优秀的产品文章(当然,我们会征求原作者的同意,并署名加原文链接),在《程序员》设立了专栏,在各种网络渠道发布,继续贡献着力量。

如果你愿意加入“七印部落”,联系我们吧,:)