Хабрахабр

Что разработчикам надо знать про бизнес

Даже в очень крупных компаниях часто отношение к разработчикам, как к грибам: держат в темноте и кормят навозом. Пишите код, родные, и не высовывайтесь. Этот подход может быть удобен для многих (в том числе иногда — для самих разработчиков в случае не очень адекватного менеджмента), но с точки зрения бизнеса неоптимален. Моя позиция: разработчики должны иметь возможность узнавать всё то, что происходит в компании и на рынке, но без давления. Захотел — копнул и разобрался, не захотел — не надо.

Редко кто не хочет видеть влияния реализованных фич на мир вокруг. Редко когда разработчик не хочет понимать, зачем и что он делает. Деньги есть везде. Да ладно, давайте будем честными: мы тут все или из-за денег, или из-за возможности делать что-то значимое. А вот интересные проекты встречаются реже.

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

Общая позиция

  • Команде разработки, насколько это возможно, — рассказывать, что происходит на рынке, какие отношения с конкурентами, что и как происходит.
  • Топ-менеджменту компании важно знать, что именно было сделано в проекте и как это ведёт к стратегической цели. Обычно речь идёт про уровень групп проектов, но если хочется — можно провалиться в отчёт до конкретных работ.
  • Другим командам интересно смотреть, что делают коллеги. У нас на разных видах транспорта (ж/д, авиа, автобусы) решаются похожие задачи, и часто можно переиспользовать код, подсмотреть идею или увидеть, как используются разные инструменты. И спросить.

На что это влияет?

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

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

Мышление инженера отличается от мышления обычного человека. И вот тут у нас много раз возникало очень интересное явление. Есть незамыленность взгляда. Где-то более структурно, где-то неожиданно хорошие решения, где-то когнитивные искажения. И плевать, сколько ему лет. Есть отрицание практик «так сложилось», потому что для кого-то они — данность, а для инженера — мрачное легаси.

У разработчиков явно были большие сложности с финансовым анализом, и надо было очень часто их грузить, чтобы обосновать возможность или невозможность (чаще) решения. Поначалу обсуждения замедлились.

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

Год назад это казалось фантастикой, и у каждого перевозчика включая небольших ИП с ржавыми автобусами 80-х были свои стандарты. Следующая важная вещь — на рынке в перспективе 1-2 лет ожидается появление единой системы. Мы и так построили часть её функциональности, но теперь можно будет убрать этот слой и сразу получать чистые данные. Теперь всё это заводится в единую информационную систему. В минимуме это снимает вопросы уровня «а чего мы не доделываем мой крутой код крутой фичи», а в максимуме даёт возможность подготовиться к изменениям эффективнее всех. Конечно, при таком изменении рынка нам нужна вся команда для обсуждения. Порисовали архитектуру того, как будет реализовываться на федеральном уровне, и поняли, что наша система станет надстройкой, чтобы управлять брендом, маркетинговыми акциями и другими инструментами по продвижению и коммуникации с пользователями. Маркетинг советуется с технической командой, спрашивая, как бы они делали новую систему и какие у неё будут ограничения. Будет не дублирующая-конкурирующая, а интегрированная.

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

Разработчик выступает на конференции, говорит про техническое решение. Следующий пример. Ему задают абсолютно пользовательский вопрос из зала на уровне «а что будет, если я сяду на следующей остановке». Рассказал про собственную систему для бронирования рейсов — личный кабинет перевозчика. Здесь он рассказал про то, как работает бизнес, какие отношения между перевозчиком и вокзалом. В 98 % случаев разработчик отвечал бы в терминах интеграции и обмена данными. И проаргументировал каждую деталь.

Ладно, как информировать-то?

Когда в компании было пять владельцев продуктов, мы раз в неделю собирались и обменивались, что полезного произошло в продукте и что может быть другим полезно. Потом нас стало восемь. Потом — 13 человек. А 13 человек уже сложнее собрать. Предложили обмениваться результатами аналитики в письмах. Стали рассказывать, что в продукте сделали полезного, и давать рекомендации, как это применить в других продуктах. Был раз в полтора месяца, потом — раз в месяц.

По результатам работы команды за месяц отправляется здоровенное письмо (последний раз по автобусам это было 27 страниц А4). Так сформировалась традиция-правило с месячными отчётами. Это помогает получать обратную связь, новые идеи. Можно читать только верх, а можно всё подряд или кусками.

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

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

В итоге появилась такая структура:

  • Основные задачи, которые были в продукте: для чего, зачем, почему, как. Тут очень важно отметить, что каждая задача как-то влияет на рынок. Группы фич собираются в пункты стратегии вроде «оформлять заказ быстрее всего» или «иметь самое точное расписание»,
  • Потом выносим результаты аналитических исследований. Так, например, благодаря нашим исследованиям мы узнали, что очень часто поездка на автобусе — это только первый шаг в путешествии, и дальше человек едет на поезде. Или с поезда пересаживается на автобус (если едет в глубинку). А это очень важно, потому что в первом приближении влияет на маркетинг, а во втором — вообще на все интерфейсы. Потому что задача уже — не купить билет на автобус, а состыковать его с поездом, чтобы добраться куда-то удобно. Следующая аналитика — сравнивали маршрутную сеть электричек, поездов, автобусов на предмет дублирования или расширения. Чтобы на странице расписания электричек Москва — Дмитров и дальше автобусы по всему Дмитровскому району были в виджете. Сейчас — в реализации.
  • Могут встречаться новости с рынка. Всё банально: просто чтобы все знали, чего ждать и что уже сделано крупного.
  • Опросы — вопросы, если кого-то надо привлечь. Собирали информацию внутри, кто как ездит и с какими проблемами сталкивался. Опрашивали команду, как было бы удобнее реализовать электронный билет. По ассортименту автобусов — кто где ездил, как там было, насколько всё ржавое. Иногда просим фотографировать расписания на остановках на определённых направлениях.

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

И мы кое-что берём. Многие наши исследования полезны коллегам. Мы-то привыкли думать, что подход к покупке билета — линейный типа воронки. По примеру другого продукта — туров — сделали CJM-пользователей. Отслеживание всех этих странных траекторий позволило принять решение, что какие-то шаги лишние, где-то люди замыкаются. На самом деле люди плутают между страницами, открывают десятки вкладок, уверенно нажимают «назад» в браузере в разных формах и вообще браузят одновременно с разных устройств (пересаживаются с мобильного телефона на десктоп, когда надо купить). Напомню, речь идёт о тех людях, кто живёт в деревнях и не знает различий между поисковым запросом и адресом сайта. Типичная российская проблема: при выборе автобуса многие не могли победить интерфейс выбора места. В общем, родилась гипотеза: надо выбрать место автоматически, а дальше надо либо согласиться, либо изменить его. Это как раз те, кто не умеет пользоваться скроллом на весах в супермаркете, если он там есть. — жители дальних русских селений, трудовые мигранты и ещё ряд категорий пользователей перестали путаться в интерфейсе. И — о чудо!

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

А потом предложили нашим перевозчикам догружать автобусы. Ещё одно интересное открытие — мы послушали коллег из авиа на такой встрече и разобрались, как у авиакомпаний-перевозчиков работает ценообразование на рейсы. 1 300 билет стоил, 400 рублей стал: перевозчику по 400 весь автобус сажать невыгодно, но взять 10 человек по 400 и везти их лучше, чем не взять вообще никого дополнительно. Когда рейс уходит с 40-процентным заполнением или меньше, мы скидываем цену за небольшой промежуток времени так, чтобы получалось меньше электричек по тому же направлению.

Как формируется сам отчёт?

Задачи и их прогресс. Примеры:

Новые правила принятия решения для КЦ

  1. Что решали? Специалисты контакт-центра должны в некоторых случаях самостоятельно принимать решения в пользу клиента, не дожидаясь разбора ситуации с партнёром (автовокзалом, перевозчиком), что может занимать недели, или разбор от саппорта. Поэтому оценили, где находится ценовой порог потерь, ниже которого специалисты КЦ могут моментально принимать решения.
  2. Результат, и что делаем дальше? Цена определена, продолжим отрабатывать на других сценариях. При этом все данные собираются, и будем контролировать эту метрику (потери на билет). Специалисты КЦ начинают самостоятельно решать часть кейсов от клиентов.
  3. Как это может быть полезно в других продуктах? Порой эффективнее и лучше скажется на бренде, если сразу помочь клиенту, чем погружаться в глубокое разбирательство. Оцените, может, тут у вас тоже есть над чем поработать.

На пустых выдачах включили все КТИСы (ж/д, авиа, электрички)

  1. Что решали? На пустых выдачах, когда мы не можем предложить клиенту автобусов, начали показывать все КТИСы, вернули ж/д. Важно было посмотреть, как это влияет на поведение, интересна ли альтернатива, и стоит ли дальше развивать.
  2. Результат, и что делаем дальше? В 36 % случаев клиенту предложили альтернативу. Предполагается, что клиенты ищут пока всё-таки реальные автобусы (где они действительно ходят), поэтому на самом деле есть большой хвост неудовлетворённых клиентов. Это потенциал как для автобусов, так и для ПТТ, где мы расширяем ассортимент. Интерес к этому есть, смотрят, но активно развивать на пустых выдачах не планируем, а вот как грамотно встроить в текущую выдачу – будем думать дальше.
  3. Как это может быть полезно в других продуктах? Для нашей большой страны автобус может быть где-то незаменимой частью поездки. Поэтому совмещение видов транспорта (мультимодальность) стратегически может иметь смысл, если приучить клиентов мыслить категорией из А в Б.

Исследования и гипотезы, пример:

Что заставляет людей возвращаться?

  1. Что решали? Описать пользователей, которые к нам вернулись, и как они отличаются своим поведением от тех, кто не вернулся.
  2. Результаты, и что делаем дальше? Составили набор поведенческих характеристик, которые описывают пользователя и которые потенциально могут влиять на его возвращаемость. Важно, что это не предсказательная модель, а описательная. Дальше будем проводить эксперименты, накладывать на характеристики и смотреть возвращаемость. В конечном счёте хотим создать предсказательную модель, чтобы понимать, как вовлекать пользователей в продукт, во что вовлекать, чтобы повысить вероятность возвращения. Очевидно, но факт: люди, уже покупавшие в других разделах, вероятно, могут вернуться за повторной покупкой в автобусы.
  3. Как это может быть полезно в других продуктах? Если интересно копать в эту сторону, то проделать аналогичную аналитику и сравнить пересечения.

Потом — ответы на вопрос: «Что происходит?», пример повестки:

  1. Почему покупают меньше? Да всё нормально, просто сезон, которого мы не знали.
  2. Прямой трафик. Откуда такой резкий рост? А вы правильно залогировали? А вас не парсят? И еще ответы на несколько вопросов (спойлер: да, нас парсят).
  3. Платформа. Вовлекаем пользователей. Первые результаты реального вовлечения людей в управление контентом на сайте. Люди активно помогают.
  4. Кроссплатформенные покупки. Электронный билет пока останавливает людей за ПК без принтера. Что дальше? 83 % из тех, кто сделал первую покупку на ПК, так и продолжают покупать на ПК.
  5. Когортный анализ. Графики не для слабонервных.
  6. Как устроен апсейл в авиа. Мы многое поняли про багажный билет и не только… (431 заказ в автобусах пользователями, которые за этот же период сделали заказ в авиа, из них 42 % — автобус к дополнению к самолёту (т. е. автобус либо в пункт отправления, либо в пункт прибытия), 12 % — на обратное направление.)

Бесчеловечные эксперименты (это интересно всем командам), пример:

Что же всё-таки влияет на спрос на рейс?

  1. Рейтинг перевозчика. Разница в один балл по рейтингу, по отзывам наших пользователей (например, 9,4 против 8,4), увеличивает вероятность покупки рейса на 23 %. Это может стать действительно значимым аргументом для перевозчиков для того, чтобы увеличивать уровень сервиса для пассажиров.
  2. Вероятность покупки акционного рейса (отмеченные бейджами «Предложение Туту.ру» с зачёркнутой ценой) увеличивается на XX %.
  3. Добавление первого акционного предложения на XX % увеличивает при прочих равных вероятность конверсии с выдачи. А это значит, что нужно расширять ассортимент направлений с акциями.
  4. Если в А/Б-тесте на каждом рейсе выдачи снизить количество свободных мест на одно, то вероятность конверсии с выдачи в среднем увеличится на X %.
  5. Если на выдачах, где больше 10 рейсов, выкинуть (спрятать) один рейс, то вероятность покупки увеличится на 0,6 %.

Сразу скажу, что мы не планируем подменять данные в выдаче по методам 3 и 4, а исследуем реальные факторы выбора. А/Б-тесты касаются примерно 1 % аудитории сайта и достаточно жёстко ограничены по времени. Все эксперименты этичны в том плане, что позволяют человеку решить задачу и не скрывают от него важных данных, и польза от них должна в разы перевешивать возможные неудобства.

Обратная связь с рынка, примеры:

  1. Поработали с валидацией данных вводимого расписания. Теперь враг не пройдёт (то есть перевозчик не сможет по невнимательности ввести данные нереального маршрута).
  2. Дали перевозчикам возможность редактировать своё расписание и рейсы. Ребята рады, и нам работы меньше 🙂

Дальше — выгрузка из Джиры (фактически) простым языком для тех, кто любит детали. Всякие дополнения и примечания. Всё.

Итог

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть