Сколько времени занимает проверка гипотезы для мобильного приложения? Давайте посчитаем:
Если ваши разработчики работают по Scrum с двухнедельными итерациями, обычно это означает, что тестирование гипотезы занимает полный месяц. С другими методологиями этот срок можно ужать, но незначительно.
Такое положение дел делает невозможным достижение ритма “5 гипотез в неделю”, к которому стремятся многие продуктовые команды.
Ниже я расскажу, как можно ускорить и улучшить этот процесс и укажу ряд готовых решений, которые можно использовать.
Поехали.
Для тех кого интересуют сами 24 рецепта — они в конце статьи.
Web Summit 2018 в Лиссабоне очень масштабное событие, я на таком присутствовал впервые и очень многое меня удивило. Во-первых то, что планируемое количество посетителей саммита 70К, при населении города 600К, то есть, в принципе, каждый десятый должен быть участником саммита. На самом деле, начинать ощущать масштаб мероприятия мы начали уже при подходе к метро. Просто толпы идут в одном направлении. Поэтому ошибиться в утренние часы в дни саммита — «а туда ли ты идешь?» — просто невозможно. Весь город идет на саммит. Следуйте за толпой.
Было приятно увидеть, что на всех схемах метро, на станции, на которой проходит саммит, есть наклейка с логотипом саммита — не заблудишься точно. На всех пересадочных станциях, везде указатели.
Очень много молодежи, видно, что с разных стран. Довольно много русской речи, многие уже имеют на груди бейджик Web Summit, значит прилетели на день раньше… А нет, приглядишься — ВСЕ имеют такой бейджик. Весь вагон. Вся станция метро.
Бейджик получаешь после регистрации на саммите. Кроме него, надевают еще тканевый браслет на руку. Потеряешь что-то одно из этого — придется выложить 100 евро, потеряешь оба — заново плати за входной билет 1500 евро! С браслетом можно мыться, проверено. Бейдж берегите.
Нам, как участникам, кстати, столько платить не пришлось, мы за все 3 билета заплатили меньше чем за один и еще получили стенд в эти деньги. Делать новые технологии выгодно!
Выйдя из метро на улице — просто идите туда куда идут все. Ближе к входу — начинают появляться волонтеры, которые разделяют потоки на тех кто уже зарегистрировался и на тех кто еще нет. Улыбаются, приветствуют, а мы предвкушаем.
Всем привет!
Под хеллоувин я побывал на конференции в Будапеште (Data Crunch) и послушал там ряд интересных докладов. Один из них был от Uber, которые рассказывали о том, на каких подходах они организовали свою платформу управления данными. Этот доклад был не столько технический, сколько менеджерский и продуктовый.
Uber обширно используется данные, которые собирает в результате взаимодействия с пассажирами и водителями. Они рассчитывают стоимость поездки, оценивают потоки людей, меняют алгоритмы цены, дают рекомендации водителям, как им больше заработать и все это основываясь на собранных данных. В такой компании вся работа с данными не может быть сконцентрирована в руках группы аналитиков и DS, т.к. иначе придется нанять их слишком много, да к тому же они не всегда погружены в бизнес контекст.
"Анализ данных" часто организован так: вот у нас разработчики хранилища, а вот у нас аналитики. В DWH (data warehouse, хранилище) умеют SQL, а аналитики у нас умеют работать c экселем. Если нам нужно что-то проанализировать, то идете к аналитикам, а они идут за данными к DWH за данными. Вроде бы логично. И многие воспринимают, что это нормальное разделение труда. В этой статье я хочу донести мысль, что это разделение труда ошибочное и грандиозно снижает эффективность и производительность труда всего процесса анализа данных.
Типичный цикл работы по аналитической задаче выглядит так:
Каждая компания это не звездные технологии и супер крутые программисты, а огромная гора bottleneck, неэффективностей и сумма плохих решений, которая как-то да едет и делает свою работу. Но вот вы решили сделать какие-то изменения и сразу начинаете сталкиваться с тем, что в огромном кол-ве бизнес процессов у вас проблемы. Ну и эти проблемы, конечно, нужно решать не идеальным способом, а оптимальным по трудозатратам.
Хочу поделится одним таким примером, связанных с моей темой анализа данных и управления данными. Во многих организациях существует финансовые службы, основная цель которых предоставлять финансовую информацию руководству о состоянии предприятия. Среди многих работ этих людей есть одна такая задача: составление прогноза выручки на следующий период (год, квартал у кого как). Этот прогноз выручки часто бывает первым этапов в согласовании планов на следующий период и составлении общего прогноза по прибылям и убыткам предприятия.
Все, кто занимается такого рода прогнозированием, понимают, что в этом вопросе важна не столько точность прогнозов, сколько правильные взаимосвязи между вашими предпосылками и результатами. Ведь что мы хотим от прогноза? Мы хотим узнать, что будет, если делать все как обычно (AS IS) и что будет, если мы что-то поменяем (сценарии). Для того, чтобы сделать эту работу финансовая служба должна придумать какую-то модель предприятия, которой она может легко управлять, легко объяснять бизнесу как она работает и легко предоставлять данные в различных разрезах, в которых бизнес захочет это дело посмотреть.
Это все отличные намерения, но тут мы сталкиваемся с суровой реальностью: методологические и технические навыки для выполнения этих задач в конкретных предприятиях откровенно слабы. Модели неудобные, быстро не изменяемые, не обновляемые, легко ничего не объясняется, файлы не удобные, а разрезы получить невозможно или очень долго. Давайте посмотрим конкретный пример, где всё плохо и как это можно исправить.
Сегодня мы добавим в анализе еще один аспект — сегментацию и кластеризацию клиентской базы. Как я уже не раз писал, анализ клиентской базы остается не полным, если мы смотрим на наших клиентов, как на большую кучу одинаковых людей. Клиенты разделяются на типы и по-разному потребяют продукт. Кто-то покупает часто, но не много, кто-то быстро уходит, кто-то покупает много и часто. Для увеличения эффективности стоит выяснить, какие есть группы клиентов и затем разобраться, как ваши действия позволят вам привлечь нужных вам клиентов. Используют два основных способа разобраться в группам ваших клиентов: эвристики и кластеризация
В рамках этого подхода вы на основе опыта, логики использования вашего продукта и клиентских историй, придумываете различные портреты потребителей и затем оцениваете, сколько у вас клиентов попадают под эти определения. Или же можете использовать более численные подходы, основанные на анализе показателей клиентов. Несколько популярных численным эвристик подходов это:
Основная идея разделить клиентов по общему вкладу в вашу выручку и по динамике роста показателей. ABC отвечает за вклад в выручку, XYZ отвечает за стабильность выручки. Это формирует 9 сегментов
Разработка программного обеспечения и эксплуатация уже реализованного софта (например, приложения) находится в особом положении в контексте анализа расходов. Особенность в том, что типичный цикл производства товара и его продажи не существует в ИТ отрасли. Вместо этого мы имеем фактически бесплатно размножаемые копии продукта, но высокие издержки на само создание этого продукта и его поддержание. По этой причине экономика ИТ компании сильно отличается от экономики “свечного завода” или магазина.
Давайте детальнее рассмотрим ситуацию с издержками в ИТ компании. К сожалению не получится обобщить все ИТ компании в одну схему. Я попробую выделить несколько распространенных схем работы и рассмотреть их. Возможно кто-то из читателей добавит еще какие-то схемы, интересные для рассмотрения.
Я хочу выделить следующие типы ИТ компаний, хотя этот список, конечно, не полный:
Какие расходы имеет первый тип компании? Давайте разделим на разные кучки расходы по основным типам, которые не зависят от предприятия:
