Существуют разные мнения о том, как команды становятся командами. Есть несколько наиболее популярных моделей, которые говорят о невозможности стать командой быстро. Это может быть долгий процесс со своей динамикой.
Бизнес же в контексте темы часто интересует, что даже если не в короткое время, то как скоро можно провернуть превращение в команду, ведь известно, что именно “командная работа” позволяет добиться самых эффективных результатов. Здесь полагаются на лидеров — руководителей проекта, Скрам Мастеров, тимлидов. Кто-то расскажет о важности “вместе сходить в бар” на начальном этапе, кто-то — о выборе названия или логотипа как о способе определить и подчеркнуть идентичность команды.
Мне больше всего нравится точка зрения на команду как на группу людей, переживших первый успешный совместный опыт. В коучинге на подобную тему мне встречалась метафора “перебраться через забор”. В ней забор — это наша способность вырабатывать решения общих проблем, и чтобы “перебраться через него”, понадобятся теплота, чувство юмора и желание действовать сообща.
Летом этого года я начала работу на проекте, который на данный момент является одним из самых приоритетных в компании. Его основная цель — заменить древние легаси бэкенды на современную микро сервисную архитектуру и таким образом сделать мир Телекома лучше. Ожидания достаточно высоки, и темп взят быстрый, а это влечет за собой активный рост и необходимость набирать и запускать новые команды. Одну из таких новых команд предстояло собрать и запустить мне.
Ну, вы поняли.
Я погрузилась в период вдумчивого подбора кандидатов, который продлился некоторое время. Я знакомилась с людьми и в неформальной беседе старалась узнать их точку зрения на разные вопросы, но с полным уходом на удаленку и разными датами выхода на проект у всех нас не было хорошей возможности по-настоящему узнать друг друга. Тем не менее состав “высокомотивированных и кросс функциональных профессионалов” (мы работаем по Scrum) постепенно набирался.
И, как часто бывает, в какой-то момент маховик стал раскручиваться быстрее и быстрее, и вот уже нет времени ни объяснять, ни на аккуратный кик-офф. Нужно хватать набранных в команду людей и стартовать быстро. В то же время режим пандемии наложил жесткое ограничение на возможность пресловутых тимбилдинговых мероприятий. Хотя сожалеть об этом, должно быть, бессмысленно: со всеми приготовлениями у нас все равно не было времени на нормальное знакомство.
Так впервые мы все “увидели” друг друга только на первом планировании. И поскольку это было не просто планирование, а PIP (Product Increment Planning — мероприятие в SAFe, посвященное высокоуровневому планированию работы команд на следующие несколько спринтов), то нам предстояло разобраться со многими вещами за ограниченный отрезок времени.
Представьте себе этот миг. Это ваш первый опыт подобного мероприятия. Вы оказываетесь в конференц-звонке с девятью незнакомцами, и хотя вас только что объявили “командой”, вы понятия не имеете, кто эти люди, какими навыками они в действительности обладают, и у вас есть три часа, чтобы вместе, “командой” создать план работы на следующие три месяца.
Вы также несколько опасаетесь той сложной задачи, которую предлагается разложить на несколько пунктов плана, поскольку в описании нет однозначной ясности.
Кстати, наш Product Increment Planning, будь он в оффлайне, мог бы выглядеть так.
Сначала мы буквально стояли, метафорически столпившись вокруг имевшегося бэклога, и обсуждали, что можно сделать. В ответ со стороны команды разработки часто отзывалась только тишина, процесс не шел легко.
И все же я, словно тот добыватель огня, неутомимо раз за разом бьющий камень о камень, продолжала дружески подбадривать команду разработки. Как неожиданно высеченная искра превратилась в маленький огонек.
Отвечая, один из разработчиков сделал паузу и… просто озвучил все то, что беспокоило каждого из присутствующих. Неуверенность, неловкость, высокий уровень неопределенности… Да, все это есть, и мы все это чувствуем. Но помешает ли это нам выполнить то, ради чего мы собрались сейчас? Это вы скажите мне!
Вдруг следом признался в собственных сомнениях другой инженер. А затем и другие. Кто-то считал свой уровень экспертности недостаточным, кто-то смущался задавать “глупые” уточняющие вопросы. Кто-то просто испытывал дискомфорт, потому что познакомился с нами буквально только что, и не хотел произвести “не то” впечатление.
Когда мы произнесли все источники нашего беспокойства вслух, дышать стало как будто бы легче. Каждый из нас сделал свое признание, и никто не осудил нас. Атмосфера становилась все теплее. Послышались шутки.
Робкий костер разгорелся в уверенное яркое пламя.
Наша группа едва знакомых друг с другом людей ощутила себя совсем иначе. Постепенно мы разработали стратегию, по которой разбирали бэклог. Разработчики оценивали требования и действовали сообща: они обсуждали, что нужно сделать, и какие уровни декомпозиции нужны той или иной задаче. Все это тут же фиксировалось в JIRA. Затем они распределили работу. В обсуждении участвовал каждый.
Это было удивительно — следить за тем, как они за считанные минуты открыли для себя, что все они — часть команды.
Выступление на TED на эту тему мне попалось намного позже.
Между тем Продукт Оунер тоже работал вовсю, несмотря на то, что приличная доля работы была выполнена им еще до этой встречи: ведь это он подготовил все требования. Он объяснял высокоуровневые цели, на которые команде нужно было ориентироваться, актуализировал бэклог, отвечал на вопросы, прояснил все, что было возможно прояснить.
Я же, как Скрам Мастер, направляла движение дискуссии, когда это было необходимо, предупреждая возникновение чувства, что сама дискуссия заходит в тупик.
Через три часа напряженной работы команда закончила строить дорожную карту в соответствии с поставленными целями на следующие три месяца, и тем самым завершила планирование.
На следующий день Продукт Оунер презентовал этот план стейкхолдерам, и, с учетом небольших комментариев к формулировкам, он был согласован и принят.
Нам всем удалось это сделать, действуя сообща. Помогая друг другу, мы получили наш первый успешный совместный опыт еще до начала работы над задачами. На этом планировании наша команда обрела общее достижение (конечно, первое из многих). Мы стали “покорителями PI планнинга”, и это вселило в нас чувство, что мы безусловно способны успешно реализовать все остальные части нашего сложного проекта.
И если бы меня спросили: “Как команды становятся командами? Долгий ли это процесс?”, я бы ответила, что истинную командную идентичность они обретают тогда, когда “перебираются через забор”, то есть преодолевают первую трудность, действуя слаженно и сплоченно. И в том, чтобы это случилось как можно скорее, и есть ответственность лидера.
А что именно он может для этого сделать, звучит, как тема для следующей статьи :)
Бизнес же в контексте темы часто интересует, что даже если не в короткое время, то как скоро можно провернуть превращение в команду, ведь известно, что именно “командная работа” позволяет добиться самых эффективных результатов. Здесь полагаются на лидеров — руководителей проекта, Скрам Мастеров, тимлидов. Кто-то расскажет о важности “вместе сходить в бар” на начальном этапе, кто-то — о выборе названия или логотипа как о способе определить и подчеркнуть идентичность команды.
Мне больше всего нравится точка зрения на команду как на группу людей, переживших первый успешный совместный опыт. В коучинге на подобную тему мне встречалась метафора “перебраться через забор”. В ней забор — это наша способность вырабатывать решения общих проблем, и чтобы “перебраться через него”, понадобятся теплота, чувство юмора и желание действовать сообща.
Летом этого года я начала работу на проекте, который на данный момент является одним из самых приоритетных в компании. Его основная цель — заменить древние легаси бэкенды на современную микро сервисную архитектуру и таким образом сделать мир Телекома лучше. Ожидания достаточно высоки, и темп взят быстрый, а это влечет за собой активный рост и необходимость набирать и запускать новые команды. Одну из таких новых команд предстояло собрать и запустить мне.
Ну, вы поняли.
Я погрузилась в период вдумчивого подбора кандидатов, который продлился некоторое время. Я знакомилась с людьми и в неформальной беседе старалась узнать их точку зрения на разные вопросы, но с полным уходом на удаленку и разными датами выхода на проект у всех нас не было хорошей возможности по-настоящему узнать друг друга. Тем не менее состав “высокомотивированных и кросс функциональных профессионалов” (мы работаем по Scrum) постепенно набирался.
И, как часто бывает, в какой-то момент маховик стал раскручиваться быстрее и быстрее, и вот уже нет времени ни объяснять, ни на аккуратный кик-офф. Нужно хватать набранных в команду людей и стартовать быстро. В то же время режим пандемии наложил жесткое ограничение на возможность пресловутых тимбилдинговых мероприятий. Хотя сожалеть об этом, должно быть, бессмысленно: со всеми приготовлениями у нас все равно не было времени на нормальное знакомство.
Так впервые мы все “увидели” друг друга только на первом планировании. И поскольку это было не просто планирование, а PIP (Product Increment Planning — мероприятие в SAFe, посвященное высокоуровневому планированию работы команд на следующие несколько спринтов), то нам предстояло разобраться со многими вещами за ограниченный отрезок времени.
Представьте себе этот миг. Это ваш первый опыт подобного мероприятия. Вы оказываетесь в конференц-звонке с девятью незнакомцами, и хотя вас только что объявили “командой”, вы понятия не имеете, кто эти люди, какими навыками они в действительности обладают, и у вас есть три часа, чтобы вместе, “командой” создать план работы на следующие три месяца.
Вы также несколько опасаетесь той сложной задачи, которую предлагается разложить на несколько пунктов плана, поскольку в описании нет однозначной ясности.
Кстати, наш Product Increment Planning, будь он в оффлайне, мог бы выглядеть так.
Сначала мы буквально стояли, метафорически столпившись вокруг имевшегося бэклога, и обсуждали, что можно сделать. В ответ со стороны команды разработки часто отзывалась только тишина, процесс не шел легко.
И все же я, словно тот добыватель огня, неутомимо раз за разом бьющий камень о камень, продолжала дружески подбадривать команду разработки. Как неожиданно высеченная искра превратилась в маленький огонек.
Отвечая, один из разработчиков сделал паузу и… просто озвучил все то, что беспокоило каждого из присутствующих. Неуверенность, неловкость, высокий уровень неопределенности… Да, все это есть, и мы все это чувствуем. Но помешает ли это нам выполнить то, ради чего мы собрались сейчас? Это вы скажите мне!
Вдруг следом признался в собственных сомнениях другой инженер. А затем и другие. Кто-то считал свой уровень экспертности недостаточным, кто-то смущался задавать “глупые” уточняющие вопросы. Кто-то просто испытывал дискомфорт, потому что познакомился с нами буквально только что, и не хотел произвести “не то” впечатление.
Когда мы произнесли все источники нашего беспокойства вслух, дышать стало как будто бы легче. Каждый из нас сделал свое признание, и никто не осудил нас. Атмосфера становилась все теплее. Послышались шутки.
Робкий костер разгорелся в уверенное яркое пламя.
Наша группа едва знакомых друг с другом людей ощутила себя совсем иначе. Постепенно мы разработали стратегию, по которой разбирали бэклог. Разработчики оценивали требования и действовали сообща: они обсуждали, что нужно сделать, и какие уровни декомпозиции нужны той или иной задаче. Все это тут же фиксировалось в JIRA. Затем они распределили работу. В обсуждении участвовал каждый.
Это было удивительно — следить за тем, как они за считанные минуты открыли для себя, что все они — часть команды.
Выступление на TED на эту тему мне попалось намного позже.
Между тем Продукт Оунер тоже работал вовсю, несмотря на то, что приличная доля работы была выполнена им еще до этой встречи: ведь это он подготовил все требования. Он объяснял высокоуровневые цели, на которые команде нужно было ориентироваться, актуализировал бэклог, отвечал на вопросы, прояснил все, что было возможно прояснить.
Я же, как Скрам Мастер, направляла движение дискуссии, когда это было необходимо, предупреждая возникновение чувства, что сама дискуссия заходит в тупик.
Через три часа напряженной работы команда закончила строить дорожную карту в соответствии с поставленными целями на следующие три месяца, и тем самым завершила планирование.
На следующий день Продукт Оунер презентовал этот план стейкхолдерам, и, с учетом небольших комментариев к формулировкам, он был согласован и принят.
Нам всем удалось это сделать, действуя сообща. Помогая друг другу, мы получили наш первый успешный совместный опыт еще до начала работы над задачами. На этом планировании наша команда обрела общее достижение (конечно, первое из многих). Мы стали “покорителями PI планнинга”, и это вселило в нас чувство, что мы безусловно способны успешно реализовать все остальные части нашего сложного проекта.
И если бы меня спросили: “Как команды становятся командами? Долгий ли это процесс?”, я бы ответила, что истинную командную идентичность они обретают тогда, когда “перебираются через забор”, то есть преодолевают первую трудность, действуя слаженно и сплоченно. И в том, чтобы это случилось как можно скорее, и есть ответственность лидера.
А что именно он может для этого сделать, звучит, как тема для следующей статьи :)
