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

Немного обо мне

Меня зовут Дарья Нилова, я специалист по обеспечению качества ПО в компании CUSTIS.

В тестирование я пришла сразу после университета. Я закончила Российский государственный гидрометеорологический университет (РГГМУ), Институт информационных систем и геотехнологий (ИСиГТ), в котором мне дали хорошую техническую базу по всему циклу разработки. То есть у меня были навыки системного аналитика, но исключительно теоретические.

На момент проведения эксперимента я работала чуть больше полутора лет в качестве тестировщика на проекте по разработке приложения для управления материально‑техническими ресурсами в нефтегазе. За это время я уже довольно хорошо изучила продукт со всеми его достоинствами и слабыми местами.

Как я оказалась в роли аналитика

У меня был достаточный опыт работы на проекте и понимание его особенностей. На протяжении шести месяцев перед этим я активно тестировала постановки и требования.

Получалось, в общем‑то, довольно хорошо: я находила как незначительные ошибки, так и довольно критичные проблемы. Нередко предлагала свои варианты решения, что положительно сказывалось на качестве системы.

Затем мы начали разрабатывать новую интеграцию с другим сервисом — системой SAP. В первые два месяца, пока велась аналитика, тестировать было ещё нечего. А аналитикам как раз нужны были свободные руки! В качестве эксперимента мне предложили попробовать новую для меня роль на проекте, и я согласилась.

Какие обязанности у меня появились

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

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

До этого у меня хорошо получалось предлагать идеи решения каких‑то наших проблем и доработок. Но были и такие места, где я могла только описать саму проблему. Придумать решение для неё и мне, и аналитикам было слишком тяжело, и эти места оставлялись «на светлое будущее» в надежде, что это буду решать не я :D

Но часть из них, как уже можно догадаться, всё равно досталась мне.

С какими сложностями я столкнулась и как справилась с ними

Задачи казались абстрактными и размытыми

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

Если раньше в проекте интеграция функционировала через выгрузки Excel, и информация по всем внутренним операциям была перемешана, то при переходе на прямую интеграцию с SAP каждый тип операций передаётся в отдельном потоке. А значит, невозможно было сделать новый вид передачи данных один в один. Нужно было переопределить, какие операции к каким потокам относятся, их новый атрибутивный состав, так как он тоже отличался. В том числе зафиксировать, какие атрибуты обязательные и необязательные, и как они соотносятся в разных системах.

Я не всегда понимала:

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

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

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

Что мы делали:

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

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

Обострённое чувство ответственности

Второй момент, преодоление которого далось мне достаточно тяжело, — обострённое чувство ответственности. Хоть это и был эксперимент, задачи были реальными, и от их выполнения зависело качество системы и возможные переделки в будущем. А так как наши доработки затрагивали основной функционал, цена ошибки была довольно высока.

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

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

Поддержание продуктивности

Новая сфера требовала от меня постоянной высокой концентрации, приходилось работать с огромным объёмом новой информации, на что уходило много сил.

Чтобы не перегорать, я со временем выработала для себя способ, который помогал мне поддерживать и психологическое состояние, и достаточный уровень продуктивности. Периодически я переключалась на более привычные для меня задачи — тестирование и разбор инцидентов. То есть делала что-то понятное и простое, и это помогало немного расслабиться и отвлечься от сложных задач, «перезагрузить» мозг.

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

Плюсы и минусы эксперимента

Начнём с минусов:

Переход в новую роль в целом был для меня тяжёлым и отнимал много сил. Новая сфера требовала большой концентрации, учила мыслить по-новому, постоянно анализировать и пропускать через себя большой объём информации.
Почти месяц ушёл у меня на притирку к новым задачам и оптимизацию процессов моей работы.
Даже с учётом оптимизации процессов, я всё равно работала медленнее, чем наш основной аналитик.
При этом сохранялись риски для команды: если бы я где-то допустила ошибку, стоимость исправлений могла быть высокой.

А теперь плюсы:

Даже с учётом того, что я работала не очень быстро, это всё равно дало большой буст по ресурсам для команды в тот период, когда сроки по аналитике горели.
В процессе работы я ещё сильнее углубилась в бизнес-процессы нашего продукта и сильно улучшила свои знания системы.
Я и раньше знала, что работа аналитика сложна и требует большого количества навыков, но убедившись в этом на собственном опыте, прониклась ещё большим уважением к своим коллегам.
И самое важное, что я приобрела для себя в этом опыте, как бы очевидно это ни звучало, — осознание того, что все постановки и требования пишут люди, которые тоже могут ошибаться и упускать что-то важное. И это, на самом деле, нормально и не так уж страшно, когда ты работаешь в сильной команде. Потому что любая успешная доработка или баг на проде — это результат командной работы, где важен вклад каждого. Благодаря такому «открытию» я научилась критичнее и внимательнее смотреть на всю документацию и процессы, с которыми работаю, что очень помогает следить за качеством продукта и всех новых доработок.
С того момента, как эксперимент был завершён и я полностью вернулась к тестированию, прошло полгода. Все доработки, сделанные по моим постановкам, прошли тестирование и период эксплуатации без каких-либо проблем.

Выводы

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

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

Временный переход тестировщика в аналитики: неожиданные плюсы и очевидные минусы