Bloody Sunshine

Just too damn hot

产品经理和产品管理

产品经理(PM)可能是人们对互联网行业了解最多的职位了,广大人民群众通过段子形成了对PM群体的印象:

  • 屁都不懂也能做
  • 没啥经验指点江山
  • 最爱的事儿是改需求

产品经理们通常自嘲的姿势是产品狗:

  • 没有人事权但要对结果负责
  • 求设计师
  • 求工程师
  • 求市场资源

黑归黑,很多人连PM是做什么的,以及存在的价值都没搞清就入了行也是事实。大体上,PM不是一个新的岗位,但是互联网行业对这个职位的需求量变得空前的大,而且也具有了更加可见的价值。

为什么需要产品经理

在传统行业中,产品迭代周期相对较长,一款产品的生命周期可能达到数年,通常老板可以协调各部门资源完成调研 - 研发 - 销售 - 反馈的迭代。一款产品的研发过程甚至不需要太多的产品决策,可以由销售驱动完成。举例来说,一家做马桶的公司,核心技术可能是陶瓷釉面和流体力学方面的研究,研发一款全新的马桶可能需要数月(换个外观)到数年(重大创新),较长研发过程中可能有相对明确的目标和产品定义,比如设计一个老年人蹲久了不会腿麻的马桶(等等为什么让老年人久蹲)。一旦研发完成可能销售数年甚至十几年。然后研发团队去继续研发下一款儿童不会掉进去的马桶。

不过一旦产品线太长,老板有限的精力会成为瓶颈,这时就需要授权下属对不同的产品进行管理,以保证公司顺利运转,如果组织结构按照产品进行整合,这个对产品进行管理的人就是产品经理了。

互联网行业有一个特点:产品是持续迭代/持续发布的。无论做一个网站或者一个App,消费者每次使用都会用到最新的版本。在这个过程中,每周甚至每一天都需要进行产品决策,如此高频率的决策需要高强度的精力投入,稍具规模的公司,老板都不会有足够的精力参与多数产品决策。于是就凸现了产品经理这个角色的价值。

产品经理的目标

如上所述,产品经理是为了解决老板精力不足以跟进产品持续迭代决策的问题。那么这个角色的目标是什么呢?

  • KPI?
  • 创造优秀的体验?
  • 为用户创造价值?
  • 改变世界?

都是瞎扯,产品经理的唯一目标是利用任何资源让产品价值最大化(此处先把长期价值和短期价值的争论放一放)。

很多产品经理患有「下一个乔布斯」妄想症,动不动就把用户体验挂在嘴边。但是你要知道,用户体验是工具而不是目的,产品经理追求用户体验的唯一愿意是:提升这个产品的用户体验,可以有效的提高价值。

换言之,如果一个提升一个产品的所谓「用户体验」,不会带来相应的价值提升,比如投入几个前端工程师去把一个内部管理系统的界面做得十分fancy,那么这个投入就是浪费的。产品经理就是失败的。

之前知乎有个问题 同样是节省时间,铁路为何花巨资提速,却不愿提升用户体验改造流程? ,这是对用户体验的典型误解,用户体验的基础是满足用户的需求,而不是提供奢华的服务。一个豪华但是没有火车通过的火车站,对于需要旅行的人用户体验好么?显然不好。在运力不足的时候,提速(提升运力的必要手段)就对用户体验最重要的提升。

很多只做用户端的产品经理,误以为用体验就是交互,设计就是UI或者外观,这是非常业余的。(此处绝非黑锤子)

产品管理

产品经理(Product Manager),顾名思义理论上做的工作应该是产品管理(Product Management)。但是在实际操作中,多数产品经理在做产品设计的工作,对于产品管理基本上处于下意识或者被动管理中。产品管理有如下关键点:

  • 产品的愿景和线路图:主要是哲学问题,这个产品是什么,为什么存在,要到哪里去?不断和团队传递产品愿景有助于提高协作效率,保证大家往正确的方向前进。
  • 需求Backlog:所有已确定和未确定的需求,再进一步讨论和整理前应该进入Backlog,之后基于Backlog中需求的优先级确定未来的研发计划。
  • 团队资源:团队资源决定了每个迭代周期能做多少事情。产品经理必须非常清楚,才能有效的安排研发计划。
  • 优先级:优先级管理是多数产品经理日常工作的核心任务,大量需求飞过来,团队需要明确的知道接下来要处理哪一些,而且要随时同步。基本上可以用急迫性/重要性的矩阵来判断。(需要注意的是,紧急但是不重要的事情多数时候不是真的紧急,在快速迭代的产品中,很多你以为的紧急,两个版本后都不是个事儿了)

在我入行的最初几年,也是过分关注产品设计而忽略了产品管理,好在跟对了老板,虽然是无意识的,还是在老板的驱动下对于优先级和Roadmap进行了管理。在实践中掌握了基本的方法,命好 :P

组织结构与敏捷开发的一点随笔

在日本呆了几个月之后,对于一些我们原本习以为常的架构,有了更深的理解。可以说是看到了落后与传统之后,更能明白先进的价值。
对于国内的互联网公司,敏捷开发是默认选项,而且实用主义的中国人并不拘泥于传统敏捷(Agile/Scrum)那一套,在软件工程管理上走得更远,更灵活。

传统的软件开发模式

传统的软件开发模式是长周期,里程碑式发布的,典型的是类似微软Office早年没几年发布一个大版本。这个开发模式的流程通常是市场研究/反馈 - 确认功能需求 - 设计(工程/视觉) - Coding - 内部QA - 小规模外部测试 - 交付/上架。这里面每一个环节都是以月甚至季度为单位计算的。
这个流程的目标是按时高质量的交付需求产品。但是现实是非常骨感的,在一年甚至数年的项目周期中,外部环境千变万化,如果在进入Coding之后的阶段有需求有变更,可能会对之前的设计架构有所冲击,开发团队将会面临三个选择

  1. 一旦需求确定,拒绝变更:会导致无法快速响应市场变化
  2. 在之前的方案上打补丁:如果架构设计出色可能问题不大,不过没有万能的架构,总会有一天补丁打得太多导致积劳成疾。
  3. 推翻重来:市场变化这么快,这次推翻重来了,谁知道俩月之后是不是要再推一次?

显而易见的:交付周期,交付质量和灵活度无法同时获得。因为有这些个问题,也就有了签字画押确认需求确认设计确认确认确认的超长流程。

敏捷开发模式

为了改善软件开发流程中遇到的问题,九十年代中期(是的1990年代),敏捷开发模式初步成型,并广为软件/互联网行业所接受。敏捷开发理念如今看来也并不过时,但是和所有理念一样,在生产实践中仍然需要具体的方法论,目前最流行的敏捷开发方法论应该是Scrum,核心方法是以周为单位开发/每日站立会/定期回顾,这些方法也被国内很多团队所采用。

大体上敏捷开发的目标是即使需求不断变化,也可以高效高质量的交付产品。
但是,如果读过敏捷开发的书籍或者文档,你就会发现,有一个词被反复提及:客户(Customers),这和国内互联网公司关注的用户(User/Customer)是不同的概念。这里的客户通常是需求方,这也引出了下面这个话题。

传统行业实际操作中的软件开发团队管理方式

在互联网行业,我们非常习惯高度集成的团队:一个产品团队中有相对独立的产品/设计/工程/商务/销售等角色,这个团队对产品结果负责。但是对于传统行业来说完全不是这样,传统行业(和这个世界上很多人)对软件工程的理解是:外包。很多行业认为软件开发并不是自己业务的一部分,所以并不会建立一支团队开发和维护自己需要的软件产品,而是通过购买或者外包开发实现目的。这种情况在发达国家非常普遍,所以各种关于敏捷开发的文档里才会如此强调交付(Delivery)。

时至今日,很多行业需要的软件仍然是行业工具,通常通过购买(比如制图软件)或者定制开发(比如ERP系统)来获得,但是随着人们生活的信息化,越来越多的行业开始通过软件或者网站为消费者提供服务,比如房地产或者服装品牌。于是需求方寻求定制开发用户产品,简单的比如官网,复杂的也许会有在线销售或者定制业务。
传统企业的组织结构示意图

