Команда это все кто числится в штате компании верно или нет

Разберемся с тем, что дает компании команда, какую роль играет команда для всей организации и для каждого отдельно взятого сотрудника.

Чем командная работа отличается от обычного взаимодействия между людьми

В каком случае люди взаимодействуют в рамках бытовых или рабочих ролей и условий, а в каком происходит командное взаимодействие? С какого момента на работе начинает происходить работа с командой и что такое команда?

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

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

Главные черты команды

Определим главные черты команды. Это:

• Совместная работа. Это не просто пазлы, которые по каким-либо признакам совпадают, это единый организм, который движется, и движется сообща в одном направлении. Члены команды что-то делают вместе, а не объединены только территориально и по другим признакам. Каждый участник этого движения взаимодополняет другого.
• У каждого участника свое позиционирование. Оно не стихийно и не меняется бесконечно, это продуманная и установленная в команде роль. За ролью закрепляются границы ответственности, задачи, которые известны другим членам команды. Работа в команде предполагает взаимодействие с учетом установленных ролей.
• Коммуникация. Каждый участник открыт с другими, нацелен на решение, а не на конфликты. Если это не так, команда распадается. Или из нее уходит тот, кто не доверяет и не готов открываться группе.
• Автономия. Команда представляет собой некую автономную единицу в какой-либо структуре. Она располагает своими собственными способами взаимодействия с «внешним миром» и другими командами, но никто не может извне повлиять на процессы, происходящие внутри команды.
• Синергия. Совместная работа дает особый синергетический эффект. Это когда полученный результат намного превышает сумму результатов каждого участника, если бы работа делалась каждым в одиночку.

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

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

Принципы и особенности команды

Исследователям удалось определиться с принципами команды. Это:

• Единая цель.
• Взаимодополняющие навыки.
• Строгие требования к продуктивности.
• Взаимоответственность.
• Небольшое количество людей.

Было доказано, что чем меньше команда, тем она продуктивнее. Команды до 5 человек работают быстрее. Большая команда более функциональна. Но чтобы она держалась и эффективно функционировала, важно профессионально установить роли и правила внутри команды.

Почему команда лучше, чем сотрудничество

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

В чем конкретно эффективность команды?

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

Эффект синергии возможен только в команде, значит, совместная работа команды способна дать больше эффекта компании, чем если каждый будет работать сам по себе.

Команда менее подвержена внешнему влиянию, а значит, крепче.

В команде остаются только взвешенные идеи, поскольку каждая из поступающих тщательно обсуждается и поддается многостороннему анализу. Обсуждается как вся идея, так и ее детали, поэтому меньше вероятности появления ошибок.

В командной работе устраняют ошибки, поскольку все они более заметны, чем при работе одному. За собой труднее замечать недочеты.

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

Повышение эффективности каждого

Команда обладает еще одним удивительным эффектом – работа в команде способна увеличить эффективность отдельного сотрудника. Хорошая команда способна повысить эффективность отдельного участника не только на время командной работы, но и вне команды. Вот почему так эффективны тренинги по работе в команде и игры на командообразование – после них каждый становится эффективнее. Опыт пребывания в команде настолько силен, что для эффекта бывает достаточно даже нескольких часов командообразующей игры.

Теперь только представьте, насколько лучше, эффективнее и гармоничнее становится человек, который постоянно работает в команде. 

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

Умение работать в команде является положительной характеристикой сотрудника. Такие специалисты высоко ценятся на рынке труда.

В свете выше сказанного, командная работа – это с одной стороны мощный инструмент для достижения компанией своих целей, с другой – средство повышение личной эффективности каждого участника команды.

Командная работа и общий успех

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

Стив Джобс и компания «Pixar»

Джобс приобрел себе небольшую компанию в конце 90-х. Компания производила компьютеры. Офис находился в здании, где было три отдельных помещения – для аниматоров, компьютерщиков и руководителей. Казалось бы, все удобно. Но Джобс не успокоился, пока не нашел способ разместить всех в одном помещении. Поместив всех в одно открытое пространство, где они могли бы общаться и совместно решать задачи, Джобс не прогадал, а попал в самую точку. Коллеги почувствовали себя одним целым, способным создать нечто великое. Что из этого получилось – известно всем.

The Rolling Stones: у каждого своя роль

Легендарные The Rolling Stones не теряют популярности уже более 50-ти лет. Своим секретом музыканты делились не раз – он в командном подходе. Перед каждым туром группа готовится вместе на протяжении двух месяцев. Подготовка представляет из себя постоянные интенсивные репетиции. На репетициях участники отрабатывают общий ритм. Кейт Ричардз делился, что он следит за играющей рукой Чарльза Уоттса, чтобы поймать момент, если он сбивается, подает знак Ронни Вуду, что нужно подстроиться под ритм. Каждый знает свою роль и каждый дополняет друг друга.

Интересное наблюдение от Google

Однажды в Google провели исследование секретов успеха идеальных команд компании и к своему удивлению пришли к выводу, что сила не в подборе кадров, как все полагали, а в присутствии чувства психологической безопасности каждого участника команды. Каждый сотрудник должен верить в то, что команда – безопасное место для возможности чувствовать себя комфортно, быть открытым, доверять, обсуждать идеи и черпать вдохновение друг у друга.

Правила участников команды

В команде существуют правила, благодаря которым команда существует и остается командой. Рассмотрим основные:

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

Плюсы и минусы командной работы

У командной работы есть свои преимущества и недостатки. О преимуществах мы уже говорили, а недостатки не упоминали. Соберем теперь вместе плюсы и минусы.

Преимущества командной работы:

• Команда способна выполнить задачи, которые не выполнит один человек.
• Команда – это уже гарантия того, что интересы всех сторон учитываются.
• Команда снижает риск принятия ошибочного или случайного решения.
• Команда снижает риск пропадания из поля зрения важных фактов.
• Команда исключает «производственную слепоту» (так называемые «мертвые зоны»). Если один не заметит, обратит внимание другой.
• Сотрудника, имеющего опыт работы в команде, ожидает меньше проблем и трудностей, связанных с взаимодействием между людьми или другими подразделениями компании.
• Команда укрепляет навыки коллегиального сотрудничества.
• Умение работать в команде – ценная квалификация.

Есть у командной работы и недостатки:

• Работа в команде может требовать дополнительных затрат времени. Период притирания занимает время.
• Работа команды более медлительна, особенно при большой численности команды. Вся команда испытывает определенные трудности при сборе в назначенное время и т.д.
• Дискуссии отнимают время, хотя и являются ценными. Улучшить ситуацию может владение навыками коммуникаций и техникой ведения дискуссий.
• Работа в команде может задерживать решения, поскольку они принимаются после продолжительных дискуссий.
• Анонимность результатов иногда снижает мотивацию трудиться.
• Работа в команде дополнительно к основной деятельности может стать серьезной избыточной нагрузкой.
• Иногда команда создает ошибочный результат, иногда расходует время неэффективно или так и не приходит к совместному решению. Известно выражение: «Верблюд – это лошадь, нарисованная командой». Но подобное происходит при отсутствии у членов команды соответствующих навыков. Ситуация исправляется тренингами, деловыми играми или работой с коучем.

Специалисты ManGO! Games могут сформировать факторы успеха для командной работы в вашей компании, разработать тренинги, а также укрепить командный дух в ходе деловой игры. С примерами работ можно ознакомиться в портфолио, а с нашими тренерами – на ютуб-канале.

Восточная пословица:
Сколько не говори слово «халва», во рту слаще не станет.

Тоже самое можно сказать про команду.
От частого употребления этого слова группа в команду не превратится.

Основные темы:

Введение

Слово «команда» является одним из самых популярных в бизнес-языке. Возможно, это связано с тем, что мы с удовольствием смотрим и восторгаемся игрой лучших команд в футболе, хоккее, волейболе, и других игровых видах спорта.

В разных статьях, книгах и интервью упоминаются разные сочетания со словом «команда».

Например:

Учитывая, что все начинается «с головы», в статье будет сделан больший акцент на организацию совместной работы топ-команд.

Ситуация

О командах в бизнесе говорят гораздо чаще, чем есть их наличие внутри компаний на самом деле.

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

Однако, когда начинается коллективная работа выясняется, что команды, как таковой нет. Есть группа людей, которая объединена некоторыми критериями как, например, работа в одной организации или внутри одного подразделения.

На основе проведенного опроса Институт Адизеса выделил несколько управленческих проблем. Две из них имеют прямое отношение к построению бизнес-команд.

Проблемы
A. У компании нет четких стратегических целей.
B. Постоянные конфликты в команде топ-менеджеров.

К сожалению, это реальность большинства российских компаний.

Что отличает топ-команду от группы в бизнесе?

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

Предельная численность составляет по разным источникам от 10 до 15 человек. Группы создаются легче. Можно набрать новое подразделение, посадить их в одной комнате и считать, что группа уже образована. У этих людей есть критерий, который их отличает от других сотрудников компании.

Прежде, чем говорить об отличиях группы от команды, я предлагаю определение команды, с которым всегда работаю.

Основные характеристики топ-команды

Основные характеристики группы

Какие проблемы мешают создавать топ-команды?

Вопрос:
Что может объяснить расхождение между частотой использования слова «команда» в выступлениях руководителей и реальным положением дел с существованием топ-команд?

На мой взгляд, это связано со многими причинами, в том числе:

Создание высокоэффективных команд требует серьезных усилий со стороны руководителя. Главная проблема – отсутствие понятных критериев, на основании которых можно стать членом команды.

Группа есть. Что мешает членам группы превратится в команду?

Дополнительные причины, затрудняющие превращение группы в команду:

«Пять пороков команды»
Патрик Ленсиони

Что нужно делать, чтобы сформировать топ-команду?

Возьмем в качестве примера спортивные команды.

Для формирования футбольной команды, например, делают:

Что можно взять из их опыта для подготовки топ-команд:

Частая ситуация (из опыта работы с разными руководителями)

В дополнение к причинам, препятствующим созданию топ-команд и изложенным выше, хочу отметить еще один момент.

Для создания топ-команды нужны:

Я сознательно поставил деньги на последнее место, потому что даже при их наличии, часто не хватает времени. Все время забирает «текучка».

Периодически слышу фразу: «Давайте сделаем это быстро»
По моему опыту, время не менее важный фактор для формирования команды, чем деньги.

Принципиально важно!

Основа формирования топ-команды – совместная мыслительная деятельность. Мне нравится фраза одного из героев сериал «Диверсанты»
«Мысль опережает действие»

Согласование мыслей ведет к согласованию действий.

Согласованные действия ведут к целостному образу организации.

Целостный образ определяет осознанное позиционирование компании и долгосрочные конкурентные преимущества.

Осознанное позиционирование и конкурентные преимущества – ключевые факторы, обеспечивающие устойчивый рост ключевых финансовых показателей.

В общем все как в стихотворении «Дом, который построил Джек» (С. Маршак)

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

Это создает основу для принятия согласованных решений и приверженности выбранным решениям.

Что дает использование формата стратегических сессий:

Почему нужно заниматься формированием топ-команд в бизнесе?

Вопрос.
Если создание топ-команд требует серьезных усилий и вложений, то может быть стоит ограничиться в работе группами?

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

По разным причинам. Например.

До сих пор храню высказывание одного собственника относительно игры сборной России по футболу, проигравшей очередной важный матч. Это было написано очень эмоционально, потому что он увидел параллели между сборной по футболу и поведением топ-менеджеров в своей компании.

«Знаете почему наша сборная по футболу так бесславно сыграла? Они (наши звезды-футболисты) не знают гимн и не поют его, им чихать на флаг, у них нет традиций, им плевать друг на друга, они встречаются только на площадке, им до фонаря их страна( вернее, она не их, они себя с ней мало ассоциируют) и (!!!) они играют исключительно за деньги — им не стыдно за любой результат, а заработают они раньше или позже в каком-либо ином месте/клубе, это они знают твердо.

Так вот, это наша компания сегодня. И никакие звезды, и их успешные в других компаниях коллективы не сделают нас победителями счастливыми, богатыми и здоровыми. Мы все время будем жить с оглядкой и затыкать собой повсюду возникающие бреши, и уж точно не сможем масштабироваться, если мы не будем системно решать ровно такие же задачи, которые не были решены в нашей сборной по футболу с этим перекормленным чужеродным тренером.

Нам нужны объединяющие долгосрочные цели, культура и единомышленники-профессионалы …»

Читайте так же:

Что такое команда? И при чем тут рабочая группа?

Часто в деловом разговоре можно услышать фразы и выражения типа «Наша команда работает на тем, чтобы…», «Команда наших разработчиков создала…», «Команда менеджеров по продажам сумела…» и так далее. Люди используют слово «команда», когда хотят показать, что у них работает целый штат сотрудников, и этот штат делает что-то очень нужное и важное. И авторы этих высказываний, как показывает моя практика, чаще всего имеют в виду не команды, а рабочие группы, состоящие из людей, работающих над какой-то задачей.

Многие действительно не понимают различия между командной и рабочей группой, используя специфический термин не по назначению, порождая некторое несоответствие. А Вы знаете, в чем разница между рабочей группой и командой? Скорее всего интуитивно догадываетесь. Попробую описать основные отличия в этой статье.

Приведу несколько определений команды, которые можно встретить у различных специалистов в сфере бизнес-моделирования и консалтинга:

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

М. Армстронг

Команда — это небольшое количество человек (чаще всего 5-7, реже до 15-20), которые разделяют цели, ценности и общие подходы к реализации совместной деятельности и взаимоопределяют принадлежность свою и партнеров к данной группе. Кроме того, члены команды имеют взаимодополняющие навыки, принимают ответственность за конечные результаты, способны исполнять любые внутригрупповые роли.

И. Салас, Р. Берд и С. Таненбаум

Команда — это небольшая группа людей, взаимодополняющих и взаимозаменяющих друг друга в ходе достижения поставленных целей. Организация команды строится на продуманном позиционировании участников, имеющих общее видение ситуации и стратегических целей и владеющих отработанными процедурами взаимодействия. Команда проходит эволюцию от рабочей группы (Working Group), которая создается для выполнения того или иного вида деятельности, до команды высшего качества (High Performance Team).

Катценбах и Смит

Рабочая команда — это взаимозависимая группа людей, которые совместно отвечают перед организацией за конкретные результаты.

Сандстром, ДеМюсе и Фатрелл

Рабочие группы обладают похожими характеристиками. Вот какое определение рабочей группы удалось найти:

Рабочая группа — двое или более людей одинаковых или различных профессий:
— работающих совместно и согласованно для достижения целей по выполнению производственного задания, оказанию услуг; и
— несущих общую ответственность за результаты работы.

Глоссарий.ru

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

Лей Томпсон

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

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

Хоть они работают в одной компании, собираются вместе и обсуждают общие дела, но для них гораздо важнее решить в первую очередь свои задачи, за которые они отвечают. А задачи и работа других менеджеров их волнуют в гораздо меньшей степени, т.к. эти результаты на работу их собственных подразделений никак не влияют. Так, начальник отдела маркетинга может хорошо относится к коммерческому директору, советоваться с ним, но не вступать в командное взаимодействие ни с ним, ни с другими менеджерами. Хотя бы потому, что у них нет совместных рабочих проектов.

Рабочие группы — достаточно стабильное образование если поддерживать его какими-то внешними источниками. Например, у таких групп часто есть формальный лидер, который задает общее направление деятельности. Так же в рабочих группах сами участники, зачастую, не имеют полномочий к самостоятельному управлению своей работой. Присутствует кто-то, кто говорит им что и КАК делать.

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

И самое главное, деятельность каждого члена такого коллектива зависит от работы его напарников. Каждый член команды понимает, что от его действий зависит успех ВСЕГО дела. Поэтому, при таком взаимодействии бить баклуши — не лучший вариант. Хорошо организованная команда, при прочих равных, в разы продуктивней хорошо организованной рабочей группы.

В следующих статьях я планирую еще больше раскрыть тему команды на живых примерах, которые я наблюдал в своей жизни. Это, кстати, уже начал делать Сергей Полонский (президент Mirax Group).

Прочитайте серию статей этого блога, в которых я описываю типы бизнес-команд.

© Бизнес-тренер Михаил Графский

Метки: командообразование, психология

Что такое команда и чем она отличается от не команды

Согласитесь, прежде, чем делать команду, важно в самом начале для себя определить, а что такое команда. От этого зависит и то, что построим в итоге.

Часто происходит путаница, когда под командой начинают понимать всю компанию. Мы разделяем эти понятия. Если говорится о компании целиком, то тогда это о командной корпоративной культуре. Вы не будете делать из всех сотрудников своей компании одну команду. Вы будете вводить в корпоративную культуру вашей компании компетенции командности. Т.е. создавать приоритетность совместной работы по отношению к индивидуальной.

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

Как правило, руководители делают малые команды, т.е. это могут быть команды проекта, Agile-команды, управленческие команды. Мы вывели такое определение малой команды.

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

Команда — это управляемо развивающаяся малая группа, которая проходит определённые этапы и постоянно совершенствуется для эффективного решения командных задач.

Ни одно определение — наше или то, которого вы будете придерживаться, не является абсолютно полным. Поэтому мы добавили более подробное описание команды к основному определению. Это внесёт большую ясность в понимание, что такое команда и чем она отличается от всех других объединений.

Основные черты командной работы.

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

Вам не нужно подбирать «совершенных сотрудников» под командные задачи. В команде они будут дополнять друг друга. В каких-то ситуациях, и заменять друг друга, если это будет возможно. Способность самостоятельно перераспределять внутригрупповые функции и гибко их менять — важные показатели командной работы.

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

Что командами не является?

Это важно, так как мы часто слышим от руководителей такие высказывания: «неэффективная команда», «эта команда работает только на себя», «слабая команда», «сотрудники в этой команде не активны и не самостоятельны».

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

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

Основные признаки некомандного поведения

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

Например, у сотрудника может быть личная цель — материальное благополучие при минимальных усилиях на работе. Как только от него начинают требовать эффективной работы, он прибегает к разным способам ухода от этого. Такой сотрудник может прибегать к сплетням, подставам по отношению к тому, кто требует от него работы. Он может показывать бурную деятельность, не приводящую ни к какому результату. Результативность его отдела и компании в целом его мало интересует.

• Нет общегрупповой ответственности. Сотрудники тяготеют передать ответственность за результат руководителю или переложить на других сотрудников или другие подразделения.
• В коллективе отсутствует самоорганизация по отношению к рабочим задачам. Сотрудники ждут приказаний и постановки задач от руководителя. После этого они ожидают распределения функционала и нагрузок. При этом те же сотрудники могут очень эффективно организовываться для проведения совместного отдыха, праздников и т.п.
• Общение сотрудников поверхностно в рамках принятых норм и правил поведения. Правила могут быть привнесены «сверху» — руководством. Им же они и контролируются. Негласные нормы поведения вырабатываются внутри коллектива по принципу наиболее комфортного выживания в создавшихся условиях.

Иногда правила принимаются группой путём голосования. Любое голосование — это выбор с наименьшей личной ответственностью и, как правило, не лучшего, а более безопасного решения.

В последнее время мы всё чаще сталкиваемся с декларацией руководством о переходе на Agile ценности в компании, но это остаётся только на словах. Например, в одной известной компании руководитель утверждал, что они уже работают по Agile, но в это же время говорил о проблемах в коллективе — «нам нужно выработать у сотрудников навыки открытого обсуждения собственных ошибок». Эта фраза показывает, что переход на новые ценности в компании не осуществлён. Возможно, они в стадии перехода. А может быть пребывают в своих иллюзиях о разделяемых персоналом новых ценностях.

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

Надеемся, вы уже сделали вывод, есть ли у вас команда.

Читайте также

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

Собрать несколько человек и сказать: «Теперь вы команда, ждем от вас результата», не получится. Людей нужно организовать, дать им вменяемую цель, мотивацию и решать возникающие проблемы.

Как раз об этом расшифровка доклада Евгения Федореева на TeamLead Conf. В докладе Евгений поэтапно описал процесс организации эффективной команды разработки в Banki.ru: про найм, общение, обмен знаниями и развитие разработчиков и тестировщиков внутри коллектива и отдела.

О спикере: Евгений Федореев (hardj) занимается веб-разработкой 15 лет, их них 6 — в позиции тимлида, а сейчас руководит направлением разработки новых проектов Banki.ru.

Что такое Banki.ru?

Контекст компании, чтобы знать, о каком опыте пойдет речь. Banki.ru — это крупнейший независимый финансовый портал Рунета с ежемесячной аудиторией больше 8 миллионов уникальных пользователей.

В IT-отделе работает 50-70 человек, поделенных на 7 команд разработки. Вся разработка ведется in-house, удаленных разработчиков нет, поэтому в соответствующих процессах и метриках нет необходимости.

Основная задача команды разработки

Когда готовился к докладу, я задавал людям вопрос:

— Какая цель у команды разработки?
— Разрабатывать.
— Что это значит? Если человек сидит, рефакторит, не приносит пользы, не решает бизнес-задач — это тоже разработка?
— … Нужно эффективно разрабатывать.

Эффективность разработки

Понятие эффективности для менеджера одно, а для разработчика другое.

Для управленца эффективная разработка — прогнозируемая: когда известна дата релиза фичи или срок выполнения задачи, чтобы провести какие-то бизнес-мероприятия.

Для разработчика — это работа с техническим долгом. Это одна из болей, так как на работу с тех. долгом, на рефакторинг, на исправления и улучшения дается очень мало времени.

Следующий критерий эффективности — минимальное количество багов. Можно было бы написать, что критерий — полное отсутствие багов, но мы знаем, что такого не бывает. Кроме того, обидятся тестировщики, ведь они будут не нужны.

Заделы на будущее. Я специально не написал «продуманная архитектура». Заранее углубляться и продумывать архитектуру — зло, поэтому в разработке должен быть задел на будущее, но без фанатизма.

Любой другой критерий, который есть у каждой команды.

Процесс разработки

Строить процессы разработки в Banki.ru мы начали после того, как компания стала развиваться и расти. Появились новые партнеры и проекты, и 6-9 backend-разработчиков не хватало. Мы пришли к тому, что нужно выстроить процесс разработки и формализовать его, для эффективной работы.

Изначально у нас было 3 команды, в каждой по 3 бэкенд-разработчика и менеджер, который отвечал за части сайта. Backend-разработчики, кроме своей работы, еще верстали и подключали jQuery-плагины, так как в тот момент на фронтенде было мало людей.

Мы взяли двух фронтенд-разработчиков и еще двух тестировщиков, чтобы жить без багов и считали, что этой конфигурации будет достаточно.

В идеальном мире процесс разработки должен выглядеть так.

• Project manager скидывает задачу в бэкенд-команду и они ее выполняют.
• Если нужна доработка — отправляют задачу фронтенд-команде.
• После доработки фронтенд отдает ее в QA.
• Багов нет? — В продакшен.

Мы предположили, что мир не идеален, и QA будут возвращать задачи, так как баги присутствуют в любой разработке, и добавили еще две стрелочки.

После обновления схемы, мы решили, что все круто и стали по ней работать — проводили планирование спринтов, а бэкенд-команды сами ставили задачи в план. Поработали 2 месяца и поняли, что что-то не так.

Наша схема трансформировалась. Задачи прыгают, как мячик в пинг-понге: от QA к фронт и бэк разработчикам, и даже долетают до менеджеров.

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

Как сократить время доставки?

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

Планированием у нас занимались три бэкенд-команды. Мы привлекли к планированию тестировщиков и фронтенд-разработчиков, но на 3 команды было всего 2 фронтенд-разработчика и 2 тестировщика. Часто звать их не получалось, потому что кому-то надо работать.

Поделили задачи отдельно на frontend и backend, чтобы отдавать их в разработку параллельно, быстрее тестировать и не ждать всю цепочку.

Мы попробовали все решения. В результате время сократилось, но все равно нас не устраивало.

Мы думали, что делать дальше. На рынке много компаний и практик, и мы стали изучать, смотреть, копать и дошли до feature-team.

Feature-team

Это когда в команде есть все полный набор людей для выполнения задачи:

• бэкенд-разработчики.
• фронтенд -разработчики.
• QA-разработчики.

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

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

Проблемы feature-team

На тот момент у нас появилось 6 проблем.

• Bus-factor.
• Долгое планирование. Для планирования мы выделяли полдня или больше: разбирали задачи, уходили на обед, потом опять разбирали. Когда планирование заканчивалось, никто уже работать не мог и не хотел — день потерян.
• Незакрытые спринты. Это серьезная боль — большинство задач в спринтах не доходило до колонки «Выполнено».
• Разный характер задач у команд.
• Появление новых команд.
• Обмен опытом среди команд.

Проблемы есть, будем решать.

Bus-factor

Изначально каждая команда состояла из фронтенд-разработчика, тестировщика и трех бэкенд-разработчиков. Мы взяли в штат дополнительных фронтенд-разработчиков — продублировали роли.

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

Фронтенд-разработчики ввели кросс-командное code-review, когда один разработчик решает в одной команде задачу и отдает ее на review в другие команды, и после минимум двух утверждений задача идет в тестирование.

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

Долгое планирование

Мы разбирали задачи на планировании. В момент спринтов все работали и кодили, а на планировании чуть ли не в первый раз открывали задачи и разбирались, что надо делать, тестировщики уточняли «definition of done», чтобы понять как тестировать задачу.

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

Мы предложили менеджерам описывать задачи подробнее, но не слишком, чтобы не закопаться в тонне документации.

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

Незакрытые спринты

Это боль. Может у кого-то они закрываются, а у нас на тот момент — нет.

Мы решили сократить емкость спринта с 10 рабочих дней, до 8-ми. Думали, что будем планировать на 8 дней, а 2 дня оставим тестерам.

В реальности оказалось, что когда разработчик видит меньше задач, то он их и выполняет неспешно. На 20% меньше задач в спринте ничего не дали.

В начале спринта, пока есть время, тестировщик составлял тест-кейсы. В теории, в начале спринта, пока разработчики работают, у тестера нет задач. Мы договорились, что в это время тестировщик может пройти все задачи, составить тест-кейсы, а когда задача придет на тестирование, — он прогонит ее по подготовленным тест-кейсам, и сократит время на тестирование. Глобально это не помогло, хотя время немного сократилось.

Сокращение емкости спринта и загрузка тестера не помогли и мы думали, как все-таки решить проблему. В тот момент нам на глаза попалась книга про цель и несколько практик Максима Дорофеева. Мы поняли, что впихнуть «невпихуемое» не получится и стали планировать спринт от узкого места — от тестирования. На планировании тестировщик ставил оценку, емкость спринта рассчитывали от него, и набирали задачу в спринт под тестера.

Класс! Мы пошли к менеджерам продавать эту идею:

— Мы решили планировать от тестеров. Спринты будут закрываться, будет круто!
— Подождите, а что в этот момент будут делать свободные разработчики? Задач будет меньше, у них появится свободное время!
— Ты хочешь, чтобы спринты закрывались, чтобы разработка была прогнозируемая или главная цель людей занять?
— Нет, все-таки прогнозируемая разработка. Давайте спринты закрывать.

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

Оказалось, что разработчики могут делать очень много дел, когда они свободны.

