不要做一只固执的鸵鸟。
6月初,微软市值突破1万亿美元大关,再创历史新高,是近4年来的最好表现。这使得微软一举超过亚马逊和苹果,成为目前美国市值最高的公司。
这一结果,不禁让人追想起五年前,微软第二任CEO史蒂芬·鲍尔默离任时的微软情景。当时微软市值只有2000多亿美元,移动互联网兴起,导致微软赖以为生的PC市场不断下滑。
为了在移动互联网时代继续保持霸主地位,微软收购了诺基亚手机事业部,并开发了Windows Phone操作系统。但是由于对移动互联网的反应太慢,且意识依旧停留在工业时代,导致无法与安卓和苹果阵营竞争,在移动互联网市场可说是一败涂地。一时间,唱衰微软之声四起。
市场表现只是企业内部管理的一种表达而已。当时微软的内部管理,也可以说是病入膏肓。
两位创始人——比尔·盖茨和保罗·艾伦——在70年代创业初期的那种创新精神已经很少看到。作为巨无霸的微软同很多大企业一样,官僚主义、封地文化盛行,部门之间竞争激烈。
管理人员以维护自己的正确性为重中之重,没有多少人关注公司的整体状况。至于客户需求,人人都知道,但是却没有人当真。
企业的发展往往如此。最初,常常是创始团队领先同时代的人,看到了一个未来的趋势或是一个存在很久的痛点,从而开启了一个商业模式。在初期,大家都紧密围绕客户问题打转,企业层级简单,管理者与客户是“零距离”接触。公司理念也很纯粹,那就是全力满足客户需求,以期在巨头霸占的市场中活下去。
或运气使然,或是创始人和管理团队用对了方法、抓住了机会,一些企业会日渐壮大。它们的客户逐渐变多,业务也不断增长,附带的,人员不断增多,组织结构日趋复杂。
到企业逐渐成为一个行业的领头羊,甚至是处于近乎垄断地位时,极少有企业会坚守初心,始终叩问自己是不是还在以客户为中心,是否脱离了市场,脱离了客户需求。
大多数企业都会被昔日的成功所绑架,将工具或手段变成目的,在一个传统产品上死磕到底,或者在自以为是的方向上盲目前行,逐渐在客户市场“失聪”。
多年前的微软,无疑就陷入了这样的自我蒙蔽当中。员工们于内唯唯诺诺,害怕犯错,没有创新精神。对外态度傲慢,以大企业姿态示人,不仅对待合作伙伴如此,对待顾客也是这样。
当时,不仅外界不看好微软,其内部的普通员工也对公司制度和前景充满了失望。鲍尔默宣布退休时,很多人都希望能够从外部引入CEO,他们认为公司内部的人都被*所塑造,没有改变的意识和能力。
最终,董事会作出的决定并未如大多数员工所愿,一位在微软工作了22年的老兵成为了新任CEO,他叫萨提亚·纳德拉。
微软CEO萨提亚·纳德拉
并不像很多人以为的那样,萨提亚并没有被*同化,相反,22年的工作历程,使得他对微软的症结所在一清二楚。
当时的微软有种种问题,但最为关键、最为致命的问题,就是忘记了为客户创造价值的初心。萨提亚上任后的第一件事,就是重提微软初创阶段的使命,并对其进行新的诠释——赋能组织和个人。呼吁以客户为中心,坚持一个微软,从销售端走向客户端。
萨提亚上任后,首先对微软的文化进行了“刷新”,在以客户为中心的基础上,开始重塑业务方向和内部流程,从而开展对微软整体地“刷新”,终于,让一株濒临朽烂的老树发新芽,开鲜花,结硕果。
不论企业开发了什么产品或服务,不论企业采用怎样的竞争策略和运营模式。当一个企业从小公司一步步成长为巨无霸后,再去转身回溯自己走过的道路时,会发现有一点是共通的,那就是企业的产品或服务以及过程中的种种努力,都或有意或无意暗合了一大群人的需求与痛点。公司得以成长和壮大的根本,在于为自己的顾客创造了便利与价值。
但是,成就很容易冲昏一些人的头脑,让他们变得高傲自大,不认为是顾客和时代成就了自己,反而觉得是自己成就了顾客,开辟了时代。将自己封为高高在上的时代缔造者,认为顾客应该对自己感恩戴德。
很多有所成就的企业,会出现典型的恐龙特征。利用市场惯性获利,逐渐失去对客户需求和市场真相的耐心与热情,只顾着自己正在萎缩的核心业务,眼光狭窄,对视野之外的威胁和机遇视而不见。
一方面过度依赖广告宣传来获得更多的认可度,不去好好倾听消费者到底喜欢什么、不喜欢什么。
另一方面,面对日益下降的市场份额和市值,它们也许会提出变革,但是又没有足够的决断力以及耐心和韧性,醉心于短期利润。因为真正的变革势必会遭遇巨大的阻力、困难,还有失败的风险,包括最高管理者在内,没有人愿意承担这些。它们也许会抄袭一些比较成功公司的做法,但是往往只能看到皮毛而没法把握核心要点。
有恐龙特征的企业大都重资本胜于顾客需求,认为资本能够解决一切问题。它们通过并购制造公司成长的幻象,通过削减成本来制造利润增加的错觉。但这种短期的刺激手段毕竟有限,企业早晚会遭遇真实的危机和衰落。
每当此时,这些恐龙则摇身一变成为鸵鸟,不愿意承认自己的错误,拼命维护管理者的正确性,将一切的失败归因于外在环境和不可抗力。容不得批评,也听不进意见。
但市场法则并不以某些“天才”的意志为转移,无数企业的兴衰沉浮都在不断证明一个道理:今天你对顾客爱搭不理,明天顾客就会弃你如敝履。
微软的崛起让我们看到,对于任何昔日的霸主而言,衰落并不是不可避免的,那些成功但是又面对威胁的公司,完全能够通过克服自满心理,适应新的市场变化,从而在竞争中再次获胜。
重回巅峰的前提是,企业管理者要能够放下自己的傲慢与偏见,开启自我革新的勇气,抛弃对短期利润的追求,重回为客户创造价值的路径。而不应该像一只傲娇的鸵鸟,把头颅埋在自我感觉很舒适的沙地中,对外界的声音充耳不闻,在偏执的道路上,我行我素。
推荐阅读
-
不要做一只固执的鸵鸟。
-
纯干货分享 | 研发效能提升——敏捷需求篇-而敏捷需求是提升效能的方式中不可或缺的模块之一。 云智慧的敏捷教练——Iris Xu近期在公司做了一场分享,主题为「敏捷需求挖掘和组织方法,交付更高业务价值的产品」。Iris具有丰富的团队敏捷转型实施经验,完成了企业多个团队从传统模式到敏捷转型的落地和实施,积淀了很多的经验。 这次分享主要包含以下2个部分: 第一部分是用户影响地图 第二部分是事件驱动的业务分析Event driven business analysis(以下简称EDBA) 用户影响地图,是一种从业务目标到产品需求映射的需求挖掘和组织的方法。 在软件开发过程中可能会遇到一些问题,比如大家使用不同的业务语言、技术语言,造成角色间的沟通阻碍,还会导致一些问题,比如需求误解、需求传递错误等;这会直接导致产品的功能需求和要实现的业务目标不是映射关系。 但在交付期间,研发人员必须要将这些需求实现交付,他们实则并不清楚这些功能需求产生的原因是什么、要解决客户的哪些痛点。研发人员往往只是拿到了解决方案,需要把它实现,但没有和业务侧一起去思考解决方案是否正确,能否真正的帮助客户解决问题。而用户影响地图通常是能够连接业务目标和产品功能的一种手段。 我们在每次迭代里加入的假设,也就是功能需求。首先把它先实现,再逐步去验证我们每一个小目标是否已经实现,再看下一个目标要是什么。那影响地图就是在这个过程中帮我们不断地去梳理目标和功能之间的关系。 我们在软件开发中可能存在的一些问题 针对这些问题,我们如何避免?先简单介绍做敏捷转型的常规思路: 先做团队级的敏捷,首先把产品、开发、测试人员,还有一些更后端的人员比如交互运维的同学放在一起,组成一个特训团队做交付。这个团队要包含交付过程中所涉及的所有角色。 接着业务敏捷要打通整个业务环节和研发侧的一个交付。上图中可以看到在敏捷中需求是分层管理的,第一层是业务需求,在这个层级是以用户目标和业务目标作为输入进行规划,同时需要去考虑客户的诉求。业务人员通过获取到的业务需求,进一步的和团队一起将其分解为产品需求。所以业务需求其实是我们真正去发布和运营的单元,它可以被独立发布到我们的生产环境上。我们的产品需求其实就是产品的具体功能,它是我们集成和测试的对象,也就是我们最终去部署到系统上的一个基本单元。产品需求再到了我们的开发团队,映射到迭代计划会上要把它分解为相应的技术任务,包括我们平时所说的比如一些前端的开发、后端的开发、测试都是相应的技术任务。所以业务敏捷要达到的目标是需要去持续顺畅高质量的交付业务价值。 将这几个点串起来,形成金字塔结构。最上层我们会把业务目标放在整个金字塔的塔尖。这个业务目标是通过用户的目标以及北极星指标确立的。确认业务目标后再去梳理相应的业务流程,最后生产。另外产品需求包含了操作流程和业务规则,具需求交付时间、工程时间以及我们的一些质量标准的要求。 谈到用户影响的地图,在敏捷江湖上其实有一个传说,大家都有一个说法叫做敏捷需求的“任督二脉”。用户影响地图其实就是任脉,在黑客马拉松上用过的用户故事地图其实叫督脉。所以说用户影响地图是在用户故事地图之前,先帮我们去梳理出我们要做哪些东西。当我们真正识别出我们要实现的业务活动之后,用户故事地图才去梳理我们整个的业务工作流,以及每个工作流节点下所要包含的具体功能和用户故事。所以说用户影响地图需要解决的问题,我们包括以下这些: 首先是范围蔓延,我们在整张地图上,功能和对应的业务目标是要去有一个映射的。这就避免了一些在我们比如有很多干系人参与的会议上,那大家都有不同想法些立场,会提出很多需求(正确以及错误的需求)。这个时候我们会依据目标去看这些需求是否真的是会影响我们的目标。 这里提到的错误需求,比如是利益相关的人提出的、客户认为产品应该有的、某个产品经理需求分析师认为可以有的....但是这些功能在用户影响地图中匹配不到对应目标的话,就需要降低优先级或弃掉。另外,通常我们去制定解决方案的时候,会考虑较完美的实现,导致解决方案括很多的功能。这个时候关键目标至关重要,会帮助我们梳理筛选、确定优先级。 看一下用户影响到地图概貌 总共分为一个三层的结构: 第一层why,你的业务目标哪个是最重要的,为什么?涉及到的角色有哪些? 第二层how ,怎样产生影响?影响用户角色什么样的行为? (不需要去列出所有的影响,基于业务目标) 第三层what,最关键的是在梳理需求时不需一次把所有细节想全,这通常团队中经常遇到的问题。 我们用这个例子来看一下 这是一个客服中心的影响地图,业务目标是 3个月内不增加客服人数的前提下能支持1.5倍的用户数。此业务目标设定是符合 smart 原则的,specific非常的具体,miserable 是可以衡量的,action reoriented是面向活动的, real list 也是很实际的。 量化的目标会指引我们接下来的行动,梳理一个业务目标,尽量去量化,比如 :我们通过打造一条什么样的流水线,能够提高整个部署的效率,时间是原来的 1/2 。这样才是一个能量化的有意义的目标。 回到这幅图, how 层级识别出来的内容,客服角色:想要对它施加的影响,把客户引导到论坛上,帮助客户更容易的跟踪问题,更快速的去定位问题。初级用户:方论坛上找到问题。高级用户:在论坛上回答问题。通过我们这些用户角色,进行活动,完成在不增加客户客服人数的前提下支持更多的用户数量。 最后一个层级,才是我们日常接触比较多的真正的功能的特性和需求,比如引导到客户到论坛上,其实这个产品就需要有一个常见问题的论坛的链接。这个层次需要我们团队进一步地在交付,在每个迭代之前做进一步的梳理,细化成相应的用户故事。 这个是云智慧团队中,自己做的影响地图的范例,可以看下整个的层级结构。序号表示优先级。 那我们用户影响地图可以总结为: