Перевести с технического языка на человеческий
Екатерина Ермакова,
инженер-аналитик САПР ТП ВЕРТИКАЛЬ
инженер-аналитик САПР ТП ВЕРТИКАЛЬ
Время чтения: 8 мин.
14 сентября 2026
Екатерина Ермакова работает в АСКОН 15 лет. Первый этап её жизни в компании был связан с тестированием системы проектирования технологических процессов ВЕРТИКАЛЬ, а затем она сменила роль на аналитика и сейчас участвует в создании новых версий продукта.
Из интервью вы узнаете:
- как опыт работы технологом на заводе помог влиться в разработку,
- что объединяет тестировщика и аналитика,
- как, с точки зрения аналитика, рождаются новые продукты.
Расскажите, с чего начинался ваш профессиональный путь.
Я отучилась в Коломенском филиале Московского Политеха по направлению «Технологии машиностроения», по образованию я инженер-технолог. Сразу после университета по целевому направлению вышла на работу на одно из градообразующих предприятий Коломны. Это и стало моей отправной точкой в профессии.
Я начинала в отделе главного технолога (позже в АСКОН мне очень пригодится этот опыт). Коллектив был сильный, но при этом в нем было очень комфортно работать. Меня сразу ввели в курс дела и закрепили за мной наставников — благодаря такой поддержке я начала быстро вливаться в процессы. Занималась написанием и согласованием технологических процессов, поддерживала ранее разработанные технологии в актуальном состоянии, следила за соблюдением технологической дисциплины. Работать было интересно.
Таким был мой первый опыт работы. А дальше коллега, с которой я познакомилась на заводе и которая уже перешла в АСКОН, предложила мне попробовать себя в роли тестировщика в разработке справочника Материалов и сортаментов. С одной стороны, было страшно: новое место работы и абсолютно неизведанное направление. С другой, это огромные возможности. Меня всегда завораживал мир разработки ПО. Но, как говорится, не попробуешь — не узнаешь. Решено — надо идти вперед!
Я отучилась в Коломенском филиале Московского Политеха по направлению «Технологии машиностроения», по образованию я инженер-технолог. Сразу после университета по целевому направлению вышла на работу на одно из градообразующих предприятий Коломны. Это и стало моей отправной точкой в профессии.
Я начинала в отделе главного технолога (позже в АСКОН мне очень пригодится этот опыт). Коллектив был сильный, но при этом в нем было очень комфортно работать. Меня сразу ввели в курс дела и закрепили за мной наставников — благодаря такой поддержке я начала быстро вливаться в процессы. Занималась написанием и согласованием технологических процессов, поддерживала ранее разработанные технологии в актуальном состоянии, следила за соблюдением технологической дисциплины. Работать было интересно.
Таким был мой первый опыт работы. А дальше коллега, с которой я познакомилась на заводе и которая уже перешла в АСКОН, предложила мне попробовать себя в роли тестировщика в разработке справочника Материалов и сортаментов. С одной стороны, было страшно: новое место работы и абсолютно неизведанное направление. С другой, это огромные возможности. Меня всегда завораживал мир разработки ПО. Но, как говорится, не попробуешь — не узнаешь. Решено — надо идти вперед!
Как воспринимался такой переход из инженеров в IT-специалисты?
Скажу честно — непросто. Поначалу процессы были мне незнакомы, а сама разработка казалась чем-то недосягаемым. И хотя я была технологом и пришла тестировать именно технологическое решение и его приложения, ранее я с этим продуктом не сталкивалась, на моей предыдущей работе использовались другие системы.
В первую очередь нужно было обучиться. Чтобы выполнять тестирование, требовалось понимать, с какими продуктами я буду работать. Но несмотря на то, что я была новый человек в IT, с самого начала мне было комфортно. Меня окружила команда профессионалов, на чью поддержку я всегда могла — и могу сейчас — рассчитывать.
Скажу честно — непросто. Поначалу процессы были мне незнакомы, а сама разработка казалась чем-то недосягаемым. И хотя я была технологом и пришла тестировать именно технологическое решение и его приложения, ранее я с этим продуктом не сталкивалась, на моей предыдущей работе использовались другие системы.
В первую очередь нужно было обучиться. Чтобы выполнять тестирование, требовалось понимать, с какими продуктами я буду работать. Но несмотря на то, что я была новый человек в IT, с самого начала мне было комфортно. Меня окружила команда профессионалов, на чью поддержку я всегда могла — и могу сейчас — рассчитывать.
Какие задачи вы решали в первое время?
Когда человек только входит в профессию, ему сначала дают простые задачки. Он набирается опыта. Так было и со мной. Начала я с базовых задач по проверке функционала и вычитке документации. Со временем задачи стали усложняться, а набор тестируемых продуктов и приложений заметно расширился. Вскоре в зону моей ответственности вошло ключевое решение ВЕРТИКАЛЬ.
Но главной сложностью было то, что мало найти баг в ПО – его нужно зафиксировать так, чтобы другим участникам команды была понятна моя аргументация. А в некоторых случаях нужно было уметь признать: «Здесь я перестаралась, это не ошибка».
А как в течение этих лет изменялись инструменты, которые вам требуются для работы?
Когда я только начинала, мы использовали багтрекер БОиП (База ошибок и предложений), сейчас его помнят только старожилы. Со временем на смену пришли Jira и Confluence. Поначалу «переезжать» было сложно, но это только первые впечатления. Сейчас без них свою работу я не представляю.
К тому же, когда я пришла в АСКОН, команда разработки ВЕРТИКАЛЬ была малочисленной, все работали из одного офиса, так что дополнительных инструментов для связи друг с другом нам не требовалось. Ковидные времена привели к тому, что команда стала территориально распределенной. И здесь подключились средства видео-конференц-связи, без которых сейчас уже не обойтись.
Инструменты разные нужны, инструменты разные важны. Так, для глубокого понимания некоторых инженерных и технологических процессов мне необходимы редкие профильные издания и архивные стандарты, которые ещё не оцифрованы. Поэтому на днях я освоила ещё один уникальный «инструмент» — оформила читательский билет в Российскую государственную библиотеку (Ленинку).
Что вам особенно нравится в тестировании?
Азарт при поиске «неуловимых», плавающих багов. Бывает, проходишь сценарий и находишь ошибку. Но золотое правило тестировщика — проверить ее воспроизводимость. И вот при повторных попытках дефект то проявляется, то нет. Но я же знаю, что он был! Тогда я начинаю раскручивать цепочку шагов заново: что было на входе, какие особенности продукта могли повлиять на результат. И вот она, удача — 100% воспроизводимость!
Еще приятно удивляет, как пользователи работают с продуктом. Наше ПО легко адаптируется, и заказчики часто расширяют его возможности. В такие моменты понимаешь, насколько гибкую систему мы создаем. Для меня как для тестировщика это отличный опыт для расширения сценариев тестирования.
Недавно вы сменили специализацию и стали аналитиком. Как произошел этот переход?
Мой переход в аналитику был плавным. Работая тестировщиком, я начала замечать в продукте не совсем удобные или логичные места. Так, помимо фиксации ошибок, стали появляться первые предложения по улучшению. Накопленный практический опыт давал мне возможность находить правильные ответы на вопросы, возникающие в процессе разработки. К тому же, мне очень помог мой опыт работы технологом, потому что у меня уже было понимание, как должно себя вести решение. Видишь, что где-то работать неудобно и это можно поменять. Например, зачем мне как пользователю кликать несколько раз, когда можно обойтись одним действием?
На мой взгляд, главная задача аналитика — перевести требования заказчика с технического языка на человеческий, а затем сопроводить реализацию и выполнить приемку. Работая в тестировании, я в какой-то момент начала неофициально проходить все эти этапы, действуя как «серый кардинал». Теперь же эти задачи закреплены за мной официально.
Меня завораживает, как в процессе работы буквально из ничего рождается решение. Сначала идет сбор информации и формирование требований к ПО, затем — презентация и защита проекта перед командой. Как аналитик я определяю, как будет выглядеть и работать новая фича. А потом наблюдаю, как создаются первые прототипы, выполняется макетирование — и это уже не просто текст на бумаге, а первый работающий образец. Постепенно рождается одна функциональность, за ней другая, и со временем они объединяются. И вот перед нами машина, которая поехала и успешно выполняет задачи пользователя! А когда приходят хорошие отзывы от клиентов — понимаешь, что всё было сделано правильно.
Когда человек только входит в профессию, ему сначала дают простые задачки. Он набирается опыта. Так было и со мной. Начала я с базовых задач по проверке функционала и вычитке документации. Со временем задачи стали усложняться, а набор тестируемых продуктов и приложений заметно расширился. Вскоре в зону моей ответственности вошло ключевое решение ВЕРТИКАЛЬ.
Но главной сложностью было то, что мало найти баг в ПО – его нужно зафиксировать так, чтобы другим участникам команды была понятна моя аргументация. А в некоторых случаях нужно было уметь признать: «Здесь я перестаралась, это не ошибка».
А как в течение этих лет изменялись инструменты, которые вам требуются для работы?
Когда я только начинала, мы использовали багтрекер БОиП (База ошибок и предложений), сейчас его помнят только старожилы. Со временем на смену пришли Jira и Confluence. Поначалу «переезжать» было сложно, но это только первые впечатления. Сейчас без них свою работу я не представляю.
К тому же, когда я пришла в АСКОН, команда разработки ВЕРТИКАЛЬ была малочисленной, все работали из одного офиса, так что дополнительных инструментов для связи друг с другом нам не требовалось. Ковидные времена привели к тому, что команда стала территориально распределенной. И здесь подключились средства видео-конференц-связи, без которых сейчас уже не обойтись.
Инструменты разные нужны, инструменты разные важны. Так, для глубокого понимания некоторых инженерных и технологических процессов мне необходимы редкие профильные издания и архивные стандарты, которые ещё не оцифрованы. Поэтому на днях я освоила ещё один уникальный «инструмент» — оформила читательский билет в Российскую государственную библиотеку (Ленинку).
Что вам особенно нравится в тестировании?
Азарт при поиске «неуловимых», плавающих багов. Бывает, проходишь сценарий и находишь ошибку. Но золотое правило тестировщика — проверить ее воспроизводимость. И вот при повторных попытках дефект то проявляется, то нет. Но я же знаю, что он был! Тогда я начинаю раскручивать цепочку шагов заново: что было на входе, какие особенности продукта могли повлиять на результат. И вот она, удача — 100% воспроизводимость!
Еще приятно удивляет, как пользователи работают с продуктом. Наше ПО легко адаптируется, и заказчики часто расширяют его возможности. В такие моменты понимаешь, насколько гибкую систему мы создаем. Для меня как для тестировщика это отличный опыт для расширения сценариев тестирования.
Недавно вы сменили специализацию и стали аналитиком. Как произошел этот переход?
Мой переход в аналитику был плавным. Работая тестировщиком, я начала замечать в продукте не совсем удобные или логичные места. Так, помимо фиксации ошибок, стали появляться первые предложения по улучшению. Накопленный практический опыт давал мне возможность находить правильные ответы на вопросы, возникающие в процессе разработки. К тому же, мне очень помог мой опыт работы технологом, потому что у меня уже было понимание, как должно себя вести решение. Видишь, что где-то работать неудобно и это можно поменять. Например, зачем мне как пользователю кликать несколько раз, когда можно обойтись одним действием?
На мой взгляд, главная задача аналитика — перевести требования заказчика с технического языка на человеческий, а затем сопроводить реализацию и выполнить приемку. Работая в тестировании, я в какой-то момент начала неофициально проходить все эти этапы, действуя как «серый кардинал». Теперь же эти задачи закреплены за мной официально.
Меня завораживает, как в процессе работы буквально из ничего рождается решение. Сначала идет сбор информации и формирование требований к ПО, затем — презентация и защита проекта перед командой. Как аналитик я определяю, как будет выглядеть и работать новая фича. А потом наблюдаю, как создаются первые прототипы, выполняется макетирование — и это уже не просто текст на бумаге, а первый работающий образец. Постепенно рождается одна функциональность, за ней другая, и со временем они объединяются. И вот перед нами машина, которая поехала и успешно выполняет задачи пользователя! А когда приходят хорошие отзывы от клиентов — понимаешь, что всё было сделано правильно.
Как между собой связаны аналитик и тестировщик?
Аналитик формирует видение того, каким продукт должен стать, а тестировщик на основе этого описания проверяет, как реализовано задуманное. При этом аналитик по результатам разработки сам выполняет приёмку готового решения — по факту проводит его обобщённое тестирование. В свою очередь, тестировщик, анализируя требования или тестируя готовый продукт, может предложить оптимизировать сценарий работы, предоставив необходимые аргументы.
В итоге аналитик и тестировщик связаны одной целью — создать функциональный, удобный и эффективный программный продукт.
А помогает ли как-то опыт в тестировании?
Безусловно, опыт в тестировании дает огромное преимущество. Когда я работала тестировщиком, в круг моих обязанностей входил в том числе анализ требований, то есть я была по одну сторону баррикад. Теперь, при постановке задач, я оказалась по другую. При написании требований я заранее думаю о том, как команда будет их проверять. Мне всегда хочется предоставить коллегам расширенные тестовые данные и описать негативные сценарии, чтобы облегчить работу и разработчикам, и тестировщикам. И мой прошлый опыт помогает мне с этим справляться.
Аналитик формирует видение того, каким продукт должен стать, а тестировщик на основе этого описания проверяет, как реализовано задуманное. При этом аналитик по результатам разработки сам выполняет приёмку готового решения — по факту проводит его обобщённое тестирование. В свою очередь, тестировщик, анализируя требования или тестируя готовый продукт, может предложить оптимизировать сценарий работы, предоставив необходимые аргументы.
В итоге аналитик и тестировщик связаны одной целью — создать функциональный, удобный и эффективный программный продукт.
А помогает ли как-то опыт в тестировании?
Безусловно, опыт в тестировании дает огромное преимущество. Когда я работала тестировщиком, в круг моих обязанностей входил в том числе анализ требований, то есть я была по одну сторону баррикад. Теперь, при постановке задач, я оказалась по другую. При написании требований я заранее думаю о том, как команда будет их проверять. Мне всегда хочется предоставить коллегам расширенные тестовые данные и описать негативные сценарии, чтобы облегчить работу и разработчикам, и тестировщикам. И мой прошлый опыт помогает мне с этим справляться.
Кто еще сейчас входит в ваш круг профессионального общения?
Я считаю, что у команды ВЕРТИКАЛЬ уникальное положение. Поскольку продукт интегрирован со всеми системами, составляющими PLM-решение АСКОН, недостатка в общении у меня точно нет.
Во-первых, абсолютно все участники нашей внутренней команды открыты.
Во-вторых, специфика продукта требует диалога со смежными командами. Если раньше, на позиции тестировщика, мой круг общения в основном ограничивался разработчиками и коллегами по тестированию, то с изменением роли он заметно расширился — добавились аналитики со стороны других систем.
Чтобы продукт работал корректно, мы руководствуемся принципом «семь раз отмерь — один раз отрежь». Написанию кода предшествует детальное командное обсуждение.
Я считаю, что у команды ВЕРТИКАЛЬ уникальное положение. Поскольку продукт интегрирован со всеми системами, составляющими PLM-решение АСКОН, недостатка в общении у меня точно нет.
Во-первых, абсолютно все участники нашей внутренней команды открыты.
Во-вторых, специфика продукта требует диалога со смежными командами. Если раньше, на позиции тестировщика, мой круг общения в основном ограничивался разработчиками и коллегами по тестированию, то с изменением роли он заметно расширился — добавились аналитики со стороны других систем.
Чтобы продукт работал корректно, мы руководствуемся принципом «семь раз отмерь — один раз отрежь». Написанию кода предшествует детальное командное обсуждение.
Читайте также
Подпишитесь на наши новости