что делает команду командой

Один в поле не воин. Путь до эффективной командной работы

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

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

Как раз об этом расшифровка доклада Евгения Федореева на 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 февраля в Москве, в самой жаркой стадии. О результатах расскажу здесь, когда уже все будет привязано к расписанию, а в рассылке будут приходить регулярные тематические подборки.

Источник

Урок 2. Команда и командная работа

Говоря о командообразовании, профессионалы утверждают, что зачастую командные проекты постигает неудача еще на ранних стадиях. Причиной тому служит непонимание того, что такое команда, как она формируется и как функционирует. Ситуации, когда один человек преуспевает в выбранной деятельности, можно, грубо говоря, пересчитать по пальцам. Быть талантливым и умелым во всем, что касается проекта, может далеко не каждый – потому-то и создаются команды, в которых работают самые разные специалисты. Если организация работы коллектива выстроена правильно, команда может свернуть горы там, где одиночка и шага не сможет сделать.

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

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

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

Содержание:

Создать сильную команду может только профессионал в создании команд

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

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

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

Чтобы научиться создавать команды, нужно проявить изрядную долю терпения и выдержки. Информация-то есть, но перед применением ее нужно осмыслить и закрепить. Представьте себе хирурга, постоянно заглядывающего в учебник или просящего подсказки у ассистента во время операции – как вы считаете, он профессионал? Точно так и здесь: не усвоив основных навыков и не сформировав нужных качеств, за формирование команды браться опасно.

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

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

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

Сначала формируется команда, а уже потом разрабатывается проект

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

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

Давайте представим, что мы пошли по первому пути, где сначала создается проект, а затем формируется команда. Работа идет, идея вдохновляет, рассматриваются разные нюансы проекта, уточняется потребность в конкретных специалистах. Вроде бы все готовы и мы начинаем формировать команду. Например, мы решаем создать компьютерную игру, и, обладая некоторыми познаниями, берем на себя функции проектировщика и разработчика, и подбираем еще двух спецов – художника и программиста. Музыкальное и звуковое сопровождение будет лицензировано. Сам проект вполне прост – обычный 3D-action. Мы свято верим в успех новой игры, а спецификации наглядно показывают достижимость результата. По нашим подсчетам новинка будет готова через полгода.

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

Месяц за месяцем нам приходится искать толкового 3D-программиста, который согласится работать на наших условиях, но мы так его и не находим. Все, что у нас есть – 2D-программист, начинающий осваивать 3D. Наш художник не может нарисовать качественную текстуру, даже если мы пригрозим ему 16-тимиллиметровым пулеметом. Он, конечно, хорош в своем 2D, но сногсшибательная новинка изрядно пострадает.

В итоге нам приходится кое-как пытаться делать конфетку из того, что имеется. Наши профи, сколько бы ни старались, не могут сделать 3D. На экране что-то маячит, но движок глючит, а игра хуже допотопного «Принца Персии» (не в обиду ценителям). Видя все это, наша команда уже перестала даже пытаться уложиться в сроки и следовать оговоренному в самом начале дизайну. У каждого есть свои идеи, которые он хочет воплотить. К тому же никто всерьез не воспринимает проектную документацию.

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

Так в чем же была ошибка нашего тимбилдинга? Дело в том, что мы сделали ставку на проектирование качественного продукта для геймеров, посчитав его достаточным условием для достижения успеха. Но в командных проектах такое, как говорится, не прокатывает. Чтобы реализовать командный проект нужно правильно подобрать людей в команду. Неправильная команда приводит к необходимости постоянного контроля. В правильной команде такой потребности не возникает, ведь индивидуальная ответственность становится нормой для всех.

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

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

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

Правильность выбора людей определяет успешность команды

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

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

Залог успеха команды – только командные игроки

В построении успешной и эффективной команды нужно руководствоваться самым важным принципом отбора людей: в команде должны быть командные игроки, а не одиночки. И вот вам отличный пример: на Зимних Олимпийских играх 1980-го года американская сборная команда по хоккею победила команду СССР со счетом 4:3 и взяла золото, произведя фурор в мире спорта. Удивительно то, что еще до Олимпиады команда СССР разгромила команду США со счетом 10:3. После Игр тренера американцев спросили, как он добился победы. Отвечая, он сказал, что провел в своей команде несколько психологических тестов, выявил эгоцентричных игроков и отобрал только тех, кто поддерживает командный дух.

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

Другой плюс командных игроков в том, что они по собственной инициативе и охотно берут на себя ответственность за достижение нужного результата, и их работа не требует жесткого контроля и управления. Ни одна проблема не останется без внимания, т.к. командные игроки найдут любой недочет и устранят его. А мотивацией для них служит тот факт, что они ПРИЧАСТНЫ к проекту – это ИХ проект.

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

Залог успеха команды – только один лидер

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

Как лидер может заслужить уважение своих людей? Ответ предельно прост: нужно использовать все преимущества единства и ставить потребности команды во главу угла. Лидер – пример для всех и каждого в частности. А потому он должен обладать такими качествами как честность, уравновешенность, порядочность и объективность. Если лидер что-то пообещал, он в лепешку разобьется, но сдержит слово. Руководитель команды – это живое воплощение командных стандартов, независимо от того, в какой степени соответствуют этим стандартам другие члены команды.

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

Сплоченность – важнейший фактор в жизни и работе команды

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

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

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

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

Эффективная и успешная команда нуждается в постоянной обратной связи

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

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

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

Каждый член команды должен вознаграждаться по заслугам

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

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

Похвала – очень мощный инструмент для поддержания позитивного настроя и энтузиазма. Ясное дело, что каждый и так знает, что он участвовал в проекте. Но грамотный руководитель сделает так, чтобы это отметить, причем публично и при помощи искренних слов, а не отговорок типа «Отличная работа, Василий!» или «Так держать, Петька!». Сравните с этим: «Евгений, вы проделали просто невероятную работу над проектом. Без ваших навыков туго пришлось бы всей команде. Сайт работает превосходно, а дизайн вообще выше всяких похвал. Вы замечательно потрудились, Евгений! С вами мы точно не пропадем!» Согласитесь, что вкупе с хорошими премиальными эти слова поднимут на седьмое небо, пожалуй, каждого.

Ведение записей – неотъемлемая часть командной работы

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

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

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

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

В команде не должно быть неэффективных людей

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

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

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

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

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

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

Хотите проверить свои знания?

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

Напоминаем, что для полноценной работы сайта вам необходимо включить cookies, javascript и iframe. Если вы ввидите это сообщение в течение долгого времени, значит настройки вашего браузера не позволяют нашему порталу полноценно работать.

Источник