The post has been translated automatically. Original language: Russian
The terms of reference are usually perceived as a way to fix development requirements. But even if the task seems clear, one ambiguous formulation can lead to the fact that the customer and the developer will present the final result differently. For example, the requirement to "add the ability to control the balance under the contract" sounds quite specific, until clarification begins: which balance to take into account, from which data to calculate it, which operations affect it, whether it is possible to exceed the set limit and what the user should see in this case.
If such moments are not determined in advance, the developer is forced to independently choose one of the possible implementation options. After the demonstration, it may turn out that the customer expected a different scenario. Formally, the task has been completed, but a new stage of refinements and improvements is beginning. A similar situation occurs when non-standard cases are not described in the requirements: missing data, repeated operations, incorrect values, or other exceptions that occur much more often in real work than they seem at the stage of setting the task.
Separately, it is important to separate the business requirement and the technical solution. First of all, the customer needs a certain result, and it is better to choose the way to implement it after analyzing the task. If the technical option is immediately fixed in the requirements, it may not be the most suitable or limit other possible solutions. For the same reason, it is necessary to determine in advance the data sources and the rules for their processing. The phrase "withdraw the amount" without explaining where it comes from and how it is calculated leaves too much room for different interpretations.
A good technical assignment is not necessarily a document with dozens of pages. It is more important to be clear before starting development.:
- the purpose of the task;
- the logic of the work;
- data sources;
- basic conditions;
- exceptions;
- expected result.
The less a developer has to figure out the requirements themselves, the less likely it is that the ready-made functionality will have to be redone.
Therefore, clarifying requirements should be considered not as an additional step that slows down the start of work, but as a way to reduce the number of questions and improvements in advance. Several refinements at the start often take much less time than changing already implemented functionality.
Техническое задание обычно воспринимается как способ зафиксировать требования к разработке. Но даже если задача кажется понятной, одна неоднозначная формулировка может привести к тому, что заказчик и разработчик будут по-разному представлять конечный результат. Например, требование «добавить возможность контролировать остаток по договору» звучит достаточно конкретно, пока не начинаются уточнения: какой именно остаток учитывать, из каких данных его рассчитывать, какие операции на него влияют, можно ли превышать установленный лимит и что в таком случае должен увидеть пользователь.
Если такие моменты не определить заранее, разработчик вынужден самостоятельно выбирать один из возможных вариантов реализации. После демонстрации может оказаться, что заказчик ожидал другой сценарий. Формально задача выполнена, но начинается новый этап уточнений и доработок. Похожая ситуация возникает, когда в требованиях не описаны нестандартные случаи: отсутствующие данные, повторные операции, некорректные значения или другие исключения, которые в реальной работе встречаются гораздо чаще, чем кажется на этапе постановки задачи.
Отдельно важно разделять бизнес-требование и техническое решение. Заказчику прежде всего нужен определённый результат, а способ его реализации лучше выбирать после анализа задачи. Если в требованиях сразу жёстко зафиксировать технический вариант, он может оказаться не самым подходящим или ограничить другие возможные решения. По той же причине необходимо заранее определить источники данных и правила их обработки. Формулировка «вывести сумму» без пояснения, откуда она берётся и как рассчитывается, оставляет слишком много пространства для разных трактовок.
Хорошее техническое задание — это не обязательно документ на десятки страниц. Важнее, чтобы до начала разработки были понятны:
- цель задачи;
- логика работы;
- источники данных;
- основные условия;
- исключения;
- ожидаемый результат.
Чем меньше разработчику приходится додумывать требования самостоятельно, тем меньше вероятность, что уже готовый функционал придётся переделывать.
Поэтому уточнение требований стоит рассматривать не как дополнительный этап, который замедляет начало работы, а как способ заранее сократить количество вопросов и доработок. Несколько уточнений на старте часто занимают гораздо меньше времени, чем изменение уже реализованного функционала.
Share
