这份文档总结了我们前面讨论出来的团队沟通技巧，适用于 Engineering Lead / Tech Lead 在面对 Dev、PM、需求变更、deadline、PR 协作、质量风险和团队 ownership 时的沟通。 核心目标不是“控制所有事情”，而是建立清晰边界、减少混乱、保护团队交付质量，并让团队逐渐形成可持续的工作方式。 --- ## 1. 总体沟通原则 ### 1.1 对人柔，对标准硬 好的团队管理不是一直强硬，也不是一直温和，而是： ```text 对人柔，对标准硬。 对情绪柔，对边界硬。 对讨论开放，对决定执行。 ``` 这意味着： - 对人的态度要尊重 - 对质量标准要坚定 - 对问题要直接指出 - 对解决方式可以保持开放 - 对已经对齐的决定要推动执行 ### 1.2 不把问题人格化 沟通时尽量避免说： ```text 你这样做不对。 你总是绕过流程。 你给 Dev 太多压力。 你开太多 PR。 ``` 更好的方式是描述行为和影响： ```text 现在的沟通方式让 Dev 收到多个方向的指令，导致他们不确定优先级。 这个 PR chain 让 review 和 merge 变得更困难。 Deadline 直接给到 individual developer，会让压力被个人吸收，而不是通过 scope 和 trade-off 管理。 ``` ### 1.3 用系统问题代替个人指责 很多团队问题不是某个人“不好”，而是系统缺少规则： - 没有 intake process - 没有 priority boundary - 没有 Definition of Ready - 没有 PR working agreement - 没有 PM / Engineering communication model - 没有 shared ownership 机制 沟通时要把重点从“谁错了”转成“我们需要什么机制”。 --- ## 2. 强硬和柔和的判断标准 ### 2.1 什么时候要强硬 以下情况需要坚定： 1. 产品质量和系统稳定性被牺牲 2. Deadline 压力直接压到 individual developer 3. PM 或其他角色绕过 engineering lead 直接改 priority / scope 4. 新需求不断进入 sprint，但没有移出旧需求 5. Dev 持续制造 long PR chain，导致 review 和协作困难 6. 团队长期各干各的，形成知识孤岛 7. 重复出现同一个问题，但没有改变行为 8. 团队在忙很多事情，但真正完成很少 强硬不是发脾气，而是清楚表达边界： ```text I understand the urgency, but I am not comfortable shipping this without proper testing and review. We can discuss reducing scope, but we should not silently reduce quality. ``` ```text We can take this new request, but we need to explicitly decide what moves out of the current plan. The team capacity is not unlimited. ``` ```text Direct communication is fine for clarification and context. But priority changes, scope changes, and deadline commitments need to be aligned through Product and Engineering first. ``` ### 2.2 什么时候要柔一点 以下情况要先理解、支持和 coaching： 1. Dev 第一次犯错 2. 问题来自经验不足，而不是态度问题 3. 技术方案还在探索阶段 4. 团队压力已经很大 5. 有人提出不同意见 6. 新流程需要争取 buy-in 7. 任务本身比预期复杂 柔和不是放弃标准，而是先理解上下文： ```text I noticed this task took longer than expected. I would like to understand what made it difficult. Was the requirement unclear, was the technical part more complex than expected, or was there a dependency we missed? ``` ```text I do not want to decide too early. Let us compare the options and trade-offs first, then we can choose a direction. ``` ### 2.3 一个简单判断模型 ```text High impact + high risk + repeated pattern -> Strong High impact + one-time mistake -> Firm but calm Low impact + learning situation -> Soft Unclear context -> Ask first Values / quality / ownership issue -> Strong Technical preference difference -> Soft, discuss trade-offs Urgent business need -> Calm but structured Personal emotion / stress -> Soft first, then clarify expectation ``` --- ## 3. 强硬沟通的结构 强硬沟通不要靠情绪，要靠结构。 使用四步： ```text 1. State the observation 2. Explain the impact 3. Set the expectation 4. Define the next step ``` 示例： ```text I noticed this request was added directly to a developer's workload during the sprint. The impact is that our current sprint scope becomes unclear, and the developer is not sure whether to continue the planned work or switch priority. Going forward, any new request that changes sprint priority needs to be aligned between Product and Engineering first. For this request, let us decide today whether it replaces one of the current sprint items or goes into the backlog. ``` --- ## 4. 柔和沟通的结构 柔和沟通也不能模糊。可以使用四步： ```text 1. Acknowledge 2. Ask 3. Support 4. Align expectation ``` 示例： ```text I understand this task turned out to be more complex than expected. Can you walk me through what made it difficult? Let us see if we can reduce scope, pair on the risky part, or split the remaining work. Going forward, I would like us to surface this type of risk earlier so we can adjust the plan sooner. ``` --- ## 5. 与 Dev 沟通的技巧 ### 5.1 不要只强调个人任务，要强调 team ownership 不要让团队长期处于： ```text Dev A 做自己的任务 Dev B 做自己的任务 Dev C 做自己的任务 大家互相不知道对方在做什么 ``` 要传达： ```text We need clear ownership, but not isolated ownership. ``` 可以这样说： ```text I do not expect everyone to implement every task. But I do expect the team to have shared ownership of the product and the codebase. That means we should understand important changes, participate in design discussions, review each other's work, and avoid creating areas that only one person understands. ``` ### 5.2 用 Primary Owner + Secondary Owner 重要任务不需要所有人都写代码，但需要至少两个人理解。 ```text Primary owner: Responsible for implementation and driving progress. Secondary owner: Understands the context, participates in design/review, and can help if needed. ``` 好处： - 减少知识孤岛 - 提高 review 质量 - 降低单点风险 - 方便其他人接手 ### 5.3 大任务开始前做 Technical Walkthrough 大任务不要直接开工，先做 30 分钟 walkthrough： ```text 1. What problem are we solving? 2. Which areas are affected? 3. What are the technical risks? 4. How do we split the work? 5. What PRs are expected? 6. Who needs to review which part? 7. What should be tested carefully? ``` 可以这样说： ```text Before we start this larger task, let us do a short technical walkthrough so the team understands the scope, risks, and how we plan to split the work. ``` ### 5.4 让 Dev 不要私下承诺 deadline 如果 Dev 直接收到 PM 或其他人的 deadline pressure，可以这样回应： ```text Thanks for the context. Let me align with the engineering lead so we can confirm the priority, scope, and timeline. ``` 你可以告诉团队： ```text If you receive a deadline-related request directly, please do not feel that you need to personally commit on the spot. Deadlines and trade-offs should be managed at the team level, not carried silently by one developer. ``` ### 5.5 鼓励早暴露风险 要让 Dev 明白：ownership 不是默默扛压力，而是尽早暴露风险。 ```text Ownership means raising risks early, not silently carrying pressure. ``` --- ## 6. 与 PM 沟通的技巧 ### 6.1 不要说“你不能直接找 Dev” 这会让 PM 感觉你在争控制权。 更好的表达是： ```text Direct communication is good. Conflicting direction is the problem. ``` 也可以说： ```text I am not trying to block direct communication. I want to separate clarification from direction-setting. ``` ### 6.2 区分 Clarification 和 Direction-setting PM 可以直接和 Dev 沟通： ```text - Product context - User problem - Customer feedback - Acceptance criteria - Requirement clarification - User flow clarification ``` 但这些事情需要 PM 和 Engineering Lead 先对齐： ```text - Priority change - Scope change - Deadline commitment - Task ownership change - Delivery sequencing - Technical trade-off - Sprint commitment change ``` 可以这样对 PM 说： ```text Product clarification can happen directly between PM and developers. Direction-setting should be aligned between PM and Engineering first. Then we communicate the decision to the team together or through one agreed channel. ``` ### 6.3 传递 urgency 可以，但 pressure 要被管理 核心句： ```text We should communicate urgency, but manage pressure. ``` 对 PM 可以说： ```text I understand that deadlines are important, and I fully agree that the team needs to be aware of business priorities and delivery expectations. The concern I have is when deadline pressure is communicated directly to individual developers without us first aligning on scope, capacity, technical risk, and trade-offs. ``` ### 6.4 如果 deadline 是固定的，就必须讨论 scope ```text If the deadline is fixed, then scope, quality, or resources need to be discussed. We cannot treat time, scope, and quality as all fixed and then push the pressure directly onto developers. If the date cannot move, we need to decide together what can change. ``` 关键原则： ```text Time fixed? Then scope or resources must move. Scope fixed? Then time or resources must move. Quality should not silently move. ``` ### 6.5 让 PM 看到“匆忙上马”的成本 可以说： ```text When we start work too quickly and compress design, testing, and review, we are not saving time. We are moving the cost to later. That cost comes back as bugs, support issues, rework, production instability, and slower future development. ``` --- ## 7. 需求和客户请求的沟通技巧 ### 7.1 客户需求是 input，不是自动进入开发 核心句： ```text Customer requests are valuable input, but they should not automatically become development work. ``` 每个客户需求进入开发前，应先问： ```text 1. What problem are we solving? 2. Is this one customer's request or a broader product need? 3. What is the business value? 4. How urgent is it? 5. What is the minimum scope? 6. What can be moved to later? 7. What is the technical risk? 8. What testing or rollout plan is needed? 9. If this enters the current sprint, what moves out? ``` ### 7.2 新需求进入 sprint，必须移出旧需求 核心句： ```text If new work comes in, something else must move out. ``` 更完整的说法： ```text If we add something new into the sprint, we need to explicitly decide what moves out. Otherwise we are pretending capacity is unlimited, and the hidden cost will show up as bugs, stress, delays, or lower quality. ``` ### 7.3 Urgent 不等于 unmanaged ```text Urgent should not mean unmanaged. ``` 紧急需求也需要： ```text - Clear owner - Clear scope - Explicit trade-off - Risk assessment - Communication plan - What current work will be delayed ``` ### 7.4 建立 Definition of Ready 任务进入开发前，至少要明确： ```text 1. User problem 2. Acceptance criteria 3. Scope 4. Non-goals 5. Priority 6. Dependencies 7. Technical risk 8. Testing expectation 9. Rollout plan if needed 10. Engineering readiness ``` 可以对 PM 说： ```text I suggest we introduce a Definition of Ready. This does not need to be heavy, but before a task enters development, we should agree on the problem, scope, acceptance criteria, priority, technical risk, and testing expectations. ``` --- ## 8. PR 和 Code Review 沟通技巧 ### 8.1 不要批评“你开太多 PR” 更好的表达是： ```text Your speed and ownership are valuable. The issue is that the current PR structure makes it harder for the team to review, merge, and participate. ``` ### 8.2 强调 team throughput，而不是 individual speed 核心句： ```text We optimize for team delivery, not only individual speed. ``` 或者： ```text Local speed should not reduce team throughput. ``` ### 8.3 Stacked PR 可以有，但要限制深度 规则： ```text - Keep stacked PR chains short, ideally no more than 2-3 PRs - Clearly document the review order - Explain which PRs are blockers - Avoid long chains where many PRs depend on one person's branch ``` ### 8.4 PR 要 small, focused, independently reviewable 好 PR 应该： ```text - Have a clear purpose - Have a limited scope - Avoid mixing refactoring, formatting, and business logic - Include testing notes - Explain dependencies - Be reviewable without needing too much hidden context ``` ### 8.5 快的人要成为 team enabler 可以对 fast engineer 说： ```text I do not want you to slow down. What I would like is for us to use your speed in a way that helps the whole team move faster. For larger tasks, I would like us to align earlier on the PR plan: which part can be merged as a contract or skeleton first, which PRs need to be stacked, what the review order is, and which parts other engineers can pick up. ``` --- ## 9. 质量和稳定性的沟通技巧 ### 9.1 可以砍 scope，但不能默默砍质量 核心句： ```text We can reduce scope, but we do not silently reduce quality. ``` 质量包括： ```text - Testing - Code review - Monitoring/logging - Rollout plan - Error handling - Security considerations - Regression risk ``` ### 9.2 质量问题要转化成可见成本 对 PM 或 management 可以说： ```text When we rush work without enough design, testing, and review, we are not removing cost. We are deferring it. It comes back as bugs, support issues, rework, instability, and slower future delivery. ``` ### 9.3 建立 Definition of Done 任务完成不只是代码写完： ```text 1. Code is implemented 2. Code review is completed 3. Tests are added or updated 4. Acceptance criteria are verified 5. No critical bugs are known 6. Monitoring/logging is considered if relevant 7. Rollout plan is ready if needed 8. Documentation is updated if needed 9. Product/QA has validated the behavior if required ``` --- ## 10. 团队会议沟通技巧 ### 10.1 开场不要责备 推荐开场： ```text I want to use this meeting to align on how we work together as an engineering team. This is not about blaming anyone. The goal is to make our delivery more stable, more predictable, and easier for the whole team to support. ``` ### 10.2 描述观察到的模式，而不是点名 ```text Recently, I have noticed a few patterns: some work is too isolated, some PR chains are difficult to review, and some requests enter development before scope, priority, and risks are clear. ``` ### 10.3 先讲影响，再讲规则 ```text The impact is that we create knowledge silos, review becomes harder, delivery becomes less predictable, and quality risk increases. So I would like us to try a few working agreements. ``` ### 10.4 以试行方式降低阻力 ```text Let us try this for a couple of weeks and review it in retro. If it does not help, we adjust. ``` --- ## 11. 与 PM 开会的沟通结构 ### 11.1 推荐结构 ```text 1. 先确认共同目标 2. 描述当前模式 3. 说明对工程团队的影响 4. 强调不是要阻止直接沟通 5. 区分 clarification 和 direction-setting 6. 提出 intake / priority / deadline agreement 7. 明确 shared ownership 8. 约定后续沟通方式 ``` ### 11.2 示例话术 ```text I think we both want the same outcome: respond to customers, deliver value quickly, and keep the product moving. At the same time, I have noticed that some new ideas or customer requests move into development very quickly, before we have fully clarified the problem, scope, priority, technical impact, and testing expectations. The issue is not direct communication. The issue is conflicting direction and unmanaged pressure. Product clarification can happen directly between PM and developers. But priority changes, scope changes, deadline commitments, task ownership changes, and delivery sequencing should be aligned between PM and Engineering first. ``` --- ## 12. 最常用的关键句 ### 对 Dev ```text We need clear ownership, but not isolated ownership. ``` ```text We optimize for team delivery, not only individual speed. ``` ```text If you receive a new request or deadline directly, do not commit on the spot. Bring it back so we can align on priority, scope, and timeline. ``` ```text Quality should not be silently sacrificed. ``` ```text Ownership means raising risks early, not silently carrying pressure. ``` ### 对 PM ```text Direct communication is good. Conflicting direction is the problem. ``` ```text We should communicate urgency, but manage pressure. ``` ```text If new work comes in, something else must move out. ``` ```text Customer requests are valuable input, but they should not automatically become development work. ``` ```text Urgent should not mean unmanaged. ``` ```text I am not asking us to avoid deadlines. I am asking us to avoid unmanaged pressure. ``` ### 对团队 ```text Stop starting, start finishing. ``` ```text Fast reaction is good, but uncontrolled reaction creates instability. ``` ```text If everything is urgent, nothing is truly prioritized. ``` ```text Adding work without removing work is hiding the cost. ``` --- ## 13. 可复用 Team Working Agreements ```text 1. Important tasks should have a primary owner and a secondary owner. 2. Larger tasks should start with a short technical walkthrough. 3. PRs should be small, focused, and easy to review. 4. Stacked PRs are allowed, but should be kept short and have a clear review order. 5. Refactoring, formatting, business logic, migrations, and tests should be separated when possible. 6. If a new request changes priority or scope, align before changing the current work. 7. If new work enters the sprint, something else must move out. 8. Developers should not personally commit to deadlines under pressure. 9. Quality, testing, and review should not be silently sacrificed. 10. No critical module should have only one person who understands it. 11. Raise blockers and risks early. 12. We optimize for team delivery, not only individual speed. ``` --- ## 14. 可复用 Product & Engineering Agreement ```text 1. PM can communicate directly with developers for product context, requirement clarification, user problems, user flows, and acceptance criteria. 2. Priority changes, scope changes, deadline commitments, task ownership changes, and delivery sequencing should be aligned between PM and Engineering Lead before being communicated to developers. 3. Customer requests are valuable input, but they should not automatically become development work. 4. Before a new request enters development, we should clarify problem, value, urgency, scope, acceptance criteria, technical risk, testing expectation, and rollout approach. 5. If new work enters the current sprint, we must explicitly decide what moves out. 6. PM can communicate business urgency, but deadline pressure should not be pushed directly onto individual developers. 7. Developers should not be asked to personally commit to deadlines under pressure. 8. Engineering owns technical feasibility, sequencing, quality, and delivery risk. 9. Product and Engineering jointly own priority, scope trade-offs, timeline decisions, and release readiness. 10. Urgent work can be expedited, but urgent does not mean unmanaged. It still needs clear owner, scope, trade-off, and communication. 11. Product and Engineering should communicate one aligned direction to the team. ``` --- ## 15. 个人 Leadership Mantra ```text Be kind, but do not be vague. Be firm, but do not be aggressive. Listen first, but decide clearly. Protect the team, but hold the team accountable. Move fast, but do not create chaos. ``` 中文理解： ```text 善意但不模糊。 坚定但不攻击。 先听，再清楚决策。 保护团队，也要求团队负责。 可以快，但不能乱。 ``` --- ## 16. 最核心的一句话 如果要把所有沟通技巧压缩成一句话，就是： ```text 我会认真听每个人的意见，但一旦决定下来，我会保护边界、推动执行、要求结果。 ``` 对应英文： ```text I will listen carefully to everyone's input, but once we make a decision, I will protect the boundaries, drive execution, and hold the team accountable for the outcome. ```