9

Читать по-русски

Discovery and gathering requirements

Discovery is the one meeting you get to run before you owe anyone a diagram, an estimate or a line of code. Everything downstream — the solution class from chapter 5, the domain shape from chapter 6, the security posture from chapter 7 — depends on what you learn here, and often more on what nobody in the room can answer. A good discovery is not a form you fill in. It is a sequence of questions asked in an order that matters, because each block narrows what the next block can even mean.

  1. Business
  2. Process
  3. Data
  4. Constraints

9.1 Business

Four questions, asked before anything else, because they decide whether there is a project at all.

What problem is being solved? A vague version — “we want to be more efficient with AI” — means nobody has done the thinking yet. A good answer names a specific, recurring cost: “our support team spends four hours a day copying ticket details into three systems.”

Who owns the process? Not who requested the meeting — who is measured on the outcome, and who loses something if it does not improve. A client who has to think about this has not found their sponsor yet, and a project without a sponsor gets deprioritised the moment budgets tighten.

What does success look like? Chapter 2 sorted the real criteria from the wishes; discovery is where you make somebody say one out loud with the room listening. Keep asking until the answer carries a metric and a direction — tickets resolved per agent per day, first-response time, a percentage off a specific queue — and write it down in their words while they are still in front of you. Note who agreed to it, too: that is the person the finance review will call in six months.

What are the current KPIs? This is the number the success metric has to move from. If nobody in the room can state it, the “improvement” you deliver in six months will be unmeasurable, and an unmeasurable project cannot be defended in the budget review that follows it.

9.2 Process

Business questions tell you whether the project is worth doing. Process questions tell you whether it is buildable.

Who does the work today? A name and a role, not a department. “The finance team” cannot demo a workflow for you; the two people who actually reconcile invoices can.

What steps do they take? Ask for the steps in order, out loud, and write them down as you hear them. If the description keeps sliding into “and then it depends,” that dependency is the interesting part — go back and ask what it depends on.

Where is the manual labour? This is the part worth automating, and it is rarely where the client points first. Clients tend to flag the step that annoys them, not the step that costs the most time; the two are not always the same step.

Where do the delays happen? A slow step and a manual step are different problems with different fixes. A three-day approval queue is a process issue no model resolves; a client who conflates the two will expect an AI system to fix an organisational bottleneck.

9.3 Data

By this point you know what problem you are solving and what the process looks like. Now: is there anything to build on.

Are there documents? Policies, contracts, tickets, wiki pages, past proposals — anything written down that answers questions the way RAG answers questions, by retrieving the passage that already contains the answer.

Is there a CRM, warehouse or database? A question answered by counting, summing or filtering rows is a text2SQL question, not a documents question, and the two need entirely different projects — chapter 5 covers why that distinction gets confused more than any other.

Is there a knowledge base, and who maintains it? A knowledge base with no owner accumulates the exact contradictions that make retrieval unreliable. Ask who edits it and how often, not just whether it exists.

Is the data structured or not? A spreadsheet with consistent columns is closer to a database than to a document, whatever format it happens to be saved in. This question decides which of the previous two answers actually applies.

Map the answer honestly against chapter 5: documents point at RAG, a database points at text2SQL, and if the client has neither — no documents worth retrieving, no structured store worth querying — the first project is not a model at all, it is the unglamorous work of writing things down and structuring them, and the proposal should say so before anyone signs it.

9.4 Constraints

The last block, and the one that silently reshapes everything already agreed. Skip it, or ask it too late, and you redesign the project in week three instead of the discovery call.

Can the cloud be used? Some clients simply cannot send data outside their own infrastructure — by policy, by contract with their own customers, or by regulation. Find out before you have a cloud-based architecture the client cannot approve.

Are there security requirements — a specific certification, an approved vendor list, an internal review process? Chapter 7 covers what these actually demand in practice; discovery’s job is only to surface that they exist and who owns them, early enough to plan around.

Is personal data involved? Names, health records, financial details, anything covered by data-protection law changes what “just send it to a cloud API” means, and sometimes rules it out entirely.

Are there regulatory limits specific to this industry or this use case? A bank, a hospital and a marketing agency do not operate under the same ceiling, and the client’s own compliance team usually knows the answer faster than any outside consultant will find it.

Red flags on the way out

Hold these five in your head walking out of a discovery call. Each one is a missing answer that tells you something specific about the project ahead, not a reason to walk away from it.

  • Personal data is present. The cloud question is now open, not settled — revisit it before promising an architecture.
  • No documents and no CRM. RAG has nothing to retrieve from; the project starts with building a corpus, not a system.
  • Process steps nobody can describe in order. It is too early to talk about an agent, or even a workflow — describe the process first, automate it second.
  • No named process owner. Nobody is accountable for the outcome, which usually means nobody is actually buying the result.
  • A high cost of error with no reviewer in the loop. Human-in-the-loop is not an add-on for later. It belongs in the design from the first sketch.

Work through the four blocks below and note where a red flag comes up.

Red flags

No red flags so far

Block A — Business

A specific, recurring cost — who loses what, and how often. "We want to be more efficient with AI" means the thinking has not been done yet.

Not who called the meeting: who is measured on the outcome and loses something if it does not improve.

Keep asking until a metric and a direction come out. Write it in their words, and note who agreed to it out loud.

The number the success metric has to move from. Without it, the improvement you deliver cannot be measured or defended.

Block B — Process

A name and a role. A department cannot demo a workflow; the two people who actually do it can.

Ask for them in order, out loud, and write them down as you hear them. Every "and then it depends" is worth going back to.

Clients flag the step that annoys them, not the step that costs the most time. Ask about the second one separately.

A three-day approval queue is an organisational bottleneck, and no model resolves it. A slow step and a manual step need different fixes.

Block C — Data

Policies, contracts, tickets, wiki pages, past proposals — anything written down that already contains the answer somewhere.

A question answered by counting, summing or filtering rows is a different project from a question answered by finding a passage.

Ask who edits it and how often, not only whether it exists — a base with no owner accumulates the contradictions that make retrieval unreliable.

A spreadsheet with consistent columns is closer to a database than to a document, whatever format it is saved in.

Retrieval does not inherit permissions on its own: the index knows a document is there, not who was meant to open it.

Block D — Constraints

By policy, by contract with their own customers, or by regulation. Find out before you bring an architecture the client cannot approve.

A certification, an approved vendor list, an internal review process. Discovery only has to surface that they exist and who signs them off.

Names, health records, financial details — anything covered by data-protection law.

A bank, a hospital and a marketing agency do not work under the same ceiling. The client’s own compliance team answers faster than any outsider.

Money, a legal position, someone’s health — or an afternoon. The answer decides how much review the design has to carry.

Somebody who sees the output and can stop it, on the cases that matter rather than on every case.

In a discovery call, a client says success would be "the team being more efficient with AI." Everyone nods and starts moving to the next agenda item. What do you do?