Skip to content
FDEFDE Wiki

Six conditions a deployment has to meet before anyone writes code

A signature starts a project; conditions decide whether starting is the cheap option. Six of them, each predicting a different way the work fails.

Updated 2026-10-305 min read

A signature starts a project because somebody wants the work to begin. Conditions are a different instrument: they decide whether beginning is the cheap option, and they can be checked in a week rather than argued over for a quarter.

The six below are not a scorecard. A score lets the strong parts pay for the weak ones: plenty of enthusiasm and decent data can still look respectable. Deployments do not average. Their factors multiply, which is why one near-zero factor in the usual five-part picture — model, scenario fit, system stability, adoption, reusable assets — takes the whole result to near zero. Five conditions satisfied and one missing is not eighty-three percent of a project; it is a project that fails in the way the missing condition predicts.

The six conditions

One, the process runs today, end to end. Evidence is one employee walking one real case on their own screen, including the step that happens in a chat group — not a diagram of how the department is supposed to operate. Without it you automate the org chart, and the real process continues beside your system as a shadow holding the exceptions.

Two, the data exists and the path to it has names. Evidence is a file you already hold, one person who provides it, one who approves access, and the environment for the test. Without it the project stalls in weeks two to four, and the stall gets filled with features, hiding the block behind visible progress. Who may read, and who may write back, belongs in the data and security boundaries, not in an assumption.

Three, the value lands on a number somebody already watches. Evidence is the owner of that number stating last month's baseline without asking anyone. Without it the system works and nobody can say whether it helped, leaving nothing to point at when the budget is defended.

Four, it happens often enough to be learned and judged. Evidence is a count from last month's log, not an estimate offered in the meeting. Without it you get a correct system used a handful of times a quarter: novelty carries the first weeks, nothing carries the fourth.

Five, a wrong output can be caught and undone. Evidence is a named reviewer, the action taken on a rejected output, and the step that reverses it. Without it one bad output becomes an event, and the project is judged on its worst case rather than its trend.

Six, one person can both sign and carry the consequence. Evidence is that the person who can change how the work is done is in the room, has said what happens if it fails, and has put a date on the decision. Without it the trial never ends: no acceptance, no rejection, a project that consumes a year. A community account of a large state-owned enterprise that contracted ten agents on a six-month plan and had nothing accepted a year later is that failure in pure form: the person who can say yes is not the person assigned to the project.

One page for the meeting

Each row is checkable this week; the third column is the next section's work.

Condition What you check this week What it becomes if it fails
Process runs today One employee walks one real case, on their own screen Exclusion: the step done outside the system stays outside, and is listed
Data and access You hold one sample file, one provider and one approver are named Dependency clause with a date consequence
Number already watched The owner states last month's baseline from a report A paid measurement step before any build
Frequency A count from last month's log Deferral with a stated volume threshold
Reversible error Reviewer named, rollback step written Human review as a delivery requirement, priced
Signer with exposure Decision-maker in the room, with a date Refusal, or a paid diagnosis instead of a build

Writing a failed condition out of scope

There are three exits, and a fourth people take because it is free to say.

The first is an exclusion with a consequence, written into the annex in three parts: what this deployment does not do, what the customer must provide, and what moves if they do not provide it. For data that reads: this version does not read the ERP; the report is produced from the export provided by the fifth working day; if the export arrives later, the acceptance date moves by the same number of working days. That sentence belongs in the same document as the scope and price, and it is what keeps a stall from turning into a negotiation.

The second is a paid diagnosis of two to three weeks producing a scene priority list and a data readiness list; its real function is a filter, since a customer who will not pay for the diagnosis was not going to pay for the build.

The third is no. A refusal that ends a conversation is worth less than one that ends with a condition attached, because "not now" returns when the condition is met; without the condition it is a postponement wearing the clothes of a plan.

The fourth exit is "phase two", the one to strike from the minutes: it is not an exit but a promise that the condition will be ignored while the project proceeds as though it had been met.

Check two of them first

Conditions one and six cost a week of walking and one conversation; two and five cost an email and a look at the security process; three and four may need data you do not have yet. So check the two that are cheapest to check and most expensive to be wrong about, not the two written first. The discovery question bank is the instrument for the first, the stakeholder map for the sixth.

The question before the first line of code

Which of the six is not true today? If the answer is "none", you are scoring the project, not checking it, and the scoring will pass. Then name which of the three exits you used for the condition that fails, and where it was written down. If a reader of the annex cannot find that line, the condition was not resolved; it was hoped away, and the hope has a delivery date. The annex is a statement of work, so the conditions belong in its clauses rather than in a slide — the ten clauses that decide whether the project survives are where a failing condition formally stops being anyone's private worry.

Sources and further reading

  • 生财有术社区公开分享;第三人称转述,数字为分享者自述
  • 据《2026 中国 FDE 人才白皮书》(曲率,2026),场景评分卡与试点选择一节
  • 司徒K《FDE 百问百答》(2026-10-26 公开长文);仅取问题与判据,答案全部重写
  • 观点启发自范冰《FDE 前线部署工程师》;作者已书面许可,仅取观点与结构

This article is original analysis by FDE Wiki. Frameworks and case material that originated elsewhere are credited below.