Привет, я Настя, и я Product owner десктоп и вэб торговых терминалов в компании Exante. Я оказалась в компании почти 5 лет назад на позиции джуна тестирования и за эти годы прошла путь до лида тестирования платформ, а оттуда - в owner продукта. В этой статье я хочу поделиться своей историей роста в компании и подчеркнуть те действия, которые помогали мне двигаться вперед. Надеюсь, мой опыт будет полезен тем, кто хочет роста, но не знает, как к нему подступиться.
Предыстория
Предпосылки к становлению карьеры в финтехе были уже в 2008 году, когда я увлеклась финансовыми рынками. За десятилетие я набрала приличный опыт в торговле различными инструментами и взаимодействия с торговыми платформами множества брокеров. Для меня это было и остается хобби, которое помогает сохранить и приумножить капитал.
В 2019 году я работала в найме в сфере электронной коммерции и параллельно с этим училась на QA. Сразу после завершения обучения я приступила к поиску работы. Первая позиция по новой специальности была в одном известном российском поисковике - набивала в руку в тестировании, но не прекращала искать возможность уйти в финтех. Спустя пару месяцев со мной связались из Exante.
Компания искала джуна в тестировании, но с горящими глазами, со знанием торговли и пониманием работы торговых терминалов. И нашла.
Я искала компанию, в которой смогу с удовольствием начать свой карьерный путь QA в интересующей меня области. И нашла.
Часть 1. Извилистая QA тропинка
“Ручник” на фронте
Первые 2 года я занималась типичными обязанностями ручного QA фронта:
тест-дизайн,
само тестирование (во всех его проявлениях: начиная с тестирования требований, заканчивая регрессиями, интеграцией и аксептансами),
ведение вики,
участие во всех созвонах, коммуникациях, планированиях и what-not.
Сначала активности были сосредоточены на одном проекте - мобилках. Мне нравился продукт, я изучила его вдоль и поперек и подмечала малейшее отклонение от ожидаемого результата. Тот энтузиазм, с которым я подходила к качеству, сказался в итоге на сокращении количества инцидентов с прода, что не могло остаться незамеченным.
Постепенно я стала тестировать и все остальные терминалы - на десктопе и вэбе. Фронтовая экспертиза росла не по дням, а по часам, я получила возможность влиять на качество сразу всех торговых терминалов. С каждым Performance Review циклом мне доверяли больше ответственности на большем количестве проектов.
“А что внутри?”
Этим вопросом я стала задаваться чаще. В итоге это привело к желанию “потрогать” не только фронтовую часть приложений.
Архитектура многих наших проектов не ограничивается простым "дёрганьем апишки", чаще end-to-end тесты затрагивают 3, а то и 4 внутренних сервиса. В итоге, кроме фронтового тестирования я стала уходить глубже в интеграцию в попытках найти первичный источник информации. Для чего? Познать проект максимально полно и помогать локализовывать проблемы, принесенные с прода.
Я чаще стала взаимодействовать с разработчиками и архитекторами бэкенда. А в какой-то момент пришла к руководителю и попросила дать мне возможность потестировать внутрянку.
Уходить из фронтовой команды я, конечно же, не собиралась и не была к этому готова, но опасалась, что усидеть на двух стульях мне никто не даст. Однако опасения были напрасны: меня услышали, поняли и предложили компромиссный вариант, который устраивал всех.
Так из отдела интерфейсных QA я на несколько месяцев присоединилась part-time к коллегам из бэкенда.
В итоге все оказались в ситуации win-win:
на фронтах я всё ещё исправно выполняла всё, что от меня требовалось,
на бэке на меня можно было закладывать человекочасы на тест тасок при планировании скоупа,
ну а я удовлетворила свой интерес к внутренним проектам и чуть нарастила хард скилл (софт, если честно, тоже, потому что чем глубже в бэк, тем интровертнее специалисты).
Лидство
Экспертиза, наращенная за почти 3 года работы с торговыми терминалами в Exante, привела меня в менеджемент – мне доверили руководство небольшой командой тестировщиков на десктоп и вэб торговых терминалах. В спектр моих обязанностей теперь входило:
я всё ещё продолжала участвовать в тестировании проектов, но уже не так активно,
фокус больше сместился с продукта на процессы и команду - её поддержку, как моральную, так и с экспертной стороны,
помощь в расширении команды тестирования (собесы и оценка кандидатов),
менторство новичков,
больше времени стало также уходить на написание документации по проектам, FAQ для будущих поколений и общее развитие внутренней вики.
В итоге на этой роли моё дальнейшее развитие заставляло меня все больше углубляться в работу с командой. Через неполный год, пришло осознание, что хочется вернуть вектор внимания к влиянию на продукт, но не со стороны его качества, а скорее со стороны его наполнения, внешнего вида, функциональности.
Часть 2. Переход в продакты и тотальная смена деятельности
Старт
Продуктовый подход к разработке в Exante был в активной фазе развития. Был создан отдел, и набиралась команда продактов, каждый из которых отвечал бы за N проектов. Команду в первую очередь набирали из внутренних сотрудников, прежде чем обращаться к помощи рынка.
Руководитель отдела меня заметил, потому что:
Я не оставалась равнодушной к проекту ни на минуту. Часто вносила обоснованные предложения по улучшению существующего функционала, UX и дизайна.
Предлагала новые продуктовые идеи.
Переводила с творческого языка заказчика на ТЗшный язык разработчиков и обратно, чтобы обе стороны могли понять друг друга
Казалось бы, совсем небольшие шаги, но они вызвали отклик. Руководитель отдела совместно с представителями ТОП-менеджмента предложили мне переход из QA департамента в команду Product owner’ов.
Эксперимент
Ранее коммерческого опыта работы продактом у меня не было. Стало страшно переходить без релевантного опыта, знаний, понимания процессов и прямых обязанностей.
В дополнение, я не могла бросить одним днем департамент QA. Об этом я и сообщила на встрече с руководством, отвечая на вопрос о возможных препятствиях к переходу.
Совместно было решено провести эксперимент: я полностью делегировала тестирование команде тестировщиков, а высвободившееся время использовала на погружение в продуктовые обязанности. На первое время соотношение было 70 на 30 в пользу лидских обязанностей, но чуть больше, чем через месяц, дошло до 50/50.
Эксперимент продлился немногим меньше полугода, и по итогу я уже могла уверенно сказать, что Product management это то, чем бы мне хотелось заниматься в дальнейшем.
И снова все оказались в ситуации win-win:
как лид я всё еще исправно выполняла всё, что от меня требовалось,
в развивающейся продуктовой команде на меня уже можно было асайнить basic, а иногда даже и full discovery,
ну а я поборола страхи, узнала много нового и была готова к новым обязанностям.
Ожидания vs Реальность
Описание задач продакта в книгах, уже ставших классическими (например, Марти Каган и его "Вдохновленные" или Мелисса Перри "Продакт менеджмент без ошибок), сильно разнилось объемом и разнообразием задач, которое мне предстояло охватить.
Если в большинстве книг среди классических задач указываются исследования рынка, проверки гипотез, обоснование бизнес-вэлью предлагаемой фичи, плотная работа с дизайнерами, сбор продакшн фидбэка и некоторые другие, то в нашей команде продактов дополнительно выделяются еще некоторые большие таски. В какие из них я оказалась вовлечена:
Детальная проработка задачи и постановка ТЗ разработчикам.
Я создаю подробную документацию с описаниями поведения, BPMN и схемами, а также со ссылками на прото внутренних сервисов. Зачем? Потому что а) это избавляет разработчиков от необходимости отвлекаться и тратить время на исследование возможных путей интеграции, и б) я как овнер фичи могу контролировать, что задумка будет реализована в соответствии с изначальными требованиями.
Постоянное взаимодействие с разработкой и QA на всех этапах жизненного цикла фичи.
Кто, как не продакт, знает, как должна работать фича, и почему именно так, а не иначе. А в случае проблем с технической реализацией конкретного поведения – подумать над альтернативой. Что это дает? Слаженность во всём коллективе, потому что каждый знает что и как должно работать, а если не знает - то всегда имеет единый источник информации, общий для всех.
Описание фичей не только как ТЗ для разработки, но и продуктовое описание для внутренних сотрудников.
Которое, кстати, в дальнейшем служит отличной базой для коллег, занимающихся наполнением клиентских инструкций.
И некоторые другие, которые так или иначе связаны с тремя глобальными пунктами выше.
Также, меня поразило количество созвонов, которое меня ожидало почти каждый день. Первое время мне было тяжело от такого количества коммуникации. Но, на текущий момент, нам удалось сократить их продолжительность, не умаляя продуктивность. Решение оказалось простым – агенда. Теперь для каждого созвона у нас есть план, даже если он короткий – он есть. И напротив каждого пункта мы прописываем экшн айтемы, чтобы не потерять итоги наших обсуждений.
В итоге за год работы продактом мне удалось приложить руку к структуризации самих процессов и повлиять на общий флоу и результаты разработки фичей. Что здесь я бы отметила:
Время на деливери фичи сократилось за счет чуть увеличенного времени на дискавери, при том не изменившись по общему эстимейту (но с точки зрения бюджета стало выгодней, потому что детальная проработка помогла сэкономить время разработчиков).
Фичи стали детально описываться в конфле, и любой сотрудник может зайти и посмотреть, как фича работает.
Улучшается консистентность между платформами (там, где она безусловно нужна). Одна и та же фича на всех терминалах работает по одной и той же логике, даже в части корнер кейсов.
Созвоны по любым темам стали короче и продуктивнее, благодаря агенде и документарной фиксации принятых решений.
И это только начало. Каждую неделю мы проводим созвон продуктовой команды, на котором мы обсуждаем дальнейшие планы по развитию отдела, процессов, коммуникации, общих фичей и многих других аспектов нашей работы. И я чувствую, что мне есть, что привнести в каждый из этих аспектов.
Наш подход к задачам продактов и правда несколько обширнее общепринятого. И я вижу какие плоды он приносит – и мне, как сотруднику, постоянно ищущему возможности развития, и команде, которой стало проще и понятнее работать, и продукту, который я люблю и на потенциал которого влияю.
Заключение
Что я хотела всем этим сказать.
Развитие в компании существует всегда, нужно просто что-то делать для того, чтобы развиваться. Возможно, это прозвучит банально, но иногда и прописные истины надо повторять. Хочешь роста (неважно, вверх или в горизонталь):
Будь проактивным и проявляй себя. Бизнесу нужны заинтересованные люди, которые могут больше, чем просто хорошо делать свою работу.
Интересуйся продуктом больше, чем от тебя требуется. Ты можешь знать вдоль и поперек свою “ветку”, но если ты не полезешь глубже, ты не нарастишь экспертизу.
Развивайся. Способов миллион - общение с более опытными коллегами, книги, подкасты, блоги, курсы. Время на это можно найти всегда, деньги на развитие часто дает сама компания.
“Гори” своим проектом (в хорошем смысле). Если тебе не интересен тот продукт, которым ты занимаешься, вряд ли мотивации хватит на долгосрочную перспективу.
Не бойся говорить с руководством. Если тебе хочется двигаться дальше, обсуждай свои возможности. Для хороших специалистов всегда найдется компромиссное решение, которое сделает win-win и тебе и бизнесу.
P.S. я уверена, что будут и несогласные с тем, что я написала. Отмечаю – это не инструкция к действию, это моя история любви с продуктом и мое видение того, как должен работать рост (и как он со мной сработал в моей компании)