相对应的,既然有这样的运作方式,组织结构自然也是如此,通常一个公司会有供应链/产品开发/市场/销售等部门,以官网为开端的互联网产品通常是市场部门寻求外包解决方案,随着需求越来越多,能带来的价值越来越高,外包成本越来越大,该市场部就会考虑自建一个团队进行用户产品开发。于是变成了供应链/产品开发/市场(包括互联网产品开发)/销售等部门。这个互联网产品开发部门其实和公司主营业务关系不大,存在的原因一般都是成本考量,这解释了为什么传统企业的互联网相关部门没有什么话语权(甚至有的时候在IT部门下),这也可以理解为一种历史包袱。
传统企业在新时代的组织结构示意图

在日本发现的有趣的事情是,某些公司虽然本身是互联网公司,在组织结构的设计上却是非常传统的横向大部门方式,业务部门/设计/工程开发部门这样,因为业务部门是最终赚钱的部门,所以有最高的话语权和最终决策权,其视设计部门为内部外包公司,把需求提给设计部门之后,设计部门整理确认,然后二度“外包”给开发部门。这样的组织结构会导致不同角色各自为政,缺少产品团队内部沟通,难以产生优秀的产品。

国内的情况

按照我的了解,国内的互联网公司基本上倾向于高集成度的小团队作战,通过减少组织层级保证信息传达的有效性。因为是一个相对稳定的团队长期经营一个产品,多数团队都对Scrum进行了简化,以对应更高节奏的开发。

从产品管理的角度看,无论网站还是App基本上都可以做到以周为单位快速迭代;工程管理角度上看,有追求的团队基本上能做到:

  • 持续集成(CI)
  • 持续测试(CT)
  • 持续交付(CD)

国内社交媒体上的产品狗们经常会黑自己经常改需求,之所以敢于自黑,通常是因为真的自信:今天改的需求明天就特么上线了,这是多么强大的效率啊。
总的来说,我觉得优秀的人才,灵活和高效的组织结构和项目管理方式,是中国互联网近十年弯道超车的重要原因。

优秀的人才

提到优秀的人才,还想补充两句就好像设计方法论无法保证作出牛逼的设计一样,项目管理方法论也无法保证项目的结果牛逼。关于敏捷开发有太多的最佳实践了,但是无论Pair programming, Code review还是TDD都无法保证你的代码是牛逼了,只有牛逼的团队能帮你接近牛逼的结果。

关于VR的交互方式

打开Ulysses发现了一篇一年前没写完的文章,发出来吧。


这两天听机核VR这一期Podcast,关于交互方式有一些想法。

这一期节目中提到了好几次,VR在游戏领域的应用可能是聚会游戏,这是一个比较糟糕的可能性,Wii当年打开市场就是聚会游戏,Party游戏这个卖点,后来Kinect其实也有类似的性质,但是最终消费者发现:使用率奇低,买来的结果多数时候都在落灰。所以Wii U失败了,Xbox One的Kinect也没能成功。聚会有太多更便宜、更加容易上手、没有场地要求且同样充满乐趣的选择。我觉得这个市场不会被VR Video Game再次打开。

托几位潮人前同事的福,玩过Oculus Rift Development Kit、Google CardBoard和三星的Gear VR,感受上后两个区别不大。整体上来说,这三个的交互方式都是大问题。

Oculus主要依靠手柄,CardBoard主要靠盯着某个点看。前者略实际上用陀螺仪取代了右摇杆,移动时容易带来某种程度上的眩晕;后者类似Kinect的悬浮确认和选择,但是十分低效且容易误操作。

大体上VR有以下这些交互点需要处理

  • 移动位置
  • 旋转
  • 轻度输入(选择)
  • 重度输入(输入文字、图片、声音、视频等)

