转载

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

最难以落笔的文章

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

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

感恩

千里马常有，伯乐不常有！

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

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

千里马

体系与布局

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

高层推动：高层与高层间的互动很重要，中国这样的文化体系下（外企另谈），这个如果是高层间的协议／妥协，则事情将会有个很好的契机。
样板工程：就像“Show me the code”一样，需要说服大家使用，必须要有样板示例，以真实数据说话。但是谁愿意成为你第一个小白鼠呢？这里考验是大家工作中人与人交互间的点点滴滴了。抓住对方的核心需求点，提供足够的支撑，并通过相互间建立的信任来达成这个目标。不然你总会遇到这个困境“是否已经有别的业务团队用过了？”
明星效应：这个是人员布局。当你的团队有技术“大神”的时候，很多时候事情也会相对容易推进，这个通常是我和团队成员说的“Technical Leadship”。因为大家都会对“大神”有一种莫名的依赖。因为如果“大神”都解决不了，这个问题就不是我的问题了。正是因为这种“有人背锅”的心里，大家会对“大神”有足够的信任度。那么事情也就好办了。如果没有“大神”怎么办？那么团队的leader就需要去培养一个“大神”，这个“大神”可以是自己，也可以是别人。幸运的是，我们团队中有还几个“神”一样存在的人，因为他们都是最晚吃饭的。
打广告：这个意思就是需要潜意思去“Sell”自己的产品，特别是当遇到方案讨论的时候，需要深度思考与自己产品的关联性，是否能有切入点。另外就是多多分享，无论内外。互联网公司都会有自己的“大学”／“学院”类的组织，通过她们来组织定期的技术分享，将产品“卖”出去。另外也可以参加对外的技术沙龙演讲，则可以反向影响公司的技术导向。对外分享还有个好处是，组织者会去帮你打广告，比你在内部自己打广告有力的多，因为总有“外来的和尚会念经”的思维，产品用的人自然就多了。
数字化：如果已经有几个成功的样板工程了，那么将其通过某种手段（如Dashboard）的方式展示出来，让更多的团队看到，自然使用的信心就增强不少，那么后续就会有更多的团队会去使用，而不是在问有没有用过的问题，他们就会自主的去接入和使用了，那么产品后续的推广就轻松很多了。如我们内部的Saturn的dashboard的使用统计，这样别的团队看见就不会有过多的质疑了：

Saturn Dashboard

团队

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

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

团队

给测试同学的话

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

Technical Leadship: 技术领导力。无论是开发和测试，都需要在自己的领域有主够的专研度。（其实产品管理也是一样道理）只有深度够了，发现问题将会更加能着力于核心点上，才能找到连开发都遗漏的问题，而不是只是局限于开发的引导。当你能做到让开发足够的信服，则测试的技术领导力就建立起来了。只要是你测过的，大家都认为是最好的保证。或者说开发最怕你做他产品／模块的测试。同时测试同学如果能指导开发如何做到更高效、更简便的测试，或提供能解决问题的某种测试工具的话，则这个技术领导力就建立起来了。
Driving: 驱动力。在一个公司，一个小组工作，基本都不可能自行完成一个事情了。都需要靠团队的配合。但是不是每个事情都靠团队的leader来牵头的，因为不同的领域大家或多或少都有某些方面的局限性。所以每个测试同学也需要懂得如何去驱动事情的顺利进行。特别是跨团队跨产品联合测试的时候，这个就需要测试的同学来主导了。但是如何主导呢？特别是对于没有经验的同学。1）事情的条理性：理清楚事情的背景、原因、关系人；理清方案细节约束；理清计划与执行人；理清所有的风险点等等。2）借力打力：不是每个事情的每个点都是自己能完全控制，如果涉及的人多，再简单的事情都将变得不那么简单。所以需要找到每个人背后能协助你的因素。3）追踪过程：不要期待每个人都能在最后给你期待的结果。需要掌控中间的过程，结果是自然的。如果还是不知道如何做，那么就从组织一个小范围的知识分享做起，如何找到分享人，如何组织会议等等。
Influence: 影响力. 如果能做到上面的两点，影响力自然而然的增加的。同时需要在一定范围内建立自己的品牌，让别人想到某个事情的时候就能想到你。如我要调优一下jvm就能想到你，我要快速验证程序就能想到你等等。这里不是鼓励大家去吹嘘自己，只有靠过硬的功底才能逐步建立起个人的品牌的。同时也要多参与内外的交流与分享，信息爆炸的时代，选择多，垃圾信息多，能记住的没多少，所以需要在某些场合做意识强化。

测试同学的寒假作业

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

《How.Google.Tests.Software》: 了解与Google的差距，以及日常的测试思维方式调整，借鉴其中的方法论。
《Site Reliability Engineering》: 这本书可以帮助具体理解系统／集群，毕竟很多测试点都是息息相关。
《Testing.in.Scala》: 这本书不用纠结它是Scala，里面有很多的方法方式是值得借鉴。而是也是适合Java的开发者的。更多的从DSL的角度关注如何让Code as Test Report。

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

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

测试点设计(Test Point Design)：测试点不是随意根据产品想到那里写到哪里的。最通常看见测试容易犯的错误就是用个Execel表就开始写测试点了。实际上测试点是需要根据产品的需求／特性，开发提供的实现说明进行设计的。建议大家用xmind的方式来写测试设计。但是是否用了xmind就能写出好的设计呢？其实不是，这个工具只是个思维导图，帮助思考，但是不能替你思考。所以还需要做的事情是，如果设计完成后，将层次缩到3层，是否能讲清楚一个故事就显得比较关键。如果不能，则这个设计就需要商榷了。因为这样能避免测试常犯的一个错误就是过于关注最后执行点的细节，而忽略需要测试的要点是什么。如果更多的关注细节，那是测试点的“实现”而非设计了。所以这里强调的是设计。
ACC模型：这个在How.Google.Tests.Software里面有讲到，可以参考去用下。最大的好处是帮助测试从非功能的角度思考产品。
Feature-Feature Mapping: 维护一个功能矩阵，当需要改动一个功能或增加一个功能的时候，用这个矩阵去帮助是否有遗漏的点。从团队的情况，对于开发遗漏的查找还是有很大帮助的。我也很多时候，以这个去思考产品的缺陷或需要改进的地方的。

开源历程

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

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

Saturn Team

为什么需要开源

官方说法

通过开源，建立VIP在业界的技术知名度，从不同的维度拓展公司的品牌影响力
在贡献优秀的技术产品或技术框架的同时，也能节约维护的工作量
通过开源，吸引更多的优秀人才的加入

内心说法

从技术角度，希望开源后大家对代码的写法的规范性，可读性上一个台阶，促进大家对于代码的精益求精，毕竟还关乎面子
增强产品的文档。内部系统文档，大家花在产品文档的时间是少之又少的，通过与外部的互动，使这个团队意识到对于文档的重要性
提供一个平台给大家一个展示自我的机会

开源是种煎熬的等待

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

开源委员会建立：我们有幸得到公司“学院”的鼓励师的大力支持，能够组织起公司的各位热衷于开源的技术大牛，成立了第一届开源委员会，并制定的相应的开源流程。为了这个我们也是花费了一个多月的时间。

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

开源流程

开源申请准备：在各位评委以及安全部门的配合下，我们顺利完成前期的准备工作
开源评审：通过正式流程的评议，我们也顺利通过了评审。
开源送审：最后通过的材料正式送达CTO做最后签发。这个还是比较煎熬的，我们比较着急，但是又不好意思去催。幸好这个事得到了CTO的大力支持，使我们的等待没有太久。

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

太多的不足

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

一定要你的开源产品能“一键启动”，以最简单的方式安装和运行一个例子。在一个追求用户体验极致的时代，如果期望用户一开始就能接受和评估你的开源产品，做到简便快速上手尤为重要。
补充完整各类文档。“最讨厌没有文档的产品，以及最烦写文档”已经流行多年。所以描述清晰自己的产品也是别人愿意使用的关键一环。
维护好社区的交流。微信已经改变大家的生活与工作。开源交互也是如此。已经很少人再用邮件列表了。所以在开源之初就维护好一个用户群也是必备的功课。如果想拓展到国外，则可以考虑Slack。目前shopee.sg的黄浩松同学做了个Wechat<->Slack的同步机器人，值的称赞！
外部宣传。准备好对外的介绍性的材料多多向社区宣传。酒香也怕巷子深。
重点扶持。前期重点照顾有意愿的公司，协助他们真正用到生产中去，成为你的样例标杆。成功的例子才是最好的说服力。

产品管理一二三

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

明确好各个角色间的职责。不同的开发模式，设定的职责范围或许不同，这个需要团队的磨合。就像我们走SCRUM模式（不想称之为流程，因为个人认为流程是个僵化的东西），角色重要的核心是PO(Product Owner)与Architect。就像部队中的政委与司令。不过很难说清PO与Architech谁是司令谁是政委。不过从技术角度看，这个比较容易区分：PO负责做什么，Architect负责怎么做。至于比较传统的Project Manager+Technical Leader的方式，我就不多说了。
清晰的迭代目标：每个迭代的版本，我都会强迫自己用一句话来概括这个迭代需要达成的目标是什么。然后再根据backlog去选定核心的feature以及可以灵活调配的feature。毕竟一个团队开发中的时间掌控是需要一定的灵活度的。
端到端的功能：对于feature的选择，一定要确保最后能够端到端的上线
粘合剂：产品开发中，一定要关注各种阻碍产品推进的因素。无论是技术难点还是人员情况。一定要深入在团队中，了解潜在的问题，提供协助，控制风险。也就说，特别在团队忙的时候，哪里需要你，你就要出现在哪里。在需求分析完成后，或许如果释放团队的战斗力也是需要去考虑的问题。
“大神”也是一种风险：最担心的地方就是“大神”有足够的影响，当他的思维开始发散而没有匹配到每个版本的最终目标的时候，这就是风险。但是很多团队成员又没有主够的说服力和控制力，这个时候产品方向就会偏离，团队成员的工作就会混乱了。所以产品也需要去协调好这些“大神”的工作内容与导向。