Роман Зыков - Роман с Data Science. Как монетизировать большие данные [litres]

Я всегда любил роль играющего тренера – управлять небольшой командой людей, учить стажеров, но при этом самому делать задачи. Скажу без ложной скромности: моя команда в компании – это всегда отряд спецназа, который решает сложные задачи за очень ограниченное время. Обычно в самом начале я всегда проектировал аналитическую систему и писал базовый код для ее фундамента наравне со всеми – всё как в стартапе. В какой-то момент я чувствовал, что ребята стали уже сильнее меня и можно им делегировать не только отдельные задачи, но и целые направления. Правда, что-то я продолжал делать сам – не хватало решимости отдать код полностью в чужие руки, и не хотелось, чтобы мои технические навыки полностью атрофировались. Но потом обстоятельства заставили меня посмотреть на работу руководителя аналитики с другой стороны.

Я попал на собеседование в Quora на должность менеджера. Послушав, чем я занимаюсь, директор по аналитике Шавье Аматриан (Xavier Amatriain) мне прямо сказал: ты ни то ни сё – не менеджер и не разработчик. И не принял меня на работу. Этот сигнал заставил меня задуматься: за двумя зайцами погонишься – ни одного не поймаешь. Что на самом деле очень сложно совмещать работу сотрудника и менеджера и при этом быть эффективным во всем.

Однажды мне на глаза попался ответ Эрика Колсона (который тогда руководил аналитикой Netfliх) на Quora [20]:

«…главная задача менеджера – наем (это действительно непросто – найти отличного аналитика данных). Далее организация команд – не только аналитиков, но и работа с другими командами в организации (Продукт, Инженеры, Маркетинг и т. д.). Затем коммуникация, координация, наставничество и т. д. Для менеджера не остается времени для решения аналитических задач, и, следовательно, это делегируется. Технические навыки лидера команды атрофируются».

И это действительно так. Вначале привлекает магия черных ящиков алгоритмов, потом хочется большего, ты становишься менеджером – и всему приходит конец, магия становится рутиной. Ты видишь только метрики, но код становится для тебя все менее читабельным. Моя история как раз об этом – роль играющего тренера очень нужна и полезна, но только на старте, в какой-то момент нужно делегировать все – иначе вы будете неэффективно делать и то и другое. Еще один факт – код или любые задачи, которые руководитель делает как исполнитель, обходятся гораздо дороже. Поначалу в Retail Rocket, собрав первую команду, я отошел от программирования к проверке (тестированию) всех выполненных ею задач. Потом, поддавшись влиянию партнера, вернулся к программированию – о чем сейчас жалею. Я согласен с Колсоном – менеджер на определенном этапе должен полностью отказаться от программирования и самостоятельного выполнения задач.

Важный аспект – мотивация менеджера. Я люблю цитировать конспект лекций «You and your research» [21] Ричарда Хэмминга. Ричард работал в лаборатории Bell Labs, в том числе с Клодом Шенноном (основателем теории информации). Как и многие знаменитые ученые того времени, Хэмминг работал над проектом первой атомной бомбы США. Сама лаборатория была очень мощной: там изобрели первый транзистор, ученые лаборатории получили семь Нобелевских премий в разных областях. Его попросили сравнить исследовательскую работу и менеджмент, и вот что он ответил:

«Если вы хотите быть великим исследователем, вы не станете им, будучи президентом компании. Другое дело, если вы хотите быть президентом компании. Я не против того, чтобы быть президентом компании. Я просто не хочу. Я думаю, Иан Росс делает хорошую работу в качестве президента Bell Labs. Я не против этого; но вы должны четко понимать, чего хотите. Еще, когда вы молоды, вы можете захотеть быть великим ученым, но пожив больше, вы можете изменить мнение. Например, я пошел однажды к своему боссу, Боду, и спросил: “Почему ты вообще стал главой департамента? Почему ты не остался просто хорошим ученым?” Он ответил: “Хэмминг, у меня было видение того, какой должна быть математика в Bell Laboratories. И я понимал, что, чтобы это видение воплотилось, это должен был сделать я; я должен был быть главой департамента”. Когда вы можете в одиночку воплотить то, что хотите, тогда вам следует этим заниматься. Как только ваше видение того, что, как вы считаете, должно быть сделано, больше того, что вы можете сделать в одиночку, вам надо двигаться в менеджмент. И чем больше видение, тем дальше в менеджмент вам надо идти. Если у вас есть видение того, какой должна быть вся лаборатория или вся Bell System, вам надо идти туда, чтобы это осуществить. Вы не можете это осуществить легко снизу.

Это зависит от ваших целей и желаний. И по мере их изменения в жизни вы должны быть готовы меняться. Я выбрал избегать менеджмента, потому что предпочитал делать то, что могу делать в одиночку. Но это выбор, который сделал я, и он субъективен. Каждый человек имеет право на собственный выбор. Пусть ваш ум будет открыт. Но когда вы выберете путь, ради всего святого, осознавайте, что вы сделали и что решили. Не пытайтесь делать и одно, и другое».

Есть один минус полного перехода в менеджмент – атрофия технических навыков. Менеджеру будет сложно вернуться в работу руками, а такое иногда бывает, например, когда создают стартап. По этому поводу Колсон написал [20], что «истинный лидер аналитики никогда не утратит любопытства и поздними вечерами или утром в выходные может самостоятельно покопаться в данных, строить простейшие графики и самостоятельно сделать выводы. Это даст ему понимание данных, которое нельзя получить никаким другим способом, кроме как погрузив туда руки». Что повысит вашу самооценку и поможет мотивировать ваших сотрудников быть любознательными и любить свою профессию. Я очень люблю свое ремесло, даже когда управляю чем-то, мне всегда интересно посмотреть код – как это работает внутри черного ящика.

Почти все задачи аналитики делятся по направлениям, и к каждому нужен свой подход:

• Инженерные задачи.

• Найти причину какого-либо явления (инсайт).

• Проверить гипотезу или провести исследование.

Инженерные задачи включают в себя разработку дашбордов, метрик, добавление источников данных, оптимизацию вычислений, решение вопросов технического долга. Все эти задачи объединяет один очень важный фактор – у них четкий и понятный результат и, как правило, легко прогнозируемая трудоемкость. Их можно щелкать, как орешки, последовательно меняя статус (рис. 3.1):

• Задача пришла от заказчика (New).

• Задача получила приоритет, оценку трудоемкости и поставлена в очередь на исполнение (To Do).

• Задача взята в работу (In Progress).