从不加班、吃喝管够:从工作环境中感受给工程师的善意
在硅谷这样的人才争夺大赛中,各家公司为了留下好的技术大牛都使出了浑身解数。Pivotal也不例外,不仅要留住技术牛,实验室的整个环境都舒适且鼓励创新,让硅谷考察团的各位频频称赞。
Pivotal Lab到处可见零食和饮品,负责人称,希望工程师们可以不要为了吃饭这样的小事情困扰。
随处可见的零食和冰柜
到访当日正值Pivotal Lab一场欢送离职员工的小酒会,周五下午,程序员们各执香槟杯畅谈。
香槟下午茶阵势
理工男热爱的键盘、耳机、象棋等一系列奇妙的物品在这里都能够找到;他们执着、热爱流程化的一般特点在这里也被无限放大。
挂满耳机的架子
便利贴画出的工作流程图处处可见
在工作区安插的象棋盘
“我们的工程师从不加班。”Pivotal Lab的副总监Terry不无自豪的说到,这也是Pivotal所称的尊重工程师在企业文化上的体现。
看惯了国内BAT无数加班成便饭的程序员,按时下班似乎是一个不努力程序员的代表。对于中国与硅谷程序员在工作节奏上的差异,Terry称“工作是干不完的,如果长期处于加班状态,程序员长期比如2-3年肯定坚持不下去会跳槽。而国内对于程序员加班是因为努力程度不够的说法也是我们想转变的观念之一”。
Pivotal的数字化变革案例:把花旗银行改造成一家“做金融的技术公司”
Pivotal也正通过自己的产品,潜移默化地创建一种新的工程师文化。首先,Pivotal提供的从云端部署到一整套的大数据解决方案,从开发到平台,全世界除他们,没有谁能将大数据与PaaS平台合二为一。
其次,Pivotal推崇的数字化转型不仅有技术,而且,从文化、流程、方法论、软件开发的方式、数据部署的方式、规划蓝图等等,都有一套转型的模式,且很好的得到了客户的肯定和验证。
Pivotal Lab的市场产品总监(associate director)Grag用花旗银行的例子,来证明Pivotal不仅提供平台,更通过协助客户,为其带来在软件开发和观念上的整体变化。
在花旗银行的最终结项报告中提出了几个重要的变化数据:在软件交互方面效益提升了57%,这意味着软件工程师交付出的功能比原来的3倍,这让他们在软件发布方面降低了运营成本,也可以更快速的为客户做创新。
花旗银行的转型有以下几层:首先在人员上,在Pivotal Lab的工作当中,很大一部分是协助客户企业当中的人员如何更好的工作,而且通过“敏捷开发”这个新的方法论学到一种新的方式,再进行敏捷开发的平台。
(注:“敏捷开发”是一种以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。从下图可以看到这是一个非常简单地概念,很多的软件开发团队大概从事了20年之久,但是Pivotal做这件事最不同的一点就是,让IT和运营组进团队之中,也就是开发运营计划。通过这种方式可以让运营的效率也大幅提升。)
其次,在发布和工作方式上,过去很多公司是使用比较大的软件,并且由一个比较大的团队负责分布式开发。而现在不再是一个大的软件或者一个大的团队,而是由多个小团队负责多个不同的小服务,同时,每个团队都有自己的发布周期,而且彼此间的相关性不是很强,也就是每一个都是一项微服务,每个团队都代表了一个微服务。
花旗银行在接受Pivotal的反馈会上给出了一句评价非常高的化:“我们现在已经不再是一个银行了,而是一个硅谷公司,是一个技术性的组织,这个技术性的组织只是刚好也做银行方面的服务罢了。现在我们的思维模式更趋向我们的客户而不是银行家(We are a technology organization that does banking-who thinks like ourcustomers, not bankers.)
以用户需求驱动:产品管理和用户体验工程师先于工程师介入
在一个项目的开发流程中,“让工程师被尊重的文化”从一开始的流程中就得到了体现。
Pivotal工程师团队
“从流程上,我们会倾向于让工程师晚于产品管理和用户体验工程师介入项目。”PivotalLab的产品管理Karen如此介绍,对于一个新的项目,产品管理和用户体验工程师会先从产品层面与用户沟通好,确认待办事项,之后再让开发工程师介入。这就让工程师逃离了很多冗杂的非技术工作,也减少了沟通的麻烦。
因此Pivotal的团队一般比较小,Karen称其为“2 pizzateam”,两张披萨就能管够的精炼团队。
过去vs现在:让工程师越来越值钱
在硅谷,从DEVOPS到docker,似乎每隔一段时间就会有一个新的技术名词。简单来说,Pivotal把技术趋势归结为四大块:
首先是开发运营一体化:也就是现在把运营和软件开发做在一块;第二个是持续交付,简单来讲就是,软件工程师他所做的每个承诺,都可以立即进行部署;第三个就是微服务,也就是现在不是大的软件为单位,而是以小的软件为单位,而且每一个微服务都是做自己的发布,彼此之间依赖性比较低。第四个是容器。
这些趋势下,过去和现在的发展模式产生了一些差异:
过去我们假定必须要有一个可以依靠的可以信赖的基础设施。但现在我们假设云基础设施是脆弱的。
过去,如果你速度够快的话,每三个月会发布一次;但是现在代码的发布是早期发布,经常发布,而且是持续发布。
在过去,开发人员常说:这些源码在我的环境里面完全没问题,为什么在别的环境里面不奏效?现在IT的运维人员和软件开发人员,是在同一个环境里面,同一个团队当中,所以他们就知道了彼此的责任何在。
最后过去我们用的是比较大的软件,彼此间的相关性比较高,现在是比较小的软件,而且彼此间的相关性比较低。其中最大的秘密就是,IT人员和运营人员是在一起工作的,因此才可以这么快速的做发布。
在过去,发布是一件了不起的大事,风险高,并且每个人都必须准备就绪,这也意味着尽管你的QA人员特别多,但是还有很多的bug是没有办法被及时发现的。现在通过微应用部署时,相关很多独立单位组成起来的。通过非常简单的应用服务器,也能拥有非常丰富的功能。
“前三十年和后三十年,我们站在一个时间的节点上,最大的变化就是改变了传统的工程师的开发的方式。这就是我们一直推行的工程师文化,我们要让工程师得到尊重,他自己觉得他自己的产出得到一种尊重,这是最核心的变化。”Terry称,“我们最重要的另一家股东是通用电气,他们提到每一家公司一夜之间会变成一家软件公司,我们的IT人员会越来越重要,因为我们能在瞬间就把客户的需求交付出去。所以工程师文化的核心是什么呢?核心是工程师越来越值钱。”