聊聊领导力与带团队的那些事
傅盛说 “人和人最大的差别是认知”,说的是认知的力量,罗伯特·清崎说”赚不到认知以外的钱”,描述了认知的局限。很明显,好的认知是力量,不好的认知是局限。但是认知又没法量化,所以有时候我们就会发现,很难认清自己,也很难学习别人。
曾经在一次内部会议上,我感慨”如何才能达到老师和老大们的认知高度呢?感觉光凭看书学习,好难啊。” 当时老大给出了回应,说 “关键在于选择”。
确实,如果能坚持选择正确的事情,不避艰难,选择长期价值,不趋小利,选择务实奋斗,不浮躁,进步是必然,只在早晚。
回首 2021 年,文章输出略少。来到 2022,新年新气象,希望给自己立个 flag,争取 Break。
作为今年的开篇,想聊聊工作上的一些认知、看法,谓之自省。
找到企业价值与团队成长的最佳战略落地点是团队 Leader 的核心工作
这应该是笔者近几年关于领导力和带团队方面最深的体悟了,没有之一。
作为团队 Leader,企业价值和团队成长必须两手抓,两手都要硬。产出不了价值,团队就不会有回报,做的事情没有一定的高度,大家个人方面就会成长不足,长期也会缺乏进步。而寻找最佳战略落地点,就是要找到那个团队关键着力点,要既能很好的达成职责和目标,还要能在技术先进上有一定的突破。
这点很重要,值得花精力慎重对待。
回头来看,云原生就是近几年我给团队找的主要战略方向了。抛开成绩不谈,通过这个战略,团队人员技术水平提高很多,且行业优势明显,这一点还是挺让我自豪的。
视人为人,超越伯乐
对于很多技术管理者来讲,这可能是最难的,包括我自己。
人心难测,但人性中最有力量。每个人都有自己的想法和诉求,而如何能团结一群人,发挥 1+1 > 2 的作用,非常考验功力。我们知道,现实中绝大多数问题归根结底是人的问题,但越是如此,领导者越不应该把问题简单定性在人上。因为,没有人是完美的,修人修心才是正途。
但,用人之长容易,培人之短甚难。我以前也有过尝试培人之短,深感不易。这也许就是为什么,很多人更认同“选对人比培养人更重要”的原因吧。
但,无论如此,任何时候都不应该丢失以人为本的心。
组织先行,倡导质量全员建设
自始至终,测试只是质量保障的手段,而不是目的。我们谈质量,实际谈的是结果质量,是产品能不能服务好最终用户,即使是面临突发情况,异常情况。
以终为始,架构设计合不合理,代码实现优不优雅,产品姿势贴不贴切,都会影响最终的服务质量。
质量保障没有银弹,也不会有一劳永逸的解决方案,功夫都在平时。而如果能调动更多的人,心系质量,参与质量建设,不管从企业 ROI 还是技术文化构建上,都有一定的积极意义。
工程效率本质是为提升工程生产力服务的,面向的是全体工程人员,而不是单指 QA
很多时候,工程效率同学从组织分布上会离 QA 较近,这会导致工效同学的目光过于关注测试的一亩三分地,局限性比较大。但是,企业内工程属性更多的其实是研发人员,解决他们的痛点从价值规模上来看才是最大的。
不过,这类人又是最难服务的,有很多”古怪”的爱好。比如,一个不爽,分分钟钟就自己搞个轮子。所以应该如何做呢?
一定要深入到研发群体去,多观察,多交流,深挖痛点。真正把他们当作实际客户,以服务的心态来面对,才容易找到破局点,并形成突破。
很多时候,我个人是不推荐建设专服务于手动测试同学的所谓自动化测试平台的。作为技术人,以代码的形式呈现用例,管理用例,感觉已经足够了。
而保持团队技术密度,倡导技控先于人控,长期角度也会有更多的惊喜。
更多工程效能、测开技术、云原生相关讨论欢迎关注: BigCarlJi
本文文字及图片出自 InfoQ
你也许感兴趣的:
- 【外评】电脑从哪里获取时间?
- 【外评】为什么 Stack Overflow 正在消失?
- Android 全力押注 Rust,Linux 却在原地踏步?谷歌:用 Rust 重写固件太简单了!
- 【外评】哪些开源项目被广泛使用,但仅由少数人维护?
- 【外评】好的重构与不好的重构
- C 语言老将从中作梗,Rust for Linux 项目内讧升级!核心维护者愤然离职:不受尊重、热情被消耗光
- 【外评】代码审查反模式
- 我受够了维护 AI 生成的代码
- 【外评】Linux 桌面市场份额升至 4.45
- 【外评】作为全栈开发人员如何跟上 AI/ML 的发展?
你对本文的反应是: