«Ответственность должна быть на инженерах, которые пишут код». Почему в People.ai отказались от QA-команды и что это дало
[От редакции. Чтобы разговор получился интересным, мы пригласили провести интервью Дмитрия Шпаковского, Senior Software Engineer in Test в SurveyMonkey, специалиста с 10+ годами опыта в индустрии, автора книги «Modern Web Testing with TestCafe»]
Четыре года назад в People.ai решили отказаться от QA-команды, и с тех пор каждый разработчик должен сам не только писать, но и тестировать свой код. Интересно, что после этих изменений, как рассказали нам в компании, релизы существенно ускорились, количество багов уменьшилось, а те, которые появляются, фиксить намного легче.
Мы пообщались с СТО People.ai Андреем Аксельродом и Data Engineer Татьяной Луцаевской, которая раньше была в составе команды QA. Расспросили их подробнее о том, при каких условиях этот подход работает, какие были сложности, когда тестированием занимались не разработчики, а также стоит ли, по их мнению, начинать свою карьеру в QA.
Татьяна Луцаевская и Андрей Аксельрод
Команда People.ai разрабатывает Revenue Operations and Intelligence платформу, которая повышает эффективность бизнеса с помощью искусственного интеллекта. Система автоматизирует сбор и анализ данных деловой активности и превращает их в рекомендации, которые ведут к более успешным продажам. Компания была основана в 2016 году Олегом Рогинским. Сейчас в ней работает порядка 200 человек, из них почти 50 инженеры. Есть ряд офисов в разных городах: в Киеве, Торонто, Сан-Франциско, Нью-Йорке и Лос-Анджелесе. Техническая команда находится в Сан-Франциско, Киеве и Торонто.
«Главное, что нам нужно было сделать — уйти от схемы „релиз каждую вторую неделю“»
— Как выглядел процесс разработки до решения отказаться от QA-команды? Какие были основные сложности? Какой был тогда состав инжиниринг-команды?
Татьяна: Мы отказались от QA в августе 2017 года. На тот момент в команде было не больше
Процесс разработки выглядел стрессово. Мы планировали фичи, как правило, на две-три недели вперед. Это довольно большой кусок работы, занимались им всей командой, затем тестировали и показывали клиентам — выбирали конкретный день для релиза. В этот день сейлз-, саппорт-команды мониторили, нет ли у заказчиков проблем со входом в систему. После релиза обычно всплывало много багов, клиенты жаловались.
Главная сложность этого подхода состояла в том, что слишком много всего было выпущено в релиз сразу. Обычно на этапе тестирования вылезало большое количество ошибок и мы не успевали их фиксить вовремя.
Сложных ситуаций было много. Могло, например, что-то сломаться в core-части, от которой зависят другие системы, и при тестировании появлялось множество багов (feature-флаги у нас были, но с core-частью они не помогут). При этом бывало, что у Олега Рогинского, нашего фаундера, через несколько дней после планирования релиза уже был назначен customer call, на котором он должен был презентовать новую фичу. Но часто из-за багов он не мог это сделать. Тогда либо приходилось переносить созвон, либо зачастую разработчики ночами не спали и чинили что-то. Потом говорили: «Олег, только не нажми случайно на эту штучку, мы тут еще дофикшиваем». Такое было почти с каждым релизом.
— Решение отказаться от QA было как-то связано с экономической ситуацией, кризисом или это было чисто техническое решение?
Андрей: Решение я принял, когда пришёл в компанию 4 года назад и реорганизовал инженерную команду. С деньгами это вообще никак не связано — только с правильной организацией работы.
— Как выглядит процесс разработки сейчас, после отказа от QA? Какие кардинальные изменения произошли?
Андрей: QA-команда у нас перестала существовать как класс. Мы предложили всем переквалифицироваться в инженеров и поддержали в этом. Два человека пошли по этому пути, еще двое ребят решили уйти из компании и продолжать карьеру в QA.
Что очень интересно — качество продукта без отдельной QA-команды даже улучшилось, хотя можно было бы предположить обратное. Главное, что нам нужно было сделать — уйти от схемы «релиз каждую вторую неделю». Это ключевое. Раньше у нас был
Получается, что цикл выхода нового кода в продакшн — месяц вместо запланированных двух недель. Две недели — это уже безумно много, месяц — вообще нереально. Стартапы так работать не могут и не должны. Одна из самых важных вещей — это скорость реакции на фидбэк, скорость цикла: выбрасываешь на продакшн, получаешь обратную связь от пользователя, обрабатываешь ее, делаешь что-то новое, выбрасываешь снова, снова смотришь отзыв. Чем быстрее этот жизненный цикл, тем быстрее стартап находит Product-Market Fit.
Давайте сравним два стартапа. Один заливает код 10 раз в день и получает оперативную обратную связь на то, что было залито. Получается, что полный цикл может быть закрыт за
Еще один важный момент — перенос ответственности. Когда у вас отдельные команды — QA и инженерная, кто ответственный за ошибку? Инженер, который сделал ошибку, или QA, который не нашёл ее и запустил в продакшн? Дима, как ты думаешь?
— Риторический вопрос, но я как последователь ISTQB, буду немножко адвокатом QA в этом случае. Постулат такой, что ты никогда не найдёшь 100% багов и это нормально, твоя роль как QA — максимально снизить риски, но не устранить всё, потому что время у нас не бесконечное. И второй постулат говорит о том, что качество — это общее дело, поэтому ответственность лежит равномерно на всей инженерной команде, QA — такие же инженеры, как и остальные разработчики.
Андрей: Я уважаю твою точку зрения, при этом считаю, что ответственность должна быть на инженерах, которые пишут код. Что происходит, когда ответственность общая? Знаешь высказывание «у семи нянек дитя без глаза»? Именно так и случается, потому что, на ком ответственность — абсолютно непонятно. Инженер говорит: «Ну, QA дотестит». А QA не в состоянии всё дотестить, он же не сидит у программиста в голове и не понимает, как работает каждый Loop Statement. Поэтому ответственность всегда на инженерах, и нужно было, чтобы они полностью осознали, что больше не будет человека, который сможет найти баг. Я это называю babysitting.
Еще один момент — что происходит в случае emergency, если ответственность размыта? Допустим, ночью возникла проблема. Что сделает нормальный инженер? Ночью что-то исправит на скорую руку, а утром встанет и первым делом полностью решит проблему. Если же ответственность будет, например, на SRE, он что-то там ночью сделает, но инженер следующим же утром эту проблему наверняка решать не станет. Он ее не прочувствовал. Поэтому важно, чтобы ответственность была на тех людях, которые пишут код. И, соответственно, любые фиксы приходили инженерам и не было никаких недопониманий с 7 няньками.
«Появилось правило: все фичи должны быть обязательно покрыты unit-тестами»
— Какой раньше использовали подход к разработке? Как поддерживалась синхронизация распределенной команды?
Татьяна: Это было больше похоже на гибридную модель. Мы старались работать по Scrum, но, например, не проводили некоторые ретроспективы.
У нас было несколько разработчиков в Украине и еще два разработчика — в Сан-Франциско. Иногда случалось так, что украинская команда начинала что-то тестировать, а потом утром американская команда это замечала и говорила: «А мы это уже оттестировали». В этом плане синхронизация была немного нарушена, мы старались больше синкапиться на митингах. Проблема была из-за того, что планирование релиза происходило батчами, каждый брал свою часть работы, шел в свой уголок и делал, лишь бы успеть к релизу.
Сейчас мы серьезно отладили Scrum-процесс, поэтому и распределенная работа происходит эффективно, работоспособность не снижается. Сейчас имеем качественное планирование, и специалисты уже не идут договариваться между собой и делать что-то отдельно. Я бы сказала, что при правильном Scrum-процессе работа значительно улучшилась.
— Как выглядело распределение структуры тестирования до отказа от QA и после? Я имею в виду пирамиду тестирования unit — integration — end-to-end.
Татьяна: До отказа от QA у нас в основном тестировали только QA. Ответственные инженеры могли добавить какие-то unit-тесты, но такого требования к ним не было.
Сейчас, если в редких случаях нужно что-то протестировать, перепроверить — это дело Technical Support команды. У нас есть QA-канал в Slack, но там чисто support-вопросы. К примеру: «Ребята, я не понимаю, как эта вещь работает» или «Я думаю, у меня баг». В 90% случаев это вопросы от новичков — Sales или Customer Support.
Разработчики тестируют свой код сами. Если кто-то делает commit, это обязательно должен проверить кто-то еще из команды. Есть чек-лист, по которому мы идем. Например, создали какие-то новые функции — надо проверить, на каждую ли функцию есть unit-тесты. Деливерим маленькими итерациями, чтобы было легче ревьюить PRы. Я в бэкенд-команде, мы пишем unit-тесты, функционально-интеграционные тесты.
Каждый инженер формирует свой подход к тестированию, в зависимости от того, чем он занимается. Также мы пользуемся up-time системами, например PagerDuty. Если сломается что-то критическое — получаем alert. Разработчики по очереди следят за уведомлениями, кто дежурит — тот и отвечает за решение проблемы. Сейчас у нас каждый инженер на on-call неделю. Раньше дежурили сутки, но в некоторых командах пошло перекидывание ответственности: сейчас уже поздно, следующий посмотрит проблему. Поэтому сделали on-call на неделю.
Есть очень маленький процент ручного тестирования — только если нужно edge case проверить. Но в основном этим Support-команда занимается, когда что-то хочет перепроверить, посмотреть, исследовать. Немало внимания мы уделяем мониторингу качества данных. В каждой команде это есть.
— Как вы делали переход от состояния «unit-тесты есть только у трудолюбивых счастливчиков» до «всё покрыто unit-тестами». Как доносили это команде и как масштабировали? Как выделяли время и ресурсы под это?
Татьяна: Как раз в том году, когда мы отказались от QA, нанимали новых инженеров, многих из Кремниевой долины. Им ничего не нужно было объяснять, они знают, что должны сами тестировать код. С этим не было проблем.
Со временем у нас появилось правило: все фичи должны быть обязательно покрыты unit-тестами. Если вдруг кто-то скажет: «Мне нужно срочно это зарелизить, но я тесты добавлю потом», Senior-инженеры, лиды просто не пропустят такой PR. Они скажут: «Окей, возьми ещё один день, напиши, пожалуйста, эти тесты сейчас».
— То же касалось и legacy-кода, на котором не было тестов, но он работал? То есть вы выделяли конкретных людей, которые доставали этот код и покрывали тестами?
Татьяна: Нет, отдельно мы этого не делали, все было в процессе. Допустим, вы добавляете новую фичу и она завязана на другие. Что-то падает — вы идете, фиксите и пишете тесты на уже существующие фичи, от которых она зависима. Тут дело только в ответственности. Таким образом, мы покрывали legacy code тестами постепенно.
«У нас изменилась культура ответственности за свои действия»
— Какие сложности возникают сейчас, после отказа от QA?
Татьяна: Не сказала бы, что сейчас есть сложности. Все-таки прошло уже 4 года с тех пор, как мы отказались от QA. Многие инженеры поменялись, пришли новые. Они уже точно знают, что должны сами тестировать свой код. Просто если раньше программисты еще долго исправляли за собой ошибки, то сейчас они меньше это делают, но пишут больше тестов.
Андрей: Из сложностей — у нас до сих пор есть проблема с тем, чтобы была стабильная среда для интеграционного тестирования. Это то, чему нам стоит уделять больше внимания. Но в целом мы очень удачно перешли на новый режим работы. Инженеры, которые его не принимали, со временем ушли. Сейчас это уже всем очевидно: ты, как инженер, делаешь собственное тестирование как часть процесса разработки. Когда деплоишь код в продакшн, должен руками проверить, работает ли он. На собеседования иногда приходят инженеры, которые считают, что QA должен ходить за ними и бейбиситить, но редко.
— Что изменилось в требованиях к разработчикам при найме и как вы распознаёте «своих» людей, которые точно подходят в команду?
Андрей: У нас изменилась культура ответственности за свои действия. Мы ищем инженеров, которым она подходит. Можно задать кандидату вопрос о QA: какой у него взгляд на эти вещи. Если человек говорит: «Я считаю, что должен быть QA», я его спрашиваю: «Как вы относитесь к тому, что у нас его нет». И тогда уже обсуждаем это, и человек либо принимает эту философию, либо нет.
То же самое про being on-call. В Долине все инженеры знают, что они ответственны за дежурства. В Украине время от времени встречаются специалисты, у которых нет понимания, что это нужно делать. Мне кажется, это отчасти из-за аутсорсингового мировоззрения.
Где-то через месяц после того, как берем нового человека, я всегда задаю ему вопрос: «Совпали ли ваши ожидания о компании, которые сформировались во время собеседования, с тем, что вы получили, когда вышли на работу?». Для меня очень важно, чтобы ожидания и реальность совпадали. Это значит, что мы не завышаем оценку компании на интервью. Несколько раз мы не сказали про on-call на собеседованиях, и, когда инженеры присоединялись к команде, это для них стало сюрпризом. Очевидно, они этого не делали раньше. Поэтому мы адаптируем процесс найма так, чтобы у людей не было диссонанса и они знали, чего ожидать.
— Какие у вас технические требования к разработчикам, какой стек нужно знать, может, в этот стек добавилось что-то в связи с необходимостью тестировать?
Андрей: Мы не требуем конкретный стек, мы считаем, что любой Senior-инженер должен писать на нескольких языках программирования. Мы ищем generalists, которые прежде всего заинтересованы в том, чтобы развивать компанию, и уже во вторую очередь — в конкретных технологиях. Мы используем те, которые нужны для решения задач, исходя из проблем бизнеса. Поэтому ищем инженеров, способных переключаться между разными языками и находить правильные технологии под конкретные бизнес-потребности.
Если посмотреть на наш стек, там есть Java, Scala, Python, Spark и еще миллион всего. Ищем ли мы людей, которые пишут конкретно на Python? Нет. Мы верим, что любой инженер может быстро начать писать на Python без особых проблем. Большинство специалистов в Кремниевой долине имеют такое же мировоззрение, и они абсолютно свободно переключаются между разными языками программирования.
Есть специалисты, которые приходят и говорят: «Хочу писать только на Java». Это означает, что человек не совсем подходит под нашу культуру. Он заинтересован в том, чтобы развивать свои навыки в определённом направлении, а не в том, чтобы помочь строить компанию. В то же время такой подход помогает инженерам развиваться в разных направлениях.
У меня есть определенная философия о том, кого нанимать в стартапы. Сейчас мы middle stage startup, тогда — 4 года назад — были early stage. Так вот, многие early stage стартапы либо не могут себе позволить нанять Senior-специалистов, либо у них не получается. Зачастую они говорят: «У нас мало денег, поэтому возьмем джуниоров». Я считаю, что это огромная ошибка. Senior-инженеры будут работать гораздо быстрее, лучше и не сделают большого количества ошибок, которые потом надо будет всем расхлебывать.
Другой момент — когда берёте Junior-инженера на работу, вы создаете своего рода контракт с ним. Он помогает вам построить бизнес, вы помогаете ему вырасти. У early stage стартапа нет процессов, чтобы помочь человеку расти. Его бросают в воду и говорят: плыви. Есть люди, которые выплывают, a есть те, кому слишком сложно.
Когда компания подходит к middle stage, уже есть условия, чтобы создать win-win ситуацию, когда и джуниор помогает расти компании, и у него есть ментор, процессы, благодаря которым он не сделает слишком много ошибок.
«Релизы существенно ускорились»
— После отказа от QA замедлились релизы? Получается, что теперь девелоперу, кроме разработки, нужно ещё и тестировать, выделять на это время.
Андрей: Релизы существенно ускорились. Итерации в разработке стали намного быстрее за счет continuous deployment. Заметно уменьшилось количество ошибок, которые мы находим после релиза.
— А как делает сам девелопер, когда берет себе тикет? Например, он говорит: «Раньше я это мог сделать за один день, но теперь мне надо еще потестировать, поэтому нужно полтора дня или два». Или же как был один день, так и остался?
Андрей: Это не обсуждается вообще, всегда подразумевается, что тестирование включено в эстимейт. Разработчик несет ответственность за просчет времени на выполнение той или иной задачи — это приводит к комитменту и правильному отношению к работе.
— То есть, когда QA были, то точно так же девелоперы комитились и подразумевалось, что тестирование они тоже сделают, но оно не делалось, правильно?
Андрей: Не делалось. Потому что были няньки QA.
— Cотрудникам, которые были QA, предложили новые позиции? Сколько из них перешло на новые позиции, сколько покинуло компанию?
Татьяна: На момент принятия решения у нас было четыре QA: три специалиста в Украине и одна я в Сан-Франциско. Два человека решили дальше продолжать работать QA и ушли. QA Automation инженер перешла в команду разработки, быстро выросла в Senior-инженера. Я перешла в Data Science команду.
— После того, как изменилась парадигма и девелоперы стали более вовлечены в тестирование, вы делали какую-то обучающую программу, курсы — что-либо, чтобы помочь им получить больше экспертизы в тестировании?
Андрей: Нет, не делали. На тот момент мы были маленькой компанией, не было достаточно ресурсов для этого. Но у нас были инженеры, которые хорошо знакомы с таким подходом и умели это делать. И вот они показывали пример, менторили тех, кто учился.
— Эта трансформация в основном происходила через ревью pull requests или, может, вы делали pair programming либо ещё какие-то техники применяли?
Татьяна: В основном через pull requests, много учимся на комментариях. К pair programming прибегали не очень часто. В основном у нас ребята, которые умеют все делать сами и им хочется самим разбираться. С другими специалистами мы просто созванивались и действовали так: один пишет, а другой комментирует, либо один пишет, а другой спрашивает. Но обычно все прокачивают скилы через коммиты и комментарии.
В нашей команде тогда было два инженера, которые пришли из Google. Там любят оставлять очень много комментариев по улучшению кода: eсли код great, его нужно сделать perfect. Некоторые другие инженеры научились этому и тоже такой подход теперь практикуют.
— Как изменился бюджет инжиниринг-департамента после отказа от QA?
Андрей: Освободившийся бюджет уходил на рост команды. Но его и освободилось не так много. Всего два человека ушло, там и говорить не о чем.
«Я считаю, что инженеры могут видеть разные edge-кейсы и даже лучше, чем QA»
— Что произошло с тест-артефактами, которые уже были: что с ними сейчас, кто их поддерживает, если они остались?
Татьяна: Раньше у нас было огромное количество тест-кейсов: от 50 до 100 на каждый репозиторий, каждый компонент продукта. Теперь, после отказа от QA, у нас нет конкретных тест-кейсов, просто весь функционал покрывается тестами сразу.
Старые тест-кейсы были некоторое время. Возможно, на них смотрели ребята, которые только пришли в компанию. Когда мы уже начали покрывать все тестами, специалисты, которые хотели разобраться, как работает конкретный аспект продукта, просто открывали папку «tests». Там можно все узнать. Давние тест-кейсы уже стали нерелевантными.
Андрей: Я бы так сказал: код становится документацией.
Татьяна: Да, это верно. Одна из вещей, на которые разработчикам следует обращать внимание, когда они апрувят пиары, — должно быть описание функции с примером, что означает этот аргумент. То есть комментарии к коду обязательно должны быть.
Андрей: Говорят, что инженеры настолько близки к коду, что не могут его эффективно тестировать и видеть все edge-кейсы, по сравнению с QA, которые думают более комплексно про разные юзкейсы. Я не уверен, что принимаю этот аргумент. Я считаю, что инженеры могут видеть разные edge-кейсы и даже лучше, чем QA, потому что они пишут этот код и продумывают эти юзкейсы по ходу дела. И один из трюков, которые мы используем, — тест-кейсы продумываются еще на этапе написания дизайн-документа для проекта. Когда вы еще не начали писать код, смотрите более целостно на то, что нужно сделать. И это позволяет потом не быть слишком предвзятым к своему коду.
Татьяна: Если посмотреть, например, на наши спринты и квартальные планинги, каждая новая фича начинается с OnePager. Пишем максимум на
После того как мы уже начали заниматься фичей, разработчики создают PRы. У нас в GitHub в каждом репозитории обязательно есть проверка — нужно, чтобы кто-то из команды апрувнул код. Если приходит кто-то извне, создаёт PR, то только человек из команды может его одобрить. Если это делает специалист из этой же команды, другой член команды должен заапрувить.
При этом, когда другие инженеры смотрят на код и не знают его достаточно хорошо, они будут задавать вопросы. Например: «Я не понимаю, как это работает, объясни мне, почему именно так нужно?» То есть мало того, что в ванпейджерах много обсуждений, ребята со свежим взглядом спрашивают о чем-то и искренне стараются разобраться.
— Когда приходит новый разработчик в команду, вы снабжаете его документацией? Или у вас есть какой-то процесс, когда старшие разработчики вводят его в курс дела проекта?
Татьяна: У нас уже давно есть onboarding buddies. Выделяем человека, который вводит новичка в курс дела и вплотную с ним работает некоторое время. Также для новых инженеров есть обязательное требование: в первые два дня сделать свой первый коммит. Чтобы человек не потратил две недели на чтение документации, а сразу же влился в работу.
Legacy code не весь покрыт документацией — я буду честна. И не все команды планируют в ванпейджерах, но все стараются это делать сейчас. Ванпейджеры — тоже своего рода документация.
На одной из ретроспектив новые ребята жаловались, что непонятно, как работают некоторые вещи. Тесты есть, но не хватает документации. Поэтому мы решили для всех новых фич выделять время на ее написание в конце спринта. Это то, чем инженеры тоже начали заниматься.
— Есть какой-то процент покрытия кода тестами, который вы постоянно поддерживаете?
Татьяна: Сейчас порядка 70% кода покрыто тестами. Пару лет назад это был очень маленький процент.
Андрей: Мы не сразу ввели Code coverage и надо понимать, что эта метрика не всегда означает то, что важно. Code coverage не гарантирует качество кода, она гарантирует только то, чтобы определённое количество строк кода было пройдено, грубо говоря. Но она даёт общее понимание, насколько команды используют автоматическое тестирование. И когда мы говорим про 70%, я считаю, что от 70 до 80% — это достаточно хорошо. На мой взгляд, всё, что больше 80% — избыточно и не означает, что качество самих тестов повышается. Дима, ты с этим согласен?
— Я считаю, что 70-80% это оптимально, больше — уже перебор. По end-to-end фронтенд-тестам — они перешли к кому-то в наследство? То есть кто-то из девелоперов продолжает их поддерживать или от них просто отказались?
Татьяна: Фронтенд поменялся довольно сильно, поэтому я уверена, что там все заменили новыми тестами.
Андрей: На самом деле, у нас фронтенд построен опытными инженерами, он очень компонентизирован и написан правильно. Интеграционные тесты на фронтенде используются минимально и только для критических мест. Тесты чаще мешают, чем помогают.
«С каждым годом количество юзеров у нас стремительно росло, а количество багов практически не менялось»
— Есть ли статистика по тому, сколько багов обнаруживали пользователи после релиза, когда была QA-команда и сейчас?
Татьяна: К сожалению, у нас в Jira не было такого тега раньше, что тикет пришёл именно с Zendesk (платформа для менеджмента саппортных тикетов — ред.), мы добавили это позже. Но я посмотрела эту статистику вручную. До того как мы отказались от QA-команды, за 2017 год было довольно много багов, которые были созданы и саппорт-командой, и разработчиками. Из них примерно 70% — это «у меня не грузится, что-то перестало работать». 30% — это «скажите, пожалуйста, как высчитать эту метрику. Мне кажется, она неправильная».
В 2018 году, когда у нас уже не было QA, количество ошибок в целом увеличилось в 2,5 раза. И при этом количество ошибок в разработке уменьшилось. Где-то 80% багом были с реквестом «что насчёт этой метрики, у меня такой вот edge-кейс, как бы вы это заапрувили» и так далее. То есть большинство ошибок уже касалось характеристики данных. И уже почти не было такого, что что-то не работает, не грузится и так далее.
И что самое интересное: с каждым годом количество юзеров у нас стремительно росло, а количество багов практически не менялось. Всего на
Андрей: Очень сложно коррелировать, но по ощущениям, когда QA-команда перестала существовать, мы не почувствовали особых изменений в негативную сторону. Скорее наоборот: мы стали быстро реагировать на то, что просачивалось в production. Когда у вас маленькое изменение кода — вы сразу видите, где проблема. И ее намного легче и быстрее фиксить.
— Какие дальнейшие планы по развитию компании, команд и улучшению процессов?
Андрей: Мы продолжаем активно нанимать людей. Когда команда растет, соответственно должны эволюционировать, становиться более зрелыми процессы. Каких-то серьезных изменений с точки зрения QA мы не планируем. На данный момент наша культура хорошо работает, и мы будем развиваться в том же направлении.
— По Retention rate у вас есть какая-то статистика? Сколько человек в среднем уходит из компании за год, например? И сколько присоединяется за год?
Андрей: Есть, но я так сходу не вспомню цифры. Что я скажу: во-первых, мы растем очень быстро. Инженерная команда увеличилась на 60% в первом квартале текущего года.
— Есть ли какие-то лайфхаки для борьбы с выгоранием, которые можешь выделить?
Андрей: В компании мы ввели recharge days. Каждый квартал мы даём всем сотрудникам
Recharge days дают хороший результат. Я бы всем рекомендовал ввести что-то подобное. При том, что у нас есть безлимитные отпуска и мы даже поощряем людей их брать — не все берут. Mы следим, чтобы не проходил очень длительный промежуток времени, когда человек не берет отпуск. Вот эти recharge days, которые заставляют взять перерыв, помогают.
— Когда закончатся карантинные меры, вы будете возвращаться в офлайн или будете продолжать работать удаленно?
Андрей: У нас будут офисы, но вот все ли сотрудники будут постоянно там работать, сказать сложно. Я думаю, что будет гибридная модель, когда часть людей работают в офисе, часть — из дома. Вполне возможно сделаем так, чтобы можно было резервировать места, когда нужно поработать в офисе или всем нужно собраться на митинг. Я не думаю, что мы вернемся к полностью офлайн-формату, когда пандемия закончится.
Уже сейчас, когда набираем специалистов, мы обращаем намного меньше внимания на их место нахождения. У нас есть люди в Харькове, во Львове, Херсоне, Днепре, Черновцах. Время от времени мы собираем всех сотрудников из Украины в Киеве, чтобы у них была возможность пообщаться, особенно когда кто-то приезжает из Сан-Франциско. До пандемии сотрудники часто ездили из Киева в Кремниевую долину и наоборот. Мы даже арендовали в Сан-Франциско постоянно две квартиры.
«QA знают продукт от А до Я, и это их суперсила»
— Что вы думаете про парадигму Software Developer in Test (SDET), когда есть человек, который занимается разработкой, но больше по части инфраструктуры, оптимизации процессов, коммуникации с командой, изготовления инструментов, чтобы упростить тестирование?
Андрей: Да, у нас есть команда, которая занимается Engineering Efficiency. Они ответственны и за инструменты для тестирования.
— И напоследок, может быть, вы сформулируете какие-то советы для людей, которые работают QA в других компаниях, как им оптимально дальше развиваться и расти?
Татьяна: Я уже знаю, что Андрей скажет, run :)
Андрей: Я думаю, тебе не понравится мой ответ. Я считаю, что QA может быть первой ступенькой для того, чтобы начать карьеру в IT. Но я никак не могу рекомендовать людям там задерживаться. С этого можно начинать, если нужно, но я бы не советовал идти в QA. А если вы там, то стоит переквалифицироваться так же, как это делали некоторые ребята у нас.
Татьяна: В свою очередь, я бы хотела дать совет. Я была в команде QA, это было добровольное желание. Но если бы я сейчас начинала карьеру в IT, то сразу бы пошла в девелоперы. Рекомендую начать с более легкого для вас направления и затем переходить в то, что интереснее. Например, некоторым инженерам сначала проще даётся фронтенд-разработка, чем бэкенд и так далее.
QA имеет хорошую базу, чтобы вырасти в инженера либо пойти в Data Science. Я в прошлом тестировала данные, отлично изучила проблемы с ними. И сейчас у меня остался майндсет такой, что нужно 1000 раз все перепроверить — это класный подход для дата-аналитика. Когда работаешь с огромным количеством данных, когда нужно постоянно коммуницировать их Executive-команде, клиентам, обязательно надо, чтобы это были качественные данные. Я сама проверяю каждую цифру. Опыт тестировщика в этом очень помогает.
Андрей: Есть ряд направлений, в которых ex-QA обычно очень успешны. QA знают продукт от А до Я, и это их суперсила. Часто инженеры так не знают продукт, как тестировщики. У нас QA перешли в инженеры и дата-сайентисты. Я видел также успешные переходы в продукт, Client Services, Technical Support.
