Техническое задание может быть выполнено дословно, но бизнес-задача все равно останется нерешенной. Разбираемся, где на этапе разработки может потеряться смысл проекта и кто помогает довести отдельные функции до работающего процесса.
Представим задачу: нужно автоматизировать передачу заказов со склада. Менеджер оформляет заказ в системе, после чего он должен автоматически появиться в рабочем месте кладовщика – чтобы тот мог сразу начать сборку. В техническом задании подробно описали создание и проведение заказа, и разработчик реализовал эти требования. На проверке выяснилось: документ создается и проводится как задумано, но кладовщик его не видит. Формально требования из ТЗ выполнены, но бизнес-процесс не работает – заказ не доходит до следующего участника.
Так возникает один из главных парадоксов автоматизации: система соответствует требованиям, но оказывается неудобной или даже бесполезной для бизнеса. Причина не всегда в плохом коде или небрежном ТЗ. Иногда отдельные требования реализованы правильно, но не проверена связь между ними, переходы между ролями и весь путь пользователя до результата.
Именно здесь проходит неформальная граница между аналитиком, который передает задачу разработчику, и аналитиком, который сопровождает разработку.
Название должности не показывает реальную зону ответственности
В одной компании специалист называется консультантом, в другой – аналитиком-консультантом, в третьей – проектным аналитиком. При этом ежедневная работа может выглядеть почти одинаково: получить запрос, уточнить потребность, описать решение, ответить на вопросы разработчика, проверить результат и вернуть его пользователю.
Разница проявляется не столько в названии роли, сколько в границе ответственности. Один специалист считает работу законченной, когда передал постановку. Другой продолжает удерживать задачу: следит, одинаково ли команда понимает требования, проверяет логику, замечает новые условия, фиксирует решения и убеждается, что пользователь действительно может выполнить свой процесс.
Требования – это не то, что вы написали, а то, как вас поняли
Можно написать подробное ТЗ и все равно оставить разработчику пространство для нескольких трактовок. Например, «подтянуть цену из последней продажи». Последняя – по дате документа, времени создания, номеру или моменту проведения? Если в один день было две продажи, какую считать последней?
Автор курса Оксана Пашкова формулирует это так:
«Требования – это не то, что вы написали, а то, как вас поняли».
Задача аналитика – не охранять исходный текст от любых изменений, а сохранять его смысл, когда команда сталкивается с вопросами, которых в документе не было.
Для этого важно создавать след решений проекта:
| Что возникает в работе | Где это фиксировать |
|---|---|
| Спорные термины | Глоссарий |
| Последовательность действий | Сценарий использования или модель процесса |
| Вопрос, контекст и принятое решение | Журнал уточнений |
| Изменение требования | Актуальная версия документации |
| Договоренность на встрече | Короткий протокол с ответственными и сроками |
Это не бюрократия ради порядка. Если ответ остался только в разговоре, через неделю у любого участника команды могут появиться три разные версии договоренности.
«Решение, которое не записано, не существует», – подчеркивает Оксана Пашкова.
Отдельные функции еще не образуют бизнес-процесс
На функциональном просмотре аналитик может проверить каждый пункт: документ создается, цена подставляется, проведение блокируется при нехватке товара, сообщение об ошибке выводится. Все галочки стоят. Но это еще не доказывает, что пользователь сможет решить задачу от начала до конца.
Здесь нужны два разных масштаба проверки.
| Инструмент | Что он помогает проверить |
|---|---|
| Чек-лист | Чек-лист отвечает на вопрос «сделано ли то, что записано в требованиях?». Он помогает быстро проверить ключевую логику, позитивные и критичные негативные сценарии. |
| Сценарий использования | Сценарий использования отвечает на другой вопрос: «складываются ли отдельные функции в рабочий путь?». В нем важны порядок шагов, передача данных и переходы между участниками. |
«Чек-лист проверит конкретные детали, а Use Case проверит, что из наших деталей соберется работающий сценарий», – объясняет Оксана Пашкова.
При сквозной проверке аналитик ищет не только баги, но и разрывы – места, где информация или управление не переходят дальше. Такие разрывы чаще всего возникают:
У таких ситуаций есть общий признак: человек вынужден компенсировать систему звонком, письмом, таблицей или сообщением в мессенджере. Если без ручного «перекидывания» процесс не продолжается, автоматизация не стала единым рабочим контуром.
Happy Path показывает не все
Даже связный сценарий легко проверить только в идеальных условиях: данные заполнены, остатки есть, права настроены, интеграция доступна. Но реальные пользователи ошибаются, отвлекаются, возвращаются к документам позже и сталкиваются с исключениями.
Поэтому сильный аналитик задает не только вопрос «как должно работать?», но и серию вопросов «а что, если?»:
- значение находится ровно на границе условия;
- одновременно срабатывают два бизнес-правила;
- обязательное поле не заполнено;
- документ провели задним числом;
- интеграция вернула ошибку;
- часть процесса нужно отменить или повторить;
- один участник завершил действие, а следующий еще не подключился.
Показательный пример – два требования к доставке. Заказ дороже определенной суммы доставляется бесплатно. Тяжелый заказ доставляется за процент от его стоимости. Каждое правило по отдельности понятно. Но что делать с тяжелым и одновременно дорогим заказом? Пока приоритет не определен, разработчик вынужден угадывать.
Это не означает, что аналитик должен до старта разработки описать все возможные случаи. Такая полнота недостижима. Важно покрыть основные сценарии, критичные исключения и явно зафиксировать допущения и ограничения.
Идеальное ТЗ в этом смысле – опасная цель: стремление предусмотреть абсолютно все может остановить работу, но не гарантирует полноты. Рабочая цель другая – снизить неопределенность до приемлемого уровня, согласовать этот риск с заказчиком и продолжать уточнение по мере разработки.
Найти проблему недостаточно – ее нужно превратить в работу
Во время проверки аналитик обнаруживает, что результат отличается от ожиданий. Дальше легко попасть в спор: это ошибка разработчика, новое пожелание заказчика или пробел в постановке?
Полезно сначала классифицировать расхождение.
| Тип расхождения | Что произошло |
|---|---|
| Баг | Согласованное требование было понято правильно, но реализовано не так. |
| Изменение | Заказчик хочет поведение, которого не было в согласованной постановке. |
| Неоднозначность | Исходное требование допускало несколько трактовок, и одна из них была реализована. |
| Противоречие | Два требования нельзя выполнить одновременно без выбора или компромисса. |
Классификация нужна не ради терминов. Она определяет следующее действие: исправить реализацию, согласовать объем изменений, уточнить решение или передать вопрос тому, у кого есть нужные полномочия.
Хорошо оформленное расхождение содержит контекст, шаги воспроизведения, фактический и ожидаемый результат, влияние на бизнес-процесс и подтверждающие материалы. Приоритет при этом зависит не только от сложности исправления. Важнее частота сценария, последствия для учета и денег, число затронутых пользователей и наличие обходного пути.
Так замеченная проблема превращается в понятную задачу, а не в реплику «здесь что-то работает не так».
Практика: быстрая проверка задачи перед показом заказчику
Эту последовательность можно применить к ближайшей доработке.
Такая проверка не заменяет полноценное тестирование. Она помогает аналитику выполнить собственную часть контроля: убедиться, что команда реализовала нужный смысл и что из отдельных функций складывается работающий процесс.
Экспертиза начинается не с того, что вы знаете, а с того, что вы замечаете
Сильный аналитик замечает неоднозначное слово до того, как оно превращается в две реализации. Видит конфликт интересов бухгалтера и менеджера. Проверяет не только форму документа, но и переход к следующей роли. Не прячет неполные данные, а фиксирует допущение. Не пересылает вопрос без контекста, а предлагает варианты решения. Не ограничивается сообщением о проблеме, а оформляет ее так, чтобы команда могла действовать.
Это и есть рост зоны ответственности: от передачи запроса – к сопровождению решения до работающего результата. Он возможен и в поддержке, и на проекте, независимо от названия должности. А готовность вести такой контур помогает браться за более сложные задачи, где недостаточно написать ТЗ и ждать приемки.
