Как сбежать из рабочего ада

Автор: Константин Франгуриди

Фото: Josh Calabrese / Unsplash

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

Что такое рабочий ад?

Все с детства помнят басню Ивана Крылова «Лебедь, рак и щука». Отличная иллюстрация того, как отсутствие общего понимания задачи, эгоизм исполнителей и неясность цели приводят к провалу всего проекта.

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

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

Еще один признак — отсутствие цели. Человек не понимает, к чему он стремится и чем должен закончиться проект. Так складывается ситуация, когда у задач нет критериев готовности. Работник оказывается в ситуации бесконечной ежедневной рутины.

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

К чему приводит постоянный ад в работе?

Ад = выгорание. Итог неструктурированной работы — снижение активности, работоспособности и заинтересованности исполнителя. Причем выгоранию подвержены как отдельные работники, так и команда проекта в целом — негатив от одного работника быстро передается другим, как инфекция в замкнутом пространстве.

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

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

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

Как не жить в аду?

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

Единый фронт работы. Для начала необходимо объяснить клиенту, что для успеха проекта ему необходимо включиться в проект. Коммуникация «клиент-подрядчик» должна быть максимально открытой. Клиент становится частью команды: у него появляется заинтересованность в результате, понимание процессов и возможностей.

В первую очередь мы вместе с представителями заказчика объединились в команду и перестали делить друг друга по принципу «клиент-подрядчик». Мы внедрили scrum-доску, на которую стали заносить все входящие задачи, совместно формализовывать их и расставлять приоритеты. Мы включили в процесс всех постановщиков задач из разных подразделений, чтобы не играть в испорченный телефон. В итоге у всей команды появилось понимание каждой задачи.

Так мы перестали быть «участниками проекта» и превратились в «командных игроков». Согласитесь, что даже такое символическое изменение статуса повышает ответственность и заинтересованность в результате.

Рабочий ритм. Ад — это не только огромное количество задач, но и постоянные простои. В один день непонятно, куда деться от огромного объема срочных запросов, но уже завтра делать ровным счетом нечего. Такие рабочие «качели» могут привести к тому, что работник не сможет выполнить важную задачу в нужный момент. Поэтому рабочий процесс должен быть выстроен так, чтобы нагрузка распределялась равномерно.

Из бэклога (списка задач) мы брали в недельный спринт только то количество задач, которое реально могли сделать. Но как найти оптимальную загрузку? Во-первых, благодаря опыту. Нам понадобилось 4 недели, чтобы удостовериться — никто не перегружен, но и не простаивает. Ни один командный игрок не выгорел, что означало: мы на верном пути. Во-вторых, прогноз на выполнение каждой задачи определялся всей командой. Кто-то оценивал ее в три часа, а кто-то — в десять. Мы собирали аргументы, соглашались или переубеждали. В итоге находили золотую середину, с которой все были согласны. Так мы научились лучше оценивать свои возможности и брать в спринт максимальное количество задач.

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

Как настроить рабочий процесс

В технологии SMART для создания работающих целей необходимо их соответствие пяти принципам:

  • конкретность (S — specific);
  • измеримость (M — Measurable);
  • достижимость (A — Attainable);
  • значимость или актуальность (R — Relevant);
  • ограниченность во времени (T — Time-bound).

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

Декомпозиция. Любой проект разбивается на задачи такого размера, чтобы можно было наблюдать динамику по их реализации ежедневно, максимум — раз в два дня. Если задача занимает больше времени, велика вероят��ость получить не тот результат.

Например, у нас есть задача — выяснить причину отказов от покупки при оформлении в мобильном приложении. Мы разложили ее на следующие задачи: написать техническое задание (1 день), проверить реализацию (полдня), провести анализ данных (1 день), написать техническое задание на исправление логики приложения (1 день). Без детализации мы бы начали работу без понимания ее объема, что привело бы к неправильному определению сроков и к их нарушению. К тому же мы не знали бы, как продемонстрировать результат.

Формализация. Часто самая большая проблема — коммуникация. Смысл задачи не передается до конца, в результате у всех членов команды может возникнуть разное понимание результата. Поэтому необходимо проговаривать с командой отдельно все небольшие точки движения задачи, четко понимать, какой итог от работы ожидается. Это действие помогает избежать ненужных эмоциональных обсуждений, когда время уже потеряно, а нужного результата нет. Эмоции, в свою очередь, напрямую влияют на производительность работников в целом. Поэтому понятные задачи — залог спокойствия в коллективе.

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

В каждый спринт мы брали по 50—60 задач, и при таком объеме использование простой линейки создавало бы хаос и не позволяло понять, какая же задача в итоге важнее. Поэтому мы применяли линейку приоритетности от 100 до 10 тыс., что позволяло определять более важную даже из двух похожих задач.

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

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

При этом не нужно забывать о гибкости. Изменения происходят постоянно, могут (и будут) появляться новые вводные. Поэтому вместе со всей командой время от времени проводите пересмотр приоритетов задач. Для этого хорошо подходит принцип Парето: 20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата. Поэтому в первую очередь добавляйте те задачи, которые приносят пользу проекту.

Командные активности

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

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

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

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

Об авторе: Константин Франгуриди — директор по оптимизации бизнес-процессов digital-агентства PINKMAN.

Источник: https://hbr-russia.ru/management/upravlenie-personalom/784678