mcpField
T
technology-radar

technology-radar

github.com/magnus919开发15362 次安装1 天前更新
代码仓库

关于 technology-radar

面向 CTO 和工程领导者的通用技能,涵盖技术组合治理、工程指标、技术债与创新决策。通过决策框架将技术选择与业务目标关联,并按影响程度设置治理。

主要功能

  1. 01技术雷达与采用策略
  2. 02自建或采购的总拥有成本分析
  3. 03按影响程度实施架构治理
  4. 04DORA、SPACE 与 DevEx 指标
  5. 05技术债优先级排序
  6. 06创新流程与生产就绪门槛

适用场景

  1. 01评估新工具的采用或退役
  2. 02比较自建与采购方案
  3. 03选择架构审查和例外处理方式
  4. 04确定技术债优先级并衡量交付表现

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/magnus919/agent-skills --skill technology-radar

安装后在 Claude Code 中输入/technology-radar确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

README.md
evals/
evals.json
references/
architecture-governance.md
build-vs-buy.md
engineering-metrics.md
source-index.md
technology-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 并:

  1. 明确决策、预期结果、受影响的系统和团队、现有证据以及决策负责人。
  2. 评估可逆性、范围、风险、影响范围、监管影响和跨团队影响。记录不确定性,不要将其转化为虚假的评分。
  3. 选择仍能控制可信风险的最轻量治理模式:自动化策略、联邦式决策、咨询流程或集中审查。当证据表明该决策比最初假设的更难逆转、范围更广、风险更高或监管要求更严格时,应升级处理。
  4. 明确决策记录、实施检查、例外处理路径以及触发重新评估的信号。
  5. 将实施和运营证据反馈到决策、标准、例外和雷达策略中。将反馈视为学习的契机,而非事后追责的依据。

参考文件

参考资料加载时机文件
技术雷达需要评估和分类某项技术或工具,以决定采纳、试用、评估或暂缓时references/technology-radar.md
自建还是采购使用 TCO 分析和决策标准比较自建与采购方案时references/build-vs-buy.md
架构治理选择或审查适度的治理模式、标准、例外、升级机制或反馈时references/architecture-governance.md
工程指标需要使用 DORA、SPACE 或 DevEx 框架衡量工程效能时references/engineering-metrics.md

设计原则

  1. 技术是手段,而非目的。 每项技术决策都必须关联到业务成果。“因为它是新的”不是采纳的理由;“因为它能更快、更安全或更便宜地解决 X”才是。
  2. 雷达是持续更新的文档。 当证据、战略、风险或使用情况发生重大变化时,应更新技术雷达。根据技术组合的特点设定更新频率,并让重大的采纳、暂缓、晋级或退役决策触发更新,而不是等到固定日期。
  3. 自建还是采购,绝不只是成本问题。 总拥有成本包括维护、招聘、培训、集成、迁移和机会成本。今天更便宜的自建方案,3 年后可能贵得多。
  4. 工程指标衡量的是系统,而非人员。 DORA 指标衡量组织的交付能力。SPACE 衡量开发者满意度。两者都不是个人绩效评估工具。
  5. 技术债务既有本金,也有利息。 本金是彻底修复它所需的成本;利息是它对速度造成的持续拖累。应优先处理利息与本金之比最高的债务。
  6. 生产就绪门槛旨在防止危机。 为了追求速度而跳过的每一道门槛,日后都会以事件响应时间的代价偿还。
  7. 治理力度应与后果相称。 局部且可逆的决策应由本地自行决定;不可逆、受监管、影响范围广或对多个团队有重大影响的决策,则需要更强的协调或权威。

可移植性

此技能有意保持与宿主无关。请使用 Agent 的常规机制加载此处列出的参考资料、模板和脚本。不要假定存在特定的配置文件系统、任务编排器、记忆服务或响应交接格式。

评论

支持 Markdown