Автор: Ольга Прохоренко

Автор: Ольга Прохоренко

За годы работы в HR я не раз сталкивалась с вопросом: почему команды сильных специалистов не всегда показывают сильный совместный результат? У людей есть опыт, необходимые инструменты, понятные должности. При этом задачи возвращаются на доработку, сроки сдвигаются, а руководители тратят всё больше времени на ручное управление. Поэтому к фразе «нам нужны более сильные люди» я отношусь с осторожностью. Иногда это действительно так. Но прежде чем искать новых сотрудников, я стараюсь разобраться, что мешает тем, кто уже работает в компании, добиваться результата вместе.

Меня заинтересовало исследование Google «Аристотель» (Project Aristotle), посвященное эффективности команд. Исследователи несколько лет изучали сотни команд и пытались понять, почему одни добиваются успеха, а другие — нет. Оказалось, состав команды почти не имеет значения. Важнее то, как люди взаимодействуют друг с другом.
Меня заинтересовала практическая сторона этих выводов. Если эффективность команды связана с тем, как люди взаимодействуют, значит, на неё можно повлиять через повседневные процессы и управленческие привычки: как обсуждаются задачи, принимаются решения, распределяется ответственность и анализируются ошибки. Многие из этих практик гораздо доступнее, чем кажется на первый взгляд. Начать можно с изменений в привычной работе: дать людям возможность высказывать сомнения при планировании, договориться о правилах смены приоритетов, обсуждать с командой результаты релизов.

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

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

• Психологическая безопасность (Psychological Safety). Сотрудники могут открыто говорить о проблемах, задавать вопросы и признавать ошибки, не опасаясь, что это обернётся против них.
• Надёжность (Dependability). Участники команды качественно и в срок выполняют свою работу, соблюдают договоренности, и коллеги могут на них положиться.
• Структура и ясность (Structure & Clarity). Люди понимают цели, свои роли, границы ответственности и планы работы.
• Личная значимость работы (Meaning). Сотрудники находят в работе смысл, важный лично для них. В нашем случае мы также рассматривали связь текущих задач с профессиональными интересами и развитием.
• Понимание влияния результата (Impact). Команда видит, какую пользу её работа приносит продукту, пользователям и бизнесу.

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

Моя роль как HR-специалиста заключалась в том, чтобы организовать диагностику, выявить проблемы взаимодействия и помочь руководителям изменить управленческие практики, которые эти проблемы “подкармливали”.

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

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

2. Надёжность: обязательства понимались по-разному
При анализе срывов сроков мы увидели, что участники брали задачи, не до конца оценив зависимость от коллег. Не всегда было общее понимание того, какой результат и к какому моменту должен получить следующий участник процесса.

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

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

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

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

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

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

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

На основе диагностики мы составили план изменений по каждому из пяти направлений.

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

• Личный пример руководителей. На общих встречах они стали спокойно признавать ошибки в собственных оценках и благодарить коллег за своевременное сообщение о рисках.
• Порядок обсуждения. При планировании сначала собирали оценки и сомнения команды, затем руководитель озвучивал свою позицию. Так участники могли высказаться до того, как услышат мнение лида.
• Разбор неудачных релизов. Обсуждали последовательность событий: какие решения принимала команда, на какую информацию опиралась и где возникали проблемы. Что мы знали в тот момент? Где терялся контекст? Какое изменение в процессе поможет избежать повторения ошибок? Поиск виноватых перестал быть целью разбора.

2. Надёжность
Здесь мы сосредоточились на содержании обязательств и распределении работы между участниками.

• Условия принятия задачи. Договорились брать задачу в работу, когда есть необходимые вводные и понятен объём ресурсов. Вместо размытых обещаний «попробуем успеть» стали фиксировать реалистичные сроки.
• Критерии готовности. Описали, что считается готовым результатом при передаче задачи от продакта разработчикам, от инженеров — тестировщику и далее по остальным этапам работы. Это помогло прояснить ответственность при передаче задач и избежать ситуаций «я всё сделал, а дальше не моя проблема».
• Раннее предупреждение. Договорились сообщать о риске задержки сразу, как только он становится известен. Руководители поддержали этот подход: они включались в поиск решения, чтобы у команды оставалось время помочь коллеге или пересмотреть план.

