Ульяна Турова

Я хочу поделиться историей, которая произошла со мной на одной из предыдущих работ. Тогда заказчики торопили разработку, времени на тесты не хватало, но мы с командой все равно справились. Как нам это удалось? Благодаря правильно построенному процессу работу. Что случилось Однажды в размеренную и четко регламентированную процессами жизнь нашей команды прилетела молния. Оказалось, что коллеги из другого отдела решили изменить внутреннюю систему. А так как этой системой занималась моя команда, то и задача стала нашей. На подготовку спецификации, разработку и тестирование заложили всего три недели. То есть мы оказались в ситуации, когда все нужно делать в ускоренном темпе. Обычный процесс работы командыВ чем же были отличия в этот раз? UX-проектировщик получает задачу. На основе проблем и пожеланий заказчика он продумывает функциональность, создает макеты и описывает спецификацию со всеми необходимыми для разработки деталями.Времени не хватало, поэтому проектировщик передал в разработку не до конца готовый макет.Тестировщик и разработчик проверяют макеты и спеку, уточняют неясные формулировки и устраняют ошибки, чтобы после реализации не переделывать всю работу.Разработчик и тестировщик не успели провести ревью, нам пришлось решать все вопросы в процессе или после разработки.После ревью проектировщик ставит задачу на разработчиков. Программист реализует всю необходимую функциональность.Разработчик не успел свериться с макетами, так как менеджер его постоянно торопил.Проектировщик и тестировщик проводят совместное ревью. На нем решают, какое поведение системы верно, будут ли они исправлять ошибки в рамках текущей задачи или отдельно.При первом тестировании всплыли важные недоработки: пришлось добавить часть функций, которых не было в макете, и поправить критичные баги. Менее серьезные ошибки мы исправили уже после релиза.После внесения изменений задача снова возвращается на тестирование, затем доводится до приемлемого состояния и катится в прод.Заказчики планировали отправить сообщение сотрудникам о новой фиче, поэтому мы не могли свободно выкатить изменения в прод. Нужно было сначала согласовать время с заказчиком. Как я взяла себя в руки и сделала невозможное Шаг 1. Настроиться на работу Я получила задачу за пару дней до релиза. Осознав, в какую ситуацию попала, я разозлилась и несколько минут потратила на то, чтобы прийти в себя. Согласитесь, неприятно, когда нарушается привычный распорядок и приходится перестраивать работу, чтобы прийти к обычному результату — вовремя и качественно выкаченной фиче. Вскоре я поняла, что эмоции только замедляют работу, и первое, что требуется — успокоиться. Можно приготовить чай, сделать дыхательную гимнастику, послушать любимую музыку, посмотреть мемы. То есть сделать все, что способно успокоить и настроить на рабочий лад. Любимые мемы, которые помогли настроиться на работу. Шаг 2. Обсудить интерфейс и провести первые тесты Дальше нужно было продумать и согласовать ускоренный процесс, который подошел бы всем участникам задачи. Сначала мы встретились с проектировщиком, чтобы обсудить новую фичу — он рассказал об основных целях, требованиях и функциональности. В эту же встречу мы уместили совместное тестирование, на котором нашли основные ошибки и распределили по времени исправления. Критичные добавляли в текущую задачу, чтобы пофиксить сразу. А менее важные, долго реализуемые или не влияющие на UX и работу системы, отложили на потом. Самой большой проблемой на этом этапе оказалось то, что на момент передачи задачи в разработку часть спеки была не готова. Из-за этого некоторые детали оказались не реализованными. Пришлось дополнительно с менеджером продукта и фронтендером решать, сколько времени займет доработка и сможем ли мы уложиться в дедлайн. Выяснили, что изменения можно внести быстро, и решили делать сразу, до выпуска фичи, а не отдельной задачей. Таким образом, после первой итерации тестирования задача вернулась разработчикам на исправление дефектов, а я смогла выдохнуть и подумать, что делать дальше. Шаг 3. Отказаться от лишних тестов Времени было мало, поэтому я договорилась с остальными разработчиками, что отложу другие задачи, пока мы не выкатим срочную. По этой же причине я решила перед релизом не проводить полный регресс, а проверить работоспособность только основных фич продукта. Важно было убедиться, что изменениями мы ничего не сломали. Еще я решила не заострять внимание на уже протестированных элементах, которые при первой итерации работали корректно. Это освободило время для более качественной проверки исправлений и новых деталей. Шаг 4. Провести финальное тестирование и выпустить в прод Во вторую итерацию я обнаружила еще несколько багов. Фронтендер сказал, что их можно исправить за несколько часов, поэтому решили заняться ошибками сразу же. Задача была готова: оставалось получить одобрение заказчика и выпустить обновление в прод. Но вновь появились сложности: коллеги-заказчики планировали одновременно с релизом опубликовать анонс фичи, только не успели подготовить текст. Пришло время нервного ожидания. Мы не знали, что происходило в другой команде, и когда они будут готовы. В компании существует правило: после 17:00 не релизить, чтобы не пришлось откатывать или исправлять ошибки среди ночи. Ближе к вечеру мы поняли, что релиз переносится на завтра — так у нас появилось время, чтобы добавить и протестировать еще одну фичу. На следующий день коллеги написали, что анонс готов и можно релизить. Мы с бэкендером наконец-то выкатили изменения! И несмотря на то, что задачу делали в ускоренном темпе, ни одного фида с багом нам так и не пришло, хотя компания активно пользовалась новой функциональностью. Выводы Я сделала для себя несколько выводов. Если менеджер требует срочного релиза, часть ответственности можно переложить на него. Нервы, негативные эмоции и суета не помогают в работе. Если зашкаливает, стоит сначала успокоиться, прийти в себя и только потом возвращаться к задаче. Так работа пойдет гораздо быстрее и с меньшим количеством ошибок. Не все вещи одинаково важны. Что-то можно отложить, что-то может оказаться лишним, и это можно не реализовывать, а что-то, наоборот, очень важно. Нужно выяснять всю информацию из доступных источников, анализировать и учиться грамотно приоритизировать задачи и действия. Учимся планированию и тайм-менеджменту. Сколько времени займет каждая задача, что мы успеем сделать сейчас, а что придется отложить на потом. То есть важно сначала выяснить детали и расставить приоритеты, а потом приступать к работе. «Работа не волк, работа — ворк». Этот пункт — следствие всех предыдущих. При планировании нужно учитывать только рабочее время. Не стоит тратить на задачи выходные — иначе наступит усталость, а за ней придет выгорание. Заключения, возможно, очевидные, но когда сталкиваешься со стрессовыми ситуациями в реальности, начинаешь по-настоящему понимать их ценность. Поэтому желаю вам спокойствия, терпения и поменьше таких срочных задач!

Ульяна Турова

Материалы автора

Как протестировать новый сервис, если сроки горят

Двухфакторная аутентификация — что это и почему важно использовать

Полезные функции DevTools для тестирования сервисов

Как мы переписывали более 200 автотестов после переезда на новый Angular