干货 | 团队建设共同愿景的探索

点击上方“中兴开发者社区”,关注我们

每天读一篇一线开发者原创好文

作者简介

作者强伟峰是一位开发团队的Scrum Master,他致力于在团队内引入各种管理理念和软件新技术;这篇文章主要讲述了团队通过建设共同愿景解决团队融合、协作和目标方面的问题,希望对其他Scrum Master或Team Leader有所借鉴。

一、问题的提出

2017年下半年我负责组建一个新团队,新团队由在业务上基本没有交集的两个团队合并而来。新团队成立后,业务交付的压力很大,各项事务错综繁杂,新团队在磨合过程还存在若干问题,典型的问题有:

1. 团队成员间缺乏了解,缺乏相互信任,沟通效率低;

2. SM在推进改进举措时得不到大家的响应,一个人推着大家走,很累且效果不佳;

3. 在一些目标达成过程中,大家想法不一样,团队无法形成合力;

4. 团队有很多地方待改进,SM一个人分身乏术,但又没有群策群力的文化氛围;

如何在较短时间内度过新团队的磨合期,激活更多人参与团建活动,形成团队合力,完成业务交付目标,是我亟需解决的问题。

二、解决思路及实践

笔者依据之前团队管理经验,带着问题学习了《第五项修炼》,被书上描绘的共同愿景对组织和个人的巨大影响所吸引。而当前新团队面临的一些问题如团队缺少整体目标、团队成员间缺乏深层次的交流连接、团队成员为完成任务而工作缺乏自驱力,是可以通过团队共同愿景的建设来解决的。

鉴于以往团队讨论完愿景就束之高阁,三天热情后就回归平静的前车之鉴,我们在进行共同愿景大讨论后,通过明确和细化愿景,让愿景跟平时的实际工作相关联,让愿景变成一条条具体可落实的举措,定期跟踪举措的落实,同步完善愿景和目标。在这个过程中,逐渐化解了团队内的一些矛盾和问题,变外驱为众人内驱,一起为团队愿景目标的完成而努力。

2.1 什么是共同愿景?

共同愿景是指组织中所有成员共同的、发自内心的意愿,这种意愿不是一种抽象的东西,而是具体的能够激发所有成员为组织这一愿景而奉献的任务、事业或使命,它能够创造巨大的凝聚力。管理大师彼得圣吉在《第五项修炼》一书中把共同愿景作为五项修炼中的其中一项,对共同愿景及其巨大作用做了众多阐述,笔者最认可的两个定义是:

1) 共同愿景是“全体成员深度分享的共同目标、价值观和使命感”;

2) 个人愿景是人们在自己头脑里的图景和画面,而共同愿景则是整个组织中人们内心共同的图景;

      通过实践发现,在和团队定义共同愿景过程中,切实围绕“深度分享”和“人们内心共同”两个要点展开,才能真正避免愿景被束之高阁。

 

2.2 为什么要开展共同愿景的建设?

共同愿景首先是组织中所有成员的内心意愿的表达,是团队共同目标、价值观和使命感。当真心的愿景建立起来的时候,人们都会力行卓越,用心学习,积极上进。这不是因为有人叫他们这么做,而是因为他们想这么做。共同愿景,特别是有内在深度的愿景,能够激发人们的热望和抱负。

在敏捷转型过程中,各级组织也在追求成为学习型组织,但是没有共同愿景就没有学习型组织。愿景能够帮助建立支配一切的总目标。共同愿景还像方向舵,当学习实践过程产生偏离、问题和压力时,它会纠正航向。

从各种类型成功的组织来看,不分大小和行业,都离不开共同愿景。在我们公司内部,也是有“做MICT 时代的领导者”这样的共同愿景支撑的,各个经营部和产品线的目标规划、任务落地都是围绕愿景达成开展的。同理,一个优秀团队必然也有其共同愿景。

很重要的是,讨论共同愿景,是挖掘、分享大家内心真实意愿和价值观的过程,这是一个信任互建,求同存异的过程。制定出的共同愿景,凝聚了所有人的意志,更能激发大家的热情,众志成城的为共同的目标去努力。

 

