18 | 组织管理：如何突破团队效率提升的三大关？
该思维导图由 AI 生成，仅供参考
1. 选择正确的事情
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文强调了提高团队效率的关键议题，突出了正确的决策和技术方案对团队成功的重要性。作者通过云计算团队的项目决策经验，强调了专注于最大化交付业务价值的决策原则，而非盲目追求技术先进性。此外，文章还强调了组织内部冲突管理的重要性，以及技术经理需要具备的魄力和能力来纠正错误决策。另外，文章还分享了突破关键瓶颈的重要性，以及如何找到关键瓶颈的方法。通过具体案例和思考，为读者提供了关于提高团队效率的宝贵经验和建议。文章内容丰富，涵盖了技术决策、团队管理和关键瓶颈突破等方面，对于技术团队的领导者和从业人员具有重要的参考价值。文章强调了正确决策和技术方案的重要性，以及管理者需要具备的魄力和能力来纠正错误决策。同时，还分享了突破关键瓶颈的重要性和如何找到关键瓶颈的方法。这些内容为技术团队的领导者和从业人员提供了宝贵的经验和建议。
《技术管理案例课》，新⼈⾸单¥59
全部留言(8)
- 最新
- 精选
Weehua问题2，授权不等于完全放手不管，对于一些简单的项目，可以放手不管，只有给我结果就行。对于核心重要项目，要了解整体架构设计和关键节点的监督检查！ 如果技术方案和我自己想的不一样，我会提出自己的建议，但是会把决定权交给经理，他决策，他负责。 非常赞同文章的观点，我们也要让经理去失败，锻炼学习，然后复盘沟通。作为二线经理，培养好一线经理太重要了，人对了，事情早晚都没问题！如果人不对，事情对也是暂时的。但我发展很多总监怕失败，就会自己上去盯，手下得不到成长，自己会很累的，也是瓶颈！作者回复: “人对了，事情早晚都没问题，如果人不对，事情对也是暂时的” — 我也学到了。
2020-10-2227- Weehua问题1的答案就是本节课说的第一点：选择正确的事情。一定要找到核心的问题，解决这个核心问题能最大化交付业务价值。这个现象普遍存在，做一件事的目标和价值没有搞懂就去做了。工作上有一个原则：默认什么需求都不做，直到搞清楚这件事的目标和价值再去做。 今天再次阅读这篇文章，感受颇深，回顾这2年多的工作，也是感觉做的很多，很辛苦，但非常有价值的事情也就2-3件。最大的问题在于不够聚焦，什么都想要，什么都没做到极致。还是太过关注眼前的事情，组织战略没做好，有舍才有得。
作者回复: 我自己其实也是不够聚焦，没有能够形成积累效应。两周前跟一个老同事一起吃饭，他说了一个词我颇受感触，这个词叫做：“战略耐心” 舍得，说起来容易做起来不易，舍比得难。
2020-11-236 
Geek_积木团队效率的提升，除了以上三点，我觉得还要找到效率的瓶颈，不能单纯的为了提升指标而提升，度量指标要反映效能瓶颈，然后才是流程优化，指标再反馈作者回复: 积木 谢谢你的留言，我觉得你说的很好。现在的我会问自己两个问题： 我现在的解决方案（很多时候是架构设计）是聪明的解决方案吗？是不是有更优方案（不要轻易停止搜索） 我做的事情本身对业务的价值和因为我当前做了这件事而不能做另外一件事所造成的机会成本。
2021-09-1633
Trapped问题1, 公司里说要提升效率，于是提出了测试代码覆盖率，CD 覆盖率，手动重复劳动自动化率等指标并要求各部门执行。 这个看起来像自上而下的一刀切的KPI操作，回到我们文中的观点，我们投入之前要明确需要解决的问题。首先我会评估公司的这个指标是否能解决我们团队具体的问题。如果能的话，只要执行就行了。但如果并没有为我们团队解决具体的问题，我会向上提议，我们想要设立更贴合自己团队的OKR，比如为了完成某个业务目标，我们需要做XYZ。 问题2，平衡给予下属的决定权和你作为部门主管经理的控制力的问题。 授权之前尽量给下属充足的上下文，交代清楚项目的缘由，需要交付的里程碑或中期结果，最后需要完成的业务指标，或者需要解决的核心问题。在前期和下属认知达成一致，而且授权并责任到人，明确奖励，作为经理表明全力支持协助的态度。 项目启动前期，相对频繁的同步来确保项目朝着合理的方向发展，如果下属的技术决定和预期不一样，及时的进行深入了解，不过如果项目之前彼此认知达成一致的话，技术决定的偏差应该不难解决，只要回到我们最初达成的问题来评估技术方案即可。作者回复: Trapped 关于第一个问题，我会尝试用第一性原理的，我们公司目前很强调开发效率，但是我并不认同基础架构部门搞一个下一代的CD pipeline 的基础架构是解决问题的关键，具体来说我们现在的2021年第一季度就是要交付基于Tekton 的CD 方案，而我并不认为这是关键，各个业务部门真的是因为没有一个CD pipeline 而使得开发效率（这里主要指测试效率）不高吗？我自己有一些假设，比如做性能测试，做失效性测试不方便的根本原因是缺乏测试的框架代码和模拟环境效率太低。毛主席说没有调查就没有发言权，所以我在给一个叫陆凯的读者的回复中说我2021 年要仔细去看一下我们部门的一个小组的开发效率问题，然后我再回复他。 关于第二个问题，我想我们两个人做一个小作业的尝试，你能不能先去看一下《道德经》里面“治大国如烹小鲜”那一段，随便看一下历史上各个时代的人对这一句话的注解，然后你结合你的理解再回复一下这个题目，好吗？
2021-02-102
陆凯作为部门测试leader，对这类问题深有感触。经历过多次组织提效定自动化率目标，早期作为一名测试工程师拿着目标埋头苦干，但结果总是不理想团队努力了但是得不到认可。升上管理岗位后自己思考了很久，发现提升自动化测试覆盖率等手段其实并不能提升效率，实现维护自动化用例其实投入成本很高，投入产出比很低。深入细节去看，日常影响效率的可能仅仅是团队沟通问题、质量管理问题等。所以在自己在之后的工作中碰到此类指标都会去思考和分析组织内部的问题和具体如何化解，把细节挖出来并做好向上沟通，将大目标一层层转换成一线员工的具体工作。作者回复: 你负责测试的模块是后端模块还是权限模块，逻辑变动非常频繁吗？我想理解一下为什么你觉得提升自动化测试覆盖率ROI 很低。 我一直觉得测试用例覆盖率高对于回归测试是很有帮助的。
2020-10-2041
BertGeek1. 分析目前影响效率的关键问题点 部门工作效率、沟通成本、资源及痛点 2. 收益回报率考虑，从更解决核心问题点出发，团队协助，调集核心人员。 攻克技术难关 带动团队更快、更好的理解项目 3. 可以适当放权，但不是缺乏监管和指导作者回复: BertGeek 我想问一下，你准备怎么解决部门工作效率的问题，怎么解决沟通成本的问题。这两个问题我现在也在处理，需要先提升自己的认知。很多的事情我们要向内求而不是向外求。最近几个月我反思了很多，得出的结论就是问题在我，不知道你会不会认可。如果需要，你可以回贴，把你说的部门效率和沟通成本的事情展开说一下。 关于从核心问题出发这一点问我高度认同，但是记住核心问题往往都不容易解决，我们坚持做对并且难的事情。
2021-07-06
拖鞋比学技术难多了，一个我也答不出来，甚至思路都没有作者回复: 不要轻易放弃，可以把整个专栏都看完以后再回来看这道题。特别是技术决策那三篇文章。
2020-10-192
可怜大灰狼我个人觉得还是要积极看待。这和职级晋升很像，虽然有时候觉得晋升规则复杂且流程不一定公平，起码是符合大多数人利益的。公司为提高效率提出各种指标要求各部门执行，虽然不一定符合每个部门每个项目组，起码也是符合大多数的情况作者回复: 我其实对这些指标持保留意见的，我觉得负责该效率的部门应该把自己最优秀的人派到一线去，去寻找那些关键瓶颈。一定要深入到客户中去。
2020-09-302