其中旋转是VR天然解决的问题。移动位置是大家比较头疼并试图挑战的。目前可以看到如下解决方案:

  1. 提供场地自由移动:完美但是场地面积总是有限的,且消费者不一定有足够大的场地。
  2. 全向跑步机:这玩意好像在各大展会show了两三年了,但是还没允许玩家试用过,私以为安全性的问题和成本的问题都很难解决
  3. 手柄:对于Hardcore玩家来说很好,但是这玩意对于普通用户毫不友好,上手并不容易,而且并不符合自然直觉。
  4. 软件设计的时候不需要用户移动:说实话这个解决方案不错,比如赛车游戏,而且我很期待不久的将来出现VR电子书,在这个虚拟世界里面,举头望明月,低头电子书。。。

目前看,方案1配合体感座椅之类的设备可以满足游戏厅类的需求,手柄可以算是比较好的满足游戏玩家的需求。

关于输入,轻度输入方面目前 Cardboard 类产品用的注视停留效率太低,一定会被淘汰,手柄/手套/手势识别是未来的趋势。而重度输入反而简单,通过mic和摄像头进行输入对操作的要求已经足够低。

上面说的这些更多的是内容消费和娱乐方向,如果讨论生产力工具会有一些不同。比如,如果希望通过VR做照片和视频编辑,很难做到自然精确,毕竟物理世界并没有对应的行为。但是如果编辑3D VR场景或者剪辑全景视频,VR应该可以非常好的胜任,想想看很可能是相当科幻的场景,被环绕在360度视频中,像上帝一样操作时间。手柄/手套/手势操作精度的问题应该可以通过类似iOS文字选择放大镜的方案解决。

Back from Hawaii

过完年去夏威夷玩了几天,和想象中多少有些差异。

去了Oahu和Maui两个岛,Oahu岛有著名的Waikiki Beach,沙虽然不那么细,但海真的美。作为怕水怕火又怕高的我自然连泳裤都没带,纯在沙滩上晒太阳,然后迅速就看腻了比基尼大妞,在Waikiki看到冲浪的人貌似都是入门新人。

  • 有个Honolulu Zoo动物园,里面有很多热带动物,比如热带企鹅(什么鬼),还挺有趣的。
  • 珍珠港/亚利桑那纪念馆,门票是免费领取的,如果不是旺季无需网上预约。去的时候碰巧遇上直升机事故,亚利桑那纪念馆不能进了。只是看了一下前段的历史展。
  • Hanauma Bay,很有名的一个海滩,旺季去貌似人暴多,是浮潜圣地,水清沙白。
  • 顺便还看了个DEADPOOL,又贱又污,值得一看😂
  • Maui岛主要干了两个事儿:开车走了Road to Hana,真心不错。出海看鲸鱼,吓死我了。。。

大体上感觉:

  • 自然风光优美,人文方面略朴实。
  • 夏威夷航空硬件和服务都很一般。
  • 到处都是日本人,海滩上到处是日本妹子的尖叫(玩水就会尖叫也是够了)。
  • 虽然并非美国本土,但是也流露出一股傻大黑粗的气质,商品都是大号的,模具都是大尺度的,能源都是大量消耗的,回头去美国本土验证一下 Orz

照片在instagram上发了几张,就不贴过来了。

给过了生命周期的Ubuntu升级

VPS八百年没改过配置了,因为想把WordPress迁移到Ghost上(WordPress君你别哭),就打算Apache也换成NginX一起搞了,apt-get的时候发现各种报错,源都连不上,全线404,还倍儿洋气是个IPv6的地址Orz。

Err http://archive.ubuntu.com raring/main i386 Packages

404 Not Found [IP: 2001:67c:1360:8c01::18 80]

搜了一下才明白,我用的Ubuntu 12.10造就过了生命周期,需要升级

简单易行的升级就是 do-release-upgrade咯。对不起,因为已经过了生命周期,apt-get源已经不支持了 Orz。还好Ubuntu官方有升级指南 。按照指引一步一步完成即可升级。

过程大体上和把大象装冰箱差不多:

  1. 修改sources.list,把源改到old-releases
  2. 安装update-manager
  3. 升级。

我在操作的过程中还是说找不到合适的镜像,要求覆盖sources.list,同意即可。

另外还发现了一个各个版本Ubuntu的Repo生成器,挺方便的:https://repogen.simplylinux.ch

(Fin.)