iTechArt logo

Как понять причины низкой производительности и устранить их

Company News

Что делать IT-компании, если сотрудник, на которого возлагали большие надежды, не оправдывает их? Как самому сотруднику со стремительно снижающимся КПД вернуться в прежнюю рабочую форму?

Чтобы найти правильный выход, нужно определить причины отсутствия результата. На недавней конференции Career Today, проходившей в Минске, Group Manager iTechArt Алена Волчек разобрала причины низкой производительности. Приводим в статье основные тезисы выступления.

Наш собеседник
Alena Volchek photo.jpg

Алена Волчек

Group Manager iTechArt

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

Когда работаешь, не щадя себя, со временем работа перестаёт доставлять удовольствие. Задачи, которые раньше захватывали, уже не так интересны, как в самом начале. Хочется на что-то переключиться, а проект долгосрочный. Так мы приходим к понятию эмоционального выгорания. Оно присутствует для всех сфер деятельности, IT не исключение. Это становится понятно, когда ваш незаменимый разработчик вдруг показывает плохой перформанс, становится неактивным и безразличным. Но это проблема не только разработчиков. PM тоже в зоне риска: сначала вы решаете много вопросов, организуете множество мероприятий/собеседований, а потом в какой-то момент вы понимаете, что вы не хотите.

Софт скиллы – необходимая база

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

Must have в арсенале ваших софт скиллов:

  • Умение общаться. Казалось бы, навык, который есть у всех, но это не так. Однажды на одном мастер-классе услышала интересную мысль: «Заказчик всегда знает, чего он хочет, но не всегда может выразить свои желания словами». Это очень важная фраза: когда мы работаем на стороне разработчиков, нам кажется, что всё просто. Мы говорим на своём «птичьем языке», но на самом деле нас далеко не все понимают. Если заказчик «нетехнический», а с вашей стороны нет нужного посыла, коммуникации не получится.
  • Способность работать в команде и взаимодействие с другими членами команды. Сейчас очень модно работать по Scrum, Kanban, Agile, хотя на самом деле все работают по какому-то страшному миксу из всех методологий вкупе с изменениями от заказчика, которые идут каким-то своим лайном и от которых никуда не деться.
  • Навыки активного слушания. Помните о том, что «слушать» и «слышать» – разные вещи. Кстати навык активного слушания незаменим на собеседованиях: очень важно отвечать на вопрос, который вам задали. В 90% случаев, когда я задаю один вопрос, получаю ответ совершенно на другой.
  • Способность адаптироваться к текущей ситуации. Прямо завтра вас на проекте не поменяют, даже если вы сегодня открыто скажете: «Мне крайне некомфортно здесь». Редкий проект можно поменять ASAP, чаще всего нужен месяц, иногда два, чтобы найти и подготовить разработчику замену.
  • Лидерство и умение брать на себя ответственность. Больше касается лидов, PM, которые должны брать на себя ответственность за те решения, которые они принимают на проекте: выбор технологии, формирование команды, коммуникацию с заказчиком, внесение и контроль change requests.
  • Эффективный тайм-менеджмент. Знаете ли вы, сколько своего времени тратите впустую? Мне понадобилось 3 дня, чтобы понять, что даже по работе я трачу колоссальное время на коммуникации, которых можно было избежать. В один из дней трекинга обнаружила, что у меня было 7 часов митингов. 7 часов чистого рабочего времени! Если и вы попробуете выписать, на что тратите время, а потом проанализируете, что можно сократить/упразднить, не пожалеете.
  • Способность аналитически мыслить. Это важно не только для программистов, но и для PM, чтобы понимать требования и объяснять, если требование со стороны заказчика нелогично.
  • Креативность и позитив
  • Готовность к изменениям и постоянному самообучению. К изменениям надо нормально относиться. План – это не клятва, а прогноз. Когда вы даете оценку по времени, вы говорите: «Мне надо 6 часов на эту задачу.» Но если вы не вкладываетесь или появились дополнительные требования от заказчика, значит нужно спокойно сообщить об этих изменениях руководителю проекта, а тот, в свою очередь, должен довести это до заказчика. Я всегда веду реестр change request на своих проектах и очень рекомендую это делать другим. Заказчик, работая на проекте по схеме «time&material», всё равно относится к нему как к fix, всё также ждёт релиза в определенные даты и скоупа выполненных задач согласно road map. Но если идут изменения, инициированные заказчиком, вы должны сказать: «Мы можем внедрить эту фичу, но вот эта перенесется на следующий спринт, а итоговый срок релиза увеличится на 10 дней».
  • Дипломатичность и самоконтроль. Не ругайтесь с заказчиком, ведите себя корректно, даже если «бомбит». Внутри команды вы можете говорить что угодно, но на заказчика мы это не переносим.

