В Xsolla никто не знал метрики оценки, предупреждений не было, вместо пяти окладов дали три: рассказ бывшего сотрудника Статьи редакции

Пересказ интервью DTF с человеком, уволенным после оценки от «бигдаты».

  • В Xsolla не было прямых штрафов за невыполнение задач, перенос срока сдачи обсуждался и не воспринимался как трагедия. HR-специалисты следили за временем выполнения, но о важности этой метрики не сообщалось.
  • Собеседник DTF считал, что сотрудников оценивали по закрытым задачам и мнению менеджера. До письма об увольнении никто не предупреждал людей о том, что они не справляются.
  • У сотрудников не было доступа к своим рейтингам, отчёты об эффективности были у главы компании и нескольких топ-менеджеров. Прозрачную систему рейтинга хотели сделать «в начале года», но отложили, принцип её построения не раскрыли.
  • Про основателя Александра Агапитова в компании есть поговорка «Шурик просыпается раз в полгода и жестит». Он открыт, но иногда показательно увольняет людей со словами «тебе не место в Xsolla». Временами проводит стримы с ответами на вопросы сотрудников, однажды некоторым участникам встречи начислили за это денежные бонусы.
  • После письма про «бигдату» часть сотрудников почуствовала превосходство над уволенными и стала демонстрировать свою лояльность. Тем, кто задавал вопросы о рейтинге, рекомендовали показывать вовлечённость — «писать топ-менеджерам, ходить на таунхоллы и читать конфлюенс».
  • Агапитов обещал выплатить уволенным четыре-шесть окладов, на деле им предложили три оклада. Расхождение он объяснил тем, что нужно было защититься перед СМИ.

Полное интервью можно прочитать на DTF:

С чего всё началось

Компания Xsolla разрабатывает платёжные системы для разработчиков и издателей игр. В начале августа 2021 года по соцсетям разошлось письмо её основателя и главы Александра Агапитова: в нём он объявил об увольнении части сотрудников, так как «бигдата» показала их низкую вовлечённость в работу.

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

0
194 комментария
Написать комментарий...
Mr. Z

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

Ответить
Развернуть ветку
Евгений Калашников

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

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

Ответить
Развернуть ветку
Mr. Z

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

Ответить
Развернуть ветку
Владимир Гулевский

А менеджмент за сроки не отвечает?
Не кажется ли вам, что с сотрудниками как бы нужно разговаривать.
Давать обратную связь - чтобы у сотрудника было понимание, всё ли ок, нормально ли он справляется. 

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

Ну либо готовьтесь к постоянно текучке и ещё больших проёбах сроков, проектов и т.д.

Процессы сами собой не построятся, чтобы там шурик себе не мечтал.

Ответить
Развернуть ветку
Mr. Z

Во всем согласен.

Ответить
Развернуть ветку
Евгений Калашников

Я это и с первого раза понял, поэтому и написал комментарий о том, что ваше мнение ценно примерно как мнение интернет-экспертов о вакцинации и критериях оценки художественной гимнастики на Олимпиаде.

Ответить
Развернуть ветку
Mr. Z

Аргументы закончились, переходим к оскорблениям )

Ответить
Развернуть ветку
Евгений Калашников

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

Ответить
Развернуть ветку
Mr. Z

Ну я правда не знаю, что кроме этого еще добавить:
"А я из интервью разработчика вижу проблему в другом.
В том, что в психологии разработчиков сложилось мнение, что срок - это не обязаловка, а просто ориентир.
И скрам-херам тут не причем вообще.
Вот и все."
Взлетите над скрам и посмотрите на задачу глазами бизнес-заказчика, вот и все.

Ответить
Развернуть ветку
Евгений Калашников

А вы в армии служили? тоже там вставали, когда хотели и одевались, как нравилось?)))

ОК, для ликбеза. Скрам - это минимально достаточный фреймворк. Это означает, что он дает тот минимум, который трогать нельзя, а дальше строй, что хочешь.

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

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

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

Весь смысл скрама - в коллективной ответственности за инкремент, иначе это уже не скрам.

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

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

Ответить
Развернуть ветку
Mr. Z

Евгений,
Спасибо за пояснение, искренне и без иронии.
Я совершенно согласен, что проблема может быть не любом этапе и винить конкретного разработчика в срыве по умолчанию  - не во скрамовски. Да и не по какому, это в принципе ненормально. 
Но и Вы согласитесь, что поработав какое-то время с группой разработчиков, менеджер понимает его специфику. Кто-то делает быстро и сразу, кто-то тянет до последнего, кто-то задаст миллион вопросов, а кто-то сделает как понял.
И для бизнеса важнее именно эта оценка то, в итоге.
И если есть какой-то разработчик, который по причине "не успел, не понял, мало данных" регулярно переносит сроки (при том, что остальные работают с меньшим количеством переносов), а потом в таймшит пишет, что делал задачу за час - вопросы будут уже к нему конкретно.
Как я писал в соседней ветке, здесь проблема миддл-менеджмента, который просто не давали людям обратной связи до последнего.

Ответить
Развернуть ветку
Евгений Калашников

Так это их работа - давать обратную связь. не давали=не работали. Следовательно я нашел, кого нужно увольнять)))

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

Пользу учета времени в скраме я сам не вижу, если честно. Сам бы забил на его месте.

Ответить
Развернуть ветку
Mr. Z

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

Ответить
Развернуть ветку
Евгений Калашников

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

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