Почему «бигдатой» контролировать и иногда увольнять сотрудников — это нормально и логично

Всем привет, меня зовут Лаптев Алексей, я разработчик сервисов utmstat и apimonster. По мотивам статьи про увольнения в Xsolla хочу объяснить кухню IT-компаний и рассказать, почему контролировать «бигдатой» вполне логично.

Проблема

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

Автор поста не прав и злодей.

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

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

Попробую объяснить.

Дисклеймер

Цифры даны условные, разумеется в разных конторах они разные, но суть везде одна.

Контроль нужен

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

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

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

KPI сотрудников в IT-компаниях

Программист

Что делает

Пилит задачи из джиры.

Результат работы

Решенная задача, прошедшая контроль и залитая в GIT.

KPI

Количество сделанных задач в месяц.
Средний срок на задачу — 1-3 дня.

Если задача большая, то ее надо дробить на задачи по 1-3 дня.

В итоге получается что в среднем программист может сделать около 10 задач в месяц.

Соответственно относительно этой цифры можно оценивать всех программистов:

  1. Если задач +/- 10 в месяц — все ок
  2. Если больше 10 — программист молодец
  3. Если меньше 10 — или ленится или какая-то. проблема, надо разбираться.

Тестировщик

Что делает

Проверяет задачи за программистами.

Результат работы

Количество задач со статусом «Протестировано».

KPI

Количество задач со статусом «Протестировано» в месяц.

Те же 10 штук в месяц.

Менеджер (продуктовый и аналоги)

Что делает

Решает задачи бизнеса. По сути теже задачи в тасктрекере.

Результат работы

Фича вылитая на прод и задача со статусом «На проде».

KPI

Количество задач со статусом «На проде» в месяц.

Пусть 10 штук в меc.

Продажник

Что делает

Общается с входящими лидами. По сути те же задачи в CRM в виде сделок и лидов.

Результат работы

Явный ответ от лида — нужен продукт или нет, желательно с продажей или хотя бы с фидбеком что не так.

KPI

Количество обработанных лидов в месяц. От 30 до 100.

Бариста

Что делает

Кофе.

Результат работы

Кофе.

KPI

Тут уже сложнее. Задач нет, наверное отсутствие жалоб на баристу от клиентов.

Как контролирует страшная бигдата?

Бигдата — это громко сказано, можно еще ИИ добавить для солидности.

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

Разумеется в разных конторах свои цифры, но они есть и суть везде примерно одинакова.

Поэтому если заморочиться, то можно начать считать задачи в месяц и на дистанции в несколько месяцев уже оценивать кто как работает:

  1. Если отклонение в меньшую сторону — надо разбираться в причинах и если причина — низкая продуктивность, то увольнять.
  2. Если отклонение в большую сторону — повышать, премировать.

Вроде все логично и вся бигдата — это лишь простая считалочка, которой начальник больше не занимается в голове.

Бигдата не увольняет за опоздание на 5 минут или затянутую задачу

Важно понимать, что всю аналитику надо делать на длинной дистанции, а не за день.

Все живые люди и каждый день работать одинаково не получиться:

  1. Сложная задача, пришлось подумать
  2. Не прет сегодня
  3. Клиент отнял много времени
  4. Личные дела
  5. Болел

Но на дистанции в несколько месяцев все сроки выравниваются и локальные отклонения значения не имеют. Можно делать объективные выводы.

Итого

Вовлеченность бигдатой действительно можно мерить, когда в основе процессов лежат CRM и такс-трекеры, а эти инструменты есть в любой IT-компании - это основа.

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

Обычно меряют вовлеченность на глаз — "ну вроде работал".
Но когда сотрудников сотни - на глаз невозможно и поэтому подключается считалочка в виде "бигдаты".

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

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

0
37 комментариев
Написать комментарий...
Максим Трусов

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

Ответить
Развернуть ветку
Andrey Kim

Нет. Херовый такой продажник, если у него считаются в первую очередь только отработанные лиды. У продажника ВСЕГДА KPI в выигранных сделках/заключенных договорах с получением денег.

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

Продажник. Результат работы

Явный ответ от лида — нужен продукт или нет, желательно с продажей или хотя бы с фидбеком что не так.
KPI

Количество обработанных лидов в месяц. От 30 до 100.

Ответить
Развернуть ветку
Alexey Laptev
Автор

Вроде про чат нигде не написано.

Вы пробовали продавать?

Отрицательный результат тоже результат и потраченное время. Фидбек поможет продать в будущем.

Ответить
Развернуть ветку
Andrey Kim

Да, я руковожу группой продаж Saas-платформы. Про чат это я так, обобщенно, исходя из поста про Xsoll.

Отрицательный результат это просто фидбэк, но это точно не KPI продажника. Алексей, вас бы точно Агапитов уволил)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Роман Нестер

Ни один из навзанных примеров не относится к категории "бигдата" хоть ты тресни 

Ответить
Развернуть ветку
Alexey Laptev
Автор

Сейчас бигдатой и ИИ называют любую автоматизацию. Так солидней.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Alexey Laptev
Автор

Как данное название будет продаваться - так сразу.

Ответить
Развернуть ветку
Рулон Обоев

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

Ответить
Развернуть ветку
Alexey Laptev
Автор

Я вроде ничего не подменяю, а наоборот объяснил что ради продаж и солидности ИИ называют любую автоматизацию.

А в статье объясняется что там простейшая арифметика, но с солидным названием .

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

Ответить
Развернуть ветку
Vanchet Ksenofontov

всё правильно

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Alexey Laptev
Автор

Разрабочик не ставит себе задачи

Ответить
Развернуть ветку
badResistor

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

менеджер разбил задачу на атомарную - скопировать файл.
руководство одобрило
галочки выполнено
всё $банулось.
KPI stonks!

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Alexey Laptev
Автор

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

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

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

Все это работает там, где процессы более менее отлажены.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Alexey Laptev
Автор

Ну разумеется везде все плохо )

Ответить
Развернуть ветку
badResistor

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

Ответить
Развернуть ветку
Alexey Laptev
Автор

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

Ответить
Развернуть ветку
badResistor

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

Ответить
Развернуть ветку
Alexey Laptev
Автор

Ну kpi тоже надо уметь внедрять.

В любом случае хоть какая-то оценка лучше чем никакой.

Ответить
Развернуть ветку
badResistor
В любом случае хоть какая-то оценка лучше чем никакой.

нет

Ответить
Развернуть ветку
Илья Миртов

У статьи в названии ошибка. Должно быть "как задешево набрать просмотров на скандальной теме? Изображайте из себя адвоката дьявола"

Ответить
Развернуть ветку
Alexey Laptev
Автор

Ну и это тоже.

Но смысл статьи от этого не меняется, просто без «просмотров» нет смысла что либо объяснять.

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

Ответить
Развернуть ветку
Ольга Павленко

Уже все про это кричат )) 

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

На личной практике я знаю, что обновлтяь кровь - это эффективная мера, если только обновление сделано правильно. Иначе, сокращение штата только усугубит ситуацию.
Децемацию практиковали со времен римских легионов ))) помогало! ))

Ответить
Развернуть ветку
Denis Vasilyev

рекламирую простой скрипт для визуализации рабочего чата в телеграм. Если работа сопровождается активным чатингом, то на графике будет сразу видно, когда был ворк, а когда простой: https://vc.ru/u/22413-denis-vasilyev/271998-podschet-i-vizualizaciya-messedzhey-v-telegram-chate

Ответить
Развернуть ветку
Alexey Laptev
Автор

Спасибо, но работа чатингом не  меряется

Ответить
Развернуть ветку
Denis Vasilyev

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

Ответить
Развернуть ветку
Alexey Laptev
Автор

