Как организовать прохождение испытательного срока BI-аналитиками

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

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

Верификация касалась полученных значений, а не стандартно предусмотренных для должности: при найме считали допустимым иметь 11 из 14 компетенций на целевом уровне, а по трём оставшимся – на одну ступень ниже. Прошедших срок сотрудников подтягивали за девять месяцев.

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

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

«Т.1.Проектирование хранилищ» проверялась директивой:

• 0 – провести аудит интегральных слоёв для конкретного источника
• 1 – устранить отклонения от выбранного архитектурного подхода в БД витрин
• 2 – протестировать влияние партицирования таблиц на производительность операций.

«Т.2.Администрирование баз данных» подтверждалась поручением:

• 0 – провести аудит имён для входа, SQL-заданий и триггеров
• 1 – создать новые или оптимизировать текущие планы обслуживания
• 2 – настроить в dev-контуре репликацию БД через группы доступности Always On.

«Т.3.Организация ETL-процессов» проверялась директивой:

• 0 – создать хранимую процедуру для отчёта или дэшборда
• 1 – разработать DAG’и Airflow под различные типы интеграций
• 2 – провести аудит механизмов захвата изменений данных в DWH.

«Т.4.Использование систем контроля версий» подтверждалась поручением:

• 0 – загрузить скрипт в репозиторий
• 1 – провести ревизию кода и соединить ветки.

«Т.5.Разворачивание решений» проверялась директивой:

• 0 – очистить сервер от старых docker-образов
• 1 – поднять Airflow на выделенной виртуальной машине
• 2 – настроить новый или оптимизировать текущий CI/CD пайплайн.

«Т.6.Визуализация показателей» подтверждалась поручением:

• 0 – спроектировать простой Power BI-дэшборд или SSRS-отчёт
• 1 – создать BI-продукт с нестандартными элементами и комплексными расчётами
• 2 – разработать новый OLAP-куб либо оптимизировать модель или процессинг готового.

«К.1.Взаимодействие с конечным заказчиком» проверялась директивой:

• -1 – ответить на запрос из службы одного окна́
• 0 – обнаружить самостоятельно баг или нестандартный процесс в данных
• 1 – внедрить справку в визуализацию и дополнить корпоративный глоссарий.

«К.2.Взаимодействие с методологом-верификатором» подтверждалась поручением:

• -1 – сформулировать по итогам встречи точные вопросы к «бадди»
• 0 – выполнить автономно задачу по ТЗ без замечаний, ведущих к переработке
• 1 – выяснить конечную потребность в данных и провести через серию BI-продуктов
• 2 – предложить устранить найденные расхождения в однородных элементах отчётности.

«К.3.Взаимодействие с экспертом по системе-источнику» проверялась директивой:

• -1 – доработать загрузку в существующую стейджинговую БД
• 0 – подключить новый источник с доступом к СУБД или готовым API
• 1 – составить ТЗ на выгрузку из исходной системы или на изменение отражения процесса.

«К.4.Взаимодействие с коллегами» подтверждалась поручением:

• -1 – задать предметные вопросы «бадди» по задаче
• 0 – разработать BI-продукт без обращения к членам команды
• 1 – улучшить код курируемого, объяснить исправления и проверить, как усвоил.

«У.1.Планирование» проверяли директивой:

• -1 – оценить адекватно объём работ на день
• 0 – спрогнозировать корректно недельную пропускную способность
• 1 – разбить комплексную задачу на несколько спринтов и выдержать срок
• 2 – выставить взаимосвязанные и амбициозно-достижимые КПЭ команде на квартал.

«У.2.Регламентирование» подтверждали поручением:

• 0 – обновить статью, столкнувшись с неработающим решением
• 1 – создать инструкцию под неописанный инструмент или аспект
• 2 – задокументировать или актуализировать выделенный этап процесса
• 3 – разработать регламент в непокрытой базой знаний зоне ответственности.

«У.3.Руководство» проверяли директивой:

• 0 – провести брифинг заменяющего при перераспределении работ
• 1 – реализовать комплексную задачу, делегировав части младшему коллеге
• 2 – раздать указания и проконтролировать исполнение на статусных встречах.

«У.4.Обеспечение» подтверждали поручением:

• -1 – разработать BI-продукт только по функциональным требованиям
• 0 – оценить долю решения в объёме хранилища и в длительности окна́ прогрузок
• 1 – просчитать тренд использования ресурсов и сформировать заявку на увеличение
• 2 – предложить оптимизацию циклов обновления отчётности и обсудить с заказчиками.

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

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

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