2.3 如何在组织内建设共同愿景?

在敏捷转型初期,笔者所在团队也曾组织过共同愿景的讨论,当时愿景建设存在如下问题:愿景讨论不够深入,十分钟就确定了愿景;愿景讨论完放在团队宣言文档和看板中,然后就束之高阁了。基于以上的问题,在学习了《第五项修炼》后,再次在新团队建设共同愿景时,我希望让共同愿景从墙上走下来,走到我们平时具体的工作中,为此做了如下三点改变:

  •  深度汇谈,输出团队共同的发自内心认可的愿景;

  •  解读愿景,搭建愿景与现实的桥梁,让愿景可实现;

  •  持续反馈,实现愿景,丰富愿景;

 

具体实践时,我们团队大致分下面三个步骤来实施:

第一阶段:定义愿景(2017.9--2017.10);

第二阶段:明确愿景(2017.11--2017.11);

第三阶段:实现愿景(2017.12--至今);

 

2.3.1  第一阶段:定义愿景

考虑到愿景涉及的范围比较大,直接讨论会有无处下手的问题,我在团队在讨论愿景前,首先明确方向,愿景的核心应该体现人和产品,大家最关注的也是人和产品,所以我们从下面两个方向展开:

一、我们要做什么样的团队?

二、我们要打造什么样的产品?

 

两个问题抛出后,立刻引发了大家的激烈讨论,在具体讨论过程中,使用了头脑风暴、脑图等方法和工具来可视化过程,然后逐步收敛达成一致。在具体讨论过程中,要注意把握以下要点:

  • 让每个人都能有发言的机会;

  • 把大家的想法及时归纳总结成若干关键词;

  •  把这些关键词贴在墙上,进行意见收敛,通过多轮投票,投出排名最靠前的几个关键词;

  • 最后和大家讨论确认,选取认可度最高的三个关键词;

我们团队经过两次会议讨论,最终确定出团队的共同愿景是:

我们要成为团结、高效、有活力的团队;

我们立志打造高质量、易用、有创新性的产品;

 

愿景的讨论过程是热烈的,每个人都参与其中;最后愿景达成的时候,作为参与人之一确实感受到书中说的“愿景能够振奋精神,焕发生气,扩张激情”。会后,我们把团队愿景写到我们

的看板墙上和团队WIKI主页上。

 

在这个过程中有些细节需要注意:

  •  团队愿景是大家的愿景,只有来自大家内心的诉求和愿望才能在以后激发大家的热情;

  • 团队的leader需要把自己摆在一个旁观者或者普通参与者角度上,别自己主导了愿景,也别让领导或团队中的某些人包揽了讨论;

  •  团队愿景是团队共同制定的,每个人都要参与其中;

  • 不要急于求成,愿景的达成是大家意愿形成合力的过程,需要充分的讨论;

  •  愿景讨论会尽量在轻松、时间充裕的会议氛围中进行;

2.3.2  第二阶段:明确愿景

很多团队在完成第一阶段的工作后,就认为共同愿景的讨论结束了,这样的愿景只是彼得圣吉眼中一时兴起的共同愿景,是无法发挥共同愿景的巨大能量的。

愿景确定后,为了不让愿景仅仅是个墙上的口号,更为了让大家看到团队在朝愿景努力,我们又组织了会议讨论如何把愿景明确和落实。通过明确愿景的正向目标、反向目标及提升正向目标的举证来建立愿景和实践的桥梁。下面上我们团队第一次愿景明确会讨论后的意见:

虽然还有很多目标不够明确,但已经比关键词具体多了。经过几轮这样的讨论,团队愿景、目标及举措已经比较具体明确了。在后续愿景实现过程中,我们会根据实际情况对这些目标及举措进行修订。

 

2.3.3  第三阶段:实现愿景

在制定具体举措后,整个团队一起把这些举措落实,通过不断的行动,让大家感知到我们在往共同愿景上努力。

通过回顾会或专项讨论会上讨论我们愿景的达成情况,对当时制定的不合理目标或举措进行修订。在这个过程中,团队的愿景目标也越来越清晰。

