Одно из ключевых отличий техлида в датасайнс-команде в нашем случае — это его суперуниверсальность. Сегодня клиент может запросить построить скоринг пользователя, а завтра — прислать запрос разработать модель оптимальной инкассации. То есть периметр задач в DS не обозначен так чётко, как это характерно для других команд.

И вот тут я бы хотел на примерах показать, зачем нужны софт-скиллы, когда, казалось бы, можно и без них.

Меня зовут Владимир. В этой статье мы с коллегой Алексеем @anaidenov поделимся опытом управления DS-командой и поговорим о роли техлида в этом процессе.

Если я больше занимаюсь «бумажной стороной» управления, то Алексей как техлид отвечает за управление алгоритмами машинного обучения в Департаменте анализов данных моделирования Газпромбанка, имея обширный опыт в этом вопросе именно с практической стороны.

Техлид — это обычно инженер с грейдом не ниже senior, который отвечает за организацию процесса соединения инструментов и команд с целями бизнеса.

За техлидом обычно закреплена какая-то область ответственности. Но у нас в банке зона ответственности техлида суперобширная: всё, что не попадает под риски и CRM, входит в наши обязанности. Мы отвечаем за всё, что касается графовой аналитики, Computer Vision, занимаемся геомоделями, графами, текстовой аналитикой, нейронными сетями — словом, всем, чем не занимаются другие подразделения банка. Публичные выступления — тоже на нас: конференции, форумы, презентации инноваций.

Чем хороший лид отличается от обычного?

У талантливого техлида на высоком уровне развития находятся навыки прогнозирования, оценки и аргументированной защиты своей позиции. Для техлида ценна способность адекватно оценивать ситуацию, чётко определяя, что выполнимо, а что — нет. Умение объяснить, почему та или иная задача при существующих ресурсах не может быть решена, — это тоже незаменимый навык хорошего специалиста.

Второй блок навыков связан с умением виртуозно управлять ресурсами. Учитывая, что команды большие (у нас в каждой — более 20 человек), это становится задачей со звёздочкой.

Необходимо уметь правильно оценивать нагрузку и своевременно её перераспределять.

Поскольку сотрудники высвобождают ресурсы «вразнобой», важно вовремя эти ресурсы правильно наполнять.

Ещё на техлида частично ложится задача удержания сотрудников. То есть он должен уметь распределять задания между работниками с учётом их персональных предпочтений и интересов, чтобы специалисту не наскучила его работа и он не сказал: «Не хочу сутками считать ваши регрессии!»

Ещё хороший техлид должен обладать чутьём на необходимость «перезагрузки» сотрудников: иногда человека необходимо просто вовремя отправить в отпуск, чтобы не допустить выгорания, а иногда важно вовремя организовать смену задачи или направления деятельности.

То есть у нас в команде заведена такая практика: задача приелась, в ней закончились зоны для профессионального развития — доведи её до финала, и можно взять совершенно другую.

Конечно, если всё это — не в ущерб задачам, проектам и команде.

Пример из практики

Долгое время сотрудник работал с графами: строил графы домохозяйств по связям.

Строил и строил, а через какое-то время говорит руководителю: «Слушай, мне надоело!»

Мы подготовили специалиста, который смог бы его заменить, и парень спокойно перешёл на другую задачу — стал заниматься оптимизацией массового обслуживания.

Что касается процесса передачи дел, то у нас проводится cross-review. Причём независимо от того, чем человек занимался — графами, гео или текстовой аналитикой, — специалист в нашем управлении должен быть способен проверить любой код.

«Буфер» Газпромбанка, или Что обычно делает техлид DS-команды?

Ежедневно техлид начинает утро с анализа и оценки текущего положения дел. Основная его обязанность — следить за сроками и задачами. Мы отказались от утренних летучек, от микроменеджмента, сохранив гибкость коммуникации между тимлидом и командой по текущим задачам. Команды работают в режиме двухнедельных спринтов. Мы даём сотруднику право на ошибку. Когда специалист ошибается, а затем исправляет ошибки, он обучается гораздо эффективнее и быстрее.

