Эту фразу я повторял, когда работал в Ostrovok.ru. Я точно не помню, с чем она была связана, возможно, требовалось расширить парк серверов. Считаю, что в эпоху облачных вычислений, дешевого хранения данных и хороших алгоритмов их сжатия нужно сохранять максимально много и подробно. Поверьте, когда понадобится найти ответ на какой-то вопрос и вы будете понимать, что данных нет, а могли бы быть, будет очень обидно. Рано или поздно собирать их все равно придется, почему бы не начать прямо сейчас?
ВАЖНО!Здесь хочу поднять одну проблему: в какой бы компании я ни работал – везде разработчики игнорируют аналитиков. При разработке какого-либо функционала или продукта анализ его функциональности через данные ставится на последнее место. В лучшем случае будет сделан сбор простейших метрик по усмотрению разработчика. Дальнейший сценарий такой – менеджеры проекта или продукта, владельцы бизнеса начинают активно интересоваться его судьбой. Что там с цифрами? Бегут к аналитикам, просят нарыть хоть что-нибудь. А что может сделать аналитик, если данных для статистических тестов не хватает и точность страдает? Только высосать информацию из пальца. С таким положением вещей я лично сталкивался десятки раз, а случаи, когда все было сделано как надо, могу по пальцам пересчитать.
Я предлагаю активно бороться с этим. Разработку можно понять – им нужно как можно быстрее выкатить новую «фичу» с очень хорошим качеством. Анализ метрик их не волнует, это лишние строчки кода, это работа аналитиков. Что делать? Это сфера ответственности менеджера проекта/продукта, лица, от имени которого ставится задача разработке. Необходимо в процессе постановки подобных задач предусмотреть «визу» от аналитиков. Что в нее входит:
1. Отправка технического задания и примерного списка вопросов к эффективности новой разработки аналитикам.
2. Аналитики со своей стороны отдают вам список метрик, а также встречное техническое задание для логирования (сбора метрик) данных проекта: что собирать и в каком формате.
Этот процесс не так прост, как кажется. Часто приходится в итеративном формате договариваться обо всех нюансах и ограничениях, в том числе с разработчиками. Происходит своеобразный торг, но он стоит того. Заранее хорошо продуманный результат не будет идеальным на 100 %, но если менеджмент получит ответы на 80 % своих вопросов в течение нескольких дней с момента запуска «фичи» – это успех. Ничто не играет против нас так, как время! И лучше его потратить до запуска, а не после, теряя деньги на неэффективном продукте.
Теперь коснемся доступа к данным внутри компании. Кто может получить его?
Отвлечемся на компанию Netflix, один из крупнейших поставщиков сериалов (мой любимый – «Карточный домик»). У компании очень интересная корпоративная культура [32]. Один из ее принципов звучит так: «Share information openly, broadly, and deliberately» (обмениваемся информацией открыто, широко и сознательно).
У этого правила, правда, есть строгое исключение: они нетерпимо относятся к торговле инсайдерской информацией, а также платежной информацией клиентов, доступ к которой ограничен. Как этот принцип можно применить на практике? Не ограничивать своим сотрудникам доступ к информации, но ограничить доступ к персональным данным клиентов. Я иду обычно еще дальше, стараюсь максимально убрать барьер между сотрудниками-неаналитиками и данными. Просто я считаю, что должна быть не только свобода доступа к данным, но и минимум посредников между «спрашивающим» и данными. Это важно, потому что против нас играет время. Часто сами запросы данных выглядят довольно простыми, их можно сделать самостоятельно. «Дайте мне выгрузку таких-то данных» – не аналитическая задача: менеджер знает, что ему конкретно нужно, пусть сам получит это через несложный интерфейс. Для этого нужно обучить команду самостоятельно работать с данными. Посредник только создаст задержку, но если кто-то не хочет или не может действовать самостоятельно, пусть использует посредников. Этим вы убьете сразу двух зайцев – ваши аналитики не будут демотивированы примитивным скучным трудом по выгрузке данных, а ваши менеджеры смогут получать данные почти мгновенно, и значит, не будут терять драйв.
Конечно, все персональные данные клиентов должны быть обезличены. Это можно сделать, шифруя их личную информацию. Полностью лучше ее не удалять, тогда можно будет решать часть вопросов клиентской поддержки с помощью вашей системы анализа данных.
Читать дальше
Конец ознакомительного отрывка
Купить книгу