Команды

Что такое команда?

Команды являются основным строительным блоком в разработке больших продуктов — и структура команд имеет громадное влияние на продуктивность и время цикла.

Команда имеет:

  • общий рабочий продукт
  • взаимозависимую работу
  • общую ответственность
  • набор рабочих соглашений
  • ответственность за управление внешними зависимостями [SJS03]
  • распределённое лидерство [Katzenbach98]

Самоуправляемые команды

Самоуправляемы команды являются основой Скрама и широко распространенными современными практиками менеджмента. Команда имеет все полномочия, чтобы проектировать, планировать и выполнять собственные задачи, отслеживать и управлять их работой и прогрессом [Hackman02]. Скорее команда, а не руководитель (проекта) — несёт ответственность за то, как ей работать.

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

Кросс-функциональные команды

Самоуправляемые команды кросс-функциональны (или многофункциональны). Кросс-функциональные команда это “группа людей с четкой целью, представляющая различные функции или дисциплины в организации, чьи совместные усилия необходимы для достижения этой цели[Parker02].

По определению Скрам-команды кросс-функциональна. Она включает в себя как минимум знания рынка (Владелец Продукта), разработку и тестирование программного обеспечения. Кросс-функциональные команды подразумевают разрушение организационных барьеров между разработкой и тестированием путём их помещения в одну команду.

Кросс-функциональность означает, что команда обладает всеми ключевыми функциями, необходимыми в проекте, обычно как минимум Инженерией, Маркетингом, производством [Smith07].

Организации, основанные на командах

LeSS-организации, основанные на командах, имеют следующую структуру:

  • Выделенные команды — Каждый сотрудник выделен на 100% своего времени на одну и только одну Команду. Это может казаться негибким, но такое выделение требуется для членов команды, если вы хотите, чтобы они взяли на себя (1) общую ответственность за достижение цели Команды и (2) владение способами их работы — их процессами.
  • Кросс-функциональные команды — Каждая команда включает в себя все функциональные навыки, необходимые для создания готового к поставке продукта. Традиционная функциональная специализация может выглядеть, как более ‘эффективная’ с точки зрения самих функций, но наибольшие проблемы и усилия в разработке продуктов находятся “между функциями”, и поэтому командам требуется кросс-функциональность, если вы хотите, чтобы они сосредоточились на всем работающем продукте целиком.
  • Колоцированная команды — Каждая команда находится в одной комнате. Это может звучать неубедительно. Не хотели бы вы в сегодняшнем глобализированном мире пользоваться услугами лучших людей в тех местах, где они есть? Нет. Мы хотим, чтобы лучшие команды, которые могу взять на себя общую ответственность за результаты Команды, учились друг у друга. Общая ответственность требует доверия. Люди выстраивают доверие быстрее в тесной кооперации и общении лицом к лицу. Колокация также способствует командному обучению — сущность непрерывного улучшения.
  • Долгоживущие команды — Команда должна оставаться вместе ‘навсегда’. Это может быть утопией, но Командам нужна стабильность, если вы хотите, чтобы они заботились о том, как они работают в качестве Команды. Любой, кто когда-либо был в настоящей долгоживущей команде, знает, что команды становятся лучше тогда, когда члены команды узнают друг друга и вместе учатся тому, как улучшить их совместную работу.

Команда управляет внешними зависимостями

Какие изменения это подразумевает для разработки крупных продуктов? Довольно серьёзные! Во-первых, каждой команде требуется чёткая цель, чтобы они знали свои границы. Создание клиентоориентированных фиче-команд помогает этому. Это приводит к общению между командами, ориентированному на код. Во-вторых, организации требуется четко дать понять, что команды самостоятельно отвечают за координацию своей работы с другими командами. Успех команды должен измеряться успехом всего продукта, чтобы избежать локальной оптимизации. Удаление официальных координационных ролей, таких как руководители проектов, делает прозрачным для команд, что координация является их ответственностью. В-третьих, создайте систему непрерывной интеграции для всего продукта. Это создаст доступность информации необходимую командам для того, чтобы они могли координировать свою работу. Здоровье продукта должно быть всегда доступно для всех.

Многопрофильные Работники

Обучение является основной активностью в разработке продуктов. В долгосрочной перспективе снижение обучения снижает эффективность — не увеличивает её. Эрик Шерман (Erik Sherman) пишет в журнале Fortune:
Сотрудники будут награждены за знания и адаптивность. Специализация уходит, новый стиль дженералистов входит в моду. Самыми востребованными работниками будут гибкие люди, которые могут с лёгкостью переходить от одной функции к другой, интегрируя различные дисциплины и точки зрения… людям потребуется способность не только выучить принципиально новые навыки, но и отучиться от устаревших способов.

Команда принимает решение

Самоуправляемые команды принимают решения сами. Однако много людей выросли в среде “командуй-и-контролируй”, где менеджмент принимал решения за них. Скрам-мастер может помочь команде понять, как принимать решения. Командное соглашение о принятии решений важнее, чем какой-то конкретный метод принятия решений.

Протокол Разрешитель [MM02] является простым и быстрым путем принятия согласованных решений.

Конфликты нужны команде

Совместная работа людей создаёт конфликты. И это не плохо. Но конфликты нужно разрешать. Неразрешённые конфликты негативно влияют на производительность команды и создают дисфункциональную атмосферу [Lencioni02]. Разрешённые конфликты, с другой стороны, создают знания и доверие, которые оказывают позитивное влияние на производительность. Конфликт является для команды возможностью улучшить свою производительность, и следовательно, это хорошо.

“Распределение ресурсов” по фазам не требуется

Скрам не является водопадным процессом. Здесь нет фаз. С самоуправляемыми, кросс-функциональными, долгоживущими фиче-командами он выравнивает “потребность в ресурсах” во время всего релиза. Одни и те же люди остаются в работе над релизом от начала до конца.

Заключение

Эти разные — но доказавшие свою эффективность — концепты команд являются причиной серьёзных изменений в организации.

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

Рекомендуем к Прочтению

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

  • Leading Teams, by Richard Hackman.
    Профессор Гарварда Ричард Хэкман - давний исследователь команд. Его книга в настоящее время является нашей любимой книгой, связанной с командами. Он уделяет большое внимание оказанию помощи руководству в переходе на командную работу.
  • Leading Self-Directed Work Teams, by Kimball Fisher.
    В этой книге особое внимание уделяется смене ролей, когда человек становится лидером самоуправляемой команды.
  • The Wisdom of Teams, by Jon Katzenbach and Douglas Smith.
    Это, пожалуй, самый популярный материал по командам, который, безусловно, стоит прочитать.
  • Пять пороков команды Патрика Ленсиони.
    Написана в жанре романа, хорошо покрывает необходимость конфликта в командах.

Кросс-функциональные команды описаны в основном книгах о продуктовой разработке. Некоторые из них:

  • Fast Cycle Time, by Chris Meyer.
    Это по-настоящему классика продуктовой разработки, которая рассказывает о кросс-функциональных (многофункциональных) командах в деталях.
  • Revolutionizing Product Development, by Steven Wheelwright and Kim Clark.
    Другая книга из классики продуктовой разработки; содержит одну главу о кросс-функциональной интеграции.

Несколько книг о командах разработки:

Перевод статьи осуществлён Кротовым Артёмом) и Романом Лапаевым.