Category Archives: 流水帐

[得到大学课程作业] 利用“教育家思维模型”管理长期目标

  前一阶段CEO对我所在部门进行了调整,剥离了短期业务,剩下的人被明确赋予了一个长期目标。这个目标实现难度很大,但战略上对公司非常重要。

  我很同意“教育家模型”这一课的一句话:“管理长期任务的挑战是,时间会稀释你的目标感。”此前我们部门的目标感的确有点模糊。某种意义上,这次组织调整,就是公司高层在用最直接的行动点一下。因此组织调整后,重点如下:

1. 把精力放在统一目标上:

  通过All hands和头脑风暴等形式,统一团队共识,让每个人都弄明白这个部门的使命和路线图。我们并不是要求大家像阅兵方阵一样机械统一,相反,希望一线同学根据具体情况作出更高效合理的决策,只要每个人清楚目标和底线在哪里,不南辕北辙。

  进一步也花了很多时间和其他部门沟通。总之,把目标昭告天下,争取所有人的知晓和配合。

2. 用持续行动维护信用

  我们定下规矩,每两周,副总裁和总监们都要深度讨论和复盘一次。有时候会上吵的很凶,但最终,做了不少“艰难但正确”的决策。

  例如,决定向另一个团队让出一块成熟而容易出绩效的业务。因为这个产品与我们的战略目标关系不大,应该把人手撤回来,保证核心战场的“范弗里特弹药量”。

  这个行动清楚告诉所有人:“我们是认真的”。一线同学的注意力变得集中;与“礼让跑道”的兄弟部门之间,边界更清楚,信任感更强,他们经常主动为我们提供各种关键的火力支援。

  总之,从我的实际体会来看。拥有一个长期目标,虽然一时会面临更复杂困难的局面,但处理好的话,这个目标本身就会变成一面旗帜,让各种人和资源向你聚拢。(具体而言,应该做到“耐心沟通统一目标”、“知行合一维护信用”这两点。)像滚雪球一样,越往后,自己、团队和友军越能获得更多成就感。

[得到大学课程作业] 利用“指挥家思维模型”推动多部门复杂协作

  这个季度,由我的部门牵头推动一个重要项目。该项目对公司具有的战略意义,但是难度又很大,尤其是复杂度很高,涉及到7个不同的部门(算法研究院、1个数据中台团队、1个硬件中台团队、1个系统中台团队、3个前台行业部)。所有部门都有各自不同的打法,例如:

  • 对硬件团队而言,开一次模上百万,换个供应商一般12个月才能保证稳定。
  • 然而,对前台行业部来说,紧贴客户订单quick and dirty,因为每半年要根据业绩末位淘汰。

  我是怎么解决的呢?借鉴“指挥家思维模型”,在立项时,通过和各方的反复沟通,统一了重点:

  1. 明确业务节奏和进度里程碑。确保业务节拍不同的团队,互相能够产生节奏配合,例如硬件产品推出前大约4个月,市场团队已经开始上一代产品的回访和新技术布道。

  2. 规定各个层次产品和业务的关键产出。划出下限,确定最坏情况下也必须限时拿下的山头。同时提前准备好风险预案。

  3. 安排内部“吃自己狗粮”团队和Beta天使客户。每一版新产品刚推出,都会在特定的内外部用户先期投入试用,听取反馈,验证产品可行性。通过Alpha 和Beta测试,建立标杆项目,总结最佳实践手册以后,再大范围推广。

  总之,通过抓住“同步节奏”、“划定下限”、“先期排练”这三件事,推动复杂的战略项目逐步落地。

2018我还活着

  钢哥在他的微信公众号BioData里面提到我的BLOG,说我几个月没更新了。所以跑来发一篇以证明我还活着,这个写了十几年的BLOG还会继续。

  2017年遇到了不少事,有的时刻很狗血,有的时刻很艰难。年初给自己定的3个目标,红头发没实现,放松状态提高沟通和决策质量只做到了一小半,考虑到地形,还好。特别感谢身边的战友。

  BLOG写得少,除了创业耗费心力以外,还有个原因:2016年的目标之一是读50本书并记录在BLOG,最后也确实坚持完成了。这也是近几年更新最频繁的一年。但有点用力过猛,此后一段时间没兴致打开BLOG敲字。

  逐步恢复正常,继续战斗,继续写BLOG。

《GeneDock Python SDK从入门到精通》写得好

  GeneDock的基因数据工程师成帆撰写了一篇BLOG《GeneDock Python SDK从入门到精通》,我觉得写得很好。连一向挑剔的CEO厦戎都转发了一下,并评论:“静下心写好每一行代码和每一段文字,会看到大不同”。

  很多公司抄袭我们,从网站文案、会议PPT、技术建议书、微信公众号到招聘JD。这么不走心,真能服务好客户吗?还是上次藏在HTML那几句话送给他们。想跟更有意思一点的对手过招。

  最后放一张以前贴在微博里的照片,珠峰四号营地,凌晨三四点钟,冲顶的队伍已经出发。登上8848的人,有4%的概率回不来。加油!

GeneDock招收生物信息实习生

  GeneDock每天帮助客户处理TB级别基因组数据。基因数据工程师支撑这个行业最活跃的创新企业设计业务架构方案,使用Docker容器等各种数据技术帮助客户把NGS分析流程迁移到云端。

  我们正在招收生物信息实习生,具体岗位要求请参考 https://www.genedock.com/joinus/ 这里的“生物信息算法工程师”和“基因数据工程师”两个JD。实习工资比照互联网行业平均标准按天计费。要求全职实习至少3个月以上。转正offer可以在面试时一起谈掉,也可以实习期间再谈。

  简历发送到 hr at genedock dot com 。也欢迎推荐人才。老规矩,实习生转正或候选人入职过了试用期,推荐人送iPhone或大疆DJI无人机。

悉达多·穆克吉的《众病之王:癌症传》

  前几天从我们GeneDock的公共存书里翻出《众病之王:癌症传》。利用上下班时间,在地铁上读完了。这是一本非常精彩的史诗。

  对抗癌症本来确实是个有点压抑甚至绝望的话题,但同时也体现出了人类惊人的智慧和坚韧。一代代医生和生化学家提出各种假设,然后努力用科学试验和临床观测证明自己的想法。大多数人都失败了,但每一时代的主人公都完成了某些使命,替后人铺了一段路。读到最后几章,希望慢慢多起来。近二十年的技术进展尤其令人振奋。Rb,res,myc……每个基因突变的发现和证明,都是一段令人叫绝的侦探故事。随着致病机理逐渐被揭示,针对各种癌症通路的靶向药物也就开始出现了。

  读这样的书会强迫你思考生命的意义。对我个人而言,GeneDock正在帮助专家分析海量的癌症基因数据。商业以外能为这项事业出一点点力,也算没白过吧。

埃里克·杰克逊的《支付战争》

  《支付战争》精彩的情节可以当小说看,很多卖点:例如作者从传统行业跳槽到互联网创业团队,刚入职时所感受到的一片混乱;例如,现在已成为常识的Growth Hacker运营手段,包括病毒式传播,直接花钱导入流量和用户,注册一个账号送10美元;又如,两个创业团队杀得血流成河,突然戏剧性地宣布合并;再如Paypal和X.com合并后,Elon Musk和Peter Thiel这两位如今红得发紫的牛人之间的激烈斗争,尤其是把Elon Musk赶下台的那次政变……看完这部美利坚商业宫斗戏,你就知道现在中国O2O行业烧钱抢用户然后相杀相爱的这一套,都是原样照搬人家十几年前的玩法。

  不过对我来说,上面这些不算特别来劲。因为Paypal黑帮的故事实在太有名了,大多数所谓“互联网思维”的段落,已经通过各种投资分享、创业宝典、大神博客看过了。

  让我兴奋的内容:

  首先,是David Sacks带领的运营和产品团队在几个关键节点的思考和应对,包括那些因为后续变化并没有执行下去的方案,例如:网络机器人买手计划、主动进军博彩业和色情业的拉斯维加斯战略、针对eBay的“核武器计划”等。Paypal黑帮很多人都是斯坦福大学的校友,这帮人的情商、逻辑和决策能力绝对是最终成功的核心因素。

  其次,是书里若隐若现的技术团队负责人Max Levchin。粗看,这人好像一直埋头忙于关注平台的安全性、防欺诈算法、性能稳定性等基础问题,与一次次激动人心的用户量暴增关系不大。但Paypal和X.com合并之后,Levchin短暂地失去了对技术方向的把控,后端平台就开始出问题,给运营前线拖后腿。最终后端服务是用Unix还是Windows这种纯技术路线的问题,居然导致了技术和产品核心骨干对Musk的反叛。

  最后,是不同组织的企业文化。有意思的是经过了十几年,2015年夏天eBay又把Paypal单独拆分出来。

