Быстрая проверка десятков гипотез: как мы вырываемся из рутины и устраиваем себе обсуждение в другом городе

У нас в каждой из шести команд разработки бэклог расписан примерно на два года вперёд с учётом почти неминуемого рефакторинга, фиксов, фич и хотелок продуктологов. Внутри всё может ездить по приоритетам, и некоторые большие блоки то становятся важнее, то убираются, то туда добавляется что-то новое. Но всегда есть понимание, куда копать в ближайшие месяцы.

У такой системы, кроме кучи плюсов, есть два очевидных недостатка:

1. Это банально скучно, а скука — это не то, что мотивирует нас писать код.
2. Накапливается много гипотез, которые по обычному процессу падают куда-то в конец бэклога, но каждая из которых может дать быстрый результат. А может и не дать. Некоторые из них интересные.

В обычном режиме разбирать эти гипотезы сложно, потому что нужно взаимодействие продуктолога, бизнес-человека (обычно руководителя направления) и ещё пары человек из других команд разработки. То есть когда у тебя есть два свободных часа, всё равно не сделать. А поскольку мы часто зарабатываем на том, что протаптываем дорожку в бизнесе к новым интерфейсам и новым фичам, проверка гипотез — это жизнь.

Сначала мы выделяли время внутри офиса и делали в общем рабочем процессе. Оказалось, что, если проверять как можно быстрее, получаются средние решения. Чтобы повысить качество, надо вырваться из общей рутины.

Поэтому мы три раза уже выезжали в какой-нибудь иностранный город и работали там.

Почему это нужно?

Если вы уже читали посты про то, как у нас копится технический долг ^[1] и что мы с этим делаем, и про то, что надо знать разработчику про бизнес ^[2], то знаете, что время от времени у нас образуются десятки гипотез по поводу того, что можно сделать. Примерно половина — от разработчиков, часть — от рассказов других подразделений и перекладывания опыта на себя, часть — от продуктолога, учредителя или просто из-за фазы Луны.

Дальше мы определяем список людей, которые нужны для решения большей части этих задач. Как правило, это конкретная команда разработки (направления авиа, железных дорог, туров, электричек, приключений или аналитики), инфраструктурщик, пара человек от бизнеса (для общей картины и оценки финансовой логичности), аналитик для перевода туда-сюда, люди из других команд.

Базовый процесс выглядел так: берём маркетолога, разработчиков, дизайнера, аналитиков и лидера. Прямо в офисе раз в неделю устраиваем обсуждение спринта по гипотезам. Выделяется один день, когда работа ведётся только по гипотезам. Если решение одной задачи выходит за шесть часов, то она прерывается и выходит из этого процесса. Задача — запустить косую бету за шесть часов. Проверяется десять гипотез в неделю по всем командам.

Это хорошо работает, но ограничения вы видели выше.

В полноценную разработку берётся то, что по результатам беты устраивает руководителя проекта.

Мы посоветовались с гуру управления проектами, и сразу несколько разных человек сказали, что нужно заводить внутри компании «спецназ», то есть тех, кто профильно занимается именно откруткой быстрых гипотез. Где-то это называется группой развития, где-то — ещё как-то. Смысл — в постоянном хакатоне для одной команды.

Звучит логично, но быстро не внедрить: это надо собрать экспертов по шести разным областям бизнеса и лишить основные команды самого интересного, потому что весь изюм из булки выковыривает этот «спецназ».

«Спецназ» нужен потому, что, если на решение задачи выделяется не 100 % времени разработчика, получается хуже. Судя по опыту. Но сделать так мы не могли.

Мы взяли ТРИЗ и предположили, что нужно фокусироваться часть времени на гипотезах, часть времени — на основной работе «вдолгую». Что мешает делать это, как мы делали в офисе? Контекст, постоянные отвлечения и регламенты, постоянная занятость членов команд и долгая обратная связь.

Именно так люди придумали хакатоны. Они снимают все ограничения офиса и дают время на фокусировку. Только хакатон — это бесплатная добровольная история, и она обычно про обучение. Разработчики тратят свою субботу, потому что могут узнать что-то новое, а не лучше сделать свою работу.

Поэтому мы решили провести эксперимент и поехать в Стамбул командой из 14 человек.

Эксперимент в Стамбуле

Почему именно Стамбул? Нам нужен был город, который соответствовал продуктовым требованиям:

1. Быстро добраться рейсом без частых задержек (другая сторона планеты не подходит, острова с непредсказуемой погодой не подходят).
2. Добраться относительно недорого (Исландия обычно не подходит).
3. Город привлекательнее Москвы в это время года (не все любят вылезать из офиса ради просто путешествия, Омск не подходит, да простят меня жители этого города).
4. Есть много интересных вещей, ради которых не надо далеко ехать (Норвегия не подходит).
5. Команда единогласно хочет в этот город.

Мы составили список подходящих городов и обсудили со всеми. Важно было, чтобы выехали именно все и сразу, и это не было жуткой обязанностью.

Решили, что мы проведём большое совещание в Стамбуле в обмен на два отгула (оплачиваемых), но билеты покупаем сами. Такая логика всех устроила, потому что это шанс состыковать эти два отгула с выходными и получить мини-отпуск в середине года.

Ну и в конце концов, мы всё же люди, увлечённые путешествиями.

На месте сняли большой дом около центра.

Кто делал? Один из разработчиков потратил своё личное время на организацию всего этого. Я не уверен, было ли это потому, что он хотел изучить процесс бизнес-поездок (мы как раз его раскручивали), или просто потому, что он хотел всем помочь.

За неделю предупредили кухню ^[3], что нам нужны перекусы в дорогу, но нагрузка в ближайшие дни на еду снизится.

С утра в пятницу поработали, как обычно, в 12:30 поехали в аэропорт, примерно в 15 часов — вылет, в 18 часов мы были на месте.

Пришли в дом, там уже был развёрнут вай-фай, с собой у меня были распечатанные материалы. Все с корпоративными ноутбуками. Поели, посидели и обсудили основные вещи. Фактически это были дебаты на тему того, что и как делать в продукте. То есть мы решали, что должно попасть в бэклог. Хотелось обсудить и «быстрые» гипотезы, и судьбу, и приоритеты долговременных задач.

На следующий день пришли к такому формату: за четверг появился список проблемных вопросов (в дополнение к тем, что уже были известны), поэтому почти всю пятницу мы разговаривали про них. Находили две стороны: одна была за гипотезу, другая — против. Дальше они устраивали поединок, который судили все остальные. То есть почти как суд над гипотезами: прокурор тянет за то, что делать не надо, а адвокат — за то, что там успех и радость. Правда, тогда менять прокурора и адвоката не додумались, а это стандартная процедура при таких дебатах.

Рабочий график был такой: выбираем самое плохое время для прогулок (в Стамбуле это середина дня), ставим туда совещание. Утро и вечер свободны, но обедаем вместе, это возможность общаться. В тот выезд кое-кто всё равно добивал небольшие задачи, то есть не смог полностью выключиться из обычного процесса. С другой стороны, я бы не сказал, что это заняло значительное время.

Пример обкатываемой гипотезы

В автобусах нет законодательно утверждённого электронного билета. Это нас неимоверно печалит, потому что пассажиры должны либо печатать бланк дома, либо печатать на принтере на автовокзале (что иногда становится проблемой, а иногда банально платно). РЖД уже давно принимает почти везде электронную регистрацию, авиа печатают вам в аэропорту без вопросов на терминалах или стойке (а кое-где и печатать не надо). А в автобусах кое-где всё ещё 70-е годы СССР.

На практике есть прогрессивные вокзалы, которым достаточно показать билет с телефона. У них всё равно есть эти данные в ведомости с их стороны, и надо просто посмотреть туда и на документ человека. Но есть консервативные вокзалы и те, кто просто «Баба Яга против». А ещё у всех вокзалов свои формы таких бланков.

С точки зрения вокзала электронный билет — это развитие. Повышается безопасность вокзала, удобнее контролёру и водителю, ускоряются операции, экономится бумага, молодые люди не задают вопросов.

Всё равно на автобусе один-два пассажира забывают билеты, и их в любом случае восстанавливают из данных вокзала. Но кое-где придираются очень сильно. Практика показала, что, если пассажир начинает сильно скандалить, его пускают. Если тихо уходит (чаще всего пенсионеры) — приходится разбираться в ситуации уже нам.

Первое, что мы сделали, — это выделили консервативные вокзалы и при покупке билетов делаем с них отдельное оповещение пассажиру о том, что надо обязательно печатать билет: без него не пустят.