下面是我们团队完成的部分举措:

  •  团队内的小游戏(飞镖比赛等)

  •  轻松的读书分享会  

  •  新需求100%开展需求实例化

  •  每月一次的质量复盘

  • 定期推送典型故障案例

2.3.4  未来

目前我们团队的共同愿景建设只是走出了一小步,现有的讨论主要还是立足在目标、使命上,有些想法还比较稚嫩和局部。放眼未来,团队对个人愿景组织愿景的挖掘上再进一步,让团队愿景更为丰富充实。具体有:

  •  团队愿景中现有的高效、创新的正反向目标举措还不够明确;

  •  要建设团队的价值观;

  •  团队愿景可以跟团队的OKR、度量结合在一起;

  •  通过赋能,让团队更多的人参与进来;

 

2.3.5  经验总结

在实践过程中,整体提炼以下经验:

1)必须首先激发大家真正参与讨论和建设过程,让大家认可愿景的重要性;

2)共同愿景是动态的,不断完善的,需要定期讨论更新;

3)愿景的建设关键是执行,要有具体的落实举措,有计划,有执行;

 

三、效果评价

针对团队之前存在的问题进行效果评价:

1. 问题:团队成员间缺乏了解,缺乏相互信任,沟通效率低;

   目前效果:团队气氛融洽,沟通顺畅,团队内的结对非常普遍。

2. 问题:SM在推进改进举措时得不到大家的响应,一个人推着大家走,很累且效果不佳;

   目前效果:SM更多制定目标,策略改进方案;大家一起行动;

3. 问题:在一些目标达成过程中,大家想法不一样,团队无法形成合力;

   目前效果:大家在总体的方向已经达成一致,有这个大前提,分歧很容易弥合了;

4. 问题:团队有很多地方待改进,SM一个人分身乏术,但又没有群策群力的文化氛围;

   目前效果:像团队评优、回顾会组织、代码走查等工作由专人负责,SM更注重过程改进和整体交付;

 针对团队交付能力、交付质量进行评价:

交付能力: 从原来交付1.5个项目,到现在同时交付3个项目;

交付质量:团队故障泄露数整体在下降,团队质量意识,下面是团队融合后故障泄露数的数据:

四、推广建议

本文讲述的是团队愿景建设的思路和方法,涉及到的工具也是公司内可获取的,可供其他团队参考。

 

五、参考内容

《第五项修炼》---彼得.圣吉。

 

—— 完 ——

