我们的工作方式
范围固定，中途没有意外
我们如何把界定模糊的问题变成固定的价格与工期，以及需要您配合什么，才能让这个日期站得住。
我们如何规划一次交付
六个阶段，从第一次交谈到生产环境中的指标。您随时知道项目处在哪个阶段，以及每个阶段结束时会拿到什么。
- S01
Study：理解
先倾听并梳理背景，再谈技术。你会拿到一页纸的问题陈述。
- P02
Plan：规划
范围、阶段、验收标准和价格。由你决定继续还是停下。
- A03
Assemble：构建
短周期推进，进度可见。代码仓库从第一天起就对你开放。
- D04
Demonstrate：演示
上线前，你在自己的环境里走一遍真实流程。
- E05
Endorse：验收
质量与安全评审，逐条核对验收标准。
- S06
Ship & Sense：上线并度量
部署、运维文档，以及对成功指标的解读。
预计排期
中等规模项目的参考值。带具体日期的实际排期，会在范围梳理结束时随交付计划给出。
- 15 天
01 调研与技术对齐
细化范围、原型和架构决策。
- 6 周
02 开发与集成
前端、后端与 API，每个周期都有交付供你验收。
- 2 周
03 测试与技术验证
自动化测试、集成测试和端到端测试。
- 1 周
04 文档与可观测性
方案文档、日志、指标与告警。
- 最终里程碑
05 最终交付与上线
代码、访问权限和生产环境交付，并开始读取指标。
各阶段互相重叠：测试与开发同步开始。日期在合同中固定，只有你提出范围变更时才会调整。
决定之前，您先拿到什么
范围梳理周期短、价格固定，产出四份文档。即使您决定不继续，这些文档也归您，可以拿去找别的供应商。
固定范围
要做什么的编号清单，以及明确写出不做什么的清单。真正避免收尾争执的，是后一份清单。
验收标准
每一项都有一句可测试的完成定义。没有形容词，没有解释空间。
交付计划
阶段、里程碑和日期，以及每个节点您会收到什么。两次付款之间，绝不会超过六周还没有可验证的交付。
固定价格
总价、付款条件和范围变更规则。不会因为技术上做起来更难而涨价：这个风险由我们承担。
我们需要您配合什么
延期最常见的原因不是技术难度，而是等待。我们在确定工期之前梳理这些事项，并把每一项当作有负责人、有截止日期的依赖来管理。
决策与人员
一位有权批准范围与验收的决策人、一个技术对接人，以及约定好的投入时间。没有决策人，每个疑问都会变成一场会议。
访问与凭据
云账号、代码仓库和 DNS 都在您名下。基础设施建在您的账号里，代码从第一次提交起就属于您。
系统与集成
每个对接系统都需要：文档、测试环境和一位技术联系人。没有沙箱，测试就只能在生产环境做，而我们不这么干。
数据
有代表性的测试数据，以及脱敏规则。用三条编造记录验证过的系统，上线第一天就会出问题。
环境与合规
谁承担基础设施费用、您在哪里做上线前验收，以及项目的个人信息合规定位，它会改变架构和日志方案。
交付之后
谁来运维、告警发往哪里、什么时候做交接。没人收到的告警只是摆设。
缺失项如何影响计划
没有分类仪式：我们围绕已有条件来编排交付。依赖缺失项的工作向后排，就绪的工作向前提。
排期永远反映现实，而不是最初的愿望。
当缺少只有你能提供的东西且无法绕开时，受影响的阶段等待，日期随之顺延，这在合同中事先约定，无违约金。
每位创始人都会问的问题
如果我中途改主意怎么办？
范围固定不等于范围冻结。您书面提出变更，我们在两个工作日内给出对工期和价格的影响，然后由您选择：接受、换成一个我们尚未开工的等值条目，或者放弃。互换不额外收费，也是最常用的做法。在您答复之前，我们不会动工。
如果你们估错了怎么办？
一定会发生，但价格不变：估算风险由我们承担，已经计入报价。如果影响工期，我们知道的当天您就会知道，而不是里程碑前一天。而且在提出延期之前，我们会先建议砍掉一个低价值条目，选择权在您。
代码真的归我吗？
是的，从第一次提交起，就在您的仓库和您的云账号里。我们不会在您的系统里留下任何私有组件。没有我们，您也能继续走下去，这是刻意为之：靠技术依赖绑住客户的供应商，就不必把质量做好了。
如果某个前置条件迟到了呢？
我们在它变成风险的那天就告知，而不是等它变成延期。有绕行方案时我们会提出，比如用合成数据代替真实数据，同时记录这个绕行将带来的返工。如果它是阻塞项且无从绕行，该阶段冻结，日期顺延同样的时长。
要不要把范围定下来？
三十分钟，免费。您会清楚这个问题值不值得解决、该不该用软件解决，以及我们是不是合适的人。