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