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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 % трафика, которого касаются бесчеловечные эксперименты).

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

Автор: Igor_tutu

Источник