На протяжении последнего года я плотно занимался аналитикой web-сервисов. Это получилось довольно случайно: изначально меня отдали помогать обрабатывать данные на MapReduce аналитикам персональных сервисов Яндекса, но простая обработка сырых данных мне быстро наскучила и я начал делать еще и аналитические задачи. Почему я решил об этом написать сейчас? Этот год работы "почти-аналитиком" закончился и я вернулся полностью к разработке. Как оказалось, за все это время прекрасная команда аналитиков (и не менее прекрасная соседняя команда маркетологов) научила меня многим важным вещам, и мне кажется крайне полезным их сейчас записать. В теории все они кажутся весьма банальными и очевидными, но на практике почему-то о них часто забывают.

Думай, что ты будешь делать с результатом

Это было самое первое и самое важное полученное знание. Как его использовать? Если хочется что-то получить, нужно представить, что это что-то уже есть и решить, достаточно ли этого для решения задачи. А еще лучше, прямо смоделировать это "уже есть".

Попробую показать на примере как это и зачем. Представим, что есть некоторый сервис индексации файлов. И представим, что сервис должен индексировать файлы в реальном времени. Чтобы иметь возможность контролировать, что 95% индексаций проходят в пределах 1 секунды, мы решаем анализировать логи и строить отчет за каждый день со следующими показателями времени индексации: "среднее", "максимальное", "медиана", "95 процентиль".

Если бы мы сразу сделали прототип этого отчета (на бумаге, например) с данными "из головы" и смоделировали несколько гипотетических ситуаций, мы бы увидели, какие метрики полезны, какие явно являются лишними, а каких не хватает. Это позволит решить многие проблемы отчета еще до того, как этот отчет покажет первые результаты. В данном случае стало понятно, что намного лучше использовать метрики, которые точно отражают KPI - число запросов, укладывающихся во время x, где x равен 1 секунде (наш условный реалтайм), 10 секундам (верхний допустимый порог), а затем разумным градациям вроде 1 минуты, 10 минутам, 1 часу и тд. Подробнее о том, почему старый набор метрик плох, я постараюсь рассказать в будущих заметках.

В разработке ПО это правило тоже можно успешно применить: сначала смоделировать работу с интерфейсом (класса, модуля, http-ручки), и только после этого заниматься реализацией. В реальном проекте всегда проще изменить реализацию, не меняя интерфейса - ведь меняя интерфейс одной сущности придется менять и все места, где эта сущность взаимодействует с другими. К тому же, после того, как становится понятен интерфейс, процесс реализации становится намного проще.

Иногда лучше плохой результат, чем отсутствие результата

Тут нужно пояснить, что "плохой" в данном случае - это неточный или нестабильный. С этим правилом я познакомится в тот момент, когда выкатился проект X (могу только сказать, что это часть десктопного ПО Яндекс.Диска) и его команде было крайне важно оценить количество пользователей, которые им воспользовались. За час из груды разрозненной документации, исходников и логов была составлена методологию подсчета и небольшой отчет - на основании которого в очень короткие сроки были приняты решения о дальнейшем его промотировании. Почему это было лучше, чем принять решение наобум? Мой отчет "может быть, содержит ошибку", то решение, принятое методом научного тыка будет ошибочным в половине случаев.

Бывают и ситуации проще - нужно только оценить порядок величин. Здесь мы сразу понимаем, что точный результат нам не нужен, а примерные значения мы можем получить малой кровью на основе имеющихся данных.

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

Но плохой результат должен быть скорректирован

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

С прототипами ситуация очень похожая - первоначальная архитектура могла оказаться не оптимальной. Здесь так же важно вовремя остановится и исправить ошибки до того, как система поедет в продакшен.

А готов ли ты это оплатить из своего кармана?

Этому прекрасному приему оценки своей веры в необходимость проекта меня научили маркетологи. Как известно, любой проект должен или приносить доход, или сокращать издержки. Поэтому, при возникновении идеи нового проекта стоит задать себе вопрос "готов ли ты оплатить реализацию проекта из своего кармана, получив деньги назад только в случае его положительной рентабельности?". Этот же вопрос можно задать и тому, кто приходит к менеджеру проекта со своей идей. Я видел, как этот фильтр отсеивал достаточно плохих идей, а те, что через него прошли, были действительно крутыми. А ведь этот вопрос всего лишь позволяет беспристрастно посмотреть на свою идею со стороны, что лишним не бывает никогда.

Знай свои инструменты

Аналитики использует в своей работе множество инструментов - Яндекс.Метрику, TNS, Comscore, логи, flurry и другие. Крайне важно всегда понимать, что каждый из них показывает в каждом случае, почему показания одно отличаются от другого, быть уверенным, что все в них нет ошибок (особенно это касается расчетов по логам). Ну и конечно же понимать, по какой методике идет расчет показателей в каждом их них. Наведение порядка в таком количестве разных сущностей - дело крайне не простое, но критически важное, поскольку аналитика оперирует не просто цифрами, а смыслом, который они в себе несут. Например, принимая решение на основе данных мобильного TNS следует учитывать, что количество их респондентов сейчас не превышает нескольких тысяч (а в некоторых срезах - и десятка), данные о действиях которых экстраполируются на миллионы.

И все вышесказанное относится не только к аналитике. Очень тяжело придется разработчику, который не знает, какие ограничения накладывает статическая или динамическая типизация (и какие преимущества несет), не знает, что Git оперирует не файлами, а изменениями, не знает, в чем заключается функциональная парадигма, не знает, как работает GIL в Python. И этот список можно продолжать достаточно долго, но смысл один - чтобы правильно использовать свои инструменты, нужно знать особенности их работы.


Comments

comments powered by Disqus