Работаю я тимлидом в аутсорсе/аутстафе уже добрый десяток лет. И были у меня в основном команды, которые я сам собирал.

Текущая команда - 8 человек, все из стран СНГ. Плюс архитектор и продакт из США. Внутреннее общение на русском, с заказчиком на английском; вся команда примерно в московском часовом поясе, плюс-минус 3 часа, заказчик в Нью-Йорке и Лос-Анджелесе. Привычная схема работы: утром внутренний звонок, обсуждаем весело текущие дела (я надеюсь), планируем работу на день, вечером встречаемся уже вместе с заказчиком - обсуждаем прогресс, задаем вопросы, планируем.

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

И тут заказчик принимает решение, что рискованно доверять всю разработку одной компании, нужно добавить своих собственных разработчиков (назовём их “инхаус-разработчиками”). Я, конечно, понимаю ход мыслей заказчика, но добавление 3-х разработчиков к 8 уже имеющимся и так-то непростая задача. А тут эти трое из другого часового пояса. И англоговорящие конечно. И менталитет другой.

Хочешь - не хочешь, а проект надо вести дальше.

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

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

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

За последние несколько лет я значительно изменил свой подход к проведению технических собеседований. Если когда-то (лет 7 назад) я мог весело и задорно интервьюировать джавистов два часа, то на текущей позиции у меня нет столько времени на каждого кандидата. При наличии 4 открытых позиций и с результативностью 10% (примерно 10% кандидатов проходят собеседование и готовы принять оффер), получается, что мне нужно провести порядка 40 собеседований. Если тратить хотя бы по часу на собеседование, то это дополнительные 40 рабочих часов, которые где-то надо найти. Плюс накинуть 10 минут на переключение между задачами, получается ещё 400 минут (~6.5 часов).

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

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

Если с тестированием привычных программных продуктов более-менее ясно, то вот с BigData возникает множество вопросов. Если у вас Java - у вас есть как минимум JUnit, а абсолютное большинство фреймворков заботятся о простоте тестирования. Например Spring посвящает этому очень много документации. Тестирование фронтенда тоже хорошо проработано: от Selenium до JestJs. Тестировать блокчейн и смарт-контракты одно удовольствие (хотя бы на Ethereum сети благодаря Truffle Suite)

Что делать, если вы используете Databricks? Обычные библиотеки для тестирования туда плохо заходят, и даже несколько официальных руководств по тестированию не отвечают на все вопросы. Ответ, который нашла наша команда, - Nutter Framework.

На текущем проекте я столкнулся с необходимостью внедрения единого процесса разработки и деплоймента для нескольких команд дата-инженеров. “Несколько команд” - это 5 команд дата-инженеров из разных стран (Америка, Индия, СНГ) плюс команда, которая отвечает за DataOps, назовём их админами. Разные часовые пояса, немного разная культура работы, немного разный уровень дисциплины и менеджмента. Мысль о том, что нужно менять процессы работы сразу в 5 командах для 40+ человек, приводила в небольшой трепет. Как разрабатывать и внедрять SDLC (software development lifecycle) для команд разработчиков я знал, но тут и люди другие, и специфика проекта другая. В общем, я ждал сложностей. И они были.

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

Прошло почти два года со старта проекта, и я готов подвести некоторые итоги и поделиться опытом.

Начну с темы найма. Найма питонистов всех мастей. 

Завораживающее предисловие, не правда ли?

Краткий вывод

Зачем колоться?

Почему Apache Lenya