团队领导力练习册
本练习册包含情景分析题、案例分析题和方案设计题，共计 18 道。每道题均附参考答案与解析，帮助你检验和提升团队领导力。
一、情景分析题
第 1 题
情景：你刚接手一个前端团队，发现团队氛围沉闷，成员之间交流很少，项目经常延期，代码质量也参差不齐。
问题：作为新负责人，你前三个月会重点做哪些事情？
查看答案与解析
参考答案：
- 诊断现状：分别与每个成员 1:1，了解他们的工作状态、痛点、期望和对团队的看法。
- 梳理项目：了解当前项目进展、技术债、流程问题。
- 建立基础规范：先落地代码规范、分支管理、Code Review 等基础工程实践。
- 小步快跑拿结果：选择 1-2 个能快速见效的问题解决，建立信任。
- 改善沟通机制：建立站会、周会、1:1 等沟通机制，提升信息透明度。
- 识别和培养骨干：找到有潜力的成员，赋予更多责任。
- 关注团队士气：通过认可、团建、技术分享等方式改善氛围。
解析：新负责人上任不宜急于大动干戈，应先诊断、建立信任、小步快跑，再推进系统性改革。
第 2 题
情景：团队里有一位技术能力很强但沟通态度较差的老员工，经常在 Code Review 中让新人感到难堪，导致新人不愿意请教他。
问题：你会如何处理？
查看答案与解析
参考答案：
- 私下沟通：不在公开场合批评，先单独和他沟通，指出具体行为对团队的影响。
- 明确期望：说明 Code Review 的原则是对事不对人，团队需要建设性的反馈。
- 了解原因：可能是他不自知，也可能是他对团队标准有更高期待但表达方式不当。
- 提供支持：如果他不擅长沟通，可以提供沟通技巧培训或导师培训。
- 建立机制：在团队层面明确 Code Review 的文明准则，鼓励提问和讨论。
- 持续观察：如果行为没有改善，需要升级到绩效或纪律处理。
解析：处理这类问题要兼顾团队氛围和人才保留。既要保护新人，也要给老员工改进的机会。
第 3 题
情景：公司要求所有团队降本增效，你的前端团队也被要求减少 20% 的人力预算。
问题：你会如何应对？
查看答案与解析
参考答案：
- 先分析现状：当前团队的人效如何？哪些工作是低价值的重复劳动？哪些岗位是关键岗位？
- 优先自动化和工具化：通过低代码平台、组件库、自动化测试等减少重复人力。
- 优化工作方式：减少无效会议、优化流程、提升交付效率。
- 保护核心能力：不能为了减人而损失关键岗位和核心技术能力。
- 与上级沟通：明确降本的目标和边界，争取合理的过渡期。
- 关注留人：避免优秀成员因恐慌而流失。
解析：降本增效不能简单裁员，而应从效率、自动化、流程优化入手，同时保护团队核心竞争力。
第 4 题
情景：团队中有两位高级工程师对技术选型有严重分歧，一位主张用 React，另一位主张用 Vue，双方各执己见，影响了项目进度。
问题：作为团队负责人，你会如何决策？
查看答案与解析
参考答案：
- 明确决策标准：不是"哪个更好"，而是"哪个更适合当前团队和业务"。
- 列出评估维度：团队熟悉度、生态成熟度、招聘难度、性能、可维护性、长期演进等。
- 收集事实和数据：比如团队现有代码占比、招聘市场情况、社区活跃度等。
- 让双方充分表达：组织一次技术评审会，让双方陈述理由并回答质疑。
- 做决策并解释：作为负责人最终拍板，并清晰说明决策理由。
- 统一执行：决策后全员执行，不允许阳奉阴违。
- 约定复盘机制：运行一段时间后复盘，看是否需要调整。
解析：技术选型决策需要理性框架，而不是无限争论。负责人要敢于拍板，并承担决策责任。
第 5 题
情景：你的一位核心骨干提出离职，理由是"感觉成长空间有限，想去更大的平台"。
问题：你会如何挽留？如果挽留不住，你会做什么？
查看答案与解析
参考答案：
挽留阶段：
- 真诚沟通：了解真实原因，是薪酬、成长、管理还是外部机会。
- 针对性解决：如果是成长空间，可以讨论新的职责、晋升计划或挑战性项目；如果是薪酬，可以申请调整。
- 表达重视：让他知道他对团队很重要，公司愿意为他投入。
- 给予时间：不要逼他立刻决定，给他时间考虑。
如果挽留不住：
- 做好交接：确保知识和项目顺利交接。
- 分析流失原因：是个人原因还是团队系统性问题。
- 加强梯队建设：避免再次单点依赖。
- 稳住团队：及时向团队沟通，避免恐慌。
- 启动招聘：寻找合适的接替者，同时考虑内部提拔。
解析：核心人才流失是管理的警钟。既要尽力挽留，也要从流失中学习，完善团队机制。
二、案例分析题
第 6 题
案例：某前端团队实行 Code Review 已经半年，但效果不佳。大家只是为了完成任务而点 approve，评审意见很少，代码质量问题依然频发。
问题：你认为问题出在哪里？如何改进？
查看答案与解析
参考答案：
问题分析：
- 团队没有真正理解 Code Review 的价值，把它当成负担。
- 缺乏明确的评审标准和 Checklist。
- 评审意见可能引发冲突，大家选择回避。
- 工作量大，没有时间认真评审。
- 缺乏激励机制，评审好坏没有区别。
改进措施：
- 重新宣导价值：通过案例说明 Code Review 如何避免线上故障、促进知识共享。
- 制定评审规范：明确评审内容、响应时间、合并标准。
- 建立安全氛围：强调对事不对人，鼓励提问和讨论。
- 控制 PR 大小：大 PR 难以评审，推动小步提交。
- 榜样示范：负责人和技术骨干带头认真评审。
- 工具辅助：引入自动化检查，减少人工重复劳动。
- 纳入绩效：将评审质量纳入团队考核，表彰优秀评审者。
解析：Code Review 文化需要制度、工具和氛围共同建设，不能只靠一纸规定。
第 7 题
案例：某团队绩效考核时，管理者给所有人打分都偏高，导致优秀员工觉得不公平，平庸员工没有改进动力。
问题：你认为绩效管理中出现了什么问题？应该如何改进？
查看答案与解析
参考答案：
问题分析：
- 绩效标准不清晰，主观性强。
- 管理者不敢区分好坏，避免冲突。
- 缺乏过程管理，只有年终一次评估。
- 绩效结果没有与晋升、薪酬、培养有效挂钩。
改进措施：
- 设定清晰目标：用 OKR 或 KPI 明确每个周期的目标。
- 持续反馈：定期进行 1:1，及时指出问题和认可进步。
- 校准机制：管理者之间进行绩效校准，确保标准一致。
- 强制分布或等级制：适当区分绩效等级，避免人人都是优秀。
- 结果应用：将绩效与晋升、调薪、培训机会挂钩。
- 透明沟通：评估结果要与员工充分沟通，说明依据和改进方向。
解析：绩效管理的核心是公平和激励。没有区分度的绩效，会失去激励作用。
第 8 题
案例：某前端团队的技术分享会变成了形式主义，大家轮流念 PPT，听众昏昏欲睡，分享质量越来越差。
问题：如何让技术分享重新焕发活力？
查看答案与解析
参考答案：
- 明确分享目的：是为了学习、解决问题还是展示成果？根据不同目的设计形式。
- 改变形式：从单向演讲改为工作坊、圆桌讨论、代码走读、案例分析等。
- 主题贴近实际：选择团队当前面临的真实问题或新技术应用场景。
- 提前征集话题：让团队成员投票选择感兴趣的话题。
- 设置分享标准：要求分享者有实际案例、有总结、有可落地建议。
- 建立反馈机制：分享后收集反馈，持续改进。
- 给予认可和激励：将优秀分享纳入绩效或给予奖励。
- 控制频率和时长：避免过度占用时间，保证每次分享质量。
解析：技术分享的生命力在于内容质量和参与感。形式多样化、主题贴近实际、激励机制到位是关键。
第 9 题
案例：某团队两位成员因为工作分配问题产生矛盾，A 认为 B 总是把难做的工作推给自己，B 认为 A 不愿意协作。
问题：作为团队负责人，你会如何调解？
查看答案与解析
参考答案：
- 分别倾听：先单独与 A 和 B 沟通，了解各自视角和诉求。
- 避免站队：不急于判断谁对谁错，先收集完整信息。
- 寻找事实：查看任务分配记录、沟通记录、项目进展情况。
- 共同对话：安排一次三方会议，让双方表达，同时引导他们聚焦问题而非人身攻击。
- 明确分工：重新梳理职责边界，确保任务分配公平透明。
- 建立机制：以后任务分配通过公开工具记录，避免口头约定。
- 跟进关系：后续关注两人合作情况，必要时再次沟通。
解析：团队冲突调解需要公正、耐心和机制建设。目标是解决问题，而不是评判对错。
第 10 题
案例：某团队招聘了一位背景很好的高级工程师，但入职三个月后发现他与团队文化格格不入，经常独来独往，也不愿意参与 Code Review。
问题：你会如何处理？
查看答案与解析
参考答案：
- 了解情况：先与他 1:1，了解他不参与 Code Review 的原因，是态度问题、能力问题还是不适应。
- 明确期望：清楚说明团队的工作方式和 Code Review 的重要性。
- 提供支持：如果是不熟悉流程，安排导师帮助；如果是 workload 问题，调整任务。
- 设定改进期：给出明确的时间和可观察的改进目标。
- 观察变化：在改进期内持续关注。
- 果断决策：如果没有改善，说明他不适合这个团队，需要考虑调整岗位或离职。
解析：招聘不能只看技术能力，文化契合同样重要。发现问题要及时干预，避免对团队造成长期负面影响。
三、方案设计题
第 11 题
题目：请设计一个前端工程师的能力模型和晋升标准，要求覆盖初级到高级。
查看答案与解析
参考答案：
能力模型（五个维度）：
技术能力
- 初级：掌握 HTML/CSS/JS 基础，能完成简单页面。
- 中级：熟悉框架，能独立开发复杂模块。
- 高级：能进行系统设计和性能优化，解决复杂技术问题。
业务理解
- 初级：能理解需求文档。
- 中级：能判断需求合理性，提出改进建议。
- 高级：能从业务目标出发设计技术方案。
工程能力
- 初级：能按规范写代码。
- 中级：能写测试、做 Code Review、参与工程化建设。
- 高级：能主导技术方案、建立工程规范。
团队协作
- 初级：能配合团队完成任务。
- 中级：能指导新人，跨团队沟通。
- 高级：能带领小团队，推动跨团队协作。
影响力
- 初级：完成分配任务。
- 中级：在团队内分享经验。
- 高级：在部门或公司层面产生技术影响力。
晋升标准：
- 在当前级别表现稳定达到预期。
- 在目标级别的多数能力维度上已有实际案例证明。
- 有明确的业务或技术成果。
- 通过晋升评审，包括自评、主管推荐、跨团队评审。
解析：能力模型和晋升标准要清晰、可衡量、可操作，让员工知道努力方向。
第 12 题
题目：某团队计划引入 OKR 进行目标管理，但团队成员担心 OKR 会变成另一种 KPI，增加负担。请设计一个适合前端团队的 OKR 实施方案。
查看答案与解析
参考答案：
实施原则：
- OKR 是目标管理工具，不是考核工具。
- 鼓励挑战性目标，允许未完成。
- 目标要少而精，聚焦重点。
- 全员参与，上下对齐。
实施步骤：
- 培训宣导：让团队理解 OKR 的价值和用法。
- 制定团队 OKR：由负责人根据公司目标制定团队 OKR。
- 个人 OKR 对齐：成员根据团队 OKR 制定个人 OKR。
- 定期 Check-in：每周或双周回顾进展，及时调整。
- 季度复盘：评估完成情况，总结经验，不直接用于绩效考核。
- 持续优化：根据反馈调整 OKR 制定和跟踪方式。
前端团队 OKR 示例：
- O：提升前端交付效率
- KR1：将平均需求交付周期从 10 天缩短到 7 天。
- KR2：组件库覆盖率达到 80%。
- KR3：自动化测试覆盖率达到 60%。
解析：OKR 成功的关键在于与考核脱钩、聚焦重点、持续跟踪。前端团队的 OKR 应兼顾业务价值和工程能力。
第 13 题
题目：请设计一个前端新员工的 Onboarding（入职培养）计划，要求在一个月内帮助新人独立承担开发任务。
查看答案与解析
参考答案：
第 1 周：熟悉环境与基础
- 办理入职、配置环境、了解公司文化和团队规范。
- 阅读技术文档、代码规范、项目 README。
- 完成 1-2 个简单的 bug 修复或小型需求。
- 分配导师，每天答疑。
第 2 周：参与实际开发
- 参与需求评审和技术评审。
- 在导师指导下完成一个中等复杂度的需求。
- 学习 Code Review 流程，提交自己的 PR 并接受评审。
- 了解 CI/CD、测试、发布流程。
第 3 周：增加独立性
- 独立完成一个需求，导师做最终 review。
- 学习前端监控、埋点、性能优化等工程实践。
- 参加团队技术分享，了解团队技术栈全貌。
第 4 周：验收与反馈
- 独立完成一个完整需求并上线。
- 导师和负责人进行阶段性评估。
- 新人反馈 Onboarding 体验，优化计划。
解析：Onboarding 计划要循序渐进，从简单到复杂，同时有明确的导师指导和验收标准。
第 14 题
题目：某团队项目经常出现延期，原因是需求变更频繁、评估不准确、风险识别不足。请设计一套项目管理体系来改善这种情况。
查看答案与解析
参考答案：
1. 需求管理
- 建立需求评审机制，未经评审的需求不进入开发。
- 设定需求冻结点，冻结后变更需审批。
- 需求变更要评估对工期、成本、质量的影响。
2. 评估机制
- 采用三点估算法（最乐观、最可能、最悲观）。
- 复杂任务拆分，避免大估大做。
- 预留 20%-30% 缓冲时间应对不确定性。
3. 风险管理
- 项目启动时识别风险，建立风险清单。
- 定期站会同步风险状态。
- 对高风险项提前准备预案。
4. 进度跟踪
- 使用看板或项目管理工具可视化进度。
- 每周进行项目状态同步。
- 关键里程碑设置检查点。
5. 复盘机制
- 项目结束后进行复盘，总结延期原因和改进措施。
- 将经验教训沉淀为团队知识。
解析：项目管理改善需要制度、流程和工具共同作用，并且要从每次失败中学习。
第 15 题
题目：请设计一个前端团队的技术培训体系，目标是持续提升团队整体技术水平。
查看答案与解析
参考答案：
培训体系架构：
新人培训
- Onboarding 计划
- 导师一对一指导
- 基础技能训练营
常规学习
- 每周技术分享会
- 双周代码走读
- 月度技术读书会
专题深造
- 新技术工作坊
- 性能优化专题
- 安全与合规培训
外部学习
- 技术大会参会
- 在线课程补贴
- 技术认证支持
知识沉淀
- 技术博客写作
- 内部知识库维护
- 开源项目贡献
激励机制：
- 将知识分享纳入绩效考核。
- 设立"最佳分享者""最佳技术文章"等奖项。
- 给予学习时间保障，例如每周固定学习时间。
效果评估：
- 培训后是否有实际项目应用。
- 团队成员技术能力是否有提升。
- 知识库和工具是否有增量。
解析：技术培训体系要常态化、多样化，并与实际工作结合，避免形式主义。
第 16 题
题目：某前端团队有 15 人，分为 3 个小组分别支持不同业务线。请设计这个团队的组织架构和日常运作机制。
查看答案与解析
参考答案：
组织架构：
- 前端负责人 1 人：整体管理、技术方向、跨部门协调。
- 技术组长 3 人：各带一个 4-5 人的业务小组。
- 工程师 11 人：按业务线分配到三个小组。
- 横向设置技术委员会或 SIG（特别兴趣小组）：负责组件库、性能、工程化等横向技术事务。
运作机制：
- 小组内：每日站会、双周迭代计划会、代码评审、项目复盘。
- 跨组协调：每周组长例会，同步各组进展、风险和资源需求。
- 技术决策：技术委员会负责技术选型、规范制定、架构评审。
- 信息共享：团队周报、技术知识库、技术分享会。
- 资源调配：根据业务优先级，负责人可在组间调配人力。
解析：15 人团队需要在业务响应和技术协同之间找到平衡。横向技术委员会可以避免各组重复建设和标准不一。
第 17 题
题目：请设计一个前端团队的绩效评估方案，要求公平、透明、可操作。
查看答案与解析
参考答案：
评估周期：季度评估 + 年度总评。
评估维度：
- 业务结果（30%）：需求交付质量、项目贡献、业务指标改善。
- 技术能力（25%）：代码质量、系统设计、技术创新。
- 团队协作（20%）：Code Review、知识分享、跨团队配合。
- 个人成长（15%）：学习能力、技能提升、承担新挑战。
- 价值观（10%）：是否符合公司文化和团队价值观。
评估流程：
- 员工自评：总结本季度工作成果和成长。
- 主管初评：根据事实和数据打分。
- 校准会议：跨团队校准，确保标准一致。
- 结果沟通：一对一反馈，说明优点和改进点。
- 结果应用：与晋升、调薪、培训挂钩。
公平性保障：
- 目标提前明确，避免临时标准。
- 用具体案例和数据支撑评价。
- 引入多人视角，减少单一主管偏见。
- 允许员工申诉和补充信息。
解析：绩效管理要做到"事前有目标、事中有反馈、事后有依据"。公平透明是赢得团队信任的关键。
第 18 题
题目：某团队希望建立"工程师成长路径"，让成员清楚知道如何晋升。请设计一个从 P4 到 P8 的前端工程师成长路径。
查看答案与解析
参考答案：
P4 中级工程师
- 能独立承担中等复杂度需求。
- 熟悉团队技术栈和开发流程。
- 能进行基础的 Code Review。
- 对业务有基本理解。
P5 高级工程师
- 能独立负责一个模块或项目。
- 能进行技术方案设计。
- 能指导 P3/P4 工程师。
- 能识别和解决性能、稳定性问题。
- 在团队内有一定技术影响力。
P6 资深工程师
- 能负责跨模块或跨团队的复杂项目。
- 能主导技术选型和架构设计。
- 能带领小团队完成目标。
- 能主动发现并推动解决团队技术债。
- 在部门内有影响力。
P7 技术专家
- 负责领域内的技术战略和架构演进。
- 能处理高复杂度、高风险的技术问题。
- 能培养骨干工程师。
- 能推动跨团队技术项目落地。
- 在公司内有技术影响力。
P8 高级专家/架构师
- 参与公司级技术战略制定。
- 引领技术创新和架构升级。
- 建立组织级技术体系和标准。
- 培养专家和 leader。
- 在行业内有影响力。
晋升机制：
- 每年 1-2 次晋升窗口。
- 员工申请 + 主管推荐。
- 晋升委员会评审，基于能力模型和实际案例。
- 结果公开透明，未通过者获得明确反馈。
解析：成长路径要清晰、可感知、有案例支撑。不同级别之间的差异要明显，让员工知道努力方向。
练习总结
通过以上 18 道题，我们希望你能掌握：
- 团队管理要从诊断、信任、小步快跑开始。
- 招聘、培养、绩效、激励是团队建设的四大支柱。
- Code Review 和技术规范需要文化、制度和工具共同建设。
- 知识管理和培训是团队长期竞争力的来源。
- 冲突处理和高效会议体现管理者的软实力。
- 清晰的成长路径是保留人才和激发动力的关键。
领域编号：L02 团队领导力
最后更新：2026-06-18