Monthly Archives: September 2015

思考:如何开发应用平台

一、开发难度

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

  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哥又发了一篇博客《做一只努力的梯子》,感觉特别符合当下的心境。“做钉子的做一只坚韧的钉子,做踏板的做一只不打滑的踏板。”

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

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

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

GeneDock刘畅将在PyCon China 2015做报告

  人生苦短,我用python。但用python最人痛苦的事情有二件,一个是编码问题,另一个则是import不了包。9月19日,GeneDock团队的刘畅大神应邀在PyCon China 2015大会上做技术分享,题目是:python的module机制与最佳实践。

  畅爷这次报告将详细讨论python的包管理机制,python如何引用包,PYTHONPATH是怎么回事,sys.path与其有什么不同。为什么py3把py2的包引入机制彻底废弃。py3的absolute import又是怎么回事。还会给出关于python项目目录的最佳实践,避免各种引用的问题。

  刘畅,曾就职于微软与阿里云,现在是我们GeneDock创业团队的一员。他的博客地址是:http://lcblog.sinaapp.com/