От программиста нужна задача в срок, а что он там делает - не важно.

Но вы несомненно молодец, что смогли сделать аналитику чатов.

Ответить
Развернуть ветку
Леонид Ялунин

Аналитик, нормально отработал - чата нет. Зачем пояснять если задача поставлена нормально с первого раза.
Старые тесты проходят, новые по задаче написаны. Сборка прошла. Тимлиду от системы сборки пришло сообщение. Он одобрил изменения в коде. Тестировщика от системы сборки пришло сообщение. Он сделал ручное тестирование или дописал тесты - одобрил. Менеджер от системы сборки получил сообщение, что функционал реализован. Посмотрел закрыл задачу. При правильном  организации трепатни в чатиках между людьми практически нет. Пришло сообщение от системы сборки или - сделал свою часть работы. Если вовремя не сделал придет также в автоматическом режиме сообщение твоему начу.
 Другой вопрос, что работа в том числе совещания менеджмента и топ менеджмента должны оставлять цифровой след. Если совещание было а протокола совещание где есть тестовая расшифровка болтавни голосом в виде текста нет. И нет решения - что кому нужно сделать по результатам совещания, менеджмент нужно увольнять.

Ответить
Развернуть ветку
Denis Vasilyev

могу только поздравить с "правильной организацией" )

Ответить
Развернуть ветку
Леонид Ялунин

Набор общих слов по хайпоой теме. Хочешь хорошо - хорошо делай, а плохо не делай! Всю статью можно заменить этой фразой. Нет разбора, а какие плюсы и минусы разных критериев. Как бороться с тем, что люди начинают работать чтобы критерии были побольше. А не чтобы работа делалась. Кто ответственнее за выбор критериев. Какие 6аиболее частые ошибки и как их избежать. Как бороться с завышением сроков на задачу программистом и занижение их же менеджментом. Почему не активный в чатиках, но вовремя и в срок закрывающий таски (поскольку знает и предметную область и кодовую базу очень хорошо на данном проекте)программист это плохо, хотя он будет ещё года два давать стабильное качество для этого Работодателя. А его коллега постоянно работающий с завышением оценки сроков сложности и числа выполненых задач месяца три получив премии выгорит и уйдет - это хорошо. Показатели то у менеджмента от такого прогарающего трастут. В отличии от его стабильного коллеги, который не сделает своему начальнику бонусы. А проблемы HR и затраты времени на поиск нового(трёхмесячного погорельца) и его онбординг не считают 

Ответить
Развернуть ветку
Alexey Laptev
Автор

Уверен, вы лучше разбираетесь в теме, но в статье буквально личный опыт и золотая середина по kpi - что бы и эффективность менять и ерундой не заниматься в виде подсчета сообщений в чате.

Ответить
Развернуть ветку
Леонид Ялунин

Как и затраты времени на ведение внутренней Вики программистами. Им же жизненно важно ее не вести, обеспечивая свою не заменимость и мнимую экспертеность.да и главное кто в системе KPI оценивает читаемость и реальную полезность документации в этой Вики, и сам факт добавления в нее информации. Главное же, чтобы наполнялись рабочим чатики. Поди потом разберись новичку в километрах этих чатиков. Вместо нормальной Вики. Задал вопрос в чатике ответ на которой есть во внутренней Вики - тебе должно прилететь по голове. Ответил на вопрос коллеги в чатике, но не добавил эту информацию в вики- тебе должно прилететь по голове. За голосовое общение в рабочее время без текстовой расшифровки и резюме, а какие решения приняты в ходе этого общения - прилететь должно всем общающимся. Переписка, а тем более болтавни голосом  которая не оставила текстовых артефактов, в виде кода в кодовой базе, новой версии ТЗ или Регламента. Новой версии или новых статей во внутренней вики должны наказываться.

Ответить
Развернуть ветку
Леонид Ялунин

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

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

Ответить
Развернуть ветку
34 комментария
Раскрывать всегда