Думаю, почти каждый разработчик сталкивался с задачей, которая на первый взгляд выглядела совсем небольшой.

Добавить кнопку, вывести новое поле, изменить поведение формы или показать дополнительный статус.

Кажется, что работы на полчаса. Но стоит немного погрузиться в требования, и выясняется, что всё не так просто.

Представим, что нужно добавить кнопку отправки заявки.

Саму кнопку действительно можно реализовать за несколько минут. Но что должно происходить после нажатия?

Можно ли отправлять заявку повторно? Что делать, если сервер не отвечает? Нужно ли блокировать кнопку во время запроса? Как показать пользователю результат операции?

А если заявка уже изменила статус в другой вкладке? Или пользователь дважды нажал кнопку до завершения первого запроса?

И вот небольшая доработка интерфейса постепенно превращается в задачу с бизнес-правилами, управлением состоянием, обработкой ошибок и тестированием.

И что интересно, каждый из участников процесса по-своему прав.

Для пользователя это действительно одна кнопка.

Для бизнеса – возможность выполнить конкретное действие.

Для аналитика – требования, сценарии и ограничения.

Для разработчика – реализация, которая должна корректно работать в существующей системе.

До перехода в IT я несколько лет занимался продажами и управлением. И сейчас всё чаще замечаю, насколько полезным оказался этот опыт.

Когда работаешь с бизнес-процессами, постепенно привыкаешь смотреть на задачу не только с позиции исполнителя, но и с точки зрения проблемы, которую необходимо решить.

В разработке этот навык оказался не менее полезным.

Иногда один правильно заданный вопрос на этапе обсуждения требований экономит больше времени, чем последующая оптимизация кода.

Особенно когда за простой формулировкой скрываются пользовательские сценарии, которые изначально никто не предусмотрел.

И здесь, на мой взгляд, важна не только работа аналитика. Разработчику тоже полезно понимать предметную область, уточнять ограничения и предлагать альтернативные решения.

Ведь конечная цель не просто реализовать кнопку по описанию, а сделать так, чтобы пользователь мог корректно выполнить необходимое действие.

Конечно, это не означает, что каждую небольшую доработку нужно превращать в многочасовое обсуждение.

Но чем раньше команда обнаружит неоднозначности в требованиях, тем меньше вероятность, что они превратятся в ошибки после реализации.

С развитием ИИ этот вопрос становится ещё интереснее.

Агент может написать код такой кнопки буквально за несколько минут. Но если в постановке задачи не учтены ограничения и пограничные сценарии, скорость генерации сама по себе проблему не решит.

Более того, теперь можно гораздо быстрее получить технически рабочее решение, которое при этом не учитывает важные бизнес-требования.

И здесь снова приходится возвращаться к аналитике, проверке сценариев и пониманию того, как изменение повлияет на существующую систему.

Поэтому я всё больше убеждаюсь, что ценность разработчика не ограничивается умением писать код. Не менее важно понимать, какую задачу этот код должен решать.

А у вас бывали задачи, которые выглядели как изменение на полчаса, а в итоге превращались в полноценную разработку? 😅