我们要努力呀,再不努力就长老了。

本文列举了华为内部认定的管理者惰怠行为,包括安于现状、明哲保身、不敢承担责任等18项表现。这些行为被视为阻碍企业发展和个人成长的主要障碍。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

华为眼中,管理者的 18 条惰怠行为:

 

1

安于现状,不思进取

 

安于现状、不思进取应该只适用于我们的少数的管理者,虽然不多,但肯定存在。

 

对于管理者而言,你敢不敢于去挑战新的领域,敢不敢于去挑战新的难题,敢不敢于有所追求?如果是不敢的话,都是安于现状的表现,也是不思进取的表现。

 

2

明哲保身,怕得罪人

 

我们有的管理者,什么事情心里都清楚,什么事情都讲得头头是道,但就是不敢站出来说话、反馈问题,或者不敢去推动,怕得罪周边,怕得罪领导,还怕得罪下属。

 

这样,在我们这么大的组织里,在流程还不健全的情况下,这种管理者怎么能推动解决问题,怎么能够当责,怎么能够持续改进?

 

 

3

以领导为核心,不以客户为中心

 

现在公司最深恶痛绝的就是做胶片。有些主管在给上级做汇报前,为了做一个汇报胶片,不知道要召集自己的下属开多少次会。

 

所以任总说,以后要做什么事情都不敢提前通知,都得临时通知,别为了他要来听一次汇报,要来看一看,下面就花费很多时间,搞很多人做胶片。

 

我想说的是,对做胶片我们不要僵化地理解。如果说,我们做胶片的过程,是进一步去思考、去讨论、去达成共识、去找到方向、找到思路,那做胶片的过程是增值的;如果连这个过程都不要了,那也太教条了。

 

但是这个过程主管不要找太多人,如果我们做一套胶片要一二十人集体来做,那效率就太低了,就太以领导为中心了。按道理来说,主管自己的汇报,最好是自己来写胶片。

 

任总的所有讲话都是自己亲自写的,从来都不让别人写,他写完后再征求EMT(EMT是华为日常经营的最高责任机构,受董事会委托执行华为的日常管理。) 成员的意见,让大家看写得对不对。

 

我们的主管就不能向任总学习吗?你要汇报的胶片,能不能自己写?写完了,可以像任总一样把大家召集起来一起评审。你要自己写的话,我相信不会超过很多页,也不会弄得花花绿绿,搞得那么漂亮了。

 

 

为了美化、格式好看,而浪费下属和你自己大量的时间,这是不增值的。不能以领导为核心,我们首先不要组织大队人马来写汇报胶片。我们要做增值的部分,坚决不做不增值的部分。

 

4

推卸责任

 

面对问题,部分高级主管已经形成了习惯:首先是搞清楚是别人的问题,那就跟自己没关系了。如果发生任何事情,主管都习惯性地先看自己有什么问题,都先把自己的原因找出来,那么真正的原因就出来了。

 

 

但我们最习惯的却是先找别人的问题,不找自己的问题;还有一种情况,就是老担心别人做不好,不担心自己做不好。现在很多人,很习惯去讲一大堆别人的问题,从来不讲自己的问题。

 

5

发现问题不找根因

 

马来的事情是这样的,AIS(卫星AIS是一种船舶定位技术)也是这样,出了问题后整个过程中就是投诉,就是指责,却不知道到底是什么原因。

 

相当多的管理者,养成了一个非常不好的习惯,出了什么事情,打个电话“你搞定”;上级领导问他“你抓了没”,他说“抓了”。

 

我们只是打了一个电话,或者批示一下,这样怎么能够把事情搞透彻,怎么能够找到解决办法?怎么能真正解决问题?

 

6

只顾部门局部利益没有整体利益

 

有些主管为了自己的部门利益,明明知道影响公司利益,明明知道公司的想法和要求,却在下面想方设法,花了很多时间、精力去搞他的小九九。

 

尤其涉及到我们有业务拆分和整合、团队和人员要划分的时候都表现得非常明显。你这样做,公司怎么敢交给你更大的责任。如果你的责任更大,你更以局部利益为主的话,那以后公司的整体利益谁来保证?

 

7

不敢淘汰惰怠员工,不敢拉开差距,搞“平均主义”

 

其实主管对他的下属有没有惰怠的很清楚,就是拉不下面子去处理,尤其是对老员工,有些还是自己的老领导或老同事,更拉不下面子。

 

在这种情况下,你不淘汰,你不拉开差距,你就是对那些高绩效者、对那些优秀者不尊重。

 

 

在我们身边,惰怠的员工比比皆是,那我们敢不敢给他降级、降等、降薪?

 

8

经常抱怨流程有问题,从来不推动流程改进

 

有主管经常抱怨流程多、流程复杂,并且时时挂在口头上。如果真发现流程有问题,一定要指出哪里流程多、哪个流程有问题。我们希望所有觉得流程有问题、流程多的人,要给所在组织的质量与运营组织、QA(Quality Assurance,品质保证)提出来,这样才好改进。

 

很多人就只抱怨,而且最后都成了口头禅,动不动流程很多、流程很长、流程阻碍了发展,但从来不去推动流程的改进,从来不指出哪里流程多了,哪个流程长了,哪个流程有问题。那怎么改进呢?

 

9

不敢接受新挑战,不愿意离开舒适区

 

在研发还好一点,因为没有哪个地方很差。但也有主管不想去新领域,不敢接受挑战。今年一个很重要的导向就是希望干部、骨干能到新领域去,有人就怕这个怕那个,患得患失。

 

10

不敢为被冤枉的员工说话

 

有的主管怕为被冤枉的员工说句公道话,因为说了,可能就会被公司“戴帽子”。如果你真的觉得某个员工被冤枉了,为什么不敢说呢?要么你根本就不对这个员工负责任,要么就是怕说了以后被主管批评,怕得罪人。但如果你都不敢说话,那又如何保护他们?

 

11

只做二传手,不做过滤器

 

有很多主管只做二传手,不做过滤器。任何地方来了事,他立即就传下去了,不管这个事情该不该做、要不要做,反正不是自己亲自做,这样一来就让下属苦不堪言,不能聚焦工作。

 

12

热衷于讨论存在的问题,从不去解决问题

 

很多主管讨论存在问题的时候,都是洋洋洒洒,能道出具体问题来,但从不去解决问题。无论是潜规则还是流程问题,或者是现在政策执行上存在的问题。

 

 

作为主管,如果能够把你们授权范围内能解决掉的问题全部解决掉,那么很多问题就没有了,特别是潜规则。对于你解决不了的,不在你授权范围内的,若你不去推动解决,那怎么能够解决?

 

13

只顾指标不顾目标

 

在我们当中,存在一些主管只关注 KPI 的完成,但不知道 KPI 完成得很好是为了什么。比如某个平台,每年的考核指标都很好,因为考核指标都是质量、进度、网上问题,但慢慢把自己做没了。

 

华为到底是为了追求一个卓越的、有竞争力的嵌入式操作系统,还是仅仅为了追求网上没事故?因此各级干部都要思考,我们的工作到底是为了什么,不是为了几个考核指标。仅仅为了考核指标工作,就是不当责。当责的干部是有清晰的目标的。

 

14

把成绩透支在本任期,把问题留给下一任

 

 

在研发比较多的是,只关注当期不关注长期,只关注现在不关注未来,该投入的不敢投入,不敢在新领域、新产品上投入,不愿在架构、平台等长期才能看到绩效的工作上投入,甚至只关注仗打得漂亮,而忽视组织能力、流程优化、人员能力提升等长远的事。

如果我们只关注眼前,华为就会失去竞争力,这样的干部就是不当责。

 

15

只报喜不报忧,不敢暴露问题

 

捂盖子现象不能说少,无论是写总结还是做述职,讲起成绩、经验来头头是道,问题和不足则一笔带过。

 

最可怕的是质量上的捂盖子,搞“和谐”,不主动暴露质量问题、流程执行问题,甚至为了过TR(Technical Review 技术评审)点而作假。如果我们睁一只眼、闭一只眼,马马虎虎应付了事,那产品的质量就没办法保证,我们就会失信于客户。

 

16

不开放进取,不主动学习,业务能力下降

 