На самом деле это одна из самых сложных вещей в работе лида — найти баланс между степенью контроля и свободы, которую нужно дать участникам команды. У специалиста должно быть достаточно «пространства» для манёвров и экспериментов. Важно давать команде возможность самостоятельно искать и находить решения проблем. Можно подсказать направление поиска, но нельзя чрезмерно вмешиваться в процесс, а то и вовсе делать работу за коллегу в случае затруднений.

Техлид также несёт ответственность за высокую эффективность и производительность коллектива. Для этого он как бы оберегает специалистов, которые погружены в текущую предметную деятельность, от непрофильных задач.

Бывает, что, несмотря на выстроенную систему, заказчик приходит и просит решения каких-то дополнительных задач по бизнесу. И одна из задач техлида — оберегать сотрудников от лишних стрессов и избыточного внешнего давления, не отдавая их в рабство заказчику.

Одно дело — общение с заказчиком или другими командами по работе. Другое — различные «помехи» для анализа данных или написания кода. Всё, что может отвлекать экспертов от работы — лишние звонки, встречи, письма, — техлид берёт на себя.

Выступая в роли посредника между внешним миром и сотрудниками, хороший техлид обеспечивает условия для продуктивного труда в команде.

И если, с одной стороны, техлид всегда на подхвате, то с другой стороны, его же задача — взрастить в участниках команды самостоятельность для взаимодействия с другими людьми и подразделениями. Мастерство техлида проявляется в умении держать руку на пульсе, чтобы вовремя подхватить и скорректировать ситуацию, в которой возникло недопонимание или подвис процесс. Разрулить эту заминку так, чтобы конкретные исполнители продолжили выполнять задачу.

Одна из ключевых проблем техлида в том, что задач много и проконтролировать всё невозможно.

Можно работать 80 часов в неделю, а можно делегировать задачи — даже те, которые техлид способен выполнить быстрее благодаря опыту. В конечном итоге исполнители больше узнают про конкретную техническую специфику, ежедневно работая с этим руками, и станут лучше справляться с конкретными задачами. Для этого им нужно дать время.

Вклад техлида в развитие сотрудников

Получая заказ от бизнеса, техлид определяет, кого и на какую задачу лучше подключить.

При этом его цель — не просто распределить ресурсы, а сделать это с учётом индивидуальных способностей и потребностей сотрудников. Задача техлида — развивать специалистов. А значит, каждая следующая должна быть сложнее и интереснее для участника команды.

Один из таких примеров профессионального роста мы приводили выше: эксперт занимался графами и перешёл к новому для него направлению — занялся оптимизацией массового обслуживания. Есть примеры, когда специалисты занимались чисто геоаналитикой и начали осваивать новый подход с переходом в геоэмбеддинги и геомоделированием.

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

Про рутинизацию процесса: как сохранять интерес команды к работе?

Если говорить про траекторию развития сотрудников, то есть два сценария.

Первый — перевод специалиста на новые задачи. Такой подход связан с кардинальной сменой направления развития сотрудника.

Второй — развитие новых навыков в рамках одного направления, рост сложности задач и уровня компетенций.

Второй подход сложнее в реализации. Когда изо дня в день человек работает с однотипными моделями, техлиду непросто поддерживать стабильный интерес к работе.

Выходом из ситуации может стать повышение уровня абстракции задач. Допустим, сделал какую-то модель, позже приходит похожая модель, а потом — ещё такая же.

Очевидное развитие ситуации, когда сотрудник на следующем этапе делает уже не просто модель — он собирает пайплайн, который такие однотипные модели будет печь как пирожки.

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

Позже добавляется ещё библиотека, которая умеет делать что-то дополнительное, например, генерировать какие-то синтетические данные под ряд специфических задач.

Такими библиотеками могут пользоваться другие сотрудники.

Когда всё это структурировано и формализовано, код может быть переиспользован другими.

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

Получается, что создаёшь уже не модель, а универсальный инструмент, который оптимизирует работу других участников команды, собирая подобные модели в полуавтоматическом режиме.

В результате возникает эффект синергии — коллеги подключаются к доработкам инструментария: пишут коды, фреймворки, приложения. Благодаря совместной деятельности появляются инструменты для работы на пересечении в разных областях.

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

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

Получается двойная выгода: повышается эффективность командной работы и появляется разнообразие в рутинных задачах.

Третий бонус — развитие. Это же самая сложная вещь — пытаться соединить разные фичи в один универсальный продукт, чтобы получилось практично, красиво и удобно. Для этого надо придумывать новые механизмы интеграции разных элементов, изобретать свои архитектурные решения, создавать новые паттерны. Приходится гуглить, читать, консультироваться с коллегами.

Пример эффекта синергии в команде

Мы разрабатывали для HR классическую модель увольнения: она оценивает вероятность того, как скоро человек уволится. Мы решили добавить в неё графы, чтобы отразить, как происходит взаимодействие в команде. Добавили связи. Потом подумали, что раз работаем с розничной сетью, то почему бы не добавить сюда гео? Время, которое сотрудник затрачивает на дорогу до работы, — существенный фактор.

Когда мы объединили наши знания в единую модель, получили очень хороший результат.

Это один из примеров эффективности глобального объединения команды.

Изначально перед нами стояла задача посчитать по одному человеку. Дальше мы добавили графовые методы и геоаналитику, а потом обернули всё в нейросети.

Особенности найма в команду

Известно, что наиболее эффективный сотрудник — человек с внутренней мотивацией.

Для выявления мотивирующих факторов на последнем этапе собеседования мы с HR проводим стресс-интервью. Подсвечиваем существующие особенности позиции и некоторые негативные аспекты работы, слегка преувеличивая их тяжесть. Говорим, к примеру, соискателю о том, что в банке очень сложно работать: много бюрократии, придётся писать кипы бумажек. Готов ли он к такому? Насколько его интерес к нашим задачам превышает сопутствующие бюрократические сложности? Бывает, что кандидаты отвечают честно: «Нет, ребят, я планировал работать без бюрократии».

Бывает, что встречаем ответы: «Конечно, без проблем! Бумажки писать? Да хоть только этим и буду заниматься». Тут возникает вопрос: а действительно ли такой кандидат нам подходит?

Конечно, позже открываем карты: говорим, что это был стресс-тест, в действительности этим не нужно заниматься вовсе или в таком большом объёме.

Как и кандидат на любую другую позицию, специалист должен обладать определённым набором хард- и софт-скиллов. Если жёсткие компетенции чётко регламентированы позицией соискателя, то с мягкими история сложнее. Выбор основан на многокритериальной оценке

Soft skills. Что проверяем?

Начинаем с исследования предыдущего опыта работы: где, как и чем специалист занимался.

Узнаём, какая была команда и как были выстроены процессы.

Как привык взаимодействовать с командой и заказчиком? По каким критериям он оценивал свою работу? Готов ли он к самостоятельности: кто ему ставил задачи? Сможет ли он сам себе поставить задачи и нести ответственность за их реализацию? Как строился процесс взаимодействия с коллегами? Что он о них говорит и как оценивает? Что ему нравилось/не нравилось на прошлом месте работы? Что он ищет на новом месте? Чего ему не хватало? К чему он стремится? Целый перечень критериев оценки.

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

Тестирование с помощью моделирования ситуаций

А если остались белые пятна, то можно задать специальные вопросы. Представь ситуацию: ты написал письмо заказчику, с которым работаешь, а он уже неделю не отвечает. Что будешь делать?

Обсуждение подобных кейсов позволяет увидеть желание и способности кандидата решать проблемы. Речь идёт не о том, правильно человек поступает или нет. Нам важно понять, есть ли совпадение между ожиданиями от работы в нашей компании с образом мышления/поведения кандидата в подобных ситуациях.