А именно: работать с тех. долгом. В команде всегда есть общий тех. долг на отдел. Эти задачи можно брать в работу и тестировать. Как правило, тех. долг — это системный рефакторинг. Для этих задач нужно проводить регрессионное тестирование, и не всегда это должен выполнять тестер команды. Отдел тестирования выделил специальных тестировщиков, которые проводили регресс, в том числе и руководитель отдела тестирования. Задачи по тех. долгу отдавались в тестирование другим сотрудникам и наши тестировщики не страдали.

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

Помогать другим командам. В тот момент у нас еще практиковалась помощь другим командам, в которых аврал, кто-то в отпуске или заболел, а проект горит. Обособленные частные задачи можно брать и помогать другим командам.

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

Разный характер задач у команд

У нас есть продуктовые команды, которые делают что-то новое. У них двухнедельное планирование, спринты, длинные проекты и к релизу они приходят через 1-2 месяца или больше.

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

Мы решили поговорить с PM и с бизнесом:

— Ребята, у нас Agile, Scrum, спринты, процессы — давайте не будем вкидывать новые задачи, а будем прогнозируемо разрабатывать.
— Смотрите, мы продаем лэндинг, его надо сделать через 3 дня. Нам за это платят миллион. Какие процессы? Деньги надо тоже зарабатывать!

Миллион нас убедил. Мы стали думать дальше.

Решили сократить спринты до недели — так мы сможем быстрее реагировать. Тоже не пошло, потому что планировать в тот момент для этой команды совсем не получалось.
Дальше решили не планировать спринты, а работать по Kanban вместо Scrum: пришла задача, взяли в работу, выпустили. Это сработало. Команда работала продуктивнее, потому что изначально понимала, что планирования нет, а есть только задачи на выполнение.

Чтобы улучшать процессы в команде и получать обратную связь, мы стали проводить ретроспективы каждые 2 недели: команда собиралась, обсуждала, что прошло хорошо, что нет, какие плюсы и минусы, и работали с этим.

Появление новых команд

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

Можно было взять тот же Kanban, чтобы разработчики выполняли задачи, как могут, но это продуктовая команда, ее надо учить. Мы решили — пусть они учатся планировать и оценивать задачи, но сократили спринт до 1 недели.

Увеличим время до 2 недель через 1-2 месяца, когда команда притрется, войдет в общую продуктовую работу, наладит процессы и разработчики смогут нормально оценивать задачи.

Обмен опытом между командами

Внутри команды разработчики и тестеры общаются между собой и обмениваются опытом, но этот опыт не обновляется, потому что команда «варится в себе». Новому опыту неоткуда взяться.

Мы стали думать — что с этим делать, и ввели еженедельные встречи тимлидов. Цель встреч — перенести опыт от одной команды к другой через тимлидов.

Первые встречи проходили так:

— Здравствуйте, меня зовут Евгений, мы сейчас пилим новости.
— Круто!

Следующая встреча:

— Здравствуйте, меня по-прежнему зовут Евгений, мы продолжаем пилить новости.
— Ок.

Ничего неординарного не происходит.

Третья встреча: Здравствуйте… И все то же самое.

Мы поняли, что надо менять формат. Почитали книги о проведении совещаний и
ввели фиксированную повестку.

Теперь у нас есть wiki-страничка с датами проведения тимлидских встреч, в которую в течении недели набрасываем проблемы и задачи для обсуждения.

Плюсы такого решения

• Ко встрече тимлиды готовятся, так как знают повестку дня, и понимают, что будет обсуждаться.
• Wiki-страница доступна всем разработчикам. Каждый сотрудник может узнать тему обсуждения, поучаствовать в процессе и поднять свои вопросы. После встречи мы фиксируем решение в комментариях, которые тоже доступны.
• Если какая-то задача не решилась по прошествии 1-2 месяцев, то можно посмотреть в архиве встречи, чем решилось обсуждение задачи и попинать команду или тимлида за невыполнение.

Формат встреч нам понравился и мы стали их проводить регулярно.

Мы ввели кросс-командное code-review. Это некий обмен опытом, который уже практиковали фронтенд-разработчики, а позднее и ребята из бэкенд. Отдавать весь код на кросс-командное code-review не обязательно, достаточно только важных вещей, например, общие библиотеки или общие куски кода. Дляcode-review мы выбирали только заинтересованные команды, не было обязательного approve.
Возникают ситуации, когда соседняя команда, которая занимается банками, просит доработать функционал — добавить поля, а мы занимаемся кредитами.Можно попросить другую команду, но у них свой план и непонятно, когда они выполнят просьбу, а ждать нельзя. В такой ситуации мы помогаем соседней команде, но на code-review отдаем другой.