有一部分干部凭着经验做事,走的是“经验主义”的老路。华为要从“土八路”走向正规军,过去的成功经验并不是未来前进的方向标,必须开放自己,自我批判,时刻学习。我们在 CT(通讯技术产业)领域的成功,不能确保我们在 ICT(信息通信技术)领域的成功。

 

17

不敢决策,不当责,把责任推给公司

 

这一点跟前面讲的抱怨流程的问题类似。绩效是评责任结果,还是评亮点和表扬信?说起来我们都清楚评的是责任结果,但真的评的时候却去评亮点。这些现象谁能纠正?就是我们各位主管。

 

18

只对过程负责,不对结果负责

 

这一点比较好理解,与只关注指标不顾目标相类似,有些主管只关注“我做了呀”,但不管”做的结果如何”。只对过程负责,不对结果负责,就会形式主义,很容易把事情复杂化,把动作做得很优美,效果却不好。

 

这就是我今天重点讲的管理者的惰怠行为,希望大家能把管理者的惰怠行为作为自我批判的依据。每个人都在自己身上去找几条出来,然后写几个案例,这也是一个反思的过程。不敢写自己的案例,事实上也是自我批判不够透彻。

 

我们也希望,每个主管能把这些惰怠行为贴在你办公桌上、放在你笔记本里,经常看一看是不是又在产生惰怠行为了。这样,我们管理者才能真正地从自我批判开始,与惰怠行为作斗争,管理者才能真正地当起责来。

转载于:https://www.cnblogs.com/weijieyun/p/6102442.html

