Привет, я Таня, QA iOS в 2ГИС. Хочу рассказать, как мы починили процесс передачи задач между командами мобильных платформ и подготовки данных. По ощущениям, до починки мы будто ехали по гравийке, а после — выехали на дорогу со свеженьким асфальтом. Поэтому я хочу поделиться нашим опытом и показать, что есть смысл улучшать даже мелкие шероховатости взаимодействия.
Как было
У нас есть команда Экспорта, которая ежемесячно выпускает обновлённые данные для наших мобильных приложений и сайта 2gis.ru. И есть команды Мобильных платформ, Android и iOS, которых мы зовём Мобилками. Их задача — проверить, что после попадания новых данных на прод в приложениях ничего не сломается.
Каждый месяц ребята из Мобилок получали от Экспорта письмо со списком задач, которые затрагивают приложения. Несмотря на то, что такие задачи приходили регулярно, заранее планировать под них время было трудно — сложность задач, их количество и время на решение нельзя спрогнозировать.
Поэтому когда от Экспорта приходило письмо, лиды и тестировщики Мобилок отрывались от своих запланированных задач и шли разбирать пришедший список: выясняли подробности, оценивали прилетевшее и срочные задачи впихивали между текущими. Не разобрать список от Экспорта нельзя — вдруг там что-то критичное?
В целом, такой процесс передачи задач работал, но было несколько проблем:
Разная длина спринтов у команд: у Мобильных платформ 3 недели, у Экспорта — 4. Посреди нового спринта Мобилкам накидывают задачи.
У лидов мало времени, чтобы погрузиться в задачи, а там часто нужно уточнить детали. Пока их выясняют, релиз становится всё ближе.
Обсуждать задачи в переписке на кучу людей неудобно. Изначальное письмо со списком задач превращается в портянку, которой перебрасывается десяток людей.
Ситуация не была для нас патовой — в большинстве случаев в текущий спринт удавалось вместить и прилетевшие, и уже запланированные задачи. Но риск, что задачи съедут на следующий спринт, оставался. Плюс всех напрягало, что стабильно приходится переключаться, вникать, впихивать и потеть.
Решиться
В самом начале было непонятно — точно ли надо что-то менять? Всем неудобно, но достаточно ли, чтобы ломать процесс, который всё-таки работает?
Чтобы оценить это, лиды команд ответили на три вопроса:
Процесс влияет на скорость выполнения задач или качество продукта?
Неудобство от процесса регулярно?
Возможно решение проблемы не займёт много времени или сил?
Все ответы были положительными. Лиды поняли, что стоит рискнуть и улучшить процесс.
Выбрать ответственного
Дальше следовало назначить ответственного — того, кто наладит взаимодействие между командами. Происходящим недовольны все, но все одновременно менять его не смогут, кто-то один должен следить за курсом изменений и корректировать его.
Нужен был человек, который прислушается к каждой команде, систематизирует требования и желания, разработает план изменений и внедрит их в процесс. В идеале это человек, который легко общается с людьми, уже находится некоторое время в компании и недоволен происходящим. Я подходила под эти критерии и взяла на себя ответственность за починку процесса.
Собрать пожелания
Для начала надо было понять, как каждая команда видит процесс сейчас и что бы хотела получить в итоге. Я нашла союзника в команде Экспорта: он тоже был не особо доволен происходящим и хотел наладить передачу задач. Мы обсудили проблемы и пожелания внутри своих команд: я внутри Мобилок, он — с Экспортом. И после этого свели полученную инфу воедино.
Идеальная картина была такой:
«У Мобилок и Экспорта есть дежурные. Есть общий канал в Слэке для обсуждения релизов и тикетов Экспорта для Мобилок.
В конце текущего спринта Мобилок в канале срабатывает напоминание „составить список задач“. Задачи, которые будут готовы в следующем спринте и затронут Мобильные платформы, дежурный Экспорта собирает в список. Список публикуется в канале и дежурный зовёт туда тестировщиков из команд Мобильных платформ. Каждая задача обсуждается в отдельном треде.
После обсуждений Мобилки планируют тестирование в будущем спринте, заводят под это тикеты в Jira. Руководители Мобилок вносят задачи в план.
Когда работа над задачей завершена, Мобилки пишут об этом в треде задачи и тегают дежурного из Экспорта. Это важно обеим сторонам — так Экспорт получает явную отмашку „Мобилки проверили“ и данные не идут на бой без тестирования».
Чтобы идеальная картина закрепилась, мы с союзником разработали инструкции для каждой команды. Там мы по шагам расписали, кто, что и когда должен делать и закрепили детали процесса:
сроки,
ответственные,
формат общения,
что является отмашкой для выпуска данных на бой.
Инструкции получились длинными, структурированными и подробными, чтобы ребята при необходимости могли обратиться к ним и вспомнить детали.
Выработать привычку
Команды приняли новые правила, начали им следовать. Но мы с союзником из Экспорта на всякий случай продолжали мониторить процесс: когда меняешь что-то, люди спотыкаются об это и раздражаются, думают «Зачем поменяли, было терпимо, а стало сложно». К счастью, нам повезло: от неудобного процесса устали многие, поэтому негативной реакции на изменения не было.
Оставалось помочь участникам выработать новые привычки. Главным на этом этапе было подчёркивать, что каждая деталь будет ещё не раз обсуждаться, процесс можно доработать.
Если я видела, что кто-то игнорирует новые правила, то приходила и лично обсуждала, почему так выходит. Обычно у такого поведения было две причины:
Человека в новых правилах что-то не устраивало — я разбиралась, что случилось и как помочь: научить, перестроить процесс или ещё что-нибудь
Человек попросту забыл или не понял правила — тогда мы вместе разбирались в непонятном, когда надо, я дополняла инструкции. Но в причине «забыл» есть нюанс: если человек забыл много раз подряд, надо пересмотреть правила — возможно там что-то категорически неудобное, раз не приживается.
Понемногу мы убирали подводные камни. Например, команды выбрали определённый день для получения списка, но позже поняли, что иногда он неудобен для команды Экспорта, поэтому день скорректировали. Или команде Экспорта давали только один день для составления списка задач, пожили так — неудобно, сместили напоминание на день раньше.
Собирать отзывы
К моей радости, команды поняли, что процесс для них, а не они для процесса и включились в отшлифовку изменений. Ответственность за изменения уже не была прибита гвоздями ко мне. Ребята запомнили: если станет неудобно, это можно и нужно исправить, неважно насколько мала проблема. Инициатором изменений может стать любой.
Команды собирали мнения о происходящем прямо во время работы над задачами: увидели, что неудобно — сразу зафиксировали. Если проблема мелкая, то решили вопрос на месте, если крупная — записали в общей доке и решили на отдельной встрече.
Итог
До изменений мы думали: «Не факт, что станет лучше, начнёшь менять — что-то сломается или завязнешь… Пока не горит, пусть будет как есть». Но в реальности всё, что мы сделали, было не так сложно и непонятно, как казалось изначально.
Нужно было:
решиться — если проблема регулярна и влияет на продукт, и может оказаться, что её несложно решить, то наверняка надо это сделать;
выбрать ответственного — бодрого, замотивированного недовольством или причинением добра;
собрать пожелания — для этого в других командах понадобится помощь союзников;
продать изменения — побыть немножко психологом и множко аналитиком;
собирать отзывы — делать это непрерывно и записывать всё, что нельзя решить в моменте.
Да, в итоге поменялась совсем небольшая часть работы, но порадоваться всё-таки хочется, ведь получилось сделать работу комфортнее для пары десятков человек. А слышать от коллег «Вроде мелочь, а стало легче, понятнее»! — особенно приятно.
У нас получилось сравнительно легко. Но было бы интересно почитать в комментариях о случаях, когда удалось протолкнуть забуксовавший процесс.