Потом мы решили делать «белый список» таких автовокзалов, где работает электронная регистрация. Проверка тройная: отзыв пассажира, звонок нашего тайного покупателя, прямой вопрос руководству вокзала.

Если законодательство отстаёт от реальности в плане разрешения электронных билетов, но есть обходная процедура через восстановление билета по данным вокзала, то почему бы это не автоматизировать и не сделать свой быстрый и удобный костыль?

В общем, мы нашли такие вокзалы и разметили на сайте метки.

Проверка повторяется время от времени.

В процессе оказалось, что есть вокзалы, которые сами пришли к такой схеме, но не особо рассказывали об этом пассажирам. Интеграторы к этому тоже идут с радостью.

Потом мы дали небольшие бонусы в системе тем вокзалам, кто с такой меткой, чтобы был экономический стимул так делать.

В итоге оказалось, что мы довольно быстро объединили (ну фактически не мы, а они сами объединились, в частности, с нашим инструментом) довольно много вокзалов и перевозчиков, которые уже делают электронную регистрацию сами.

То есть можно было не просто сидеть и ждать, пока всё появится законодательно, а придумать, как это сделать программно. И всё. Нужна была связка из разработчика, менеджера, человека на общении с партнёрами и дизайнера.

Что в итоге?

Потери первого опыта:

• Минус билеты и проживание.

Выгоды:

• Почти как отпуск посреди года.
• Решили на ближайшие полгода все вопросы скопом.
• Смогли пообщаться именно командой. Почему-то в офисе так не выходит.
• Сложно измеримые вещи на уровне ощущений: изменились отношения в команде.
• Посмотрели на свой же продукт со стороны: ведь мы всё время пользовались своими инструментами (и других команд), придумали несколько фич «на лету».
• Просто сгоняли в путешествие, что логично для компании, которая про путешествия.
• «Старшие» товарищи учили «джунов» думать рационально не только в разработке, но и в планировании на день. Это очень малозначительно, но чувствуется передача опыта.
• Смогли подтянуть к общению удалённых разработчиков, чего обычно не хватало.

Нежданчики:

• Узнали, что у двух девушек катастрофические проблемы с ориентацией на местности: они потерялись, мы их нашли, больше не отпускали. Это чуть не сорвало рабочую сессию.
• Тот разработчик, который взял на себя организацию, показал проявление ситуационного лидерства. Не совсем ожидалось, эйчар и руководитель были удивлены.
• Узнали, что наш коллега Миша круто фотографирует. Взял фотоаппарат, всех снимал, потом подарил отпечатки бумажные. На память.

Очень сложно синхронизироваться по поездкам, и процессом это ещё не стало. Но, думаю, станет, потому что польза очевидна. Сейчас мы используем оба подхода: выделяем время команд в офисе на разбор гипотез и изредка выезжаем. Выезды нужны больше для определения видения и неодиночных задач, а «do not disturb» в офисе — для обкатки гипотез в режиме персонального хакатона.

В первую итерацию отобрали и проверили семь гипотез, из них три показали результаты. Например, на направлении автобусов.

На этапе ввода данных пассажиров начали показывать плашку с надписью «Последняя покупка билета на этот рейс N минут назад». На мобильной версии А/Б показала +N % к продажам, на десктопе нет значимых результатов. Развернули форму поиска на мобильной версии страниц с расписанием — в итоге получили +NN % к продажам. Получаем данные от клиентов, чтобы иметь возможность их вернуть. На пустых выдачах начали собирать имейлы пользователей, чтобы прислать автобусы, если появятся на направлении, их сотни в неделю. На основе предпочтений пользователя собираем предложения в рассылку. Итоги. Попадание: 91–93 %. Продажи из открывших письмо: +NN,3 % (значимо). Но! Люди ездят на автобусах по одним и тем же направлениям, а значит, и предсказания одинаковые. Пока получается, что рассылки будут всегда одинаковые. Будем думать, как разнообразить.

В это время в бэклоге были типовые задачи, например, такая рутина:

• Запустить две интеграции с автовокзалами.
• Обновить три текущие интеграции.
• Интегрировать литовских перевозчиков на автобусах.
• Сделать коннекторы для личного кабинета 16 перевозчиков.

В общем, это работает, но мы бы с удовольствием послушали ваш опыт работы «в отрыве» от офиса и выездов куда-то, если они у вас были.

Автор: Игорь Сивец

Источник ^[4]