Горизонтальные коммуникации в команде: разбор проекта, который горел

Проект, который казался типовым

Alto — компания заказной разработки. Сайтов на Битриксе мы сделали сотни, поэтому новый проект выглядел рутиной: корпоративный сайт, знакомый стек, понятный объём. Отличался только клиент. Это одна из 30 крупнейших компаний страны, десятки тысяч сотрудников и внутренняя бюрократия под стать.

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

Где сломались сроки

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

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

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

Диагностика: что происходило с людьми

Я перестал смотреть на диаграммы Ганта и задачи в трекере и пошёл разговаривать с людьми, чтобы понять, как на самом деле устроена коммуникация в команде. Картина оказалась такой.

• Все несли проблемы мне. Не из злого умысла: к руководителю идти удобнее, он, скорее всего, знает ответ.
• Команда потеряла надежду, что проект закончится. Если спринт за спринтом срывается, проект кажется бесконечным, и стараться незачем.
• Люди привыкли к конвейеру. В аутсорсе у специалиста бывает три проекта за месяц подряд: менеджер нарезал задачи, тестировщик проверил, получил новые. Здесь была выделенная команда, и от каждого требовалось участие.
• Тлели скрытые конфликты. Менеджер на планёрке объявляет недельный спринт, выходит из Zoom, заходит тимлид: делаем то, что скажу я.
• «Мы такого раньше не делали» стало индульгенцией на ошибку.
• Тестировщики и программисты обвиняли друг друга: одни не проверяют свою работу, другие требуют слишком много, а iPhone для тестов есть не у всех.
• Переработки по вечерам и выходным плюс обещание «после релиза отдохнём», которое не сбывалось.
• Встречи без понятного смысла для команды.

Коммуникация: учим договариваться без руководителя

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

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

Горизонтальная коммуникация начинается с общих встреч

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

Тестировщика, который жаловался мне на программистов, я буквально за руку привёл на встречу и попросил сказать им то же самое. Его не побили и не высмеяли. Во второй раз ему было уже легко, и обмен требованиями пошёл напрямую.

Проблемы — на общее обсуждение, а не ко мне

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

Планирование и командный дух

Мы запланировали отпуска. Это было критично: человек должен видеть, что гонка когда-то закончится и можно будет выдохнуть.

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

Для командного духа мы объяснили, как устроен клиент: много вертикалей, у каждого участника свой интерес, поэтому отдельные встречи по технике, по срокам и по дизайну. Ритуалы перестали казаться бессмысленными. Там, где у человека пропадала вера, что он справится, мы садились и раскладывали задачу на подзадачи, пока не становилось понятно, как её сделать. И убрали дежурное «давайте поднажмём»: на второй неделе оно мотивирует, на девятой бесит.

Результат и откат через четыре месяца

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

Ещё через четыре месяца начался регресс. Такие практики нельзя внедрить один раз и передать. В моменте всегда хочется срезать углы, и всё забывается. Сам проект мы довели до финишной прямой, но ушли на нём в минус 3 млн руб. — мой личный рекорд.

Что я вынес из этого проекта

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

Первой надо спасать команду, а не бежать к клиенту с обещаниями. Если не решить проблемы внутри, они потом утянут проект.

Где толсто, там и рвётся. Наш менеджер был самым стрессоустойчивым человеком на проекте, держал всё в себе, и я не заметил, как он начал сдавать. Там, где человек кажется непробиваемым, вы, скорее всего, недополучаете обратную связь.

Договариваться мы все умеем со школы. Мешает недоверие: тестировщик знал проблему и знал, к кому идти, но боялся, что его не услышат. Нет доверия в команде — нет и разговора по горизонтали. Мне многое прояснила книга «Пять пороков команды»: бизнес-роман на 200 страниц о директоре, который собирает распавшуюся команду. Мне её советовали пять лет, а прочитал я её только после этого проекта.

Ответы на вопросы из зала

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

Какую роль играл менеджер в скраме? На бумаге в заказной разработке все хотят водопад, а внутри — скрам. Здесь был жёсткий водопад и фиксированная цена. Менеджер не был владельцем продукта, отчасти выполнял роль скрам-мастера, но прежде всего связывал 12 участников клиента, генподрядчика и команду.

Как масштабировать? Повторять тот же алгоритм в каждой команде. В заказной разработке есть правило: хочешь вырасти больше 30 человек — сделай несколько агентств по 30 и объедини их. Чем больше команда, тем сложнее строить доверие без бюрократии.