Tag Archives: 产品经理

2014新年快乐

  新年快乐,万事如意!

  2013年一共发表了32篇BLOG,比往年平均值要少很多,10月份以后因为忙ODPS对外开放的事情,更新频率更下降了。但我会继续写下去,还会写很多年。感谢您对这个BLOG的关注。

  单细胞动物,又很懒,没法多线程。关注这BLOG稍久一点的同学,大概会知道我总习惯在一月份定些重点,之后一年里如果遇到冲突纠结,就力保这两三个主要目标,其他一律让路。这种做法是从2006年开始的:软件、论文、专利、买房、买车、求婚、生娃、跳槽、旅游……运气好的一年,定了4项大事,忙到年底累得臭死,居然都能搞定;也有瓶颈年头,只定1个目标,年底仍然有遗憾。但总体而言,集中精力是个好习惯,受益匪浅。

  回去翻了翻BLOG,2012年有3个目标,年底感觉其中工作方面的目标没达标。于是2013年继续,而且只定了这一个目标:成为合格的产品经理,给ODPS留下独特贡献。

  一年下来,在ODPS团队里帮了些忙,仍然称不上“独特贡献”。所以2014年还得继续盯住这个目标。不过我快沾到边了。等ODPS对外开放一期、二期、三期的事都妥帖了,修炼可算小成。

  最近两个月为工作焦头烂额,家人说我:“念念叨叨总是你的ODPS对外开放,其他事完全不关心。”我的确像是有点魔障了。但这事真的很重要。感谢老婆、老妈和刚会说话的女儿,家里这三个女人都比我聪明、体贴、淡定和坚韧。

  除了眼前的具体目标,我希望在2014年能有更多勇气面对理想。回去看2006年初次盘点年度目标的BLOG,写了这么一段:"本科听老罗的课:'年纪大一点以后,最难的就是保持强悍,仍然敢把理想挂在嘴边'。没真正理解,或者说不够老,还没资格发表观点。"8年过去,三十多岁的大叔了,是证明所谓“强悍”的时候了。

产品经理感悟

  我一本正经教训过别人如何当产品经理,其实自己也入行没多久。这个夏天有些进展,邮件报捷各路老大回复鼓励。自己却一度纠结困扰:领导力、产品设计、执行……都抓不住方向。

  tiny4cocoa论坛有个帖子这么说:“几乎所有研发团队的技术都听命于技术经理,并且尊称老大,没人会去听命于产品经理的。产品经理虽然挂着一个经理的头衔,但是却没有实权。在天朝,大部分产品经理所作的工作就是把老板的想法产品化,而不是自己设计产品”。写得挺好,要警醒,不要仅仅成为监军。

  看到一个国外电视节目叫Design Superheros,镜头跟着专业设计师从头构思一间咖啡馆、书店或者服装店的每个细节。挺有意思。各个行业其实都有类似“产品经理”的角色。例如二战之前的美国报纸行业的鼎盛时代,各大著名报刊一般都有几个坚持自己品味的传奇性编辑,这些人甚至会跑去修改登在报纸最后一版上的广告和寻人启事的文辞和标点,以便“与其他版面的文字品质一致”。我做了十多年软件开发,总是有意无意把设计仅仅当成了一门技术,只要按某种流程依次按电钮就能得到满意结果。现在才意识到,做好产品的关键是思考人会怎么用它,这需要感悟,即使是我们这种只有API和SDK的平台型产品。

  老大点拨说我太执着于拉更多的业务上来。他还说很多人把所谓“创业精神”当作思维懒惰的借口。没多久coolshell.cn里就发表了一篇博客,摘录了《Rework》的一段话:“他们花大把大把的时间去解决问题,他们以为能靠蛮力来弥补思维上的惰性,其结果就是折腾出一堆粗糙无用的解决方案”。反省:首要目标应该是做出好平台。于是开始花很多时间动脑子,煎熬了一个多月。有一次周六,我在客厅里瞪着天花板呆了一夜,直到周日早上5点外头蒙蒙亮。系统独立思考好难。

  当然除了推演和品位,还有很多工具可以辅助梳理用户的使用场景,例如用户反馈调研和数据分析。有幸参加新浪微博的一次用户访谈,调研内容是针对新推出的某个收费功能。调研员是中科院心理所毕业的美女。细节值得回味。新浪的同学没解释产品设计思路和调研目的,回来搜索了一下,又想了想。意识到这次重点不是为了收集新需求,而是为了验证产品设计。还按照老大的建议,扎到数据仓库里写了一大堆SQL去分析系统日志。实际情况往往和“我以为”有好大差距。挖出了数据,再给典型用户打电话,他们惊讶:“这你都知道……”

  最晕的时候请xc吃饭,说来说去,出问题的根源,不是背景能力,不是做事方法,不是人际关系,而是无法“入戏”。就去找zn老大,主动承担了对外有关的产品功能规划。起初各种开会。记得有个高端复杂的功能需求,花了大家很多精力,最后成果是:把这个需求砍掉,客户和我们暂时啥都不做。以前在哪里看过一句话说:给产品经理打分,不必看他引入了哪些新功能,而是要数数他砍掉了几个需求。如果这句话是真的,那我又加一分。后来又开始一个类一个类梳理ODPS SDK。平台发布出去的接口就像嫁出去的闺女、泼出去的水,再想重构不向前兼容就很难了。花了很多精力讨论、文档、编码。前两天有测试同学在reviewboard吐槽,说leheng是pd没资格审核ship别人的代码。俺只好上去解释:客户端的这个模块很多代码都是俺写的。测试同学回复:“算我没说,leheng牛的”……快乐指数稳步上升,开始“入戏”

  刚写好一份比较像样的产品规格说明,心情很好。看样子这次算挺过来了。旁人看来波澜不惊,自己的感受却很像pFind第一次被客户现场实用那回一样

产品经理应该怎么起步

  在知乎上回答了一个问题“想成为产品经理,应该怎么起步?”

  1.找到一个有意义的项目,跳进去;

  2.把开发和测试同学不想做的活儿都做了。比如写文档、出席无聊会议、收集客户意见、写部署和测试用的一次性python小脚本、团队熬夜加班的时候给大家买夜宵……;

  3.花大量的时间,系统深入地思考你们正在做的产品(警告你,大多数人在这一步会卡壳,停留在协调人和团队秘书的角色上),整理成文字;

  4.向团队展示自己的思考逻辑和结果,说服他们做某事,给项目和产品的未来带来好处。

  我进入现在在做的ODPS组的方法是,在他们都在客户现场加班的时候,参加进去每天一起加班到半夜。要来上百页的用户手册,把里面几百条指令一条一条动手试用了一遍。然后花两天时间写了一个教新用户上手的《入门手册》,并且提交了若干个测试中发现的bug。

  再早,还在pFind蛋白搜索引擎的时候,去生物学家的实验室收集软件需求。就陪着他们杀老鼠,熬夜做实验,每2小时闹钟叫醒添加试剂并记录数据,在高辐射或剧毒环境下处理试验样品。最重要的,和他们一起体会,因为生物信息数据软件设计考虑不周导致前面的一切都必须再做一遍时,那种巨大的愤怒和无奈。

  别以为自己是当诸葛亮,掐指一算,羽扇一指,千军万马就冲杀上去了。产品经理,是一线领头冲锋的工兵,要给身后的兄弟们搭桥、排雷、探路。

  最近算法平台产品推进好纠结,我得拜一拜乔帮主。

jobs

软件研发和团队交流

  下面每一段话都源于近半年的亲身经历,很多话是拥有十几年软件经验的老兵的原话。

  当了pm,尤其是没有界面不需要Axure的底层Web Service的pm,依赖一支巨大的分布式团队,面对不止一家强势客户,交流就成了最关键的任务。半年前我还是中科院里一个不折不扣的技术宅男,与生人聊非技术话题有障碍,害怕给陌生人打电话,外出聚餐拿菜单看半天也不知道点什么。幸运的是,跳槽后碰到几位好上级,每次掉进坑里都能获得诚恳的建议,甚至专门帮我复盘。

  我有每天记录想法的习惯,很多内容整理之后就发BLOG。但这个“团队交流”的主题等了很久。涉及公司内部信息,无法带上具体场景,很多血泪经验就成了糖水大道理。也因为积压太久,即使只放是糖水大道理,慢慢也存了很多段。不管怎样还是发出来吧。

  公司一直在剧烈重组。以往我设计软件架构很少考虑人的交流因素。现在算是理解了著名的Conway’s Law: A design reflects the structure of the organization that produced it。这条定律的意思是:什么样的团队组织结构,最终就会开发出一模一样的软件架构。如果有四个团队合作开发编译器,系统最终一定会长成一个四阶段编译器。所以大型软件组织内,在重构系统之前往往先reorg团队。对分布式的团队,更加如此。前一阵很多人在Blog里写分布式团队的交流问题,用了很多招数,例如两边架起摄像头和大屏幕,形成一个虚拟的统一环境。

  到飞天团队,发现与以前在pFind倡导的工程实践没太多区别:SVN、BugFree、定期重构、单元测试、站立会议、代码review……所不同的是执行。飞天主力是微软出来的,有软件工程基因。制度和团队平台给力,就算是大三实习生也能大展拳脚,两三天内完成千核并行复杂算法的剧烈重构和测试。实际上pFind团队规模已经很大了。飞天内很多小team总共才四五条枪,而且大多是本科刚毕业甚至实习生,有些专注于统计机器学习的算法团队,工程产品也非常宏大。这是人际沟通和工程效率问题,不是学术或工程的非此即彼的投资方向选择。对pFind感情很深,希望后继者有勇气和智慧做到我没能做到的。

  敢提出傻问题是有责任心的表现。很多新人、边缘人、接口人都有交流障碍:不敢把点子或疑问拿到桌面上来,借口是:还不了解情况,等我彻底变成“自己人”再说。怕问错了显得不够牛,或者问对了牵涉别人的利益。明哲保身是动物本能,但它仅仅在黑暗森林低级生态环境下才算是最佳策略,在一个有序、专业、理性的团队里,过分谨小慎微只会显得无能,让别人放弃对你分享信息。反过来,直言不讳也是一种压力测试,可以借以观察团队氛围是否正常。

  tech lead最重要的素质是充分沟通的勇气和器量,“领导和下属之间应该’下棋’而不是’打牌’,在信息对等的情况下决策。尤其是坏消息,必须第一时间告知下属,坏消息往往传得很快,最好让下属从你这里首先获知。”反过来,最愚蠢的举动就是伤害团队对自己的信任。情绪管理、私人利益、交流效率都对信任感造成影响。

  网络公司的技术团队往往被分为前端团队、后端服务团队和基础平台团队。不同类型的团队交流和思考的方式不同。出色的基础平台团队,节奏感往往非常强,知道先做什么后做什么,一开始只做最难最重要的事。

  需求分析的时候,用户经常是在告诉你怎么做(How),这些信息没用,你要问清楚他们的本质需求(What/Why)。用户说要什么就做什么往往死得很惨。福特说:“如果最初我去问顾客想要什么,他们一定会说:一匹更快的马”。

  技术->项目->产品->服务,这是个漫长的进化过程。和一个陌生的技术团队聊,最重要的就是评估他们在这条打怪升级的不归路上位于何处。已经拥有成熟服务的团队会问你:“需要多大程度的可用性?我们的服务目前能达到五个 9,也就是一年无故停机最多5分钟。”(关于服务怎么运维,现在DevOps讨论很热,推荐看看这个

OSS和OTS的区别?

  今天又到产品经理给营销部门作培训了。这次是鹿鹿介绍OSS,我和yj也跑去旁听,讲座很细致。

  结束的时候,有人问OSSOTS的区别,鹿鹿的解释比较正统,有些人还不能充分理解。我插嘴说,拿Office比喻,OSS类似Word,OTS就是Excel,后者有结构,有行和列。当然比起桌面软件,云服务可以存储T甚至P级的数据,通过网络访问,容错安全更强大。美女们纷纷点头说这个比喻用的好,听懂了。

  aliyun.com销售的不是最终产品,而是支撑程序员和创业者的后台服务。因此市场和技术的对接方面,产品经理就面临挑战。把艰深的技术词汇翻译成日常表达,其实还不是最难的。如何体会用户需求,再和技术部门合作炒出一盘好菜?这实在需要悟性、耐力和一点点运气。

  昨天动用领导,纠结的疙瘩总算有解,项目推动起来了。明天飞回北京。在杭州呆好久了,想女儿。之前说好的《伯罗奔尼撒战争史》的读后感,我会稍后补上。

技术出身的产品经理,以及《伯罗奔尼撒战争史》

  从杭州回到北京呆了三天,元宵节又飞到杭州。一般总喜欢坐14L座,靠着窗户,又能最近距离看到机翼和发动机。那晚从天上看下去,一路上经过的所有城市,都有千百朵礼花在闪,非常壮观。

  事情多,同时追两个产品。其中一个慢慢理清楚了。接下来主要就是配合商务和市场团队,观察他们如何操办推进。另外一个产品得更有耐心,目前就是和技术团队泡在一起。周六里程碑发布前,好几天都到很晚。今天办公室没什么人,这篇拖了好久BLOG才有闲暇收尾写完。

  技术出身的pd,和程序员们相处很容易。看大家都那么忙,我也就卷起袖子干点力所能及的活。把文档要过来,一个脚本一个脚本测试,还真发现了不少纰漏。我正在写一个新手入门实例的kick off文档。动动手,有一点实际贡献,而不只是在那里长篇大论指手画脚,团队就会逐渐把你当自己人了。

  另一方面,入职时领导拿亲身经历提醒我,技术背景强的pd,刚开始会对不敲代码有失落感。嗯,还好还好。读温伯格的《成为技术领导者》时,仔细体会过“技术能量减弱”的主题。这次转型我是想清楚了的。很喜欢现在的宽阔视野。(运营美女说,产品经理们各个都是八卦大王,无论后端平台、前端设计师、运营商务、市场公关……pd总能掌握各团队的最新版小道消息)。具体来说,我目前负责的数据分析产品线,对pd的要求更偏技术,招聘中也考虑到了我的背景。大头目说,俺这个月的重点就是沉下去,把后端团队的技术摸透,然后才有可能深入思考如何包装和销售Web服务。

成为技术领导者

  频繁飞行。在机场和天上又重读修昔底德的《伯罗奔尼撒战争史》。我很迷古希腊罗马的史书。以前说过,由于古希腊罗马的贵族大多实际上过战场,甚至自己就是指挥官,因此相比中国史官,他们对战争的偶然性和残酷性的记录要翔实客观得多。这里面最典型的当然要算凯撒的《高卢战记》。而修昔底德本人也是一个很好的例子。很明显他在安菲波里斯攻防战中并无大错,他的舰队赶到时,城市已经陷落了。这次失败,城市的守将攸克利斯的责任肯定更多。只可惜后者的家族背景强大,修昔底德成了替罪羊,以叛国罪流放。

伯罗奔尼撒战争史

  看了一下,《伯罗奔尼撒战争史》的读后感还有大段文字。BLOG不宜太长,今天就到这里吧,这几天会陆续发布。感谢关注。

  补:一开始写《伯罗奔尼撒战争史》读后感,只打算写一篇BLOG,没想到拖成了一个系列。我没有能力对这本巨著进行全景汇总,仅仅是对自己印象深刻的碎片做些记录。这个系列的5篇分别是:

 《伯罗奔尼撒战争史》读后感开篇
 《伯罗奔尼撒战争史》读后感之二:古希腊时代的冷战
 《伯罗奔尼撒战争史》读后感之三:战争之初,伯里克利VS阿基达马斯
 《伯罗奔尼撒战争史》读后感之四:弱国的内部党争
 《伯罗奔尼撒战争史》读后感之五:西西里远征

入职

  On board不到100小时,除了第一天领电脑找工位,后面都过得像旋风一样。飞了好几千公里,见了不少人,参加了十几个嘈杂激烈的会,读了上千页的文档资料。

  今晚6点几个人冲出会议室。让出租司机随便选路线,只要能尽快杀到机场,赶得上回北京的飞机。老大问我感觉怎么样。嗯,听了这么多吵架扯皮,我居然越来越兴奋。在飞机上看完了韩寒的杂文集《青春》。11点,降低高度,机翼底下远远看到灯火通明的东三环和巨大丑陋的央视大裤衩。

  因为是云公司,所以pd间讨论的总是涉及到RESTful的服务API。技术出身的惯性思维很强,听到某件事,第一反应还是先考虑怎么实现。然后就不断意识到,大家其实是在讲业务,关注的焦点是如何理顺上下游,让各团队都有安全感并且高效协同。

  除了内部的事。在客户产品方面做了初步了解。我没想到离开计算所以后,会这么快迎头遇到如此“学术”的工作内容,什么PCA、关联规则分析、神经网络……当然,我的背景决定了领导分派的任务。

  至于真正技术方面,抽空和核心团队的工程师聊了一下底层平台。比我想象的要好很多。具体内容不方便写(Google了一下,在一些博客出现过讨论底层平台的文字,但这些作者随后都收到了公司法务的信,作为商业秘密被删除了)。《程序员》即将出版一期阿里云的特刊,也许里面会有部分介绍。有兴趣的同志们可以关注一下。

  半夜11点59分进家门,女儿睡得像小猪。据说我又错过了关键瞬间,她学会了翻身,把自己卡在了床和椅子中间。

  时间尚短,但感觉这的确正是我想要的。所以还是那句话:愿老天保佑俺们和俺们喜欢的工作。