Как настроить работу команды в режиме аврала

Петр Левин

Директор по разработке ПО, компании IT_One.

Вызовы меняющегося вокруг мира сократили время выхода продуктов на рынок до немыслимых пределов. Когда весь бизнес переходит на «цифру» одновременно, состояние аврала становится новой нормальностью для команд разработки. Государству и бизнесу сегодня нужны IT-решения с пометкой срочности «вчера». Как построить эффективную работу команды в таком интенсивном режиме? Рассказывает Пётр Левин, директор по разработке ПО, компании IT_One.

Цифровой взрыв, который повлёк за собой 2020-й год, только усилил те процессы, которые уже давно назревали в бизнесе и государственном управлении – digital-трансформацию. Однако хотя весь мир двигался по пути внедрения IT во все сферы, никто не ожидал, что финальный переход будет таким быстрым и стремительным.

Команды разработчиков оказались поставлены в условия, когда реакция на потребности заказчиков должна быть молниеносной. IT_One, например, работает в крупных проектах, где заказчиками выступают государственные компании. Могу сказать, что скорость запуска сервисов в сфере e-government просто стремительная. Сегодня IT — это гонка. Не всегда за прибыль, но часто даже за само право оставаться на рынке и в контексте современной цифровой экономики.

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

Дозируем стресс

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

Почему именно в небольшой дозе? Пребывание в полном неведении относительно перспектив проекта создаёт ситуацию, когда, с одной стороны, каждый «пилит» свой участок, но не видит картины в целом и общих задач. С другой стороны, если сгружать на команду весь стресс целиком, на корабле может возникнуть паника. А это не только не продуктивно, но и чревато полной демотивацией.

Отсюда следует ещё одно правило. Менеджеру важно уметь работать со своим стрессом и своими эмоциями, не перекладывать их на сотрудников. Есть различные методики борьбы со стрессом, от медитаций до спорта, и каждый может найти свой способ. Но психологическая разгрузка менеджеров должна стать золотым стандартом. Лично мне очень помогает разделение личной жизни и профессиональной, как бы банально это ни звучало. Чем больше у менеджера ценностей вне работы, тем, как правило, он адекватнее реагирует на стрессы в рамках проектов.

Делим ответственность

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

В IT_One, например, мы используем работу с сотрудниками в разных форматах. От групповых митапов, где менеджеры проектов транслируют ближайшие цели и помогают всем держать общие ориентиры, до персональных one-to-one встреч с каждым сотрудником, в этом нас поддерживает служба HR. Оставаясь в контакте со всеми вместе и каждым в отдельности, мы, во-первых, лучше знаем, на кого можем опереться и кому и какие задачи делегировать. Во-вторых, обеспечиваем качественное делегирование и разделение ответственности.

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

Это хорошая задача из области управления. Как сделать так, чтобы команда доверяла своему лидеру, поддерживала его решения, а не саботировала их? Если команда видит, что лидер, действительно, предпринимает усилия, чтобы создать максимально комфортные условия для работы каждого в рамках текущих бизнес-задач – за ним идут и в него верят. Даже в те дни, когда горят дедлайны, и приходится много работать сверхурочно.

Управляем ситуацией

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

Качественную обратную связь важно давать и заказчику. Почему мы не успеваем или по каким причинам задерживаются сроки проекта? Связано ли это с тем, что все сотрудники слишком много времени тратят не на проектные задачи или все-таки есть объективные сложности. Если да – то какие. Не стоит оставаться для заказчика черным ящиком и подпитывать его фантазии. Если он будет понимать нюансы процессов разработки на нашей стороне, то это поможет ему перейти при обсуждении проекта с эмоционального уровня на конструктивный.

Бонусы аврала

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

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

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