«Подумал-сказал-понял» и немного о других коммуникационных барьерах

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

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

«Нетехнические» заказчики – крайне сложные. Важно быть терпеливым и выслушать, что же имеет в виду заказчик. У меня есть пример, когда человек к своему приложению прикручивал систему оплаты. Использовали Stripe. Если кто-то работал с ним, то знает, что в нём после зачисления денег на счёт, вывести их можно не ранее, чем через 7 дней. Это ограничение не моё и не заказчика – это ограничение конкретной платёжной системы. Мы предупредили заказчика об ограничениях, на что получили ответ: «Мы смотрели с девелопером, всё отлично». Оказывается, девелопер на стороне заказчика тестировал транзакции под девелоперским доступом. Как только мы перешли на пользовательский аккаунт, ограничения вернулись. Как итог заказчик просит сделать так, чтобы ограничений не было.

Принимаем во внимание эмоции и отслеживаем «звоночки» выгорания

Очень важно понимать эмоции человека и обращать внимание на состояние, в котором он к вам пришёл. Иногда на ревью можно услышать, как человек говорит: «Я так счастлив на этом проекте!», а ты по интонации голоса и его виду понимаешь, что это не так.

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

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

Как только «словили» такие сигналы, стоит задуматься об отпуске. Если нет возможности взять долгосрочный перерыв, возьмите пару отгулов, так, чтобы они были перед выходными. Отключите все гаджеты, всё, что связано с работой. Если нужно, скажите, что вы в глухой деревне, где не ловит сигнал. 3 дней хватит, чтобы перезагрузиться и выдохнуть от 2 недель до месяца. Но всё равно потом нужен будет долгосрочный отпуск с полным переключением.

Что служит причиной выгорания:

  • Чересчур интенсивный ритм работы («работа на износ»)
  • Физическая и эмоциональная усталость
  • Дефицит бонусов (не только материальных, но и психологических – например, банального «спасибо» за работу)
  • Отсутствие чётких требований и критериев оценки производительности
  • Отсутствие полномочий для влияния на принимаемые решения 
  • Скучный и монотонных характер рабочих задач
  • Стагнация и «туманность» перспектив на текущем месте
  • Постоянная работа в выходные дни, отсутствие отпуска
  • Офисная рутина полностью вытесняет другие сферы жизни
  • Конфликты между личными «хочу» и рабочими «должен»

Как справиться с выгоранием, если оно уже случилось?

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

О важности ресурсного планирования и тимбилдингов

Почему важно работать с командой и заказчиком? К сожалению, заказчики не всегда понимают ситуацию. Часто они думаю, что проект можно сдать в 2 раза быстрее, если увеличить штат в 2 раза. Так не работает. Всё время объясняю это на примере того, что 9 женщин не смогут за 1 месяц родить одного ребенка. Если PM не будет этого объяснять, заказчик будет растить команду и выжигать её, потеряем всех. Ресурсное планирование должно быть правильным. Если вы собираете команду, зная, что вам нужно 5 человек, то команда из 2 человек, а впоследствии – ещё 5 – не рабочий вариант. Команда под проект должны формироваться сразу.

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

Основные причины низкой производительности, помимо неразвитых софт скиллов и выгорания:

  1. Стандартизация бизнес-процессов компании (регламенты, инструкции). Да, совсем без инструкций, наверное, не обойтись. Но регламенты и инструкции в гибких методологиях носят рекомендательный характер. И как вы их имплементируете в свою команду, это лично ваше дело. Надо подстраивать регламенты под вашу команду. Например, в Scrum есть daily-митинги, которые длятся не более 15 минут. Представьте, что у вас команда в 20 человек. Уложитесь ли вы в отведенный тайминг? Едва ли.
  2. Ошибки в подборе персонала. Если у человека хороший английский и он хочет учиться, у него есть все шансы поменять работу и найти себя в IT. Не хочет развиваться – даже с классным английским он не найдёт себя нигде. Ему будет скучно на любом проекте.
  3. Нехватка обучения и развития персонала. Никогда не ограничиваемся только конкретной технологией, даём сотрудникам возможность выбора. Хотят стать Full-stack разработчиками? Да пожалуйста!
  4. Неправильная организация рабочего пространства. Когда у вас под рукой тарелка с чипсами, чуть дальше газировка, рядом ноут, чашка кофе, ещё что-то, то вы постоянно отвлекаетесь. Есть специально организованные зоны для отдыха и для приёма пищи.
  5. Низкая мотивация сотрудников. Если сотрудник понимает, что он работает в одной из самых крутых групп департамента – мотивация уже повышается. Есть мероприятия, которые сплачивают коллектив – ещё выше мотивация. Есть психологические и материальные бонусы – ещё лучше.