<think>好的,用户现在问的是在更改Gradle版本的情况下怎么解决Spring Boot插件兼容的问题。之前我给出的方案是升级Gradle,但用户可能有能升级的原因,比如项目其他依赖的限制,或者公司政策允许升级。这时候需要找替代方案。 首先,我需要确认用户的问题核心:当前Gradle版本4.10.3太旧,而Spring Boot插件需要更高的Gradle版本。用户想升级Gradle,那可能需要降低Spring Boot插件的版本,或者找到兼容旧Gradle的Spring Boot版本。 接下来,我需要回忆一下Spring Boot和Gradle的版本对应关系。之前的回复里提到过Spring Boot 2.7.x需要Gradle 6.8到7.x,而更早的Spring Boot版本可能支持更旧的Gradle。比如Spring Boot 2.4.x可能支持Gradle 6.x,但用户现在用的是4.10.3,可能更老。可能需要找更旧的Spring Boot版本。 另外,检查是否有其他插件或配置导致问题,比如是否必须使用Spring Boot插件,或者是否有其他方式绕过。比如使用Spring Boot的Gradle插件,手动配置依赖和任务,但这可能会比较复杂,增加用户的工作量。 还需要考虑用户可能的项目限制,比如他们可能因为某些依赖只能使用旧版本的Spring Boot,或者他们无法升级Gradle因为其他插件兼容。这时候需要平衡版本之间的兼容性。 另外,可能存在的解决方案是使用兼容层或调整构建脚本中的插件版本,或者使用旧版的Spring Boot插件,但需要确保该插件确实支持Gradle 4.10.3。可能需要查阅Spring Boot的官方文档或发布说明,找到支持旧Gradle的版本。 例如,Spring Boot 2.3.x可能支持Gradle 5.x或6.x,但Gradle 4.10.3可能还是太旧。可能需要更老的Spring Boot版本,比如2.1.x或更早,这时候需要确认这些版本是否还在维护,是否有安全风险,以及是否满足用户的项目需求。 同时,用户可能需要调整其他依赖的版本,比如Spring框架的版本,以匹配旧版的Spring Boot。这可能会带来连锁反应,需要处理依赖冲突。 如果实在找到兼容的Spring Boot版本,可能需要考虑其他替代方案,比如使用Maven代替Gradle,但用户可能愿意改变构建工具。 另外,可以建议用户使用Gradle的Wrapper升级到指定版本,但用户明确想更改版本,所以这个方案可行。 总结可能的解决方案:降低Spring Boot插件版本到兼容Gradle 4.10.3的旧版,并调整相关依赖,或者调整构建脚本使用Spring Boot插件,手动配置。 现在需要验证Spring Boot版本和Gradle 4.10.3的兼容性。例如,Spring Boot 2.0.x可能支持Gradle 4.x。查阅Spring Boot官方文档,发现Spring Boot 2.0.x要求Gradle 4.x,所以这可能是一个可行的方案。用户需要将Spring Boot版本降到2.0.9.RELEASE或类似,同时调整其他依赖版本。 但需要注意,Spring Boot 2.0.x已经停止维护,可能存在安全漏洞或缺少功能,需要用户评估风险。此外,Java版本也需要兼容,Spring Boot 2.0.x需要Java 8或9,而用户可能使用的是较新的Java版本,需要降级Java或者调整。 另外,构建脚本中的插件应用方式可能同,比如旧版Spring Boot可能需要使用apply plugin的方式而是plugins块,或者需要调整依赖管理配置。 此外,可能还需要调整其他插件版本,比如依赖管理插件或其他的Gradle插件,以确保兼容性。 因此,解决方案的步骤可能是:降低Spring Boot插件版本到2.0.x,调整构建脚本中的插件声明方式,确保其他依赖兼容,处理可能的Java版本问题,并测试构建是否成功。 同时,提醒用户旧版可能的风险,并建议长期考虑升级Gradle,但在短期内提供临时解决方案。</think>$\textcolor{blue}{在升级Gradle版本的情况下,需通过降级Spring Boot插件实现兼容。以下是具体操作步骤:}$ --- ### $\textcolor{orange}{1. 匹配历史版本组合}$ - **当前环境限制** Gradle 4.10.3 (发布于2018年) Spring Boot要求的最低Gradle版本为5.6.x(对应Spring Boot 2.1.x) - **兼容方案选择** | Spring Boot版本 | 支持Gradle版本 | Java要求 | |----------------|----------------|----------| | 2.0.9.RELEASE | 4.x | 8 | | 1.5.x | 3.x-4.x | 7-8 | --- ### $\textcolor{orange}{2. 修改构建配置}$ 在`build.gradle`中**强制使用旧版Spring Boot**: ```groovy // 替换原Spring Boot插件声明 buildscript { repositories { mavenCentral() } dependencies { classpath("org.springframework.boot:spring-boot-gradle-plugin:2.0.9.RELEASE") } } apply plugin: 'org.springframework.boot' // 旧版需用apply方式 apply plugin: 'io.spring.dependency-management' // 依赖管理插件 // 指定Java版本兼容性 sourceCompatibility = 1.8 targetCompatibility = 1.8 ``` --- ### $\textcolor{orange}{3. 依赖版本降级}$ 同步调整其他相关依赖版本(需与Spring Boot 2.0.x兼容): ```groovy dependencies { implementation 'org.springframework.boot:spring-boot-starter-web:2.0.9.RELEASE' testImplementation 'org.springframework.boot:spring-boot-starter-test:2.0.9.RELEASE' } ``` --- ### $\textcolor{orange}{4. 规避插件API冲突}$ 若出现`Could not find method implementation()`等错误,需**启用旧版插件语法**: ```groovy // 在build.gradle顶部添加以下配置 plugins { id 'java' id 'maven' // 替代maven-publish插件 } // 用compile替换implementation(Gradle4.x兼容语法) dependencies { compile 'org.springframework:spring-core:5.0.19.RELEASE' } ``` --- ### $\textcolor{orange}{5. 执行构建验证}$ ```bash # 清理旧构建并重新生成 ./gradlew clean assemble # 若报错"无法解析依赖",尝试添加阿里云镜像 repositories { maven { url 'https://maven.aliyun.com/repository/public' } mavenCentral() } ``` --- ### $\textcolor{red}{⚠️ 重要警告}$ 此方案为**临时应急措施**,存在以下风险: 1. **安全漏洞**:Spring Boot 2.0.x已停止维护 2. **功能缺失**:支持WebFlux、Actuator高级特性等 3. **生态断裂**:无法使用Spring Cloud 2020+版本 $\textcolor{green}{✅ 建议后续操作}$ 完成紧急修复后,应制定迁移计划: ```mermaid graph LR A[Gradle4.10.3] -->|第一步| B[升级到Gradle5.x] B -->|第二步| C[迁移到Spring Boot2.4.x] C -->|最终目标| D[Gradle7.x + Spring Boot3.x] ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值