В понедельник команда выпустила приложение с афишей Москвы: в нём можно было выбрать событие на выходные и купить билет. В таск-трекере запуск прошёл идеально: карточку «Запуск» перетащили в «Готово».
Через неделю стало не до поздравлений. Люди приходили из рекламы, устанавливали приложение и уходили. Многие не открыли ни одного события. Покупок было мало, возвращений — тоже. Руководитель попросил выяснить, что случилось.
Следователю по продуктовым делам достался редкий случай: продукт выпустили, но запуск всё равно провалился.
На месте преступления
Следователь открыл чат проекта. В Figma лежали макеты, в таск-трекере — десятки закрытых задач, в календаре — дата релиза, обведённая красным. По документам команда сделала всё, что собиралась.
Он установил приложение и попробовал найти спектакль на субботу. Сначала пришлось указать дату, бюджет и интересы. Список интересов оказался длинным; кнопка «Показать варианты» ждала внизу. Следователь добрался до афиши. Там были события, подборки, фильтры и возможность сохранить понравившееся.
Он вернулся к началу анкеты. Почему нельзя сразу посмотреть, что вообще предлагают? Это могло объяснить часть уходов. Но оставался второй вопрос: почему не возвращались те, кто всё-таки добрался до событий?
Следователь запросил историю проекта и вызвал подозреваемых.
Расследование расследованием, а у нас для вас — промокод со скидкой на любую профессию Яндекс Практикума.
Подозреваемый № 1: Срок
Срок явился первым. Он был строг и сразу положил на стол календарь.
— Я здесь ни при чём, — сказал он. — Я всего лишь дата.
— Откуда вы взялись?
Срок помолчал. Потом признался: его поставили на планёрке. Руководитель спросил, успеет ли команда к концу месяца. Команда посмотрела друг на друга, на руководителя — и сказала, что успеет.
На тот момент у неё был прототип приложения. Исследователь ещё разбирал интервью и записи тестов. Продакт предложил вернуться к результатам на следующей встрече, но дату записали сразу.
— И чем заняли оставшееся время? — спросил следователь.
Срок придвинул список задач. В нём были подборки событий, сохранение понравившегося, уведомления и фильтр по настроению. По отдельности всё выглядело посильным. Вместе задачи заняли почти всё время до релиза.
Следователь задержался на первой карточке: «Сделать подборки к запуску». У задачи были исполнитель, макеты и согласование руководителя. Он вызвал Фичу.
Подозреваемая № 2: Фича
Фича (она же «Подборки событий») положила на стол согласованные макеты.
— Почему вас решили добавить?
— Руководитель увидел меня у конкурента. Спросил, почему у нас такого нет. Продакт сказал, что к релизу будет.
В протоколе планёрки всё подтвердилось. После вопроса руководителя команда обсуждала, какие подборки сделать: для детей, для дождливой погоды, для небольшого бюджета. Потом понадобились фильтры, а ещё — возможность сохранить событие и получить напоминание.
Разработчики оценивали задачи, дизайнер рисовал карточки. На следующем созвоне выбирали обложки. Вопрос о том, нужны ли эти функции, постепенно уступил место вопросу, когда они будут готовы.
— Что вы должны были изменить для человека? — спросил следователь.
— Помочь быстрее выбрать событие и купить билет.
— Откуда это известно?
— Так в гипотезе написано.
Следователь попросил распечатать гипотезу. Одних согласованных макетов для алиби было недостаточно.
Подозреваемая № 3: Гипотеза
Гипотеза принесла документ: «Жителям Москвы трудно выбирать, куда пойти. Если собрать события в одном приложении и предложить готовые подборки, они начнут покупать билеты у нас».
— Вас проверяли?
— Собирались после запуска.
— Как?
— Посмотреть, будут ли покупать билеты.
— А какой результат заставил бы команду отказаться от идеи?
Гипотеза заглянула в распечатку. Такого пункта там не было.
Следователь восстановил, что произошло с документом. Сначала продакт записал предположение. Потом дизайнер нарисовал по нему экраны, разработчики получили задачи, руководитель согласовал план. По ходу работы никто не вернулся к вопросу, на чём держится исходная идея.
В протоколе одной встречи нашлась реплика дизайнера: «А мы знаем, почему человек выберет наше приложение, если билеты уже можно купить в других местах?»
Продакт ответил: «Запустим и посмотрим».
— С людьми до этого хоть кто-нибудь разговаривал? — спросил следователь.
Гипотеза указала на исследователя. У него была таблица.
Свидетель: таблица исследований
Таблицу вывели на экран переговорки.
— Вас читали? — спросил следователь.
— Ссылку на меня в чате лайкнули, — ответила таблица.
Внутри лежали записи интервью с людьми, для которых команда собиралась делать приложение. Один узнавал о концертах из канала любимой площадки и покупал билеты на её сайте. Другой выбирал спектакли по рекомендациям друзей. Третий сохранял ссылки в общей переписке, где компания договаривалась о планах.
Это не означало, что новое приложение обречено. Но команда пока не нашла причину, по которой этим людям стоило поменять привычный способ. Собрать афишу и добавить подборки было недостаточно.
На соседней вкладке оказались записи теста прототипа. Участникам предлагали найти событие на выходные. Один спросил, обязательно ли заполнять интересы. Другой закрыл приложение, не дойдя до афиши. Подборок в той версии ещё не было: люди застревали раньше.
Следователь открыл сообщение, с которым исследователь отправил таблицу. Тот предложил упростить вход в афишу и до разработки новых функций проверить, ради чего человек станет пользоваться именно этим приложением.
Продакт ответил: «После релиза вернёмся. Сейчас надо закончить то, что запланировали».
Руководитель подтвердил: «Дату не двигаем».
Следователь сверил время сообщения с календарём. До запуска ещё можно было изменить план. Решение оставить всё как есть приняли уже после предупреждения.
Кто убил запуск
После релиза команда поговорила с людьми, которые установили приложение и перестали им пользоваться. Одни не увидели причины уходить с привычных сайтов за билетами. Другие хотели посмотреть события, но закрыли приложение на анкете. Данные об уходах совпали с тем, что исследователь наблюдал ещё в прототипе.
На последней встрече руководитель предложил добавить новые подборки. Следователь попросил пока не заводить задачу и разложил на столе календарь, макеты, гипотезу и таблицу.
— Так кто убил запуск? — спросил руководитель.
— Вы с продактом, — ответил следователь. — Вы приняли решение выпускать приложение, хотя не выяснили, зачем людям им пользоваться. А трудность, которую уже обнаружили на тестах, решили исправить потом.
— Но мы же сделали всё, что было в плане.
— Да. И вы сами перенесли проверку за пределы этого плана.
Срок не выбирал, какие задачи оставить. Фича не могла решить, нужна ли она людям. Гипотеза с самого начала была предположением. Руководитель и продакт располагали предупреждениями, но сохранили дату и список функций.
В заключении следователь указал причину провала: команда выпустила приложение, которое привлечённым людям было незачем предпочитать привычным сервисам и трудно попробовать. К делу он приложил сообщение с решением отложить проверку. На нём и сошлись.
Как закрыть дело
Итак, перед тем как обещать дату и отдавать подборки в разработку, команде стоит ответить на четыре вопроса.
- Что человек пытается сделать и где у него возникает трудность?
- Какие данные об этом уже есть и чего мы ещё не знаем?
- Почему предлагаем именно подборки и как быстро проверить эту идею?
- По какому признаку поймём после релиза, что человеку стало проще?
Если ответов пока нет, в план нужно заложить время на проверку — до того, как обещать дату релиза.
