technical-roadmaps

技术路线图

借助 1 位产品负责人提供的框架和见解，帮助用户制定有效的技术路线图。

如何提供帮助

用户寻求技术路线图方面的帮助时：

1. 了解背景——询问他们当前的技术状况、团队规模和业务限制
2. 确保策略有文档记录——没有记录下来的策略就无法调试，也无法让大家达成共识
3. 应用 Rumelt 框架——按诊断（问题是什么）、指导方针（决策原则）和行动（要做什么）来构建策略
4. 优先选择稳妥的策略——帮助他们抵制在现有工具已足够时仍引入新工具的冲动

核心原则

把策略写下来

Will Larson：“策略的首要原则是，写下来才能改进。如果没有记录下来，就很难判断某位产品经理是不够优秀，还是在尝试应用自己误解了的策略。”书面策略提供了可供评议和改进的基准。

稳妥的策略往往更有效

Will Larson：“一个常见且非常有效、但很无聊的策略是：只使用我们现有的工具。工程师总想引入新的编程语言、新的数据库、新的云服务商。对几乎所有公司来说，一个非常好的策略就是使用我们已有的标准工具集。”将工程精力集中在对业务有价值的问题上，而不是追求技术新颖性。

使用 Rumelt 框架

使用 Richard Rumelt 的框架构建技术策略：诊断（核心挑战是什么？）、指导方针（哪些原则将指导决策？）和行动（具体要做什么？）。

建立标准工具集

列出获准使用的工具、语言和平台。这可以限制技术蔓延，让团队专注于解决核心产品问题，而不是重复造基础设施的轮子。

帮助用户思考的问题

• “这份技术策略有记录在任何人都能查阅的地方吗？”
• “你要解决的核心技术挑战是什么（诊断）？”
• “哪些原则将指导你的技术决策（指导方针）？”
• “你引入新工具是因为确实需要，还是因为它们很有意思？”
• “你们获准使用的‘标准工具集’包括什么？”
• “这份技术路线图如何与业务成果相关联？”

应指出的常见错误

• 策略未成文——只存在于某人脑海中的策略无法调试，也无法让大家达成共识
• 工具泛滥——现有技术已足够时仍引入新技术，会增加维护负担
• 与业务价值脱节——与产品或业务成果无关的技术路线图缺乏合理依据
• 只有诊断，没有行动——好的策略需要具体行动，而不只是分析问题
• 缺少指导方针——没有原则，每项技术决策都会变成从头开始的辩论

深入了解

关于 1 位嘉宾的全部 2 条见解，请参阅 references/guest-insights.md

相关技能

• 管理技术债务
• 平台策略
• 工程文化
• 路线图优先级排序