转载

做服务而不仅仅是开发软件

今天读到一篇博客,标题为 DevOps – Not Good Enough ,作者 MARTY ABBOTT 的观点大致为,DevOps 把开发、QA、运维等环节打通,解决或缓解了传统 IT 所遇到的很多问题,然而这还不够,我们需要认清最根本的两个问题。第一个问题是:传统企业的 IT 基础设施和架构是为了支持各种各样的第三方软件,其目的是节省成本而不是创新;第二个问题是:传统的软件开发和维护是分离的,开发软件更多的关注是把它卖了,而不太关心软件最终如何运行。

然而,今天行业发生了巨大的变化:

现在,客户购买服务而不是软件。要在这个全新的世界获得成功,就需要改变观点,即组成这些服务的原材料不仅包括软件,也包括硬件(基础设施)。如果你的团队没有合理地组合这些原材料,那么最终服务也不会如预期的那么好。如果继续“生产”软件,然后“托管”在基础设施上,那么最好的结果也仅仅是次优的解决方案,最差的结果则可能是一场灾难。

MARTY 又接着说,我们应该:

把团队组织成跨职能的、实用且多样的、自治的团队,各个团队拥有整个产品中独立的一些服务。各个团队和服务应该由集中面向业务的 KPI 驱动。这些团队应该能够独立自主地开发、部署、支持自己的服务,不需要依赖其他团队。

我们都知道,如果一件工作需要跨团队合作,工作效率会急剧下降,各种推责扯皮的事情就会冒出来,管理成本直线上升,需要富有经验的项目经理协调,需要指定共同的目标,需要开很多很多的会…… 在这种背景下,快速地应对市场变化、开发创新的产品就难免变得困难重重。为什么现在很多很小的互联网公司能那么快速地发展起来,我想一个很大的原因就是因为他们够快, 够“敏捷”,现在很多基础设施如代码托管、服务托管、应用程序监控都有了比较成熟的市场及服务(至少在国外),它们中有我们耳熟能详的 Github、Amazon EC2、New Relic 等等,在这些基础设施足够灵活、足够稳定的情况下,小型互联网公司能够专注自己产品和服务,技术人才也比较容易“跨职能”,设想在传统的大的 IT 公司内,一名开发人员要了解运维体系几乎是不太可能的事情,但现在如果是用 Amazon EC2,则只要学习一些简单的 API 即可,而且相关工具也更加简单。

市场上成熟的 IAAS/PAAS 帮开发人员简化了很多问题,也使得程序员关注 OPS 的门槛降低了。除此之外,敏捷运动在帮助开发团队跨职能方面也功不可没,尤其是,敏捷强调开发和测试角色的融合,事实上,现在优秀的开发人员都具备比较强的测试意识和测试技能,而像 Google 那样的公司,专职测试的研发能力较普通开发来说有过之而无不及(见 Google软件测试之道 )。也正因为如此,如果一个团队的成员都比较优秀,再加上有比较出色的产品经理,那么拥有一支靠谱的跨职能团队也不是那么遥不可及的事情,他们能够每天直面用户,以小时为单位做出响应,因此在市场中有巨大的竞争优势。

对于一名普普通通的程序员(像我这样),应该如何面对这样的行业趋势?如何才能保持自己的竞争优势,不至于在40岁的时候被裁员、被淘汰?

首先是观念的转变,“程序员”或者“软件工程师”这样的头衔也许已经过时了,实际上我们应该是做服务的,这一点和开餐厅、开发廊没有本质的区别。唯有做到吸引更多的客户、让客户满意,才能保证组织的生存和壮大,也进而是我们自己的发展和壮大。怎样做才能吸引客户?才能让客户满意呢?那你得理解他,例如通过运维数据去理解;你得保证服务的质量,要保证可用性,保证功能正确;你得有创新,让客户眼前一亮。因此,你不仅要和机器打交道,你还要学会通过各种方法和客户打交道。

其二,在观念转变的基础上,有针对地拓展自己的技能。为什么要学习自动化测试?因为它能帮助我们提升软件质量,让客户满意;为什么要学习 DevOps 方法论和相关工具?因为它能让我们更快发布软件响应客户的需要;为什么要关注性能?因为客户是人,人的耐性是有限度的;为什么要关注可用性?因为客户是人,一般人如果遇到 Starbucks人满为患,它会去对面的 Costa 买拿铁的。

我无法想像20年后程序员后会用什么语言怎样开发软件,正如20年前也很少有人能想到今天移动互联网的如火如荼,也许届时程序员这个职业也会渐渐消失,但不论如何,我相信通过技术服务人的人性需求,这样的一个基本事实是不大可能发生变化的。

正文到此结束
Loading...