Decomposition of business processes

Then we understand the processes. We find out how the company solves the problem now, without the service. How the manager receives the documents, what he does if there are errors in them, where he sends them.

There is a good tool for this stage — BPMN. Simply put, this is a large chain of business processes in which it is clearly visible who is doing what, how they are doing and who is responsible for what.

Here the task becomes overgrown with “meat” — we already understand where the data will come from in the future project, how the business processes them, how long the path will be.

“If you are working with a startup, you will have to take risks: not to describe current business processes, but to build hypotheses about how it should all work”

Stage 3. Detailing the client’s wishes

It happens that a person begins to tell how he sees the solution of his task immediately through the processes. For example, he wants documents to be collected and processed in such a way that there are such and such results at specific stages.

Another option is that the customer can not fantasize about anything and say that he expects us to solve his problems. This is also possible — then we will work it out ourselves.

Roles

We check the details with the customer and begin to describe the roles in the service — that is, a list of those who will use it.

In the case of Lesha’s brokerage service, everything is simple: there are managers who can make a single package of several documents, add additional data and send them back. There are administrators who can make changes to the structure of packages, say how documents are processed specifically. And there is Lyosha, who can control all the processes and watch the statistics.

Not in all projects everything turns out so simple. For example, Dima has several times more roles in Uber logistics — there are ten types of customers who can send orders, several types of drivers who need to see orders, respond to them, dealers, carriers and other users, each with their own functions.

Four roles in a small project — the customer wants a marketplace

Stage 5. Functional requirements

For each role, we prescribe capabilities — they are also called functional requirements. We take the data from business processes and describe it in detail.

We find out from the customer what each user will do in the project, what functions he will have access to, how the system will respond to his actions.

If you want to conduct a “Discovery” yourself, more often ask yourself two questions: “What’s next?” and “What if not?”.

For example, a driver in a forwarding project can get into a personal account. And what’s next? He will see a notification about a new order. And what’s next? He can offer his price. And what’s next? Will take the order. And what if he doesn’t, if he refuses to take the order? Will the service offer a new one? And if he takes the order, but does not go? Etc.

The result of this step is a card with a role and a list of functional requirements.

An extended description of the user’s capabilities with comments for the developer

Stage 6. Formation of functional blocks

This is the internal stage of Discovery, which the analyst does without involving the customer. Studying the resulting functional cards, the specialist makes a list of all the necessary functions of the project: registration, authorization, order search, order response.

It turns out a large list of so-called user stories, or different possibilities, actions.

Stage 7. Development of prototypes

To work, we connect a designer who creates prototypes in Figma — a set of basic windows of the future application. These are not the final design, but examples of how the project will work. The color palette, arrangement and order of the elements may differ in the end.

The point of prototyping is to show the customer how the project will work in general, whether we understood each other correctly in the end. And it also helps to understand the functions more deeply — the customer can use prototypes to clarify what other nuances there are in the project.

The result of prototyping is the final approval of the project.

This is what prototypes look like — we make them in Figma

How much time and attention is required from the customer

We work in iterations: we met with the customer, collected data, then the analysts worked on them, met again, discussed the result and collected clarifications, went to the next round.

The number of iterations and days for each stage depends on the scale of the project. Maybe we will only collect information about business processes in a few days, if this is a large project like a logistics Uber. Or we will collect all the information literally in 3-4 hours, if this is a conditional marketplace with some atypical requirements.

“It usually works like this: we met-called on Monday, I will return for clarifications on Wednesday. By Friday, the documents were prepared, on Monday we called again and discussed. Sometimes this is enough, sometimes you need to repeat the process several more times.

A good analogy of “Discovery” is like writing a diploma. If the topic is simple, you will talk to the supervisor a couple of times and everything is ready. If it’s difficult, you’ll meet ten times, right?”

What the customer receives from Discovery is the

result of the Discovery phase with us — the terms of reference. The document consists of several elements: