Всем привет! Меня зовут Ксения, я Engineering Manager в кластере Buyers Experience в Uzum Market. Наша команда занимается разработкой страницы товара и отзывов на вебе и в мобильных приложениях.
Путь нашей команды начался достаточно интересно: мы очень долго и упорно разрабатывали новую функциональность, потом очень долго и упорно ее тестировали, пока не довели до идеала ее работу и дизайн. Мы много созванивались друг с другом и обсуждали задачу, и наконец отправили ее в релиз. Вся команда, гордая собой, пришла к Product‑менеджеру, чтобы он увидел плод наших стараний, но он оказался не так рад. Продакт сказал, что это не то, что он хотел изначально. Повисла ужасающая тишина. Эта задача называлась: «Форма для оставления отзывов на главной». Запомните это название, мы еще с ним встретимся.
Следом за продактом пришел дизайнер, который сказал, что вообще эту форму не видел, а мы вроде бы показывали, но все было достаточно суматошно, так что мы действительно не были уверены.
Так начался наш путь к улучшению процесса разработки.
Стало понятно, что нам точно есть, что улучшать:
Слишком долгий процесс от груминга до релиза:
выяснение требований;
множественные созвоны по постановке задачи разработчикам и QA;
исправления ошибок;
исправления по замечаниям от дизайнера, а иногда мы и вовсе забывали про дизайн-ревью.
Большая когнитивная нагрузка но команду:
нужно помнить о постановке задачи;
нужно помнить о договоренностях во время обсуждения;
нужно помнить о том, что задачу придется когда-то показать дизайнеру.
Продакт, который получал непредсказуемый для себя результат. А далее — доработки, исправления и невозможность перейти к следующей задаче и быстро тестировать гипотезы.
Есть процесс разработки, он как конвейер. На каждом шаге могут возникнуть проблемы, которые отсрочат получение итогового продукта. У нас был классический процесс, далекий от идеала, и хотелось внести изменения сразу и во многих местах. Но начали, конечно, по порядку.
Выяснить, сколько времени мы тратим в среднем на каждом этапе и между этапами
Идея — Продуктовые требования. Здесь все понятно и зависит от Product‑менеджера, который формулирует продуктовые требования. Он должен описать их в понятном виде. В нашей форме отзыва требований почти не было, так как всем казалось, что мы понимаем задачу одинаково.
Продуктовые требования — Груминг. У команды должен быть запас времени в спринте, чтобы иметь возможность качественно погрумить задачу. Это значит, что продуктовые требования команде нужно отправить заранее, чтобы команда прочитала их и подготовила список вопросов. Обдумала, как это устроено у нас сейчас. Если команда в огне и доделывает в срочном порядке задачи — не ждите качественный груминг с предварительной подготовкой. Обычно у команды есть чек‑лист того, что обязательно должно быть в требованиях, это помогает не ошибиться. У нас был груминг по задаче с формой отзывов, но это был переходный период, и так вышло, что грумили одни люди, а реализовывать пришлось немного другим составом.
Груминг — Разработка. Все зависит от загрузки команды. Не стоит грумить задачу сильно заранее, иначе к моменту реализации команда потеряет контекст и придется делать еще одни груминг. В идеале, задача должна пойти в разработку в течение месяца после груминга. Если пройдет больше времени, тогда точно нужно снова грумить.
В нашей задаче с формой отзывов между разработкой и грумингом прошло достаточно времени, чтобы часть информации забылась.
Разработка. Чем лучше погрумили задачу, тем проще будет разработка. Чем лучше описаны продуктовые требования, тем меньше будет доработок во время тестирования и после проверки Product‑менеджером. В нашем конвейере отсутствует этап «технические требования». Спойлер — поговорим об этом позже, это важный этап, который точно следует добавить. Чем больше устных договоренностей и нечетких формулировок, тем больше будет доработок.
В нашей задаче с формой отзывов было много устных договоренностей, даже слишком. А тестировал ее QA‑специалист, который не был в курсе всего этого, и ему приходилось постоянно переспрашивать, и, конечно, получился «испорченный телефон».
Тестирование. Если четких продуктовых и технических требований нет, то смело добавляйте время на выяснение требований командой QA. Это нужно ей для начала тестирования задачи. Если вы хотели сэкономить на этом время, то на этапе тестирования придется потратить минимум вдвое больше. Также следует определить, проверяет ли QA‑специалист дизайн до того, как этим займется сам дизайнер. Количество времени на тестирование зависит от многих факторов: требований, багов, качества кода, культуры передачи задачи от разработчика к тестировщику.
Проверка дизайна. На этом этапе дизайнер проверяет соответствие реализации дизайну. Возвращать на доработку с этого этапа очень дорого, так как исправления нужно будет еще перетестировать. Чем быстрее проверим дизайн, тем быстрее задача окажется в продакшене. Иногда этим этапом пренебрегают для ускорения релиза, что не всегда правильно.
В нашей задаче с формой отзывов мы отправляли скриншоты в личные сообщения дизайнеру, которые могли затеряться. Вся коммуникация должна была быть вынесена в тред в Slack или в отдельную задачу.
Релиз — Ревью продактом. На этом этапе Product‑менеджер смотрит то, что получилось. На самом деле лучше этим заняться как можно раньше, чтобы быть уверенным, что команда сделала то, что хотел продакт. Доработки на этом этапе самые дорогие. Если фича сделана не так, то придется начинать сначала.
Нашу форму отзывов продакт смотрел уже на проде, это было слишком поздно. Все дальнейшие изменения стоили нам очень дорого, так как приходилось начинать весь процесс с самого начала и проходить все этапы снова.
Перестановка
Для себя мы выстроили определенный порядок, ориентируясь на следующие факторы:
Мы должны как можно раньше исправлять ошибки, требующие больше всего времени. В этом смысле дороже всего — сделать концептуально не то, что задумывал бизнес. Поэтому у нас должны быть четкие требования и максимально быстрая коммуникация с продактом.
Мы должны максимально рано узнавать о доработках и ошибках, то есть нам нужно как можно раньше выполнять шаги с наибольшим количеством доработок.
Никто не должен делать несколько раз одну и ту же работу. Например, QA‑специалист не должен тестировать одно и то же несколько раз.
После нескольких итераций мы пришли к итоговому варианту (последняя строка):
Что изменили:
Ввели этап технических требований. Это четкие требования, переведенные с языка бизнеса на язык разработки. Требования формируем во время и после груминга, а после — проверяем по продуктовым критериям. Сейчас их формулирует и записывает в задачу тимлид.
Проверки дизайнером и продактом вынесли на этап после разработки и код ревью, но до тестирования. Разработчик записывает видео и скриншоты для презентации продакту и для проверки дизайна. Также это помогло повысить качество отдаваемого в тест кода: разработчик при самопроверке уже видит явные ошибки и исправляет их. В результате мы избавились от проявления в тестировании блокирующих багов.
Вынесли в отдельный этап итоговую проверку продактом после тестирования. Иногда во время тестирования обнаруживаем мажорные баги, после исправления которых мы должны еще раз проверить решение вместе с заказчиком.
И тут как будто можно и заканчивать. Мы доработали форму отзывов, и она оказалась действительно классной фичей, которая приносит компании деньги. Product‑менеджер был доволен результатом, клиенты были довольны классным интерфейсом и возможностью оценивать товары, а продавцы были довольны тем, что они получают обратную связь, которую можно анализировать для дальнейшего улучшения продуктов. По этому процессу мы провели еще несколько крупных задач, он работает, наши метрики улучшаются. Но однажды наш любимый продакт принес задачу «Доработки и улучшения формы для оставления отзывов». Вся команда вспомнила нашу первую задачу, и в воздухе снова повисла тишина.
Но хэппи энд действительно случился. Мы провели новую задачу по обновленному процессу, и — «Работает!» Разница оказалась разительной: мы закончили фичу почти вдвое быстрее и смогли зарелизить ее с первого раза без доработок.
Каких результатов мы добились
Основное — мы быстрее доводим задачу от груминга до релиза. Расскажу подробнее, как этого добились.
Бизнес заранее понимает, какую функциональность может реализовать команда и сколько времени это займет. Бизнес может заранее пересмотреть свои требования и скорректировать ожидания.
Благодаря хорошо прописанным техническим и бизнес-требованиям разработчику не приходится вспоминать, что мы когда-то обсуждали, искать контекст. Тестировщик не тратит время на выяснение того, как это должно быть, так как требования едины для продакта, разработчика и QA. Длительность разработки задач одинаковой сложности сократилась в среднем на 30% в сравнении с прошлым кварталом.
Продакт видит проблемы и баги сразу же после реализации. В этот момент мы уже можем понять, все ли корректно мы сделали. Если есть большие и серьезные проблемы, мы исправляем их сразу, не переключаясь на другие задачи. В среднем сейчас на одну задачу приходится примерно два возвращения на доработку. Первый раз — после проверки дизайна, второй — после итерации тестирования. Раньше возвращали после нескольких итераций тестирования, так как были блокирующие баги.
Дизайн проверяем во время или после проверки кода. Разработчик не успевает переключиться с контекста задачи и сразу же правит баги дизайна.
Мы не передаем блокирующие баги на тестирование, так как разработчик сам проходит позитивный сценарий, когда записывает видео для продакта и дизайнера. Очевидные баги правим еще до тестирования. За последний квартал во время тестирования обнаружили 1 баг. В предыдущем квартале — тоже.
Поскольку большинство багов мы исправляем до тестирования, мы стали обнаруживать их реже и чиним быстрее.
Для Product-менеджера всегда оказывается предсказуемый результат на проде, и нам не приходится переделывать фичу уже после релиза.
Теперь мы получаем приятные сообщения от продакта, когда он еще до выкатки на прод видит новую функциональность.