Бывает так, что разработчики просят перевестись на другое направление или сменить технологию. Например, у нас один сотрудник год занимался кредитными картами и просит сменить область, а другой хочет поменять технологию с UI на Symfony. По договоренности мы организуем переход разработчиков между командами.

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

Все было круто. На посиделках команды рассказывали, чем занимаются, что нового. Например, с одной из команд у нас возникло непонимание, никто не знал, чем она занимается. На пятничной встрече команда рассказала про свою работу, показала аналитику и все поняли смысл их работы. Фронтенд-разработчики рассказывали как происходит сборка, обсуждали общетехнические темы, например, как пользоваться Debugger’ом в PHPStorm, как происходит деплой.

А потом темы по разработке закончились, мы перешли на психологические и история стала угасать. Как дальше простимулировать разработчиков что-то рассказывать?

И тут мы вспомнили про KPI! Давайте каждого разработчика научим выступать и включим в его KPI 2 доклада за полгода на пятничных посиделках. Мы думали, что идея крутая и все будут выступать.

Оказалось, что после введения KPI, разработчики перестали делать доклады. К обязательным выступлениям возник негатив. Программисты решили пожертвовать 100% выполнением KPI, лишь бы не делать добровольно-принудительные доклады.

Выводы

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

• Подстраивайтесь под изменения и не зацикливайтесь на том, что принято, смотрите на изменения и выбирайте лучшие практики для работы с командой. Если разработчики не могут работать по Scrum —работайте по Kanban, чтобы все были довольны и счастливы.
• Постоянно контролируйте и изменяйте процессы. Как тимлиды, вы должны контролировать процессы в команде. Директору уже не до этого, а разработчикам пока не до этого. Смотрите, что происходит, улучшайте обстановку. Кроме вас это никто не сделает и тогда вы построите команду, Которая эффективно выполняет свои функции.

Принципы эффективной команды

Каждый член команды — самостоятельный сотрудник.

Мы учим людей выполнять задачу полностью. Например, когда у человека не хватает требований или доступов, мы хотим, чтобы он мог найти эти данные сам: пойти к админами, к PM, попросить логин или пароль.

Задача должна быть сделана одним человеком — если ты взял ее на себя, то должен довести до конца.

Бывали случаи, когда разработчик говорит:
— У меня нет паролей на интеграцию с партнерами.— ОК, напиши письмо или скажи PM.
Сказал PM и опять сидит день или два.
— Вася, что случилось?— Я PM написал, а пароля все нет.

Мы пришли к тому, что человек должен дожимать, чтобы как можно быстрее получать необходимые данные.

Важно общение внутри команды. Меньше формальностей.

Так как мы все работаем в одном офисе, важно минимизировать формальности внутри команды. Есть инструменты вроде Jira или Slack, которые помогают общаться с удаленными работниками по интернету, а у нас люди общаются между собой лично, решают и обсуждают проблемы сразу. Мы даже ушли от еженедельных Scrum-митингов, потому что они не нужны.

Когда у нас появляется проблема, мы ее сразу обсуждаем и решаем.

Тимлид поддерживает единство в команде.

Тимлид следит за настроением в команде и решает проблемы. Например, у нас один разработчик работал год. Мы заметили, что команда перестала с ним общаться. Человек сидит, что-то делает, а к нему никто не подходит — это уже сигнал, — что-то не так. Когда люди создали внутри команды чат для обмена сообщениями, сигнал вопил как пожарная сигнализация. Разработчик спрашивает:

— А что происходит?
— Мы в командном чатике общаемся!
— Меня туда добавьте!
— А у тебя не Айфон, мы в iMessage!

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

Мы перевели его в другую команду, и всем стало лучше: взяли нового разработчика, который влился в команду, а предыдущий нашел себя в новой команде, проработал 2 года, и получал хорошие отзывы от тимлида.

Тимлид защищает команду от «внешних факторов».

Тимлид — это фильтр, который решает какую информацию извне допускать в команду, а какую нет.

Объясню на примере. В отделе маркетинга или в руководстве, всегда «лучше»знают, сколько времени уходит на разработку — им друзья рассказывали, что у себя фичу запилили за месяц, а наши полгода делают. Руководству не объяснить, что у нас куча подводных камней, которые решаем, но быстрее не можем. Когда такая информация доходит до команды, часть разработчиков демотивируется, уходит в себя.
Будьте фильтрами между внешней средой и командой. Всю информацию надо дозировать, чтобы не демотивировать разработчиков.

Сбор программы TeamLead Conf, которая пройдет 25 и 26 февраля в Москве, в самой жаркой стадии. О результатах расскажу здесь, когда уже все будет привязано к расписанию, а в рассылке будут приходить регулярные тематические подборки.