Сергей Стрижак – Лидерство как сервис. Как управлять командой, не управляя людьми (страница 2)
Подход Архитектора: Он вместе с командой создает простые, понятные и гибкие процессы. Он не придумывает их в своем кабинете, а наблюдает за тем, как работа выполняется на самом деле, и формализует лучшие практики.
Пример простого, но мощного процесса – Definition of Done (DoD), или «Критерии готовности», взятое из Scrum. Прежде чем команда начнет работать над задачей типа «Написать статью», они все вместе договариваются, что именно означает «статья готова». Например:
– Текст написан.
– Проверен корректором.
– Подобраны иллюстрации.
– Согласован с юридическим отделом.
– Опубликован в блоге.
– Анонсирован в соцсетях.
Такой простой чек-лист устраняет 90% будущих конфликтов и вопросов в стиле «А я думал, это сделаешь ты». Это и есть проектирование среды: вы создаете процесс, который работает вместо вас, обеспечивая качество и ясность.
В команде Контролера вся информация течет через него. Он – центральный узел, который собирает данные от одних и передает их другим. Это делает его незаменимым, но катастрофически замедляет всю систему.
– Проблема Контролера: Коммуникации хаотичны и синхронны. Чтобы узнать статус проекта, нужно лично спросить или созвать совещание.
– Подход Архитектора: Он проектирует архитектуру информации. Его цель – сделать максимум информации доступной всем членам команды асинхронно. То есть, чтобы для получения ответа на 90% вопросов сотруднику не нужно было никого отвлекать.
Как это выглядит на практике?
– Единый источник правды: Вся информация по проекту (цели, задачи, статусы, документы, решения) хранится в одном, всем доступном месте (например, на странице проекта в Notion).
– Прозрачные таск-трекеры: Любой член команды может зайти и увидеть, на каком этапе находится любая задача. Это убивает необходимость в совещаниях-статусах.
– Четкие правила для каналов связи: Команда договаривается, что использовать для чего. Например:
Такая система освобождает вас от роли «человека-коммутатора» и дает команде возможность двигаться вперед самостоятельно.
Это самый сложный и самый важный элемент. Культура – это то, как люди ведут себя, когда на них никто не смотрит. Вы можете внедрить лучшие инструменты и процессы, но если в команде царит страх ошибки, они не будут работать.
Проблема Контролера: Он создает культуру страха. Ошибки наказываются. Инициатива, которая не совпадает с его мнением, пресекается. Люди боятся говорить о проблемах, пока не становится слишком поздно.
Подход Архитектора: Он целенаправленно культивирует психологическую безопасность (об этом мы подробно поговорим в следующей главе). Он личным примером показывает, что ошибаться – это нормально. Он поощряет вопросы и здоровую критику. Он празднует не только успехи, но и ценные уроки, извлеченные из неудач.
Как архитектор, вы создаете культурный климат через свои реакции.
– Когда сотрудник сообщает о проблеме, вы говорите: «Спасибо, что сказал об этом вовремя. Давай вместе подумаем, как это решить» или «Кто тебя надоумил так сделать?!».
– Когда кто-то допускает ошибку, вы спрашиваете: «Какой урок мы можем из этого извлечь, чтобы не повторить ее в будущем?» или «Кто виноват?».
Ваша реакция – это мощнейший инструмент формирования культуры. Она как климат-контроль в теплице: может создать идеальные условия для роста или устроить засуху.
Практика: Аудит вашей среды
Хватит теории. Давайте перейдем к практике. Прямо сейчас вы можете сделать первый шаг от Контролера к Архитектору. Проведите аудит вашей командной среды. Возьмите лист бумаги или откройте новый документ и честно ответьте на эти вопросы. Лучше – обсудите их с командой.
Аудит среды: Чек-лист для Лидера-Архитектора
Инструменты:
– Есть ли у моей команды все необходимые инструменты для эффективной работы?
– Какие рутинные операции мы можем автоматизировать?
– Жалуется ли кто-то на неудобство текущих программ? Спрашивал ли я их об этом за последний месяц?
– Наши инструменты помогают нам быть прозрачными или создают информационные «бункеры»?
Процессы:
– Понимает ли каждый член команды, как задача проходит путь от идеи до реализации?
– Есть ли у нас четкое «Определение готовности» для ключевых типов задач?
– Как мы принимаем решения? Этот процесс понятен всем?
– Существуют ли в нашей работе «серые зоны», где никто не знает, кто за что отвечает?
Коммуникации:
– Сколько времени я трачу на совещаниях, единственная цель которых – узнать статус?
– Может ли новый сотрудник, придя в команду, самостоятельно найти всю необходимую информацию для старта работы?
– Есть ли у нас единый источник правды по проектам? Он актуален?
– Как часто работа останавливается, потому что кто-то ждет моего ответа или решения?
Культура:
– Как в последний раз я отреагировал на плохие новости или ошибку сотрудника?
– Как часто члены моей команды спорят со мной или оспаривают мои идеи? (Если никогда – это очень плохой знак).
– Поощряем ли мы эксперименты, которые могут закончиться неудачей?
– Что происходит, когда кто-то говорит «Я не знаю» или «Мне нужна помощь»?
Этот аудит – ваша отправная точка. Он покажет вам, где ваша «почва» наиболее истощена и требует вашего внимания как архитектора.
Перестаньте быть садовником, который пытается выпрямить каждый стебель. Станьте архитектором, который проектирует сад, где все растет само. Ваша работа – не в том, чтобы быть самым трудолюбивым человеком в команде. Ваша работа – в том, чтобы создать систему, в которой каждый может быть максимально эффективным. Это требует смены фокуса, но именно этот сдвиг освободит ваше время, раскроет потенциал вашей команды и, в конечном итоге, приведет к выдающимся результатам.
В следующей главе мы поговорим о фундаменте этой системы – о психологической безопасности. Без нее даже самый прекрасный сад не даст урожая.
Глава 2. Психологическая безопасность: фундамент для автономии и инициативы
Представьте себе команду разработчиков, работающую над важным проектом. Лидер команды, Дмитрий, – блестящий программист, но очень требовательный и нетерпимый к ошибкам руководитель.
На одном из совещаний молодой разработчик Андрей, просматривая код, замечает потенциальную уязвимость в системе безопасности. Он не уверен на 100%, но интуиция подсказывает ему, что здесь что-то не так. Он открывает рот, чтобы сказать об этом, но в этот момент Дмитрий жестко отчитывает другого сотрудника за небольшую оплошность в коде. «Как можно было этого не заметить? Это же основы!» – гремит голос Дмитрия.
Андрей закрывает рот. Мысли в его голове проносятся с бешеной скоростью:
Через месяц проект выходит в релиз. А еще через неделю хакеры используют ту самую уязвимость, крадут данные тысяч клиентов и наносят компании многомиллионный ущерб.
Кто виноват в этой катастрофе? Хакеры? Неопытный Андрей? Некомпетентный коллега, которого отчитывали?
Нет. Виновато отсутствие психологической безопасности. Виновата среда, в которой сказать «Я думаю, здесь может быть проблема» страшнее, чем промолчать и допустить катастрофу.
Психологическая безопасность – это, пожалуй, самое непонятое и в то же время самое важное свойство высокоэффективных команд. Когда компания Google провела многолетнее исследование «Проект Аристотель», чтобы выяснить, что отличает их лучшие команды от остальных, ответ удивил многих. Это были не гениальность участников, не четкие цели и не авторитетный лидер. Самым важным фактором, предсказывающим успех команды, оказалась именно психологическая безопасность.
Что такое психологическая безопасность?
В своей основе, это общее убеждение членов команды, что в этом коллективе безопасно брать на себя межличностные риски.
Что это за риски?
– Задать «глупый» вопрос.
– Предложить сумасшедшую идею.