2016新年快乐

  从2006年开始,每次1月份都会定两三个目标。之后一旦遇到纠结就力保重点,其他事一律让路。翻了翻过去10年元旦左右的BLOG:产品、论文、专利、买房、买车、求婚、生娃、跳槽、旅游、项目、商用、创业……单细胞动物,明取舍断妄念,受益匪浅。

  2015年只定了一个目标,是关于创业和成长的。一年下来,挺困难挺好玩的。感谢周围一圈恨铁不成钢、费心点拨我的朋友师长。忠告听进去了,善意记下来了,方法论还需要更多思考、学习和实践。今年最主要的目标一定还是与此有关,我需要好好琢磨一下。在GeneDock产品还不完美时,很多胆大的天使客户就毅然转向了基因云服务。2016年,要让他们获得与远见相称的收获。

  过去一年,只发了12篇BLOG,只买了34本书,都不到往年的一小半。所以2016年的目标之一是读50本书,并在BLOG和豆瓣上分享读书笔记,哪怕只是只言片语。

  RUDY哥酷爱马拉松一年参加四次正赛并获得奖牌,他总鼓励我尝试参加一次半程马拉松。我还在犹豫。其实想滑更多次雪,新买的单板装备却总没时间用,郁闷!倒是和RUDY哥打了一个赌:如果能B轮成功,我会把头发全部染白,RUDY全部染红(BTW,这个赌局,CEO怂了)。大家给我们作证!

思考:如何开发应用平台

一、开发难度

  和创造单个应用相比,创造应用平台的难度要高一个数量级:

  1. 架构难度:和特定应用不同,应用平台是开放性的,允许别人到系统肚子里自主编程,因此应用平台的用户边界本质上是API。设计一套干净强大、可拓展、安全、完整自洽的API,并在此基础上构建SDK、Console、GUI……是很难的。进一步,为了支撑第三方开发,需要有编程工具链。尽管程序员们都会用编程工具,但即使是计算机系科班出身的程序员,90%也不清楚DSL编译器和IDE的实现原理。

  2. 产品难度:应用平台的产品设计,需要抽象和分解能力。不仅仅满足某个具体用户场景,而是必须把握各种应用开发者在各阶段遇到的各种问题。这里面除了用户体验、E2E场景、还得注意统一的设计哲学和必要的分寸感。没经验的PD往往忽视谨慎思考和设计,强调快速迭代和重构。对应用平台而言,指望靠蛮力代替深思熟虑,行不通。

二、成长周期

  关于平台何时成熟,存在一些客观规律:

  1. 平台真正“立”起来至少需要4年时间。看那几本回忆Unix、Windows NT、NeXT、AWS初创的书,例如G.Pascal Zachary写的《观止:微软创建NT和未来的夺命狂奔》,这些系统前4年都跌跌撞撞甚至反复重构。

  2. 第2年最容易死。BAT三巨头几乎同时启动自主云平台:阿里的飞天系统、腾讯的台风系统、百度的C++重写Hadoop计划。但腾讯和百度的团队在第2年的时候都挂掉了。事实上,阿里云差不多也在那个阶段经历了惊涛骇浪,只不过运气好,马云这个老板异于常人。

  3. 关键是团队的成熟。阿里云最重要的行业贡献不在于其本身的IaaS业务,而在于那支从零开始把操作系统做出来的技术团队。现在飞天团队很多牛人跳出来创业,如果还是做平台的话,就会知道哪里有坑。

三、方法论

  1. 发布的节奏感非常重要。从阿里云辞职,老上级点拨我:如果只做一件事,就是保持发布节奏。一个里程碑一个里程碑下来,现在是Sprint 18。真是做对了。虽然前面说4年才能成熟,但是不可能有老板真能容忍你4年啥业务也不扛。这就意味着,得向客户和业务团队承诺产出,一旦承诺了就必须说到做到。这还意味着,必须现实主义,收敛战线,降低阶段性期望,为支持业务做些妥协。衡量一个技术团队的基本标准,就是持续交付能力。

(Intel曾经遇到过困境,CPU浮点运算部件有错误,不得不召回,AMD弯道超车抢先推出多核CPU。可惜AMD无法保证稳定交付,结果又坐失良机。再往前,摩尔定律其实不是客观存在的自然规律,而是Intel的明确战略,给客户承诺的交付节奏,给自己团队戴的紧箍咒。在撞到纳米墙之前几十年,Intel一直说到做到)

  2. 时刻关注平台架构。保持低耦合高内聚,保持模块之间的正交。否则越往后越痛苦。尤其是客户业务接进来之后,如果边界不清晰,到处插管子,就死定了。要理解著名的Conway’s Law: A design reflects the structure of the organization that produced it。这条定律的意思是:什么样的团队组织结构,最终就会开发出一模一样的软件架构。如果有四个小组合作开发编译器,系统最终一定会长成一个四阶段编译器。所以大型软件组织内,在重构系统之前往往先reorg团队。

  3. 好的软件工程实践,决定了技术团队的层次。Github用的怎么样、Bug管理怎么样、代码审核是否严格、发布升级是否自动化、有没有单元和集成测试……到一个技术团队里呆几个小时,鼻子闻一闻,就知道几斤几两。技术团队如果这些基本功不好,摩擦力会越来越大。

  4. 问题是什么,永远比解决方案更重要。最常见的错误就是:拿着个锤头,眼里看来满世界的问题都是钉子。必须花很多时间深入思考:客户有什么问题?我们能带来什么改变?逐渐建立对这个领域的独特洞见。

