expectation-alignment

# 期望对齐指南 用于在团队成员、利益相关者和领导层之间设定、沟通和管理期望的框架。 ## 为什么期望会产生偏差 软件团队中期望偏差的常见原因： | 原因 | 示例 | | --- | --- | | **隐含假设** | “我以为我们会用现有的 API” vs “我以为我们要重写一个” | | **定义不同** | 对你来说“完成”意味着代码写完，但对他们来说意味着已部署 | | **信息缺口** | 你知道某个依赖项，但他们不知道 | | **进度乐观** | 在压力下给出的估算，未考虑现实情况 | | **范围蔓延** | 小的改动堆积成巨大的差异 | | **沟通缺口** | 更新未共享，变更未通知 | ## 期望对齐框架 ### 1. 明确定义成功 永远不要假设双方已对齐。请明确成功标准： | 模糊描述 | 明确描述 | | --- | --- | | “让它变快” | “在 3G 网络下页面加载时间低于 2 秒” | | “高质量” | “首月零 P1 级 Bug；测试覆盖率 80%” | | “很快” | “在冲刺结束前（周五下午 5 点）” | | “用户友好” | “新用户可以在 3 分钟内完成结账” | ### 2. 暴露假设 在开始工作前，先浮现隐藏的假设： **需要询问的问题：** - “关于 [时间线/资源/范围]，你有什么假设？” - “什么因素会让这件事比预期的更难？” - “最坏的情况是什么？” - “我们假设哪些依赖项是可用的？” - “这件事的‘完成’定义是什么？” ### 3. 文档化与共享 没有写下来的期望等于不存在： - 将验收标准放入工单中 - 在口头协议后发送跟进邮件 - 当情况发生变化时更新文档 - 公开共享（不要只发私信） ### 4. 定期检查对齐情况 不要等到交付时才发现偏差： - 每日站会尽早发现阻塞点 - 冲刺中期检查以捕捉范围蔓延 - 在“完成”前演示进度以验证方向 - 定期的利益相关者更新可防止意外 ## 场景：不切实际的截止日期 ### 识别信号 - 未经工程团队输入就设定了时间线 - 估算值远低于过去类似的工作 - 没有为未知因素留出缓冲时间 - 假设依赖项没有风险 - “我们只需要……”（使用淡化语言） ### 应对框架 **1. 认可目标：** > “我理解在 [业务原因] 之前完成这个日期很重要。” **2. 提供数据：** > “根据过去类似的工作，这通常需要 [X]。”