专栏名称: vipdocker
VIPDOCKER关注Docker、Mesos等容器化技术
目录
相关文章推荐
未来汽车Daily  ·  5C大战5.5C,真·超充还得看岚图知音 ·  昨天  
未来汽车Daily  ·  5C大战5.5C,真·超充还得看岚图知音 ·  昨天  
51好读  ›  专栏  ›  vipdocker

唯品会技术产品人的2016年终回顾

vipdocker  · 公众号  · 后端  · 2017-01-26 12:10

正文

最难以落笔的文章

以往都是不太情愿去写些总结类的东西,主要是一个觉得比较懒,二是觉得价值不大。但是今年却有强烈的冲动需要将过去的一年都记录总结下来,不知道是不是因为一年来的变化比过去好几年都大呢,还是心态成熟的缘故。可是思绪太多,却是从去年12月一致构思到现在才提笔。同时还在等待“靴子”落地,也就觉得提前写没有太大的意义。不过最终的“靴子”终于落地了,所以才正式提起笔来(应该说在正式开始敲键盘)。后面的内容比较“凌乱”,并不是纯技术干货,有技术,有”soft skill”类,有对于管理的理解等等。如果是期待某种技术总结,请绕道了。

人生是一场修行,工作是一种磨难

感恩


千里马常有,伯乐不常有!

在唯品会的一年多,最感谢的是最懂我的“威哥”(真名:宋威)。目前已经在硅谷Linkedin过上了逍遥的正常的上下班的生活,不用再为了迁就我们的时区每天工作到3-4点了。正是因为威哥的信任与放权,让我有了主够的空间主导一个个产品的从无到有的过程。更难得是为了一个个人的PPT与我reveiw再review再review,总共改了8个版。虽然最后没有获得期望的结果,但是这些都不重要了。还有一个需要分享的是威哥让我受益非浅的:“Choose the battle to fire!”。工作中,你不可能永远是“老好人”,你也不可能“四面临敌”。但是你总会需要在某些场合,某些时间点去“战斗”。但是如何做到威哥说的这个,的确考验了我很多。同时我们不能因为某种别人的声音而阻碍了你对事情的推进,更不能为了推进事情让大家都站你的对立面。所以每次如果遇到需要“战斗”的场合,先停下来思考一下,只选择必须“开火”而且是必须“胜利”的战役。在这之前必须不断锻炼自己,强大自己的内心与气场。虽然无法再与威哥共事,但是能与威哥一年半的经历已是一种幸运。

千里马

体系与布局

另外一个必须感谢的人是我们唯品会平台架构部的高级总监鲍大伦先生,现在已经贵为“掌贝”公司的CTO了。在唯品会虽然级别上与鲍总不在一个层次上,不过好在坐的位置近水楼台,得到鲍总不少的教诲。最受益非浅的是两个词“体系”“布局”。在现今的互联网技术体系中,再依赖一个系统/产品去解决问题已经不现实了(公司规模小另说),技术需要的是一个体系,一个融合的体系,一个能延伸的体系。在唯品会,我得以机会做两个从零开始的产品,一个是我们已经开源的弹性任务调度系统Saturn,一个是小规模试运行的容器化系统。除了得益于开源的组件,我们能快速构建我们的产品,不断的迭代推陈出新。更得益于鲍总的“体系”的理念,让我不再局促在某个产品,某个部门的范畴考虑产品应有的核心价值,而是融合体系中各个产品,将自己的产品的核心价值放大,并让各个产品同时受益并乐于配合。另外一个就是“布局”了。在一个大的公司,特别像唯品会这样的几千技术人的体量的公司,想将一个产品推动到公司层面让所有的技术团队接受并乐于使用,并不是一件容易的事。因为技术人总有觉得自己是最牛x的,或是总有喜新厌旧的心里,总希望做/用最新的技术,然而这样却给公司带来资源的浪费和团队的矛盾与冲突。所以所在的平台架构部,就是希望将统一的技术体系集中力量实现与优化,降低成本与门槛。但是不同的团队能那么容易接受么?特别是需要推翻各自为政的某些类似的已有产品。这就需要很好的“布局”了。主要体现在如下几个方面:

  • 高层推动:高层与高层间的互动很重要,中国这样的文化体系下(外企另谈),这个如果是高层间的协议/妥协,则事情将会有个很好的契机。

  • 样板工程:就像“Show me the code”一样,需要说服大家使用,必须要有样板示例,以真实数据说话。但是谁愿意成为你第一个小白鼠呢?这里考验是大家工作中人与人交互间的点点滴滴了。抓住对方的核心需求点,提供足够的支撑,并通过相互间建立的信任来达成这个目标。不然你总会遇到这个困境“是否已经有别的业务团队用过了?”

  • 明星效应:这个是人员布局。当你的团队有技术“大神”的时候,很多时候事情也会相对容易推进,这个通常是我和团队成员说的“Technical Leadship”。因为大家都会对“大神”有一种莫名的依赖。因为如果“大神”都解决不了,这个问题就不是我的问题了。正是因为这种“有人背锅”的心里,大家会对“大神”有足够的信任度。那么事情也就好办了。如果没有“大神”怎么办?那么团队的leader就需要去培养一个“大神”,这个“大神”可以是自己,也可以是别人。幸运的是,我们团队中有还几个“神”一样存在的人,因为他们都是最晚吃饭的。

  • 打广告:这个意思就是需要潜意思去“Sell”自己的产品,特别是当遇到方案讨论的时候,需要深度思考与自己产品的关联性,是否能有切入点。另外就是多多分享,无论内外。互联网公司都会有自己的“大学”/“学院”类的组织,通过她们来组织定期的技术分享,将产品“卖”出去。另外也可以参加对外的技术沙龙演讲,则可以反向影响公司的技术导向。对外分享还有个好处是,组织者会去帮你打广告,比你在内部自己打广告有力的多,因为总有“外来的和尚会念经”的思维,产品用的人自然就多了。

  • 数字化:如果已经有几个成功的样板工程了,那么将其通过某种手段(如Dashboard)的方式展示出来,让更多的团队看到,自然使用的信心就增强不少,那么后续就会有更多的团队会去使用,而不是在问有没有用过的问题,他们就会自主的去接入和使用了,那么产品后续的推广就轻松很多了。如我们内部的Saturn的dashboard的使用统计,这样别的团队看见就不会有过多的质疑了:

Saturn Dashboard

团队

一年下来,同时要感谢是陪伴我的两个开发团队,一个是我们服务化体系的OSP团队,另外一个是我上面提的已经开源的产品Saturn所负责的团队。正是他们的付出才使我们的产品有了现在的样子。OSP已经支撑公司百亿级别每天的调用,Saturn也已经对接了公司超过60个业务,管理着180+的机器,超过800的作业(机器平均作业数似乎很低,这个另外一个问题,容以后再表)。 不过一年下来,最牛X的事不是在公司领了多少奖,不是提升了多少性能,不是有多少业务已经使用了我们做的产品,而是我们依然在一起,辉煌将继续。谢谢你们!

团队

给测试同学的话

在两个产品开发团队中,相对较弱的环节是测试。所以一年来,对于成员的指导更多的是在测试方面。毕竟开发的leader都比较强,产品管理就只有我自己。总体而言在唯品会的测试的理论体系还是比较薄弱的,如何能更好的发挥到测试角色的作用而不是仅仅为开发的跟随者或助手,还需要更多的努力。如果能快速提高呢?下面是教给我们测试同学的话,希望对大家有所借鉴。其实不也不是单指测试同学了,对于经验比较少或工作时间比较短的开发同学也是适用的。这些都是我在老东家学习到,其实无论到哪里工作,这些都是通用的“Soft Skill”

测试同学的寒假作业

普遍而言,唯品会的测试的理论基础不足,重视的程度不够,所以过往积累更多是人肉的方式做测试。尽管已经开始做了很多自动化特别是新建立的团队,自动化层度都已经上来了。不过关键问题是测试到底要做什么,怎么做?理论知识还有待提高。所以我给测试的同学布置了些寒假作业,多读些书,推荐如下:

某些值得提的“简单”方法论

在这一年中,给测试提供些技巧或方法论的指引,这里简单总结一下:

  1. 测试点设计(Test Point Design):测试点不是随意根据产品想到那里写到哪里的。最通常看见测试容易犯的错误就是用个Execel表就开始写测试点了。实际上测试点是需要根据产品的需求/特性,开发提供的实现说明进行设计的。建议大家用xmind的方式来写测试设计。但是是否用了xmind就能写出好的设计呢?其实不是,这个工具只是个思维导图,帮助思考,但是不能替你思考。所以还需要做的事情是,如果设计完成后,将层次缩到3层,是否能讲清楚一个故事就显得比较关键。如果不能,则这个设计就需要商榷了。因为这样能避免测试常犯的一个错误就是过于关注最后执行点的细节,而忽略需要测试的要点是什么。如果更多的关注细节,那是测试点的“实现”而非设计了。所以这里强调的是设计。

  2. ACC模型:这个在How.Google.Tests.Software里面有讲到,可以参考去用下。最大的好处是帮助测试从非功能的角度思考产品。

  3. Feature-Feature Mapping: 维护一个功能矩阵,当需要改动一个功能或增加一个功能的时候,用这个矩阵去帮助是否有遗漏的点。从团队的情况,对于开发遗漏的查找还是有很大帮助的。我也很多时候,以这个去思考产品的缺陷或需要改进的地方的。

开源历程

2016年做的最值的团队自豪的事情是我们将我们做的弹性任务调度系统Saturn(https://github.coom/vipshop/Saturn)开源了。并且是唯品会成立8年来,第一个开源产品。这里不得不提一下我们团队中的成员:架构师薛珂、开发黄国钦何小鹏杨镌颖以及测试郭小波李晓娟。正是他们的努力才有了Saturn的开源。

Saturn Team

为什么需要开源
官方说法
内心说法
开源是种煎熬的等待

从产品的开始之初我们就想了要开源,因为毕竟是以当当的EJ做为我们代码的code base, 我们只从社区获取而没有共享,从内心有些不好意思。但是我们又无任何开源的经验,同时公司又无任何流程支撑我们是否能做这个事,所以当我们觉得代码已经可以对外公开的时候,内部如何驱动却成了我们最大的障碍。所以一切又需要从零开始。当中得到了鲍大伦先生的很多支持与鼓励。

开源流程

  • 开源申请准备:在各位评委以及安全部门的配合下,我们顺利完成前期的准备工作

  • 开源评审:通过正式流程的评议,我们也顺利通过了评审。

  • 开源送审:最后通过的材料正式送达CTO做最后签发。这个还是比较煎熬的,我们比较着急,但是又不好意思去催。幸好这个事得到了CTO的大力支持,使我们的等待没有太久。

每个公司对于开源的态度和做法都不同,关键是去驱动公司的相关关键人的认同与协助。这个考验开源团队的智慧与情商。

太多的不足

原以为我们准备的已经足够充分了,但是当代码正式上到Github后,我们才发现,我们还有很多不足,还有很多工作需要做。至此依然没有达到江南白衣心目中的标准。不过我比较欣慰的是,我们已经在路上了,目标就只会更近不会更远了。不过开源中的一些经验还是需要分享一下的

产品管理一二三

过去的一年,在公司更多的精力都放在了产品管理上(虽然也弄些技术的事,搭建些开源的东西玩玩,不过主要是为了确保产品方向是否合适,以及继续看些技术类的书)。不过在唯品会更多人理解的产品管理就是结合业务需求,分析后交给开发团队就可以了。其实很多时候,同一件事不同的人会有不同的做法,效果也会不一样。我也不是说我的方式是最好,只是因为负责都是技术性的产品,所以特点不一样,同时因为架构与开发的背景,所以做产品的思路也是不同,而且或多或少也受工作经历中每家公司的影响。总结些个人的看法,供大家选择性参考

社区的参与

一年下来,还有一个最大的收获就是与开源社区建立了多种联系。现在互联网/IT行业已经变了,依然靠自己就能解决问题的时代已经过去了。除了自身的能力外,开需要更多的外部资源的协调和帮助。因为已经不可能做一个产品从第一行代码开始,都是通过开源的组件或系统作为基础了。

2017的展望

2016已经过去,虽然中间的变化比我之前经历的5-8年都要多,但是时代或许就是这样的变化。

2017我会重新开始,无论在哪里,驱动一件事最后落地,展示出它应有的价值,这才是我的目标!

感谢有你的陪伴,我的领导们,我的团队成员,我的社区朋友们!

春节快乐,期待下次的相遇!