关于 technology-radar
面向 CTO 和工程领导者的通用技能,涵盖技术组合治理、工程指标、技术债与创新决策。通过决策框架将技术选择与业务目标关联,并按影响程度设置治理。
主要功能
- 01技术雷达与采用策略
- 02自建或采购的总拥有成本分析
- 03按影响程度实施架构治理
- 04DORA、SPACE 与 DevEx 指标
- 05技术债优先级排序
- 06创新流程与生产就绪门槛
适用场景
- 01评估新工具的采用或退役
- 02比较自建与采购方案
- 03选择架构审查和例外处理方式
- 04确定技术债优先级并衡量交付表现
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ magnus919/ agent-skills --skill technology-radar安装后在 Claude Code 中输入/technology-radar确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
README.mdevals/evals.jsonreferences/architecture-governance.mdbuild-vs-buy.mdengineering-metrics.mdsource-index.mdtechnology-radar.md详细介绍
技术雷达
用于制定技术决策、治理架构、衡量工程效能、管理技术债务和运营创新管道的 CTO 方法论。这些框架有助于 CTO 在短期交付速度与长期平台健康之间取得平衡。
不适用场景
- 将企业能力地图、运营模式设计以及当前状态/目标状态路线图交由
enterprise-architecture处理。本技能聚焦于技术组合策略和治理机制;系统级目标设计请使用software-architecture。 - 将单项重大决策的持久记录交由
adr-authoring处理;使用本技能选择治理路径,并将决策与标准或雷达反馈关联起来。 - 将系统设计和代码变更交由相关工程技能处理,将安全要求和威胁建模交由
secure-software-engineering处理,将实时运维或 SLO 工作交由site-reliability-engineering处理。
领域模型
| 领域 | 涵盖内容 | 产物 |
|---|---|---|
| 技术雷达 | Adopt/Trial/Assess/Hold 象限、工具选择标准、弃用政策 | 技术雷达文档 |
| 自建还是采购 | TCO 分析、决策矩阵、供应商评估、集成成本 | 自建与采购建议 |
| 架构治理 | 自动化策略、联邦式决策、咨询流程、集中审查、标准、例外和反馈 | 治理决策记录、标准、例外、雷达更新 |
| 工程指标 | DORA(部署频率、前置时间、MTTR、变更失败率)、SPACE、DevEx | 工程仪表板、健康报告 |
| 技术债务 | 利息计算、修复优先级排序、本金估算 | 技术债务登记表 |
| 创新管道 | 技术趋势扫描、POC 标准、生产就绪关卡 | 创新漏斗、POC 报告 |
何时加载
在任务涉及以下内容时加载此技能:
- 评估是否采用新技术或工具
- 通过 TCO 分析做出自建还是采购的决策
- 设计或审计架构治理流程
- 搭建工程指标仪表板(DORA、SPACE)
- 量化技术债务修复工作并确定优先级
- 运营包含 POC 到生产关卡的创新管道
- 弃用或退役旧技术
- 选择或审计自动化策略、联邦式决策、咨询流程或集中审查
治理工作流
对于架构或技术治理工作,请阅读 references/architecture-governance.md 并:
- 明确决策、预期结果、受影响的系统和团队、现有证据以及决策负责人。
- 评估可逆性、范围、风险、影响范围、监管影响和跨团队影响。记录不确定性,不要将其转化为虚假的评分。
- 选择仍能控制可信风险的最轻量治理模式:自动化策略、联邦式决策、咨询流程或集中审查。当证据表明该决策比最初假设的更难逆转、范围更广、风险更高或监管要求更严格时,应升级处理。
- 明确决策记录、实施检查、例外处理路径以及触发重新评估的信号。
- 将实施和运营证据反馈到决策、标准、例外和雷达策略中。将反馈视为学习的契机,而非事后追责的依据。
参考文件
| 参考资料 | 加载时机 | 文件 |
|---|---|---|
| 技术雷达 | 需要评估和分类某项技术或工具,以决定采纳、试用、评估或暂缓时 | references/technology-radar.md |
| 自建还是采购 | 使用 TCO 分析和决策标准比较自建与采购方案时 | references/build-vs-buy.md |
| 架构治理 | 选择或审查适度的治理模式、标准、例外、升级机制或反馈时 | references/architecture-governance.md |
| 工程指标 | 需要使用 DORA、SPACE 或 DevEx 框架衡量工程效能时 | references/engineering-metrics.md |
设计原则
- 技术是手段,而非目的。 每项技术决策都必须关联到业务成果。“因为它是新的”不是采纳的理由;“因为它能更快、更安全或更便宜地解决 X”才是。
- 雷达是持续更新的文档。 当证据、战略、风险或使用情况发生重大变化时,应更新技术雷达。根据技术组合的特点设定更新频率,并让重大的采纳、暂缓、晋级或退役决策触发更新,而不是等到固定日期。
- 自建还是采购,绝不只是成本问题。 总拥有成本包括维护、招聘、培训、集成、迁移和机会成本。今天更便宜的自建方案,3 年后可能贵得多。
- 工程指标衡量的是系统,而非人员。 DORA 指标衡量组织的交付能力。SPACE 衡量开发者满意度。两者都不是个人绩效评估工具。
- 技术债务既有本金,也有利息。 本金是彻底修复它所需的成本;利息是它对速度造成的持续拖累。应优先处理利息与本金之比最高的债务。
- 生产就绪门槛旨在防止危机。 为了追求速度而跳过的每一道门槛,日后都会以事件响应时间的代价偿还。
- 治理力度应与后果相称。 局部且可逆的决策应由本地自行决定;不可逆、受监管、影响范围广或对多个团队有重大影响的决策,则需要更强的协调或权威。
可移植性
此技能有意保持与宿主无关。请使用 Agent 的常规机制加载此处列出的参考资料、模板和脚本。不要假定存在特定的配置文件系统、任务编排器、记忆服务或响应交接格式。
评论
支持 Markdown