3. Структура и ясность
Мы зафиксировали порядок принятия решений, который раньше приходилось заново обсуждать при каждом конфликте приоритетов.

• Матрица полномочий. В Confluence выложили краткую матрицу: кто принимает окончательное решение по продуктовому scope, кто — по техническому долгу, и куда эскалировать вопрос при конфликте приоритетов.
• Правило «входного билета». Срочная задача от бизнеса могла попасть в текущий спринт только с явным снятием другой задачи сопоставимой трудоёмкости. Решение о новом приоритете теперь включало договорённость о том, что команда откладывает.

4. Личная значимость работы
Изменили содержание личных встреч и стали учитывать профессиональные интересы при распределении задач.

• Фокус 1-on-1. Статусы текущей работы перенесли на доску. На личных встречах стали обсуждать мотивацию, признаки выгорания, развитие и необходимую поддержку. «Что из текущей работы тебя действительно драйвит, а что высаживает? В какую сторону ты хочешь расти в ближайшем полугодии?»
• Задачи для развития. Ответы начали учитывать в работе. Например, разработчику, заинтересованному в архитектуре, доверили проработку сложного модуля под кураторством. Аналитика подключили к обсуждению продуктовых гипотез ещё до формирования ТЗ, а тестировщику дали возможность внедрять автотесты.

5. Влияние результата
Добавили продуктовый контекст в начало работы и обратную связь после выпуска.

• Контекст на старте. Запуская крупные эпики, до команды доносили полный контекст: какую конкретно проблему пользователя решает фича и по каким метрикам будет оцениваться успех.
• Данные после релиза. Участники получали информацию о том, как изменилась конверсия, сколько людей использовали новую функцию, уменьшилось ли число ошибок и обращений в поддержку. Закрытая задача в трекере перестала быть последней точкой обсуждения результата.

После пилота мы провели повторный опрос и проанализировали динамику спринтов в Jira. В работе команды заметили несколько изменений.

1. Риски стали обсуждать раньше
Технические и продуктовые неопределённости начали поднимать уже на этапе планирования. Сомнения, которые прежде оставались в личных переписках, стали предметом общего обсуждения. У команды появлялось больше времени, чтобы учесть их в работе.

2. Договорённости стали предсказуемее
Критерии готовности помогли точнее согласовывать обязательства между участниками. При передаче задач стало меньше расхождений в ожиданиях: каждый понимал, какой результат нужен коллегам для следующего этапа работы. Это сократило дополнительные уточнения и доработки, из-за которых раньше сдвигались сроки.

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

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

1. Диагностика определяет, какие изменения нужны команде. Внешне спокойная встреча ещё не говорит о том, что люди свободно обсуждают проблемы. А сорванный срок сам по себе не объясняет, где возник сбой. В нашем случае сопоставление интервью, опроса и прошлых спринтов помогло увидеть причины молчания и разрывов в договорённостях. На этой основе мы могли выбирать конкретные управленческие действия.

2. HR необходимо понимать рабочий процесс и контекст бизнеса. Для работы с эффективностью команды недостаточно отслеживать HR-показатели. Нужно понимать путь задачи — от постановки до релиза, зависимости между участниками и порядок принятия решений. Участие в планировании и разбор рабочих ситуаций позволяли мне обсуждать с руководителями конкретные причины задержек и напряжения в команде.

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

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

По итогам пилотного проекта та же команда смогла сократить время разработки и выпускать релизы в запланированные сроки. Для меня ценность подхода Google проявилась в диагностике: молчание на встречах, размытые обязательства, слабая связь задач с профессиональными интересами и отсутствие обратной связи о результатах работы рассматривались в комплексе. Это помогло понять, как повседневные управленческие практики влияют на работу команды, и определить, что именно нужно менять. За три месяца мы увидели улучшения как во взаимодействии, так и в выполнении задач. Такой результат дал основание продолжить работу с этими практиками и оценить, насколько устойчивым окажется эффект.