За 14 лет работы разработчиком я ни разу не работала в компании, где мне просто выдавали готовое техническое задание, а дальше оставалось только написать код. Я знаю, что такие компании существуют. Крупные продуктовые команды, где между разработчиком и пользователем стоят аналитики, продакты и руководители проектов. Но почему-то мне всегда попадалась другая реальность. Обычно всё начиналось примерно так: — Нужно сделать отчёт. Какой именно? — Ну такой, чтобы показывал всё. Что именно должен показывать? — Сейчас объясню… И через полчаса разговора выясняется, что проблема вообще не в отчёте. За эти годы я поняла одну вещь. Самый дорогой навык разработчика — не программирование. Не знание языка. Не сертификаты. Не количество технологий в резюме. Самый дорогой навык — умение понять, что на самом деле нужно человеку. Потому что если на старте не разобраться в задаче, дальше уже неважно, насколько хорошо написан код. Можно сделать идеальное решение. Без ошибок. Быстрое. Красивое. Удобное. Но если оно решает не ту проблему, заказчик всё равно останется недоволен. И наоборот. Иногда один правильно заданный вопрос экономит больше времени, чем несколько дней разработки. С опытом начинаешь замечать интересную вещь. Появляется профессиональная интуиция. Пользователь начинает объяснять задачу, а ты уже где-то на второй минуте разговора понимаешь, к чему всё идёт. Не потому что умеешь читать мысли. Просто многие ситуации уже встречались раньше. Бухгалтер начинает рассказывать про отчёт, а ты уже вспоминаешь похожий кейс двухлетней давности. Руководитель говорит, что ему нужен новый документ, а ты понимаешь, что проблема вообще не в документе, а в процессе согласования. Пользователь просит автоматизировать операцию, а через несколько уточняющих вопросов выясняется, что автоматизировать нужно совсем другой участок работы. Конечно, это не работает в 100% случаев. Ошибки бывают у всех. Иногда кажется, что всё понял правильно, а потом оказывается, что нет. Но именно опыт общения с людьми постепенно начинает приносить больше пользы, чем знание очередного механизма платформы. Иногда мне говорят, что выявление требований — это задача аналитика, а разработчик должен просто реализовать готовое техническое задание. Возможно, в крупных продуктовых командах так и происходит. Но за 14 лет работы я редко сталкивалась с такой моделью. Чаще всего разработчику приходится самому разбираться в процессах, задавать вопросы, искать противоречия в требованиях и помогать пользователю сформулировать задачу. Поэтому со временем начинаешь понимать, что разработка — это не только про код. Это ещё и про умение быть переводчиком между бизнесом и системой. Пользователь говорит на языке своих процессов. Система говорит на языке данных и алгоритмов. А разработчику приходится понимать оба языка. Наверное, поэтому я никогда не воспринимала коммуникацию как что-то второстепенное. Для меня разговор с пользователем — это не препятствие перед разработкой. Это часть разработки. Потому что хороший код начинается не с первой строчки программы. Он начинается с понимания задачи. И чем раньше удаётся понять, что действительно нужно человеку, тем выше шанс, что результат устроит всех участников процесса.