Ozon Tech опубликовал разбор про шесть состояний команды: от группы людей, которых просто посадили в один проект, до момента, когда общий маршрут заканчивается. Материал Антона Куракина вышел в блоге компании и рассчитан на 13 минут чтения, сообщает Habr / Карьера. Для русскоязычных разработчиков, тимлидов, продактов и HR это не теория из учебника по менеджменту, а довольно узнаваемая карта рабочих симптомов: страх вместо ответственности, молчание вместо доверия, зеленые метрики вместо движения к цели.
Автор строит текст как полет: команда оказывается экипажем, проект — маршрутом, а управленческие сбои — турбулентностью. В статье названы шесть этапов: фюзеляж, топливо, декомпрессия, автопилот, шпангоуты и усталость металла. Образы местами театральные, но за ними вполне практичная мысль: команда не появляется после создания чата, назначения менеджера и первого дейлика. Сначала это просто люди с разными задачами, календарями и версиями реальности.
Первое состояние — «фюзеляж» — описывает раннюю стадию, когда люди уже собраны организационно, но еще не связаны общей картиной проекта. У команды может быть название, бэклог и общий созвон, но при первом инциденте выясняется, что никто не понимает, кто за что отвечает. Для IT-команд это знакомый сценарий: прод упал, в чате появляется вопрос «кто знает эту часть?», и внезапно оказывается, что рядом работали не коллеги, а параллельные исполнители. Вывод простой и неприятный: на этом этапе нельзя требовать зрелого командного поведения, если роли, цели, риски и правила коммуникации не проговорены.
Второе состояние — «топливо» — разбирает, за счет чего команда вообще едет вперед. Автор отделяет ответственность от страха: внешне они могут выглядеть одинаково, особенно если люди постоянно онлайн, заранее оправдываются за задержки, берут чужие задачи и называют переработки «поддержкой команды». Но страх плохо масштабируется. Он может вытянуть релиз, квартал или пожар в проде, зато быстро сжигает людей. В статье прямо перечислены тревожные признаки: переработки становятся нормой, плохие новости откладываются до последнего, красный статус воспринимается как поиск виноватого, а фраза «я не успеваю» звучит как признание слабости.
Третья стадия — «декомпрессия» — начинается, когда кто-то в команде впервые говорит правду без упаковки в корпоративный пенопласт. Например: «я не понимаю, зачем мы это делаем» или «я не справляюсь». Для руководителя это неприятный момент, потому что хочется немедленно вернуть разговор в управляемое русло: зафиксировать, вынести отдельно, не уходить в эмоции. Но именно здесь, по логике автора, команда получает шанс стать настоящей. Плохая новость, сказанная рано, дешевле аварии, которую полгода прятали за молчанием и зеленым статусом.
Четвертое состояние — «автопилот» — особенно полезно для зрелых продуктовых команд. Когда все работает, релизы предсказуемы, созвоны короткие, а графики прилично выглядят в презентации, легко принять инерцию за здоровье. В статье это описано через ситуацию, где у команды все показатели в норме, но курс уже изменился. Для бизнеса риск здесь не в хаосе, а в его отсутствии: команда перестает спорить, предлагать эксперименты и проверять, туда ли она летит. В IT это может стоить дороже, чем один сорванный спринт, потому что рынок, пользовательское поведение и стратегия компании меняются быстрее, чем красивые ритуалы.
Пятое состояние — «шпангоуты» — про то, что удерживает людей вместе. Не лозунги про миссию и не бесконечные встречи один на один, а понятный маршрут, доверие, возможность признать усталость и уверенность, что коллеги временно подхватят участок без скрытого счета к оплате. Автор отдельно подчеркивает важное ограничение: взаимопомощь не должна превращаться в компенсацию хронически плохого планирования. Иначе культура поддержки быстро становится культурой героизма, где сильные молча закрывают системные ошибки менеджмента.
Последнее состояние — «усталость металла». Команда может закончиться не скандалом и не массовым увольнением, а тихо: последний коммит был девять месяцев назад, задачи переехали в другой проект, часть людей ушла в другие подразделения, название еще висит в оргструктуре, но общей работы уже нет. Это, пожалуй, самый недооцененный этап в управлении разработкой. Компании умеют нанимать, онбордить, оценивать и увольнять, но хуже умеют завершать команды: благодарить, передавать накопленный опыт, закрывать хвосты и честно признавать, что прежний маршрут больше не нужен.
Практический смысл материала не в том, чтобы срочно переименовать ретро в «предполетный брифинг». Он в диагностике. Если команда не знает ролей — это не проблема мотивации. Если люди боятся сообщать плохие новости — это не вопрос формата дейлика. Если все метрики зеленые, но никто не спорит о направлении, возможно, проект просто красиво летит не туда. Состояния команды помогают назвать эти симптомы до того, как они превращаются в выгорание, текучку или продуктовую инерцию.
Для тимлидов и IT-директоров главный вопрос после такого разбора звучит довольно буднично: ваша команда сейчас на взлете, на автопилоте или уже держится на усталости конструкции? Ответ лучше искать не в презентации для руководства, а в том, какие разговоры люди позволяют себе вести вслух.