需求之坑
需求很少存在于表面上，它们深深地埋藏在层层假定、误解和政治手段的下面。挖掘真实需求的关键在于区分政策与需求。例如，"只有人事部门才能查看员工档案"是政策，而"只有得到授权的用户可以访问员工档案"才是真正的需求。将政策与需求分离，能让系统更灵活地应对政策变化，只需更新元数据而非修改代码。
挖掘需求的实用技巧
使用项目词汇表：创建并维护专用术语的唯一信息源，避免"客户"与"顾客"等术语的混淆。
编写用户故事：用"作为<角色>，我想要<功能>，以便<价值>"的格式描述需求，聚焦用户真实目标。
制作原型验证：通过低保真原型（如纸质界面草图）快速验证需求，避免过早陷入细节。
需求文档的黄金原则
抽象比细节活得更久：投资于"用户可以配置界面主题"而非"按钮背景"。
保持可追溯性：每个需求都应关联到业务目标，便于后期评估变更影响。
动态维护：需求文档应作为活文档，随项目进展持续迭代，而非冻结在启动阶段。
解开不可能解开的谜题
面对"不可能"的需求或技术难题时，关键是区分真正的约束与假想的约束。亚历山大大帝用剑劈开戈尔迪结的故事告诉我们：有时重构问题定义比强行求解更有效。
破解难题的思维框架
质疑基本假设：
"必须支持IE8"是否源于用户真实需求？"性能指标100ms"是否有数据支撑？
寻找替代路径：
无法实现实时同步时，考虑"本地优先+冲突合并"的妥协方案。
渐进式验证：
用"概念验证原型"测试关键技术点，如在决定采用微服务前先验证服务间通信延迟。
案例：当性能遇到瓶颈
某电商平台商品搜索响应时间要求<200ms，但数据量已达亿级。团队通过以下步骤破解：
拆解约束：发现"全量索引"是假想约束，实际80%查询集中在20%热门商品。
分层优化：热门商品用内存索引，长尾商品走分布式搜索。
异步更新：索引更新从同步改为10分钟延迟，通过缓存掩盖不一致。
等你准备好
"过早启动"与"过度分析"同样危险。优秀的开发者能倾听直觉中的"疑虑信号"，在"准备就绪"与"错失良机"间找到平衡。
启动时机的判断信号
绿灯信号：核心技术验证通过、团队对领域模型达成共识、用户故事闭环。
红灯信号：关键依赖未确定（如第三方API未开放）、团队对核心需求仍有分歧。
原型法：化解启动焦虑
当直觉告诉你"还没准备好"时，构建探索式原型而非 production 代码：
范围：聚焦风险最高的模块（如支付流程、复杂算法）。
生命周期：明确标注"原型代码将废弃"，避免后期维护债务。
输出：不仅验证可行性，更要输出《风险缓解方案》《技术选型报告》等决策依据。
规范陷阱
规范是必要的，但过度规范会扼杀创造力。不列颠航空公司曾发布"着陆飞行员职责"备忘录，用200字描述"谁在何时接管操纵权"，反而引发更多混乱。
健康规范的边界
做什么 vs 怎么做：
规范应定义"订单必须包含唯一ID"，而非"用UUID v4生成ID"。
关键路径优先：
核心业务流程（如退款）需严格规范，内部工具可灵活迭代。
保持演进空间：
为规范预留"例外条款"，如"特殊场景需经架构委员会审批"。
文档即代码的实践
版本控制：规范文档与代码一同纳入Git，便于追溯变更历史。
自动化校验：用工具验证规范执行情况，如用ESLint检查代码风格，用Schema验证API文档。
示例驱动：好的规范应包含可执行示例，如Swagger文档直接生成API测试用例。
圆圈与箭头
UML图、甘特图等工具是手段而非目的。盲目依赖形式化方法而忽视实际问题，如同"拿着锤子找钉子"。
方法论选择的三问
它解决什么具体问题？（如Scrum解决迭代交付问题，DDD解决领域建模问题）
团队接受成本如何？ 强行推行XP结对编程可能适得其反。
能否与现有实践融合？ 混合使用Kanban的可视化与Scrum的回顾会。
反脆弱的开发流程
轻量级仪式：每日站会控制在15分钟内，聚焦"阻碍物移除"而非状态汇报。
动态调整：某团队发现Sprint规划会耗时过长，改为"双周大规划+每周微调"。
工具最小化：用物理看板而非昂贵的项目管理软件，降低流程摩擦。
实践总结：项目启动 checklist
项目启动不是发射火箭——不需要所有参数完美归零。真正的注重实效者会：
接受"启动时80%准备度"的现实
建立快速反馈机制（如每日构建、用户内测）
在迭代中持续校准方向
正如书中所言："完美是优秀的敌人"，适时启动并保持调整能力，比追求理论上的"万全准备"更重要。
