合作方式
合作方式
五个阶段的合作，每个阶段结束时都有一次决策；第一个阶段的设计前提是：即使就此停下，您也已经比之前更清楚该怎么做。
五个阶段
每个阶段都结束在由您决定的地方。
- 01
界定
弄清真正要构建的是什么，以及它是否值得构建。
系统必须做什么、会触及哪些既有系统、需要迁移哪些数据，以及什么会导致它失败。范围明确，时间封顶。
继续、调整方向，或停止——无论哪一种，您都拿到了有用的东西。
产出
- 书面范围说明
- 架构判断
- 成本模型
- 一份建议
- 02
设计
设计系统本身，以及它与其他一切之间的接缝。
接口、数据归属、失败模式与评估方案，在编写那些回退代价高昂的代码之前先达成一致。
验收标准在这里签字确认，而不是在结束时谈判。
产出
- 架构决策记录
- 接口契约
- 评估方案
- 双方确认的验收标准
- 03
构建
从第一次迭代起，就在您的环境中运行的可用软件。
在测试确实值得其维护成本的层次上进行测试，并通过一条您看得见的流水线部署。
进展持续可见，因此结束时不存在“揭晓”这一环节。
产出
- 您账户中的源代码与基础设施
- 部署流水线
- 测试与变更记录
- 04
验证
用证据证明验收标准，而不是口头声明。
评估运行、负载表现、安全审查、无障碍性，以及演练过的故障处理——包括回滚。
上线是依据证据做出的决定，而不是一个日期。
产出
- 针对既定评估集的评估结果
- 安全与无障碍性发现
- 演练过的回滚方案
- 05
运维交接
交付一套接手团队真正能运行起来的系统。
与各方认可的服务水平挂钩的监控埋点、有实际意义的告警，以及为接手者而写的文档。
需要的话我们继续提供支持；不需要的话，也不存在依赖。
产出
- 仪表盘与告警
- 交接文档
交付原则
塑造以上一切的四条规则。
- 界定范围的，就是交付的人
- 为您撰写架构判断的工程师就在构建团队里。不存在“把一场您参与过的对话，转交给一个不在场的团队”这种交接——而这正是这个行业里大部分误解的源头。
- 验收标准在构建之前确定
- “完成”意味着什么，在设计阶段就写下来，那时没有人承受截止日期的压力。它不会在最后一周被重新谈判——而那通常正是“完成”的定义被悄悄放宽的时候。
- 进展持续可见
- 从第一次迭代起，工作就存在于您的代码仓库和您的看板里。结束时没有“揭晓”，因为需要揭晓，就意味着在问题还便宜的时候没有人看得见它们。
- 用证据，而不是用断言
- 上线就绪是被证明出来的——评估运行、负载表现、演练过的回滚——而不是在一次进度会上宣称的。
需要您配合的部分
这项合作需要您提供什么
以下这些东西一旦缺失，往往就是项目停滞的真正原因。提前确认它们是否存在是值得的。
- 一位能拍板的人
- 不是一个委员会。是能在一天而不是两周内解决一个范围问题的人。
- 相关系统的访问权限
- 环境、数据样本，以及知道某个系统为什么会这样运行的人。绕开一个无法访问的系统去做估算，那是猜测。
- 对约束条件的坦诚说明
- 合规边界、无法挪动的日期、一份供应商合同、一个组织内部的现实。早期说明的约束会塑造设计；发现得太晚，则会推翻设计。
- 一个您自己相信的成功定义
- 具体到上线之后可以度量。如果它无法被度量，那么也就无法针对它交付。
起步方式
风险最低的起步方式
第一个阶段可以单独进行，作为一次 AI 治理预审计：对贵组织内已经在使用的 AI、公司数据正流向何处，以及下一套系统上线之前必须先成立哪些前提，做一次范围明确的评估。
它产出一份发现报告，每一项都带有严重程度、证据与责任人，并附上一份按暴露程度排序的整改顺序。无论之后发生什么，这些结论都属于您——这项合作的设计前提，就是即使到此为止它也有用。
是否适合
什么情况下 Xcelerates 不是正确的选择
早点把这件事说清楚，对双方来说都比在第二个月才发现要便宜。
- 需要在短时间内组建一支大规模团队。Xcelerates 同一时间只承接少量项目。
- 以最低小时单价为主导的需求。我们的商业模式是对结果负责，而不是提供工时。
- IT 外包运维、服务台，或外部 CIO 职能。那是另一门生意。
- 目的只是“存在过”、而不指向下一步的概念验证。演示在别处买更便宜。