Тимбилдинг для сотрудников: примеры и сценарии командообразования
Зачем нужен тимбилдинг и как его проводить, чтобы решить задачи бизнеса, а не просто потратить деньги на корпоратив
Александр Старостин
Гендиректор компании «Технология игр», проводит тимбилдинги компаниям
Тимбилдинг — это не корпоратив, а мероприятие, которое помогает сотрудникам стать командой не на словах, а на деле. Сплоченность и доверительные отношения между коллегами в итоге помогают бизнесу зарабатывать больше: сотрудники быстрее справляются с задачами и без проблем делятся идеями с руководством.
В статье объясняем, какие задачи решает тимбилдинг и как самостоятельно организовать такое мероприятие, которое впишется в бюджет и поможет добиться поставленных целей.
Что такое тимбилдинг
В глобальном смысле тимбилдинг — это процесс, когда группа людей, которые работают в компании, становится командой. Вот чем разница между группой людей и командой.
| Группа людей | Команда |
|---|---|
| Все преследуют свои цели, которые редко пересекаются с целью компании | У компании и сотрудников есть общая цель, они вместе ее преследуют |
| Сотрудники готовы спорить о пустяках, даже если это мешает работе | Все слушают друг друга, а не ждут очереди заговорить |
| Никто никому не доверяет | Можно открыто высказывать свое мнение и говорить о чувствах |
| Конфликты длятся долго, мешают работе и часто связаны с личной неприязнью | Конфликты есть, но возникают идей и методов, а не личностей. Разрешаются быстро и не мешают работать |
| Отделы не помогают друг другу, даже если видят, что нужна помощь: «Не мои заботы» | Все готовы друг другу помочь |
Чтобы сделать из группы людей команду, руководители обычно пользуются такими инструментами:
Это не исчерпывающий список — можно делать что угодно, чтобы группа людей превратилась в команду. О каждом инструменте можно написать по книге или статье. В этом тексте мы сфокусируемся на тимбилдинге в узком смысле слова.
Тимбилдинг — это мероприятие, которое помогает группе коллег стать командой. Есть четыре критерия, как отличить тимбилдинг от других мероприятий:
Общая цель. Цель должна быть такой, чтобы достигнуть ее можно было только с помощью работы в команде.
| ❌ Нет командной цели | ✅ Есть командная цель |
|---|---|
| Сотрудники сидят в офисе и слушают лекцию Джима Кемпа. В перерыве общаются, пишут посты о вдохновении и пьют чай из пластиковых стаканчиков | Сотрудники делятся на две команды: каждая создает из себя мини-конвейер по передаче шариков от пинг-понга друг другу. Побеждает та, кто сделает это быстрее |
Участники развивают навыки работы в команде. Их еще называют софт-скиллы: эмоциональный интеллект, коммуникация, делегирование, переговоры.
| ❌ Все просто отдыхают | ✅ Развивают взаимопонимание |
|---|---|
| Сотрудники собрались в баре и пьют пиво, поют в караоке песню из заставки «Чип и Дейла» | Два человека садятся спиной друг к другу: у одного лист бумаги, у другого — инструкция, как сложить журавлика. Тот, что с инструкцией, голосом объясняет другому, как складывать журавлика |
Участники пришли на мероприятие по своему желанию. Они понимают, зачем нужен тимбилдинг, и готовы в нем участвовать.
| ❌ Люди не готовы участвовать и не понимают смысла мероприятия | ✅ Люди готовы участвовать и понимают, зачем им это |
|---|---|
| Руководители собирают всех сотрудников каждый рабочий день в девять утра в большом зале, где играет гимн компании, а на экране показывают портрет ее руководителя. Когда гимн кончается, сотрудники делятся на команды и участвуют в викторине. Если не прийти, можно получить выговор | Часть сотрудников пришла в пятницу вечером на пейнтбол по своей воле. Если бы они не пришли, никаких санкций бы не последовало |
Тимбилдинги проходят регулярно. Когда тимбилдинги проводят раз в год, это не помогает сформировать команду: между ними проходит много времени — сотрудники не смогут отточить навыки работы в команде. Другое дело, если тимбилдинг проходит каждую неделю или раз в месяц. Это помогает сформировать команду и научиться в ней взаимодействовать.
Когда нужен тимбилдинг
Тимбилдинг помогает в таких ситуациях:
Сотрудники незнакомы друг с другом. Когда открыли новую компанию или филиал, сотрудники еще не знают друг друга. Чтобы они быстрее поладили между собой и стали конструктивно общаться, можно провести тимбилдинг в «комнате побега».
«Комната побега»: сотрудников помещают в закрытое помещение, им нужно сбежать оттуда за час. Для этого нужно понять, как открыть замок, найти потайной люк или решить загадку, чтобы получить подсказку. Чтобы все успеть, сотрудникам придется довериться друг другу и делегировать задачи. В конце инструктор проводит разбор полетов.
«Комнаты побега» помогают медикам научится работать в команде
Ситуация. «Комнаты побега» изучали на кафедре неотложной медицинской помощи в университете Томаса Джефферсона в Филадельфии. Ученые хотели узнать, помогают ли такие комнаты медикам научиться работать в команде.
Метод. Для исследования они нашли «комнату побега» в городе и собрали ней в работников отделения неотложной помощи. Чтобы оценить эффективность такого тимбилдинга, ученые наблюдали за участниками и опросили их.
Результаты. Выяснилось, что такие тимбилдинги полезны для того, чтобы развивать командные навыки у медиков. Например, в работе над побегом из комнаты участники использовали те же навыки, что и в отделении неотложной помощи: переключение, делегирование, сбор данных, разработку плана.
Личностные конфликты у сотрудников. Конфликты — это нормально, когда они касаются решений в работе и не мешают делать все в срок. Плохо, когда конфликты касаются личностей сотрудников и мешают работать.
| ❌ Нездоровый конфликт | ✅ Здоровый конфликт |
|---|---|
| Ваня постоянно сплетничает о коллегах в то время, когда Женя завалена задачами. Женя в ответ может накричать на Ваню, а Ваня обижается и перестает делать свою часть работы по совместным задачам с Женей вовремя. |
В итоге конфликт идет месяцами, задачи всегда выполняют с задержками, и компания теряет этого деньги
В итоге Женя с Ваней нашли решение: протестировать соцсети в течение двух месяцев. Конфликт шел не больше недели, а компания ничего не потеряла него
Чтобы сотрудники научились быстро решать личностные конфликты, можно провести тимбилдинг, который поможет научиться. Например, игровые переговоры.
«Игровые переговоры»: сотрудники делятся на команды по 2—3 человека, каждой команде дают сценарий. В нем описывается конфликт и роли каждого человека в команде. Когда все поняли свою роль, команды выходят на переговоры, чтобы разрешить конфликт, но достичь своей цели по сценарию. В конце судьи проводят разбор полетов.
Руководители подразделений не общаются друг с другом. Когда руководители разных отделов в одной компании знакомы друг с другом, но не общаются, они не обмениваются опытом и могут тратить время и деньги на неэффективные решения. В такой ситуации может помочь тимбилдинг, который подтолкнет их к общению и совместной работе. Например, провести корпоративную регату.
Корпоративная регата — это гонка между парусными яхтами. Руководителей делят на команды по 3—5 человек и сажают на спортивные яхты. Во главе команды инструктор: он говорит, что и в какой последовательности делать, чтобы работа участников приводила лодку в движение. У каждого своя роль в экипаже и свои задачи, но только синхронная работа позволяет обогнать другие яхты на дистанции и прийти первыми. Чья команда лучше скоординирована и синхронизирована в своих действиях, та и приходит быстрее всех.
На лодке все время надо согласовывать действия между собой и быстро реагировать на команды, чтобы яхта непрерывно двигалась вперед и не теряла скорости. Если собрать в одну команду руководителей, которые не общаются друг с другом, им придется начать общение и наладить контакт. Иначе они проиграют.
Структура компании сильно меняется. Например, небольшая компания сливается с корпорацией и три подразделения объединили в одно: друг друга не знает, бывшие руководители стали подчиненными, в команде появляются новые роли. В таком случае может помочь тимбилдинг, который поможет адаптировать сотрудников к новым условиями.
Чтобы такой тимбилдинг помог адаптировать команду к изменениям, нужно формировать команды такими, какими они стали в компании после изменений. Например, если раньше у разработчиков был руководитель Семен, а теперь вместо него Петр, надо сделать Петра командиром в пейнтболе. А если 10 дизайнеров раньше были в одном отделе, а теперь в разных, надо не давать им объединяться старым составом, а собрать команды из новых отделов.
Когда не нужен тимбилдинг
Тимбилдинг — хороший инструмент для работы с командой. Но если применить его не к месту, он ничем не поможет. Например, тимбилдинг не поможет, в таких ситуациях:
Нет командной работы. В некоторых командах люди редко общаются друг с другом по работе, потому что они делают задачи в одиночку. В таких случаях тимбилдинг ничем не поможет — он не для одиночек.
| Нет командной работы | Есть командная работа |
|---|---|
| Мерчандайзеры в основном работают одни: они выкладывают продукты в магазинах, проводят инвентаризацию на складе и следят за тем, чтобы товары не кончались на полках. Изредка они общаются с администрацией магазина, чтобы предупредить, что печенье кончается и надо бы его закупить. Мерчандайзерам почти не надо ни с кем взаимодействовать, чтобы справляться с работой | Врачи скорой помощи работают сообща: когда с пациентами не так, один готовит обезболивающие, другой — дефибриллятор, третий следит за состоянием человека. Пациент может умереть, если врачи будут медлить. Таким врачам нужно постоянно взаимодействовать между собой, чтобы справляться с работой |
Сотрудники сильно устают. Врачи, журналисты, руководители, кадровики часто испытывают стресс на работе и сильно устают. В итоге результат работы может не соответствовать ожиданиям руководства. Уставшая команда — это не повод проводить тимбилдинги: уставший человек хочет спать и восстанавливать силы, а не бегать по лабиринтам.
Уставшая команда — это повод задуматься, что не так в процессе. Может быть, руководители не дают точных сроков для задач и всегда говорят, что они срочные. В такой ситуации сотрудники могут переработать: не все задачи можно сделать быстро. Тогда можно сделать так, чтобы руководители договаривались с сотрудниками о точных сроках и грамотнее подходили к планированию нагрузки, а не сбрасывали на них все задачи с пометкой ASAP. Другой вариант — нанять еще людей, если задач стало так много, что команде уже просто не хватает рук.
Сотрудники работают посредственно. Представим, что в компании сотрудники решают задачи неохотно, выдают посредственные результаты и приходят, чтобы дождаться конца рабочего дня. Такую проблему решить одним тимбилдингом не получится.
Сначала нужно выяснить, почему сотрудники стали работать плохо. Для этого можно провести анонимный опрос, поговорить с руководителями и волнующими сотрудниками. Дальше все зависит от ситуации. Возможно, нужно улучшить процессы, уволить, поднять зарплату, перестать давать задачи, которые он не должен решать. А уже затем, может быть, проводить тимбилдинги.
В компании текучка. Если из компании часто уходят сотрудники, а на их места приходят новые, говорят, что в компании высокая текучка. Это не повод проводить тимбилдинги чаще: вряд ли они помогут сделать так, чтобы никто не уходил.
У сотрудников могут быть тысячи причин для ухода. Сначала нужно провести исследование, чего уходят люди. Им может не нравиться уровень зарплаты, добираться неудобно, задачи неинтересные, хотят другую позицию, руководитель слишком требовательный.
Один тимбилдинг вряд поможет сделать так, чтобы человеку вдруг стало удобно добираться до работы. Но он может помочь новым сотрудникам познакомится с коллегами и быстрее поладить, если проблема коллектива действительно в этом.
Как самостоятельно провести мероприятие по тимбилдингу
Тимбилдинг можно провести самому или делегировать это специалисту. Дальше поговорим о варианте со специалистом, а сейчас разберем, что нужно сделать, чтобы все устроить самостоятельно:
Определить цель и бюджет. Если бесцельно проводить тимбилдинги, это ни к чему не приведет. Другое дело, если у компании есть задача, которую могут решить тимбилдинги, например:
Когда определите цели тимбилдинга, нужно решить, сколько компания готова тратить на него. Возможно, при подсчете нужно учесть, сколько денег компании уходит проблем, которые вы собрались решать тимбилдингом. Например, можно рассчитать часовую ставку ссорящихся сотрудников и засечь, сколько часов уходит на личные конфликты, чтобы вообще понять целесообразность такого мероприятия.
От бюджета будет зависеть формат, сценарий и ведущий.
Узнать предпочтения сотрудников. Хороший тимбилдинг — это когда сценарий и формат вписываются в предпочтения сотрудников. Чтобы выбрать формат и разработать сценарий, нужно провести опрос среди сотрудников. Если не спросить, есть шанс проколоться.
❌ Кадровик Леша придумывал формат тимбилдинга для отдела бухгалтеров. Леша решил, что раз в отделе в основном женщины за 50, они не готовы играть в футбол, пейнтбол или перетягивать канат. В итоге он отправил их в «комнату побега», но там им было скучно. Когда Леша собирал обратную связь, он с удивлением узнал, что бухгалтеры хотели более активного.
❌ В другой день Леша придумал формат тимбилдинга для другого отдела. Решил, пусть будет формат «лабиринт с проводником». Отдел делится на команды и выбирает главаря. Главарь завязывает глаза своей команде и за руку ведет каждого по полосе препятствий из пункта «А» в пункт «Б». Кто быстрее переведет команду на другую сторону, тот и победил. Когда Леша собирал обратную связь, он с удивлением узнал, что многие сотрудники не любят, когда их трогают коллеги.
Чтобы опросить коллег, можно создать анонимный опрос в Google Формах, оставить там вопросы и отправить ссылку на него в чат коллег. Собрали главное, что нужно спросить:
Сотрудники могут медлить с заполнением опроса, если в нем можно дать только открытые ответы. Чтобы ускорить процесс, можно добавить готовые варианты ответов для выбора галками. Например, перечислить популярные виды командного спорта в вопросе о нем.
Когда получите ответы, можно придумать несколько форматов тимбилдинга и попросить сотрудников проголосовать, какой им понравится больше.
Выбрать формат. Важно, чтобы формат подходит под предпочтения сотрудников. Иначе они не придут или тимбилдинг не решит своей задачи.
Формат «в офисе» подойдет, если бюджет сильно ограничен. В офисе не поиграешь футбол, но можно придумать свою «комнату побега», проводить игровые переговоры, делиться на команды и состязаться в викторине по профессиональным темам или придумывать логотипы на время.
Выездной формат подходит, когда важно сменить обстановку. За пределами офиса можно делать все что угодно: играть в баскетбол, устроить соревнования по лазертагу, организовать корпоративную регату на яхтах, пройти веревочный курс или сплавляться по местной речке.
Разработать сценарий. Сценарий должен вписываться в предпочтения сотрудников и помогать решать задачу тимбилдинга, которую вы поставили.
| ❌ Сценарий не решает задачу | ✅ Сценарий решает задачу |
|---|---|
| Чтобы коллеги начали ладить друг с другом, мы разработали такой сценарий: каждому сотруднику за два часа нужно сверстать лендинг, написать к нему текст и разработать иллюстрации. Кто успеет сделать хороший лендинг, тот и победил | Чтобы коллеги начали ладить друг с другом, мы разработали такой сценарий: сотрудники делятся на команды по 3—5 человек, чтобы за два часа сверстать лендинг, написать к нему текст и разработать иллюстрации. Какая команда успеет сделать хороший лендинг, та и победила |
Выбрать ведущего. Ведущий — это человек, который объясняет правила мероприятия и следит за тем, чтобы их не нарушали, но всем было весело. Если ведущего не будет, может начаться хаос.
| ❌ Никто не следит за тимбилдингом | ✅ Ведущий следит |
|---|---|
| Сотрудники играют в футбол. Нападающий нечаянно задел мяч рукой прямо перед воротами соперника. Нападающий отрицает, что нарушил правила. Вратарь, который все видел, стоит на своем. Начинается конфликт | Сотрудники играют в футбол. Нападающий играет рукой прямо перед вратарем и отрицает это. Ведущий все видел и назначает штрафной в пользу команды вратаря |
Если нет бюджета на ведущего, им может быть из сотрудников, например кадровик или маркетолог. Если бюджет есть, можно нанять специалиста по тимбилдингу.
Выбрать подходящее время. О времени и дате лучше узнавать у сотрудников во время опроса. Если не спросить, можно проколоться. Один коллектив может расстроиться, если тимбилдинг будет посреди рабочей недели, а другой коллектив этому только обрадуется.
Организовать мероприятие. Организация — ответственная часть тимбилдинга. Если компания проводит мероприятие на природе, важно накормить сотрудников как следует, позаботиться, чтобы на площадке была питьевая вода, не было слишком жарко или, наоборот, холодно.
Чтобы программа тимбилдинга прошла гладко, нужно все учесть заранее. Собрали вопросы, на которые нужно ответить перед тем, как начать организовывать тимбилдинг:
Собрать обратную связь. Чтобы следующий тимбилдинг прошел гладко, спросите у сотрудников, как все прошло. Сотрудники не будут стесняться, если провести анонимный опрос в Google Формах. Вот что можно спросить:
Хорошо организовать тимбилдинг — большой труд. Если у вас нет времени на это, поручите это специалисту.
Как найти специалиста по тимбилдингу
Выездной тимбилдинг — большая задача. Кадровик может не справиться, если у него никогда не было такого опыта или он завален своими задачами. Если есть бюджет, лучше всего найти специалиста по тимбилдингу. Вот что он может уметь:
Можно начать поиски специалиста по тимбилдингу через знакомых или в интернете. Поспрашивайте знакомых, кто им проводит тимбилдинги и готовы ли они рекомендовать специалиста или компанию. Если никто не знает таких, вбейте в поисковик или соцсети «заказать тимбилдинг» и укажите название региона.
Изучите, насколько предложения, кейсы и отзывы специалиста или компании подходят под вашу задачу. Если специалист уже проводил тимбилдинги для компаний вашего типа и отзывы об этом положительные, значит, у него можно попробовать заказать то же самое. Если ничего под вашу задачу не подходит, поищите другого специалиста или компанию.
Если выбрали специалиста или компанию, созвонитесь и обратите внимание в разговоре, вникает ли на той стороне в вашу задачу или сразу спрашивает про детали.
Если специалист вникает в задачу, это значит, что он понимает нюансы и может предложить подходящее решение. Если не вникает, значит, он пока не знает, как предпочтения сотрудников и тип компании влияют на результат. Тогда есть риск, что его тимбилдинг никак компании не поможет.
Главное о тимбилдингах
Сервисы для массовых выплат
Поможем организовать выплаты для сотрудников и фрилансеров:
Сейчас читают
LTV: что особенного в этой метрике и почему нужно за ней следить
LTV — это долгосрочная прибыль от клиента. Помогает увидеть, какие клиенты приносят больше всего денег компании
Как вести бизнес через облачные сервисы
Облачные сервисы — это онлайн-программы и другие инструменты, которые помогают удаленно управлять бизнес-процессами. За счет «облаков» компании могут автоматизировать работу, сэкономить и лучше защитить свои данные
Как организовать вебинар и заработать на нем
Рассказываем, как вебинары помогают бизнесу увеличить прибыль, даем пошаговый план организации вебинара и делимся приемами, которые помогают продавать в прямом эфире
Рассылка для бизнеса
Получайте первыми приглашения на вебинары, анонсы курсов и подборки статей, которые помогут сделать бизнес сильнее
© 2006—2021, АО «Тинькофф Банк», Лицензия ЦБ РФ № 2673 — Команда проекта
Тинькофф Бизнес защищает персональные данные пользователей и обрабатывает Cookies только для персонализации сервисов. Запретить обработку Cookies можно в настройках Вашего браузера. Пожалуйста, ознакомьтесь с Условиями обработки персональных данных и Cookies.
Чтобы скачать чек-лист,
подпишитесь на рассылку о бизнесе
После подписки вам откроется страница для скачивания
Один в поле не воин. Путь до эффективной командной работы
Команда — это группа людей, которые вместе двигаются к общей цели, распределяют между собой задачи и ответственность за конкретный результат. Команды создаются, чтобы решать задачи, которые один человек выполнить не сможет. Эффективная команда достигает цели за минимальный срок с минимальными затратами.
Собрать несколько человек и сказать: «Теперь вы команда, ждем от вас результата», не получится. Людей нужно организовать, дать им вменяемую цель, мотивацию и решать возникающие проблемы.
Как раз об этом расшифровка доклада Евгения Федореева на TeamLead Conf. В докладе Евгений поэтапно описал процесс организации эффективной команды разработки в Banki.ru: про найм, общение, обмен знаниями и развитие разработчиков и тестировщиков внутри коллектива и отдела.
Что такое Banki.ru?
Контекст компании, чтобы знать, о каком опыте пойдет речь. Banki.ru — это крупнейший независимый финансовый портал Рунета с ежемесячной аудиторией больше 8 миллионов уникальных пользователей.
В IT-отделе работает 50-70 человек, поделенных на 7 команд разработки. Вся разработка ведется in-house, удаленных разработчиков нет, поэтому в соответствующих процессах и метриках нет необходимости.
Основная задача команды разработки
Когда готовился к докладу, я задавал людям вопрос:
— Какая цель у команды разработки?
— Разрабатывать.
— Что это значит? Если человек сидит, рефакторит, не приносит пользы, не решает бизнес-задач — это тоже разработка?
— … Нужно эффективно разрабатывать.
Эффективность разработки
Понятие эффективности для менеджера одно, а для разработчика другое.
Для управленца эффективная разработка — прогнозируемая: когда известна дата релиза фичи или срок выполнения задачи, чтобы провести какие-то бизнес-мероприятия.
Для разработчика — это работа с техническим долгом. Это одна из болей, так как на работу с тех. долгом, на рефакторинг, на исправления и улучшения дается очень мало времени.
Следующий критерий эффективности — минимальное количество багов. Можно было бы написать, что критерий — полное отсутствие багов, но мы знаем, что такого не бывает. Кроме того, обидятся тестировщики, ведь они будут не нужны.
Заделы на будущее. Я специально не написал «продуманная архитектура». Заранее углубляться и продумывать архитектуру — зло, поэтому в разработке должен быть задел на будущее, но без фанатизма.
Любой другой критерий, который есть у каждой команды.
Процесс разработки
Строить процессы разработки в Banki.ru мы начали после того, как компания стала развиваться и расти. Появились новые партнеры и проекты, и 6-9 backend-разработчиков не хватало. Мы пришли к тому, что нужно выстроить процесс разработки и формализовать его, для эффективной работы.
Изначально у нас было 3 команды, в каждой по 3 бэкенд-разработчика и менеджер, который отвечал за части сайта. Backend-разработчики, кроме своей работы, еще верстали и подключали jQuery-плагины, так как в тот момент на фронтенде было мало людей.
Мы взяли двух фронтенд-разработчиков и еще двух тестировщиков, чтобы жить без багов и считали, что этой конфигурации будет достаточно.
В идеальном мире процесс разработки должен выглядеть так.
После обновления схемы, мы решили, что все круто и стали по ней работать — проводили планирование спринтов, а бэкенд-команды сами ставили задачи в план. Поработали 2 месяца и поняли, что что-то не так.
Наша схема трансформировалась. Задачи прыгают, как мячик в пинг-понге: от QA к фронт и бэк разработчикам, и даже долетают до менеджеров.
Стрелочки занимают много времени — процесс доставки задачи на боевые сервера слишком длинный. Нас это не устраивало. Мы хотели минимизировать количество стрелок, чтобы задачи выполнялись быстрее.
Как сократить время доставки?
Первое, что пришло на ум — задать вопрос о том, почему мы возвращаем задачи? Почему бэкенд, фронтенд и QA понимают задачу по-разному? Почему взгляды различаются? Мы пришли к тому, что нашли виноватого в менеджере проекта, что он описывает задачи не полностью, и сказали PM описывать задачи полнее, чтобы всем понимать, что имелось в виду.
Планированием у нас занимались три бэкенд-команды. Мы привлекли к планированию тестировщиков и фронтенд-разработчиков, но на 3 команды было всего 2 фронтенд-разработчика и 2 тестировщика. Часто звать их не получалось, потому что кому-то надо работать.
Поделили задачи отдельно на frontend и backend, чтобы отдавать их в разработку параллельно, быстрее тестировать и не ждать всю цепочку.
Мы попробовали все решения. В результате время сократилось, но все равно нас не устраивало.
Мы думали, что делать дальше. На рынке много компаний и практик, и мы стали изучать, смотреть, копать и дошли до feature-team.
Feature-team
Это когда в команде есть все полный набор людей для выполнения задачи:
Проблемы feature-team
На тот момент у нас появилось 6 проблем.
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-страничка с датами проведения тимлидских встреч, в которую в течении недели набрасываем проблемы и задачи для обсуждения.
Плюсы такого решения
Мы ввели кросс-командное code-review. Это некий обмен опытом, который уже практиковали фронтенд-разработчики, а позднее и ребята из бэкенд. Отдавать весь код на кросс-командное code-review не обязательно, достаточно только важных вещей, например, общие библиотеки или общие куски кода. Дляcode-review мы выбирали только заинтересованные команды, не было обязательного approve.
Возникают ситуации, когда соседняя команда, которая занимается банками, просит доработать функционал — добавить поля, а мы занимаемся кредитами.Можно попросить другую команду, но у них свой план и непонятно, когда они выполнят просьбу, а ждать нельзя. В такой ситуации мы помогаем соседней команде, но на code-review отдаем другой.
Бывает так, что разработчики просят перевестись на другое направление или сменить технологию. Например, у нас один сотрудник год занимался кредитными картами и просит сменить область, а другой хочет поменять технологию с UI на Symfony. По договоренности мы организуем переход разработчиков между командами.
Некоторые компании практикуют встречи по пятницам: люди собираются для обмена опытом, что-то обсуждают, рассказывают. Мы тоже решили организовать пятничные посиделки — завели страничку в Wiki, где каждый, кто хочет выступить, пишет тему своего доклада.
Все было круто. На посиделках команды рассказывали, чем занимаются, что нового. Например, с одной из команд у нас возникло непонимание, никто не знал, чем она занимается. На пятничной встрече команда рассказала про свою работу, показала аналитику и все поняли смысл их работы. Фронтенд-разработчики рассказывали как происходит сборка, обсуждали общетехнические темы, например, как пользоваться Debugger’ом в PHPStorm, как происходит деплой.
А потом темы по разработке закончились, мы перешли на психологические и история стала угасать. Как дальше простимулировать разработчиков что-то рассказывать?
И тут мы вспомнили про KPI! Давайте каждого разработчика научим выступать и включим в его KPI 2 доклада за полгода на пятничных посиделках. Мы думали, что идея крутая и все будут выступать.
Оказалось, что после введения KPI, разработчики перестали делать доклады. К обязательным выступлениям возник негатив. Программисты решили пожертвовать 100% выполнением KPI, лишь бы не делать добровольно-принудительные доклады.
Выводы
Принципы эффективной команды
Каждый член команды — самостоятельный сотрудник.
Мы учим людей выполнять задачу полностью. Например, когда у человека не хватает требований или доступов, мы хотим, чтобы он мог найти эти данные сам: пойти к админами, к PM, попросить логин или пароль.
Задача должна быть сделана одним человеком — если ты взял ее на себя, то должен довести до конца.
Бывали случаи, когда разработчик говорит:
— У меня нет паролей на интеграцию с партнерами.— ОК, напиши письмо или скажи PM.
Сказал PM и опять сидит день или два.
— Вася, что случилось?— Я PM написал, а пароля все нет.
Мы пришли к тому, что человек должен дожимать, чтобы как можно быстрее получать необходимые данные.
Важно общение внутри команды. Меньше формальностей.
Так как мы все работаем в одном офисе, важно минимизировать формальности внутри команды. Есть инструменты вроде Jira или Slack, которые помогают общаться с удаленными работниками по интернету, а у нас люди общаются между собой лично, решают и обсуждают проблемы сразу. Мы даже ушли от еженедельных Scrum-митингов, потому что они не нужны.
Когда у нас появляется проблема, мы ее сразу обсуждаем и решаем.
Тимлид поддерживает единство в команде.
Тимлид следит за настроением в команде и решает проблемы. Например, у нас один разработчик работал год. Мы заметили, что команда перестала с ним общаться. Человек сидит, что-то делает, а к нему никто не подходит — это уже сигнал, — что-то не так. Когда люди создали внутри команды чат для обмена сообщениями, сигнал вопил как пожарная сигнализация. Разработчик спрашивает:
— А что происходит?
— Мы в командном чатике общаемся!
— Меня туда добавьте!
— А у тебя не Айфон, мы в iMessage!
После этого я пошел к директору по разработке и сказал, что надо что-то делать: команда демотивирована, классный специалист не может работать.
Мы перевели его в другую команду, и всем стало лучше: взяли нового разработчика, который влился в команду, а предыдущий нашел себя в новой команде, проработал 2 года, и получал хорошие отзывы от тимлида.
Тимлид защищает команду от «внешних факторов».
Тимлид — это фильтр, который решает какую информацию извне допускать в команду, а какую нет.
Объясню на примере. В отделе маркетинга или в руководстве, всегда «лучше»знают, сколько времени уходит на разработку — им друзья рассказывали, что у себя фичу запилили за месяц, а наши полгода делают. Руководству не объяснить, что у нас куча подводных камней, которые решаем, но быстрее не можем. Когда такая информация доходит до команды, часть разработчиков демотивируется, уходит в себя.
Будьте фильтрами между внешней средой и командой. Всю информацию надо дозировать, чтобы не демотивировать разработчиков.
Сбор программы TeamLead Conf, которая пройдет 25 и 26 февраля в Москве, в самой жаркой стадии. О результатах расскажу здесь, когда уже все будет привязано к расписанию, а в рассылке будут приходить регулярные тематические подборки.
