Аналитиков данных я собеседую так: делаю первым звонок на 15 минут, задаю несколько несложных вопросов на понимание концепции машинного обучения. Если все ок, приглашаем на собеседование. Первое собеседование делится на две части: полчаса общаемся на тему машинного обучения, от азов до более сложных вещей. Во второй части задаем инженерные вопросы, например, какие-то вещи делаем на SQL. Потом устраиваем еще одно собеседование – решаем простейшую задачу машинного обучения. Буквально – садимся вместе за один компьютер, и кандидат выполняет задание, а я в это время задаю вопросы, чтобы убедиться, что он понимает, что и почему делает, действительно ли кандидат – практик. Обычно это сразу видно по скорости написания кода. В целом этих собеседований достаточно, чтобы оценить человека и сделать ему оффер.
Тема увольнения обычно стыдливо замалчивается, но оно даже важнее найма. Популистские высказывания в духе «нанимай медленно, увольняй быстро» я не поддерживаю. К сотрудникам нужно относиться по-человечески. Расставаться тоже нужно по-человечески, это важная часть корпоративной культуры. Увольнения происходят с двух сторон: по инициативе сотрудника и по инициативе работодателя. В моей практике первых было больше. Главная причина – мало машинного обучения, а ведь на курсах рассказывали, что этого будет много. Наука сильно расходится здесь с жизнью. Не устаю повторять, что реального машинного обучения в проектах машинного обучения 5–10 % времени. После такого опыта я стал целенаправленно отсеивать таких кандидатов-мечтателей на этапе собеседования. Вторая причина – сотрудник сильно вырос или устал долго работать на одном проекте. В таких случаях я обычно помогаю ему найти новое место работы, используя свои связи.
Причины уволить сотрудника могут быть разными – откровенно лажает, не вписывается в нашу аналитическую культуру. Но я никогда не тороплю события, ведь я также могу ошибаться. Для начала советуюсь с командой, с каждым отдельно. Если получаю негативные отзывы – это практически всегда означает, что нужно расставаться. Можно попробовать поговорить, подкинуть проекты, но обычно это не работает. Я наблюдал за карьерой уволенных и обратил внимание, что часто эти сотрудники находят нормальную работу и приживаются там. То есть они не были плохими – просто они не подошли нам, и это нормально.
Кому подчиняются аналитики
В идеале аналитики должны быть независимы от менеджеров, которых они оценивают. Тут принцип – кто платит, тот и музыку заказывает. Не может сотрудник менеджера объективно оценить его работу. Решать задачи отдела может (помните про децентрализацию из прошлой главы?), но оценивать – нет. Здесь нужна независимость от операций. Я бы рекомендовал, чтобы центральный аналитический отдел подчинялся генеральному директору, финансам или IT. Список дан в порядке приоритета. У меня был опыт подчинения генеральному директору, директору по маркетингу и IT. Первый вариант был самым лучшим опытом – внешнее давление минимально. Но в этом есть и проблема: как правило, менеджеры не знают, как управлять аналитикой, а генеральному директору еще и времени не хватает. Руководителю аналитики придется проявить недюжинную самостоятельность. Я лично получал задания в духе: «найди что-нибудь интересненькое». Эту книгу я начал писать в том числе и для того, чтобы ее прочитали топ-менеджеры, которым подчиняется аналитика. Мне бы этого очень хотелось!
Должен ли руководитель аналитики писать код
Я всегда любил роль играющего тренера – управлять небольшой командой людей, учить стажеров, но при этом самому делать задачи. Скажу без ложной скромности: моя команда в компании – это всегда отряд спецназа, который решает сложные задачи за очень ограниченное время. Обычно в самом начале я всегда проектировал аналитическую систему и писал базовый код для ее фундамента наравне со всеми – всё как в стартапе. В какой-то момент я чувствовал, что ребята стали уже сильнее меня и можно им делегировать не только отдельные задачи, но и целые направления. Правда, что-то я продолжал делать сам – не хватало решимости отдать код полностью в чужие руки, и не хотелось, чтобы мои технические навыки полностью атрофировались. Но потом обстоятельства заставили меня посмотреть на работу руководителя аналитики с другой стороны.
Я попал на собеседование в Quora на должность менеджера. Послушав, чем я занимаюсь, директор по аналитике Шавье Аматриан (Xavier Amatriain) мне прямо сказал: ты ни то ни сё – не менеджер и не разработчик. И не принял меня на работу. Этот сигнал заставил меня задуматься: за двумя зайцами погонишься – ни одного не поймаешь. Что на самом деле очень сложно совмещать работу сотрудника и менеджера и при этом быть эффективным во всем.
Однажды мне на глаза попался ответ Эрика Колсона (который тогда руководил аналитикой Netfliх) на Quora [20]:
«…главная задача менеджера – наем (это действительно непросто – найти отличного аналитика данных). Далее организация команд – не только аналитиков, но и работа с другими командами в организации (Продукт, Инженеры, Маркетинг и т. д.). Затем коммуникация, координация, наставничество и т. д. Для менеджера не остается времени для решения аналитических задач, и, следовательно, это делегируется. Технические навыки лидера команды атрофируются».
И это действительно так. Вначале привлекает магия черных ящиков алгоритмов, потом хочется большего, ты становишься менеджером – и всему приходит конец, магия становится рутиной. Ты видишь только метрики, но код становится для тебя все менее читабельным. Моя история как раз об этом – роль играющего тренера очень нужна и полезна, но только на старте, в какой-то момент нужно делегировать все – иначе вы будете неэффективно делать и то и другое. Еще один факт – код или любые задачи, которые руководитель делает как исполнитель, обходятся гораздо дороже. Поначалу в Retail Rocket, собрав первую команду, я отошел от программирования к проверке (тестированию) всех выполненных ею задач. Потом, поддавшись влиянию партнера, вернулся к программированию – о чем сейчас жалею. Я согласен с Колсоном – менеджер на определенном этапе должен полностью отказаться от программирования и самостоятельного выполнения задач.
Важный аспект – мотивация менеджера. Я люблю цитировать конспект лекций «You and your research» [21] Ричарда Хэмминга. Ричард работал в лаборатории Bell Labs, в том числе с Клодом Шенноном (основателем теории информации). Как и многие знаменитые ученые того времени, Хэмминг работал над проектом первой атомной бомбы США. Сама лаборатория была очень мощной: там изобрели первый транзистор, ученые лаборатории получили семь Нобелевских премий в разных областях. Его попросили сравнить исследовательскую работу и менеджмент, и вот что он ответил:
«Если вы хотите быть великим исследователем, вы не станете им, будучи президентом компании. Другое дело, если вы хотите быть президентом компании. Я не против того, чтобы быть президентом компании. Я просто не хочу. Я думаю, Иан Росс делает хорошую работу в качестве президента Bell Labs. Я не против этого; но вы должны четко понимать, чего хотите. Еще, когда вы молоды, вы можете захотеть быть великим ученым, но пожив больше, вы можете изменить мнение. Например, я пошел однажды к своему боссу, Боду, и спросил: “Почему ты вообще стал главой департамента? Почему ты не остался просто хорошим ученым?” Он ответил: “Хэмминг, у меня было видение того, какой должна быть математика в Bell Laboratories. И я понимал, что, чтобы это видение воплотилось, это должен был сделать я; я должен был быть главой департамента”. Когда вы можете в одиночку воплотить то, что хотите, тогда вам следует этим заниматься. Как только ваше видение того, что, как вы считаете, должно быть сделано, больше того, что вы можете сделать в одиночку, вам надо двигаться в менеджмент. И чем больше видение, тем дальше в менеджмент вам надо идти. Если у вас есть видение того, какой должна быть вся лаборатория или вся Bell System, вам надо идти туда, чтобы это осуществить. Вы не можете это осуществить легко снизу.
