您所在的位置:彩票投注app·新零售阵线 >> 新零售频道 >> 正文
亚马逊首次公开:驱动万亿市值巨轮的创新公式

  在中国,你无法逃脱微信、支付宝的数字帝国;在美国,你无法逃避的就是亚马逊的彩票投注app帝国了。

  作为一家万亿美元巨头,亚马逊以惊人的速度颠覆了从零售到软件开发的诸多领域。同时,随着亚马逊的规模不断放大,它的创新速度也在不断加快,看来大象真的可以跳舞?

  这一切是怎么做到的?

  2019年7月份,在MIT平台战略峰会(MIT Platform Strategy Summit)上,亚马逊云服务(AWS)的物联网总裁Dirk Didascalou阐述了亚马逊大规模创新的成功密码,本文的图片也主要来自大会中展示的幻灯片。

  从高层次看,亚马逊有三大文化准则:

  1. 关注消费者而非竞争对手

  2. 愿意承担失败的建设者和先驱者

  3. 着眼于长期而非短期

  当然,几乎所有公司都会有上述说法,不过比起亚马逊,它们真的就是说说而已。

  不过,价值观好说,如何实施、落地这些价值观呢?Dirk提出一个四因素的成功公式来让一切落地,这四大因素包括:

  1. 架构(Architecture)

  创造一个支持快速成长和变革的结构

  2. 组织(Organization)

  让小而有能力的团队拥有他们所创造的东西

  3. 机制(Mechanisms)

  将行为编码进我们促进创新思维的DNA中

  4. 文化(Culture)

  雇佣建设者,让他们建设,用信念系统支持他们

  针对这四大因素,亚马逊提出了自己的创新公式:

  

  架构——支持快速增长与变革的结构

  在亚马逊整个架构层面,最为知名——很多人也认为是最为“臭名昭著”——的是贝索斯的“API授权”,他要求整个软件团队在搭建应用程序的时候,必须向其他团队通过API公开数据和功能。

  当年,贝索斯的原话是,“任何不这样做的人都会被开除。谢谢。祝你今天愉快!”

  并非所有的API最终都对外界开放,虽然按照设计,应该这么做。不过,这一切也正是亚马逊云服务的起源。

  这种公司级“微服务(Microservice)”架构的好处在于,每个团队都可以快速开发自己的部分,而不用考虑其他团队——他们可以用自己的数据库、自己的技术库、自己的内部设计——只不过,最后必须通过API让其他团队也可以在不了解他们内部原理的情况下调用这些服务。

  然后,团队间可以快速、灵活地通过API调用其他人的服务、数据,而不必在跨团队协作会议中互相撕逼。这些API实现了快速、灵活、可复用且松散耦合的特点——这时,团队就可以在内部继续迭代、进化,只要保证API正常对外工作就可以了。

  此外,Dirk还提出另一个架构观点,那就是“两个总比零个好”。

  也就是说,由于是在高度分布的团队中进行工作,很可能会出现,两个团队在无意中搞出了一样的或者高度近似的东西。

  这是没问题的。

  因为让几个快速工作的团队做了相同的工作,总比让他们花费数天、数周甚至数月撕逼,最终得出一个通用解决方案要有价值得多。虽然最终出了点冗余的东西,但是总归避开了无价值的会议撕逼。

  最后,如果有必要的话,几个项目可以合并,或者随着时间的推移,一个项目战胜/替代了另一个项目。

  不过,考虑到两个团队同时取得成功的概率实在比较低——毕竟亚马逊鼓励快速、大胆实验,而大部分实验最终以失败告终(还记得Fire Phone么)——其实出现内部团队间的赛马,看看哪个真正能跑出来,也是没问题的。

  

  组织——小型、赋能的团队

  两个披萨团队——即two-pizzar team——算是你听说过的亚马逊名词了:团队人数不应该很大,大约2个披萨就可以让每个人吃饱,也就是说,每个团队大约6-8人。

  当然,这也取决于披萨到底有多大,有时候可能2-4人构成的团队也是没问题的。

  为什么要让团队足够小,理由如下:

  1. 小团队中,实现彼此坦诚、充分、开放的交流比较容易,随着人数的增加,人与人之间的联系数量就会快速增加——网络效应听说过吧,在小团队中,内部网络效应过大未必是好事。

  2. 团队人数较少本身就会限制他们承担的项目的大小——这是好事,因为直接推出一个宏大的项目本身就是风险重重的,很容易直接就失控掉。而小团队更容易采用迭代、叠加的方式快速开发,本质上来说,他们可以针对变化、反馈而快速调整,实现敏捷开发。

  3. 小团队会以自己拥有这个项目而自豪,这个过程中形成了创业心态,甚至可以避免浑水摸鱼的“搭便车”情况。

  4. 小团队更加扁平,没有过多等级制度。小团队的领导可以清楚地了解团队中发生的每一件事,并可以为成员提供实际的帮助和支持。

  5. 小团队可以快速做出决策。

  亚马逊坚持每个小团队必须为他们建立的东西承担责任:他们不可以随手建个什么东西,然后就丢给外界。无论是好是坏,团队都“拥有(own)”在设计和实现中所做出的一切决策,并且为结果负责。

2页 [1] [2] 下一页 

关注公号:redshcom  关注更多: 亚马逊