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

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

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

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

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

Как вообще происходит становление хорошей команды?

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



Сначала группа формируется и все знакомятся друг с другом (этап Forming), затем на этапе Storming они начинают понимать, кто за что будет отвечать, и кто что делает. Здесь возникает некоторая задержка из-за того, что сотрудникам необходимо притереться, понять, как организовать взаимодействие.

На следующей стадии (Norming) уже образуется коллектив, который готов совместно работать. Сотрудники начинают разрешать разногласия, признают сильные стороны других членов команды и авторитет руководителя. На стадии Performing команда уже работает и движется к цели. Структура группы и процессы уже устоялись. Именно здесь руководитель может делегировать выполнение отдельных работ и сосредоточиться на развитии членов коллектива. Это самая эффективная фаза, которая есть в управлении.



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

Думай с конца, думай вовремя

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

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

Что же нужно делать, чтобы этого не допустить?



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



И раз уж мы заговорили про тимлида, то затронем и наболевшую тему — декомпозицию задач. Не раз я попадал в холиварные споры, которые начинались с фраз: «Когда переставать делить?» или «Дайте мне чёткие критерии для разделения задачи». Вопрос декомпозиции связан не только со скоростью выполнения, но и с эффективностью использования доступных вам ресурсов. И здесь не всё так просто, как может показаться. Добавление программистов в команду может не ускорить выполнение задачи, а, наоборот, разбалансировать группу, заставив нас вернуться на этап «Forming» и потерять на этом время.

Как говорил известный американский учёный в области теории вычислительных систем, автор книги «Мифический человеко-месяц» Фредерик Брукс, «то, что один программист сделает за месяц, два программиста сделают за два».

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

Одной из таких метрик является диаграмма «сгорания задач» (Burndown Chart). Она показывает скорость выполненных задач в спринте или во всём проекте, а также как быстро команда работает над своими задачами. Конечно, требуется организованность к трекингу времени для решения каждой таски, но со временем приходит понимание, что большинство задач схоже между собой, и для каждого типажа у вас есть статистика, будь то в попугаях стори-поинтах или часах.

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



Впрочем, вы уже и сами хорошо знаете, о чём я.

Каким должен быть тимлид (team lead)?

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

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

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

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



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

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

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

Ещё важное правило: «Всегда убеждайтесь, что вас поняли правильно». Уточнять, так ли вас поняли, важно: вы тут контролируете не исполнителя, вы контролируете себя. Уточнять надо не только при постановке задачи, но и через некоторое время, чтобы проверить верность курса. Исполнитель всегда понимает сказанное правильно со своей точки зрения. А тимлиду нужно ставить задачу так, чтобы не произошло искажения смыслов и не сбился курс движения. Иначе вместо желаемой бухты можно влететь всем экипажем на скалы — не только на морской прогулке, но и в проекте. То есть нужно грамотно делегировать выполнение задач, чётко выставлять цели, понятно объяснять, что делать и в какие сроки. И дальше так же, как шкипер на яхте, лидер должен постоянно и терпеливо контролировать «обстановку на судне». Верно ли понимают задачи все члены команды? Как идёт их исполнение? Все ли помнят о цели, которую мы наметили? Не отклоняется ли от неё наш «корабль»?

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

Как выстроить коммуникации внутри команды?

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

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

Предоставление обратной связи человеку, открытому для её получения, даёт ему возможность скорректировать свои действия. Каждому вашему сотруднику иногда в голову приходят вопросы типа: «Хорошо ли я справляюсь?» или «Есть ли что-то, что мне нужно улучшить?» Каждому человеку необходимо получать обратную связь. Ваш подчинённый сделал что-то как нужно и вовремя? Это отличный повод поздравить члена команды и сделать ему искренний комплимент! Пусть он вдохновится своим успехом и продолжает делать то, что у него хорошо получается.

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

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



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



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

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

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

Ещё одна важная задача тимлида — забота об обучении и передаче информации внутри коллектива.



Многие наверняка знакомы с понятием пирамиды Дейла, или пирамиды усвоения информации. Согласно этой концепции человек из прочитанного запоминает не более 10 %, из того, что он услышит, — 20 %, из просмотра видео в памяти останется не более 30 %, а когда человек что-то делает сам, то он будет помнить это практически полностью. И максимальный эффект даёт обучение других людей.

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

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

Как эффективно управлять командой в проекте?

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

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

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

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

Со временем я понял: быть отличным тимлидом — намного шире общего понимания роли руководителя. Здесь я набил себе порядком шишек.

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