Мы смотрим, занимает ли кандидат достаточно проактивную позицию и демонстрирует ли целеустремлённость, чтобы добиться нужного ему результата.

Тревожный звоночек, когда сотрудник начинает беспощадно ругать свою прошлую команду. Когда все вокруг неправильные, а человек один в белом пальто — это всегда настораживает.

Мы пользуемся рекомендованными HR-методиками. Просим назвать критерии успешного и эффективного руководителя. Как человек оценивает, какие критерии называет для оценки своей позиции — это тоже его характеризует и позволяет понять, насколько есть соответствие между тем, к чему кандидат привык, и процессами в нашей компании.

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

Мы можем рассмотреть кандидата с очень крутыми техническими навыками при невысоких софт-скиллах. Но тогда такой эксперт будет сфокусирован на решении каких-то технических задач, а для решения задач в коммуникативной части профессии ему понадобится напарник.

Такой вариант возможен, но нам удобнее, когда претендент на эту роль имеет более универсальные навыки.

Кейсы из HR-практики. Провалы и удачи при найме специалистов

Однажды к нам устроился умный человек. Он хорошо работал, и всё шло вроде бы нормально, а потом начались закидоны: то нахамит на встрече, то обругает кого-нибудь прямо на ровном месте. На собеседованиях об этом не узнаешь.

Но комьюнити Data Science — это довольно узкое сообщество, здесь все друг друга знают.

И если ты где-то что-то плохо сделал, то рано или поздно об этом станет известно.

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

Однажды мы наняли человека с отличными коммуникативными навыками, с хорошим образованием. И вот встреча: общаемся с заказчиком на «вы»: так принято в их команде.

Заказчики бывают разные: кто-то открыт и готов сразу перейти на «ты», а есть те, у кого заведено обращаться по имени-отчеству и на «вы». И вот в конце встречи наш новый специалист говорит: «Покедули всем!» Пришлось звонить, объяснять, что с заказчиком нужно общаться уважительно, не перебивать и не использовать всякий сленг.

Умение убеждать — одна из ключевых компетенций техлида

Заказчиков у нас много, и все — разные. Мы работаем на 26 самостоятельных подразделений и департаментов. Бывает, что заказчик настаивает на собственном видении решения задачи, как нужно делать. Математически им объясняешь, что так делать нельзя. Иногда по нескольку раз.

Важно уметь убедить, что мы хорошо делаем свою работу, просим посмотреть на результат.

Был случай, когда заказчик пришёл и говорит: «Я хочу именно это!» Проанализировав проблему, ты понимаешь, что его спасёт совсем другое. А «именно это» ему не нужно.

Удалось объяснить и переубедить благодаря сильным переговорным навыкам.

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

Зачастую достижение положительного эффекта предполагает пересмотр устоявшихся процессов.

Как результат — сопротивление заказчика. И здесь важна способность убеждать.

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

Бывает, что заказчик не может сформулировать, чего конкретно он хочет. Говорит: «Хотим чуда! У нас есть 20 терабайт данных». А когда спрашиваем, что за чудо вам надо, — нет ответа.

Начинаем сами искать ответ на этот вопрос:

• Чем занимаетесь?
• Что больше всего требует внимания во время работы?
• На что тратите время?

Допустим, отвечают: тратим время на то, чтобы переписывать от руки служебные записки.

Думаем, как мы можем это упростить и сократить. То есть в ходе разговора мы выясняем, как устроен процесс, где у заказчика перегрузка, как можно добиться результатов и в чём будет максимальный экономический эффект.

Однажды мы потратили полгода на убеждение заказчика, чтобы он поверил, что мы всё делаем правильно. Пришлось делать параллельно две работы: тот вариант, который требовал заказчик, и тот, который считали правильным мы. Показывали разницу на результатах. Через полгода заказчик сдался и сказал: «Да, ребята, вы всё делаете правильно. Я вам доверяю».

По всем правилам нужно было эскалировать наверх, что заказчик неправ. Но поскольку на тот момент мы не до конца разбирались в теме и бизнес-процессах клиента, то решили сначала проверить нашу гипотезу. И оказалось, что она более эффективна.

Тонкий момент заключался в том, что мы не обязаны были делать эту двойную работу, а заказчик не обязан использовать модели, которые создали, чтобы ему помогать.

Отсутствовали KPI, что всё должно быть автоматизировано на 70 %. Если бы мы не рискнули пойти таким путём, то заказчик просто отказался бы от помощи, вообразив, что справится сам. Мы потратили время, но смогли убедить его, что наша математика работает.

Как изучаем бизнес заказчика?

Для качественного выполнения задач техлид глубоко погружается в бизнес клиента.

Одним из действенных методов погружения можно назвать гембы. Проведение гембы предполагает, что Data Scientist на месте изучает процесс работы исполнителя, который предстоит изменить.

Целый день DS-специалист наблюдает за тем, что исполнитель делает, на что тратит время.

Такая практика даёт локальное понимание одного дня работы сотрудника в бизнесе заказчика.

Но чаще для погружения применяем вопросы, вопросы и ещё раз вопросы. И только если понимаем, что где-то не хватает достоверной информации из первых рук и что-то идёт не так, прибегаем к гембам.

Как вариант можем сделать небольшое MVP. Поскольку заказчик далеко не всегда способен подробно рассказать, каким он видит конечный результат, мы можем сами представить конкретные варианты решения проблемы. То есть заказчик понимает, какую проблему нужно решить, но не видит, как. Мы в порядке ограниченного по времени эксперимента демонстрируем ему возможности, которые наглядно показывают, как это может работать.

Если видим способ, который будет работать лучше, чем тот, что есть у заказчика, то предлагаем наш вариант.

MVP помогает клиенту «пощупать» решение и понять, соответствует оно его запросам или нет.

Карта развития сотрудников

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

Сейчас этот документ дорабатываем до финала. По этой карте оцениваем разные компетенции сотрудников. Например, проверка «хардовой» части включает в себя знание SQL, Phyton, Git, статистику и алгоритмы, методы машинного обучения. В общем-то стандартный набор требований.

Проверка soft skills позволяет оценить умения сотрудника мотивировать команду, принимать решения в нештатных ситуациях, делегировать, давать обратную связь и так далее. Всего по этой шкале мы оцениваем около 20 навыков.

Для техлида в DS критически важно уметь выстраивать технологический процесс: объединять людей, инструменты и технологии для достижения целей бизнеса. И если работоспособность программ можно гарантировать, то для поддержания эффективности работы людей нужны особые инструменты и подход. И нам важно, чтобы «человеческий фактор» был на высоте.

Как продвинутые навыки влияют на репутацию компании

Недавно, сделав доклад на тему «Темпоральные графы», мы вошли в топ-5 самых просматриваемых выступлений на ODS. Это сразу же подняло рейтинг банка, ярко отражая уровень экспертизы команды. Внедрив динамические графы в HR, мы получили огромный прирост в качестве моделей. Мы осветили тему, по которой до момента нашего выступления было лишь небольшое количество публикаций. По сути, стали драйвить тему динамических графов.

Подводя итоги

Хороший техлид в DS — это суперуниверсальный специалист с широким пулом обязанностей: управление продуктом и командой, взаимодействие с клиентами и общественностью.

Техлид в DS — это эксперт, который одинаково хорошо может наладить общение и с командой, и с бизнесом, найти баланс их интересов, не терять фокуса на целях и при этом обладает достаточными техническими компетенциями для построения решений. Хотя техлид делегирует даже сложные задачи команде, уровень его профессионализма важен для контроля качества моделей.

При построении модели её качество напрямую зависит от бизнес-метрик. Когда ты улучшаешь модель, тем самым параллельно улучшаешь и бизнес.

Наличие такой взаимосвязи накладывает на техлида в DS особую ответственность: от качества разработки моделей по большому счёту могут зависеть эффективность и будущее компании в целом.