(仔细读了读巴菲特创业最初10年的信。他先建立了自己的独特benchmark,然后把投资对象分为4类,每类有不同的触发条件和行动。)

  5. 找到issue优先级明确roadmap才能减少焦虑。能砍事儿的才是合格的产品经理。做了太多客户不需要的事,团队总是加班,这是管理债,是耻辱,不是骄傲。

(讲到这里,顺便贴一篇两年前给pFind组的回信,最近Boss H又翻出来抄送给pFind团队)

  我已经离开pFind很长时间了,不了解细节。说错了大家拍砖。憋了好久,没憋住,因为pFind始终是我的产品。

  所谓战略,是明确不做那些“比较对的事”,只做一两件“非常对”的事情,壮士断腕才能做好产品,好产品才有资格进一步谈平台化和生态系统。

  客户需要精确的结果,客户需要飞快的速度,客户需要傻瓜式的安装和参数配置,客户需要全流程解决方案,客户需要在平台第三方开发的API和SDK,客户需要易用的界面、配图和表格……不从前面这些需求里砍掉90%,集中精力把剩下的一两项做到全世界第一,就没意义。

  不如每个人列两个单子:你认为pFind最该做的事,最该放弃的事。别写很多所有人都同意的真理,信息熵为0。如果为了防止互相影响,就单独发给BOSS H汇总。

  恕我直言,所有界面类的开发工作,pFind组都很不擅长,做得很苦、做得很烂。我们这些人离顶级UED差得太远,也未必有热情追求用户体验的卓越。也许更应该集中做算法、做流程框架、设计数据接口和API、向外界开发者提供API和SDK(这里的API也许是本地的,也许是Web Service)。至于界面也不是彻底不做,现有界面可以重构到前面说的API和SDK上去(以便吃自己的狗食,验证API、SDK的设计合理性)然后再开源出去。

四、BD和运营团队

  传统背景的业务人员面临挑战。因为他们要花一些时间才能意识到:推销的是通用平台,而不再是某种具体应用。

  1. toB销售,又面对专业技术话题,业务团队需要配备得力的业务架构师(BA)帮助技术交流,给解决方案。

  2. 找来了很多客户,仔细聊下来,有一半其实是需要Word(应用),而不是Windows和VC++(平台)。早期应该组建专门的技术小组,自己扑上去帮客户开发应用,也算吃自己的狗粮。后期再逐渐找外包商和集成商。CEO说,友盟的前70个客户,都是友盟自己的程序员扑上去帮他们写APP。

  3. 平台是前所未有的东西,是改变现状的创新。所以业务团队的目标不是销售数字,而是尽快立起标杆客户。

  4. 业务团队需要了解技术团队的发布节奏。知道有“水面以下”工作量存在,例如产品架构设计,例如重构偿还技术债。这些最终会影响到技术团队的持续交付能力。

  5. 业务团队有权要求更多后方的火力支援,理直气壮扯着产品经理的耳朵大喊客户需求,明确业务优先级,并监督技术团队的产出。

  6. 最终,其实和技术团队一样,业务团队最大的挑战还是学习能力,建立独特的思考模型。

GeneDock成立一周年了

  今天是GeneDock成立一周年。一大早,在外出差的厦戎就发了一封邮件出来。我很喜欢里面的一句话:“一起建设一家员工喜爱,客户信任,行业尊重的好公司。”

  后来RUDY哥又发了一篇博客《做一只努力的梯子》,感觉特别符合当下的心境。“做钉子的做一只坚韧的钉子,做踏板的做一只不打滑的踏板。”

  搜索了一下,找到去年刚开始时发的一篇微博

  回到家,女儿跑过来,给了一个认真的拥抱。

  跳出懒惰、恐惧、自负、自怨自艾……专注起来,做一个快乐、靠谱、勤勉的创业大叔。