### 回答1: Spark Streaming 和 Flink 都是流处理框架,但在一些方面有所不同。 1. 数据处理模型 Spark Streaming 基于批处理模型,将流数据分成一批批进行处理。而 Flink 则是基于流处理模型,可以实时处理数据流。 2. 窗口处理 Spark Streaming 的窗口处理是基于时间的,即将一段时间内的数据作为一个窗口进行处理。而 Flink 的窗口处理可以基于时间和数据量,可以更加灵活地进行窗口处理。 3. 状态管理 Spark Streaming 的状态管理是基于 RDD 的,需要将状态存储在内存中。而 Flink 的状态管理是基于内存和磁盘的,可以更加灵活地管理状态。 4. 容错性 Flink 的容错性比 Spark Streaming 更加强大,可以在节点故障时快速恢复,而 Spark Streaming 则需要重新计算整个批次的数据。 总的来说,Flink 在流处理方面更加强大和灵活,而 Spark Streaming 则更适合批处理和数据仓库等场景。 ### 回答2: Spark Streaming 和 Flink 都是流处理框架,它们都支持低延迟的流处理和高吞吐量的批处理。但是,它们在处理数据流的方式和性能上有许多不同之处。下面是它们的详细比较: 1. 处理模型 Spark Streaming 采用离散化流处理模型(DPM),将长周期的数据流划分为离散化的小批量,每个批次的数据被存储在 RDD 中进行处理,因此 Spark Streaming 具有较好的容错性和可靠性。而 Flink 采用连续流处理模型(CPM),能够在其流处理过程中进行事件时间处理和状态管理,因此 Flink 更适合处理需要精确时间戳和状态管理的应用场景。 2. 数据延迟 Spark Streaming 在处理数据流时会有一定的延迟,主要是由于对数据进行缓存和离散化处理的原因。而 Flink 的数据延迟比 Spark Streaming 更低,因为 Flink 的数据处理和计算过程是实时进行的,不需要缓存和离散化处理。 3. 机器资源和负载均衡 Spark Streaming 采用了 Spark 的机器资源调度和负载均衡机制,它们之间具有相同的容错和资源管理特性。而 Flink 使用 Yarn 和 Mesos 等分布式计算框架进行机器资源调度和负载均衡,因此 Flink 在大规模集群上的性能表现更好。 4. 数据窗口处理 Spark Streaming 提供了滑动、翻转和窗口操作等灵活的数据窗口处理功能,可以使用户更好地控制数据处理的逻辑。而 Flink 也提供了滚动窗口和滑动窗口处理功能,但相对于 Spark Streaming 更加灵活,可以在事件时间和处理时间上进行窗口处理,并且支持增量聚合和全量聚合两种方式。 5. 集成生态系统 Spark Streaming 作为 Apache Spark 的一部分,可以充分利用 Spark 的分布式计算和批处理生态系统,并且支持许多不同类型的数据源,包括Kafka、Flume和HDFS等。而 Flink 提供了完整的流处理生态系统,包括流SQL查询、流机器学习和流图形处理等功能,能够灵活地适应不同的业务场景。 总之,Spark Streaming 和 Flink 都是出色的流处理框架,在不同的场景下都能够发挥出很好的性能。选择哪种框架取决于实际需求和业务场景。 ### 回答3: Spark Streaming和Flink都是流处理引擎,但它们的设计和实现方式有所不同。在下面的对比中,我们将比较这两种流处理引擎的主要特点和差异。 1. 处理模型 Spark Streaming采用离散流处理模型,即将数据按时间间隔分割成一批一批数据进行处理。这种方式可以使得Spark Streaming具有高吞吐量和低延迟,但也会导致数据处理的粒度比较粗,难以应对大量实时事件的高吞吐量。 相比之下,Flink采用连续流处理模型,即数据的处理是连续的、实时的。与Spark Streaming不同,Flink的流处理引擎能够应对各种不同的实时场景。Flink的实时流处理能力更强,因此在某些特定的场景下,它的性能可能比Spark Streaming更好。 2. 窗口计算 Spark Streaming内置了许多的窗口计算支持,如滑动窗口、滚动窗口,但支持的窗口计算的灵活性较低,只适合于一些简单的窗口计算。而Flink的窗口计算支持非常灵活,可以支持任意窗口大小或滑动跨度。 3. 数据库支持 在处理大数据时,存储和读取数据是非常重要的。Spark Streaming通常使用HDFS作为其数据存储底层的系统。而Flink支持许多不同的数据存储形式,包括HDFS,以及许多其他开源和商业的数据存储,如Kafka、Cassandra和Elasticsearch等。 4. 处理性能 Spark Streaming的性能比Flink慢一些,尤其是在特定的情况下,例如在处理高吞吐量的数据时,在某些情况下可能受制于分批处理的架构。Flink通过其流处理模型和不同的调度器和优化器来支持更高效的实时数据处理。 5. 生态系统 Spark有着庞大的生态系统,具有成熟的ML库、图处理库、SQL框架等等。而Flink的生态系统相对较小,但它正在不断地发展壮大。 6. 规模性 Spark Streaming适用于规模小且不太复杂的项目。而Flink可扩展性更好,适用于更大、更复杂的项目。Flink也可以处理无限制的数据流。 综上所述,Spark Streaming和Flink都是流处理引擎,它们有各自的优缺点。在选择使用哪一个流处理引擎时,需要根据实际业务场景和需求进行选择。如果你的业务场景较为复杂,需要处理海量数据并且需要比较灵活的窗口计算支持,那么Flink可能是更好的选择;如果你只需要简单的流处理和一些通用的窗口计算,Spark Streaming是更为简单的选择。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值