- 博客(2228)
- 收藏
- 关注
RSS订阅原创 21 | 深入对比Spark与Flink：帮你系统设计两开花
Flink 中最核心的数据结构是 Stream，它代表一个运行在多个分区上的并行流。在 Stream 上同样可以进行各种转换操作（Transformation）。与 Spark 的 RDD 不同的是，Stream 代表一个数据流而不是静态数据的集合。所以，它包含的数据是随着时间增长而变化的。而且 Stream 上的转换操作都是逐条进行的，即每当有新的数据进来，整个流程都会被执行并更新结果。这样的基本处理模式决定了 Flink 会比 Spark Streaming 有更低的流处理延迟性。
2024-07-03 17:19:32
1609
原创 20 | 流处理案例实战：分析纽约市出租车载客信息
今天的数据集是纽约市 2009～2015 年出租车载客的信息。每一次出行包含了两个事件，一个事件代表出发，另一个事件代表到达。每个事件都有 11 个属性，它的 schema 如下所示：这部分数据有个不太直观的地方，那就是同一次出行会有两个记录，而且代表出发的事件没有任何意义，因为到达事件已经涵盖了所有必要的信息。现实世界中的数据都是这样复杂，不可能像学校的测试数据一样简单直观，所以处理之前，我们要先对数据进行清洗，只留下必要的信息。
2024-07-03 16:46:36
761
原创 19 | 综合案例实战：处理加州房屋信息，构建线性回归模型
为了完成今天的综合案例实战，使用的是美国加州 1990 年房屋普查的数据集。数据集中的每一个数据都代表着一块区域内房屋和人口的基本信息，总共包括 9 项：1. 该地区中心的纬度（latitude）2. 该地区中心的经度（longitude）3. 区域内所有房屋屋龄的中位数（housingMedianAge）4. 区域内总房间数（totalRooms）5. 区域内总卧室数（totalBedrooms）6. 区域内总人口数（population）7. 区域内总家庭数（households）
2024-07-03 15:46:23
1392
原创 18 | Word Count：从零开始运行你的第一个Spark应用
今天我们来从零开始运行第一个 Spark 应用。我们先来回顾一下模块三的学习路径。首先，我们由浅入深地学习了 Spark 的基本数据结构 RDD，了解了它这样设计的原因，以及它所支持的 API。之后，我们又学习了 Spark SQL 的 DataSet/DataFrame API，了解到它不仅提供类似于 SQL query 的接口，大大提高了开发者的工作效率，还集成了 Catalyst 优化器，可以提升程序的性能。这些 API 应对的都是批处理的场景。
2024-07-03 15:06:34
811
原创 17 | Structured Streaming：如何用DataFrame API进行实时数据分析?
上一讲中，我们介绍了 Spark 中的流处理库 Spark Streaming。它将无边界的流数据抽象成 DStream，按特定的时间间隔，把数据流分割成一个个 RDD 进行批处理。所以，DStream API 与 RDD API 高度相似，也拥有 RDD 的各种性质。在第 15 讲中，我们比较过 RDD 和 DataSet/DataFrame。你还记得 DataSet/DataFrame 的优点吗？你有没有想过，既然已经有了 RDD API，我们为什么还要引入 DataSet/DataFrame 呢？
2024-07-03 11:26:34
900
原创 16 | Spark Streaming：Spark的实时流计算API
今天要与你分享的内容是“Spark Streaming”。通过上一讲的内容，我们深入了解了 Spark SQL API。通过它，我们可以像查询关系型数据库一样查询 Spark 的数据，并且对原生数据做相应的转换和动作。但是，无论是 DataFrame API 还是 DataSet API，都是基于批处理模式对静态数据进行处理的。比如，在每天某个特定的时间对一天的日志进行处理分析。在第二章中你已经知道了，批处理和流处理是大数据处理最常见的两个场景。
2024-07-03 10:54:11
1077
原创 15 | Spark SQL：Spark数据查询的利器
上一讲中，介绍了弹性分布式数据集的特性和它支持的各种数据操作。不过在实际的开发过程中，我们并不是总需要在 RDD 的层次进行编程。就好比编程刚发明的年代，工程师只能用汇编语言，到后来才慢慢发展出高级语言，如 Basic、C、Java 等。使用高级语言大大提升了开发者的效率。同样的，Spark 生态系统也提供很多库，让我们在不同的场景中使用。今天，让我们来一起探讨 Spark 最常用的数据查询模块——Spark SQL。
2024-07-03 09:53:13
736
原创 14 | 弹性分布式数据集：Spark大厦的地基（下）
上一讲我们介绍了弹性分布式数据集（RDD）的定义、特性以及结构，并且深入讨论了依赖关系（Dependencies）。今天让我们一起来继续学习 RDD 的其他特性。
2024-07-02 17:11:11
633
原创 13 | 弹性分布式数据集：Spark大厦的地基（上）
弹性分布式数据集是英文直译的名字，乍一看这个名字相信你会不知所云。RDD 表示已被分区、不可变的，并能够被并行操作的数据集合。这个定义很不直观，我认识的很多 Spark 初学者在查阅了很多资料后还是对 RDD 一头雾水，很难理解这个抽象的概念。接下来，让我们一起来对这个晦涩的概念抽丝剥茧，见其真义。在上述定义以及 RDD 的中文译名中，我们不难发现，RDD 有以下基本特性：分区、不可变和并行操作。接下来让我分别讲解这些特点。
2024-07-02 16:28:31
769
原创 12 | 我们为什么需要Spark？
今天我要与你分享的主题是“我们为什么需要 Spark”。也许你之前没有做过大规模数据处理的项目，但是 Spark 这个词我相信你一定有所耳闻。Spark 是当今最流行的分布式大规模数据处理引擎，被广泛应用在各类大数据处理场景。2009 年，美国加州大学伯克利分校的 AMP 实验室开发了 Spark。2013 年，Spark 成为 Apache 软件基金会旗下的孵化项目。而现在，Spark 已经成为了该基金会管理的项目中最活跃的一个。
2024-07-02 14:42:02
792
原创 11 | Kappa架构：利用Kafka锻造的屠龙刀
今天要分享的主题是 Kappa 架构。同样身为大规模数据处理架构，Kappa 架构这把利用 Kafka 锻造的“屠龙刀”，它与 Lambda 架构的不同之处在哪里呢？上一讲中，讲述了在处理大规模数据时所用到经典架构，Lambda 架构。先来带你简要回顾一下。Lambda 架构结合了批处理和流处理的架构思想，将进入系统的大规模数据同时送入这两套架构层中，分别是批处理层（Batch Layer）和速度层（Speed Layer），同时产生两套数据结果并存入服务层。
2024-07-02 11:28:40
932
原创 10 | Lambda架构：Twitter亿级实时数据分析架构背后的倚天剑
今天要与你分享的主题是 Lambda 架构。通过这一讲，你可以了解什么是 Lambda 架构，以及它为什么能够成为 Twitter 亿级实时数据分析架构背后的“倚天剑”。在学习了架构师的必备技能后，你是否已经摩拳擦掌，跃跃欲试地想要上手一个实际项目了呢？没问题，我们一起来看一个我的架构经历里的真实项目。情况是这样的，我们正运行着广告精准投放业务，并且拥有海量的用户网站访问行为。我们需要进行用户行为分析来建立一个模型，然后根据这个模型来投放用户喜好的广告。你可能想到了批处理架构。
2024-07-02 10:20:41
667
原创 09 | CAP定理：三选二，架构师必须学会的取舍
今天要与你分享的主题是 CAP 定理。在分布式系统的两讲中，我们一起学习到了两个重要的概念：可用性和一致性。而今天，想和你讲解一个与这两个概念相关，并且在设计分布式系统架构时都会讨论到的一个定理——
2024-07-02 09:04:38
794
原创 08 | 发布/订阅模式：流处理架构中的瑞士军刀
今天想要与你分享的是在处理大规模数据中十分流行的一种设计模式：发布 / 订阅模式（Publish/Subscribe Pattern），有些地方也称它为 Pub/Sub。在了解发布 / 订阅模式之前，我想先简单介绍几个基础概念——消息（Message）和消息队列（Message Queue）。
2024-07-01 17:37:53
679
原创 07 | Workflow设计模式：让你在大规模数据世界中君临天下
今天要与你分享的主题是“Workflow 设计模式”。在上一讲中，我们一起学习了大规模数据处理的两种处理模式——批处理和流处理。利用好这两种处理模式，作为架构师的你就可以运筹帷幄，根据实际需求搭建出一套符合自己应用的数据处理系统。然而，光是掌握了这两种数据处理模式就足够自如应对大规模数据世界中的需求挑战吗？从我的实战经验中看来，其实未必。我们每个人在最开始学习大规模数据处理的时候，可能都是以 WordCount 作为教学例子来进行学习的。
2024-07-01 16:25:37
960
原创 06 | 如何区分批处理还是流处理？
今天，将会带领你一起学习在进行大规模数据处理时，无论如何也绕不开的两个处理模式：批处理（Batching Processing）和流处理（Streaming Processing）。在我看来，大规模的视频流系统、大规模物联网（IoT）数据监控系统等各种现代大规模数据系统的出现，已经成为了一种必然的历史潮流。无论你是在从事哪一种开发方向，都不可避免地要与这些海量数据打交道。如何能既满足实际应用场景的需求，又高效地处理好大规模数据，在整个项目开发架构中都是非常重要的一个环节。
2024-07-01 15:38:31
779
原创 05 | 分布式系统（下）：架构师不得不知的三大指标
上一讲中，我们学习了如何用服务等级协议（SLA）来评估我们设计的分布式系统，并了解了几个常见的 SLA 指标。今天我们继续来探索分布式系统的另外几个重要基础概念。
2024-07-01 14:32:29
928
原创 04 | 分布式系统（上）：学会用服务等级协议SLA来评估你的系统
从今天开始，我们进入专栏的第二模块。通过这一模块的学习，带你一起夯实大规模数据处理的基础。首先，我将结合硅谷顶尖科技公司的(Best Practice) ，和你一起分享在设计分布式系统架构时，我们有可能会碰到哪些雷区？又有哪些必备的基础知识？在硅谷一线大厂所维护的系统服务中，我们经常可以看见 SLA 这样的承诺。例如，在谷歌的云计算服务平台 Google Cloud Platform 中，他们会写着“99.9% Availability”这样的承诺。那什么是“99.9% Availability”呢。
2024-07-01 11:50:02
710
原创 03 | 大规模数据处理初体验：怎样实现大型电商热销榜？
今天要与你分享的主题是“怎样实现大型电商热销榜”。在 Google 面试过很多优秀的候选人，应对普通的编程问题 coding 能力很强，算法数据结构也应用得不错。可是当我追问数据规模变大时该怎么设计系统，他们却说不出所以然来。这说明他们缺乏必备的规模增长的技术思维（mindset of scaling）。这会限制这些候选人的职业成长。因为产品从 1 万用户到 1 亿用户，技术团队从 10 个人到 1000 个人，你的技术规模和数据规模都会完全不一样。
2024-07-01 10:54:28
878
原创 02 | MapReduce后谁主沉浮：怎样设计下一代数据处理技术？
在上一讲中，我们介绍了 2014 年之前的大数据历史，也就是 MapReduce 作为数据处理的默认标准的时代。重点探讨了 MapReduce 面对日益复杂的业务逻辑时表现出的不足之处，那就是：1. 维护成本高；2. 时间性能不足。同时，我们也提到了 2008 年诞生在 Google 西雅图研发中心的 FlumeJava，它成为了 Google 内部的数据处理新宠。那么，为什么是它扛起了继任 MapReduce 的大旗呢？
2024-07-01 10:18:29
622
原创 01 | 为什么MapReduce会被硅谷一线公司淘汰？
今天我要与你分享的主题是“为什么 MapReduce 会被硅谷一线公司淘汰”。我有幸几次与来 Google 参观的同行进行交流，当谈起数据处理技术时，他们总是试图打探 MapReduce 方面的经验。这一点让我颇感惊讶，因为在硅谷，早已没有人去谈论 MapReduce 了。今天这一讲，我们就来聊聊为什么 MapReduce 会被硅谷一线公司淘汰。我们先来沿着时间线看一下超大规模数据处理的重要技术以及它们产生的年代。我认为可以把超大规模数据处理的技术发展分为三个阶段：石器时代，青铜时代，蒸汽机时代。
2024-07-01 09:44:52
871
原创 36 | 走出自己的管理之路
原因很简单：我们的目标是和上级一起定的，资源是向上级申请的，工作结果是上级来评价的，你会发现我们管理中的“看方向”“带人”和“做事”都是离不开上级的。事实上，所有的路上都有一条法则是奏效的，那就是“价值兑换”，所以，做技术不重要，做管理也不重要，把技术和管理当成你职业的两条腿，在职场中输出自己最大的价值，才是最好的，才真正属于你。因为，只有职位对应的职责固定和明确时，这样的问题才是有意义的，而在我们互联网领域这显然不现实，因为不同的上级对于你这个职位的期待是千差万别的。这既是时代的需要，也是人的需要。
2024-06-28 15:36:34
729
原创 35 | 从空降谈管理方法论的积累
细心的话，你会发现我在管理规划、团队建设、任务管理这三个模块的 13 个要素外围都有留白，我的用意就是希望你在自己的实际管理工作中，也能提炼出你自己的心得体会和方法论，并给它们起个名字放入这些空白的地方，从而形成属于你自己的“管理全景图”。好了，我相信，从这五大方面、18 个要素去按图索骥地、系统地积累自己的方法论，假以时日，你会成为一个既有深度又有广度，既有框架又有方法，既有理论又有实操，既能“自用”又能“带人”的资深管理者。所以你看，你的角色是由上级和公司对你的具体期待决定的，而不是你的头衔。
2024-06-28 14:50:10
1050
原创 34 | 管理沟通上有哪些常见的坑儿呢？
原因在于，这是一种“对人不对事”的沟通，你已经给对方贴上了负面的“标签”，而一旦给人贴上了标签，对方也就放弃了改变自己的意愿，失去了改变自己的动力。而实际上，我们也许并不需要完美地解决这个问题，而只需要把一个 40 分的状态改善到 60 分就行了，或者即便没有改善到 60 分，我们也把事情往好的方向上推进了一点点，这也是我们的价值。不过，就上面这五类最集中的问题，如果我们“照照镜子”的话，肯定是能看到自己的一些“轮廓”的，不是吗？所以，对于你关心的问题，一定要去确认清楚，跟进到底，形成沟通闭环。
2024-06-28 10:57:07
893
原创 33 | 向下沟通的常见实例解析
不过，在正式探讨这些问题之前，我需要首先澄清一个理念：通过上面大家反馈的问题你会发现，虽然大家都认为这是一个“向下沟通”的问题，但是如果我们脱开管理逻辑，单纯去探讨如何“沟通”，就会掉入“舍本逐末”的陷阱，导致在和员工沟通的时候很苍白无力、收效甚微。好了，相信你已经明白我的意思了，就是不要把管理沟通问题单纯看成是沟通问题，其实很大的比重是在管理逻辑上，需要我们从“角色认知”和“管理规划”“团队建设”“任务管理”（还记得我们的“三明治”管理框架吗）的管理方法论上去思考整体解决方案。”“你看我的理解对不对？
2024-06-28 09:46:54
818
原创 32 | 横向沟通和非职权影响力
但是，现实更常见的情况是，管理者在某技术方面的专业度并不是团队里或行业里最高的，此时，借助你可以借助的权威，让这些权威人士，或是权威人士的说法给你站台，也是可以提高说服力的。虽然职权影响力是影响力的一个重要组成部分，但是我们只要能大体了解，或者知道什么是职权影响力就可以了，这并不是我们探讨的重点，因为这个影响力的发挥和发展，受到职位因素的影响比人为因素的影响更大。所以，无论是对上，还是对下，抑或是对横向的合作者，明确好对象，才能去评判自己的影响力高低，以及哪个维度和因素的影响力更大。
2024-06-28 09:13:44
657
原创 31 | 我各方面做得都很好，就是做不好向上沟通
这是向上沟通中的一大类需求，无论是“希望上级接受自己的建议”或者“拒绝上级的不合理需求”，还是“调整上级的预期”或者“说服上级给予资源和支持”，归结起来都是让上级听从自己的看法和方案，即把自己的认知和期待输出给上级。原因是，每个人在评判“该不该聊”的时候，都是基于自己的管理常识（common sense），而每个人在和不同的上级打交道的过程中，形成的常识是不同的，所以会给出不同的答案。由于向上沟通永远是你和上级的“私事”，所以我们无法给出一个普遍适用、一劳永逸的标准答案，也无法穷举所有的向上沟通的场景。
2024-06-27 17:20:36
928
原创 30 | 如何掌控自己的情绪，以及如何管理情绪化的员工？
美国学者麦克林（Mclean）根据大脑演化过程提出了三个脑层次的理论：最里面的是“爬行动物脑”，这部分脑是从爬行动物那里继承下来的，控制着人本能的、无意识的、瞬间反应的行为，属于“生存式大脑”；如果你写过“钩子”程序，你就会发现，这个觉察的模式就好像是挂载一个“钩子”，一旦“钩子”被触发，后面跟上处理程序就可以了，显然这个处理程序就是情绪应对的步骤。也就是说，“爬行脑”和“情绪脑”更容易中断“理性脑”的工作，而且一旦我们的大脑工作在“爬行脑”和“情绪脑”状态，就无暇顾及“理性脑”的工作了。
2024-06-27 15:00:39
906
原创 29 | 沟通经常鸡同鸭讲，说不到一块怎么办？
沟通中常常会遇到的一个情况就是，你说你的、他说他的，好似“鸡同鸭讲”，用东北话说就是“费老劲了”？通过用“3F”倾听和沟通层次图对上面的案例进行分层拆解，你不难发现，如果我们在沟通中，有意识地分事实、感受、意图这三个层次去理解对方的话，并且从这三个层次分别和自己的事实、感受、意图做一个对应，就可以减少很多不必要的误会，同时避免情绪对抗，从而达成有效的沟通结果。由于每个人生活的环境不同，所处的角色不同，惯用的思维方式不同，沟通的初衷也不同，所以，即便是针对同样的客观事实，双方的感受和看法也常常是不同的。
2024-06-27 14:17:38
688
原创 28 | 管理沟通那些事儿
人大概是这个世界上最不稳定的“因素”了，自然性、社会性、情感性交织在一起，再加上无时无刻的相互影响和波动，就别指望有什么流程和规则是可以用于和很多人的相处了，即便是和某个确定的人相处，都很难摸到规律，冲突和矛盾不断。因为，我们在第 27 篇文章中已经提到过，流程和机制是用来保障工作的“下限”的，而激励是激发团队工作“上限”的，所以，员工激励作为很“艺术”的一个管理主题，被众多的技术管理者列在了“最具挑战管理主题”的前三。我想说，我们通常所说的“管理沟通”，很多时候重点并不在“沟通”上，而在“管理”上。
2024-06-27 11:02:27
906
原创 27 | 如何让流程机制得到有效的执行？
由于机制都是有场景化特性的，当场景发生了变化，机制也要随着升级，而对于机制的重新审视和学习都意味着额外的开销，所以，每个机制的维护都是有成本的。你要明白一个道理：机制的建立并不会解决问题，对机制的执行才能解决问题，而机制的建立、执行和后期维护都是需要成本的，所以，千万不要贪多，在风险可控的前提下，机制能不建就不建，能少则少。建立一套机制，不必要对所有的细节进行完整的描述，没有人喜欢看长篇大论的文字，你只要告诉大家，在哪几个最关键的节点，做什么样的动作即可，而且这样的关键点也不能太多，以不超过 5 个为宜。
2024-06-27 10:13:34
573
原创 26 | 如何确保项目的有效执行？
如果各个角色之间有长期稳定的合作关系，比如某 APP 的迭代团队，就可以把各个角色的负责人组织起来，组成一个项目管理的虚拟组织，大家轮流来做总负责人。你也可以回忆一下那些执行良好的项目，你应该不难发现，它们都有一个共同而又必要的条件：清晰的目标，只不过在实际执行过程中，每个人对“清晰”的理解会有所不同。当然，关于项目得不到有效执行，也许还有许许多多的其他问题，就好像“不幸的生活各有各的不幸”一样，项目执行不好也各有各的原因。关于管理沟通的问题，是我们下一个篇章的主题，到时候我们也会做更详细的探讨。
2024-06-27 09:13:00
822
原创 25 | 多任务并行该如何应对？
而实际上，对于一个任务来说，其进度、质量和效果这三个要素是可以此消彼长的，所以在拆解任务的时候，对进度的预期不同，对质量的要求不同，对效果的期待不同，都会导致时间预算和优先级的变化。在实际的工作中，我们经常做的并不是梳理轻重缓急四象限，更常见的情形是，我们要把日常的工作分为两种情况：一种是计划内的，也就是按照我们的规划进行的；所以，不能用固化的视角看待一个任务，每一个任务其实都是可以弹性安排的，不一定是你需要的 4 周，也不见得是上级希望的两周，根据进度、质量、效果的不同期待，你可以给出很多种排期方案。
2024-06-26 16:40:22
662
原创 24 | 如何让团建活动不再“收效甚微”？
比如，如果你想让员工间尽快熟悉、增进彼此认同，而按照员工的兴趣，选用的方案是去 KTV 唱歌，或者去钓鱼馆钓鱼，这个效果就很难达成，因为这些活动的关键环节都不在于彼此交流和互动；再比如，如果你团队的文化是“强执行”，但是你对整个活动中的迟到、随性的行为却没有任何反应，也没有设计什么活动环节来体现“强执行”这个理念的话，那么这个活动对于你团队文化的建设是没有任何效果的。团建活动的主体和对象，即团队，是你的，所以活动能够在团建方面给你带来哪些帮助，是你要考虑的，这就是所谓的团建的初衷和目的。
2024-06-26 14:59:46
690
原创 23 | 如何和低绩效员工谈绩效？
由于通常绩效相关的工作都是由 HR 来推进，所以，很多管理者把绩效管理和绩效沟通当成是 HR 的“政治任务”来完成，有的时候还把低绩效的问题归结为是绩效制度的弊端，和员工沟通的时候，也以一副“全赖公司和 HR，我也没有办法”的无可奈何的姿态。因为，绩效说到底主要是你和员工之间的事儿，它作为一种管理手段，是用来确保员工的产出和你的预期相匹配的，所以是你俩之间的一个“工作协议”，其他人更多的是第三方的角色。绩效沟通的过程，不仅仅是告知员工绩效结果，更重要的是通过对过去工作的回顾，让员工有更多的思考和觉察。
2024-06-26 14:24:04
633
原创 22 | 如何建设团队文化，营造团队氛围？
你是什么样的作风和价值观，你团队就会是什么样的，也就是说，你的团队文化和你喜欢什么样的文化关系不大，而和你是什么样的人关系很大。于是很多公司提出的文化价值观就是几个词，比如前面我们提到腾讯的文化价值观是“正直、进取、合作、创新”，这在我眼里就是个反面教材，因为你记不住，就算是记住了，也很快会忘掉，因为很难感知，也太没区分度了。不信你去看看那些有凝聚力、有战斗力的团队，他们都是有鲜明的气质和调性的，比如有的是“强执行”文化，有的是“靠谱”文化，有的是“极客”文化，还有的是“温暖”文化……
2024-06-26 11:29:40
568
原创 21 | 如何物色和培养核心人才？
而团队文化就好像是团队的气质和调性，它会吸引“气味相投”的人持续加入，而把不符合团队气质的人筛选出去，越来越鲜明的团队价值观让大家紧密地聚拢在一起，从而让团队越来越“结实”，越来越“经得起折腾”，不断增强团队的耐力和韧劲。我们通常所说的“梯队建设”，其实包含了“梯队规划”和“梯队培养”两部分内容，你可以认为规划和培养的关系，是“计划”和“实施”的关系，是“想”和“做”的关系。在人才培养的主动授权中，我推崇的方式是教练式的引导和启发，而不是直接告诉答案，因为经过他自己的思考，他才能更好地掌握工作技能。
2024-06-26 10:54:14
694
原创 20 | 有什么方法可以有效提升团队凝聚力吗？
团队成员间良好的关系，和团队凝聚力的提升是互为因果的，所以不要小看能促进员工间关系的一些小事，恰恰是这些小事，能够促使员工间的合作关系走上正向循环的轨道，员工会因为喜欢和团队的人相处而觉得有归属感。你不难发现，一个非常有凝聚力的团队，对于良好的协作有着直接和关键的影响，而良好的协作反过来也会提升团队成员间的认同度和默契度，从而提升团队的凝聚力。4. 坚持不懈地做步骤 3。关于有哪些可以有效提升团队凝聚力的手段，在我的调研中，有不少管理者反馈，一起面对挑战的时候，特别能够让大家拧成一股绳，我也深以为然。
2024-06-26 10:12:54
747
原创 19 | 如何兼顾团队分工的稳定性和灵活性？
通俗点说，就是为了干大事。所以，分工不是为了高效，而是为了能容纳更多的人来一起干更大、更复杂的事情，做简单的小事情，是不需要分工的。这样一来，人力资源是按照角色“横向”来组织的，而项目执行是按照任务“纵向”来推动的，就形成了一个纵横交错的矩阵式结构，所以叫矩阵式组织结构。为了做一些紧急项目，管理者往往会随意抽调员工，这样的事情出现的多了，员工的归属感会减弱，边界感会消失。常见的一个问题是，管理者常常以员工的产出对自己团队价值不大为理由压低员工绩效，这是典型的让员工背负管理者的决策后果，很不可取。
2024-06-26 09:37:00
893
原创 18 | 如何提升员工的工作意愿和积极性？
由于每个人的业务特点不同、团队性质不同、管理风格不同、员工特征不同、问题挑战不同，所以不要迷信别人给你的激励建议，我更建议你充分考虑自己面临的实际情况，结合自己的特质和激励框架，来设计适用于自己的激励体系。另外，说起“画大饼”，在我看来，“画饼”越来越成为管理者的必备技能，只不过不宜过大，饼太大了是没有激励效果的，要注意和员工有切实的联系。如果说驱动力 2.0 的核心在于“利益”最大化，那么驱动力 3.0 在不拒绝利益的同时，更强调的是工作价值的最大化，希望自己做出来的工作是有意义和价值的。
2024-06-26 09:05:22
1205
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人