Снова всех приветствую! Как и обещал, я продолжаю писать о менеджменте в IT. В прошлой статье я рассказал о поиске и найме новых игроков в команду. Но какими бы классными и талантливыми людьми они ни были, они пока не команда. Можно провести параллель с футболом: вы можете купить суперигроков и выпустить их на поле, но они не будут командой и матч скорее всего проиграют, так как у них нет тактики и стратегии.

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

Цели, задачи и тактики

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

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

Команды и почему они не эффективны

Что такое команда? Можно сформулировать такое определение: группа лиц, объединённая мотивами и интересами для достижения общей цели. Звучит здорово, но на практике есть проблемы.

• Умение понимать друг друга и разговаривать на одном языке. Все мы разные и воспринимаем всё по-разному, с этим остаётся только смириться, так уж устроен человек. У каждого своё мировосприятие. Просишь запилить какую-то фичу, например, выгрузку в Excel из таблицы, а на выходе получаешь совсем не то. И вроде бы задача простая, но какая-то ерунда на выходе. Опыт и образы мышления у всех разные, и далеко не факт, что другой человек подразумевает то же самое, что и ты. Есть занимательный тест на эту тему, попробуйте дать его коллегам.
• Умение говорить. Обычная ситуация: попадается сложная задача, надо найти оптимальное решение. Ты собираешь коллег и предлагаешь обсудить решение. Хорошо, если кто-то высказывается, а бывает, что людям нечего предложить. Они просто ждут конкретной задачи, как им скажут, так и напишут. Они просто не понимают или не видят, чем могут помочь.
• Мотивация и интересы. Уверены, что они совпадают у TL и команды? У вас мотивация сделать так, чтобы фичи работали и были сделаны в срок. А члены команды хотят внедрить новый язык или попробовать сделать крутое архитектурное решение на все случаи жизни, когда фича нужна здесь и сейчас.
• Слышать и слушать. Зачастую инженеры на совещаниях совершенно не понимают, зачем их вытащили, и даже не слушают.
• Вовлечённость в процесс. Бывает, что программисты просто решают те или иные задачи, но они не понимают их конечного смысла для проекта в целом. Например, надо добавить кнопку, но они не понимают зачем, просто «вслепую» пишут код, чтобы закрыть тикет.

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

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

Как сплотить людей

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

Я считаю, что ключевой процесс в хорошей команде — это коммуникация. Ниже я перечислю основные принципы и советы по налаживанию коммуникации.

• Сядьте и пообщайтесь с каждым сотрудником, спросите об умениях и опыте. Постарайтесь найти сильные и слабые стороны коллег. Вам надо в дальнейшем сделать так, чтобы люди дополняли друг друга, задействуя в работе свои сильные стороны. Только так можно достичь максимальной эффективности в итоге.
• Доносите до команды цели работы. Если реализовывается какой-то функционал, то каждый должен понимать его изначальный смысл. Например, интеграция с партнерами нужна для расширения ассортимента и повышения продаж, а значит и прибыли компании. Расскажите команде о конечной сути фич, так люди будут понимать реальную цель и выполнять задачи с большей охотой.
• Объясняйте всё простыми словами, чтобы каждый понимал, и у него не оставалось сомнений. Как сказал Эйнштейн: «Если вы не можете объяснить это просто — значит, вы сами не понимаете этого до конца».
• Вовлекайте людей в обсуждение. Например, если у отдела продаж есть какая-то проблема, то вы можете спросить у команды, что они думают по этому поводу. Сначала может никто и не будет высказываться, но никто не мешает сделать первый шаг и завязать беседу. Постепенно вовлекайте команду в обсуждения. И важно, чтобы каждый инженер понимал, что к его мнению прислушиваются. Как-то мы сделали интеграцию нашей внутренней системы с другими логистическими сервисами. И считали, что они удобны. Но когда сели оформлять логистику для клиентов, поняли, что неудобно пользоваться, делать отправку данных, просматривать статусы и прочее. Так мы выявили проблемы, ребята очень увлеклись и стали решать задачу, как будто это была их боль.
• Забудьте слово «ошибка». Покажите, что ошибка или неудача — это поиск нового решения. Все члены команды должны понимать, что это нормальный рабочий процесс. Не ошибается тот, кто ничего не делает. Все учились кататься на велосипеде, я не думаю, что у кого-то получилось поехать, ни разу не упав.
• Учитесь критиковать только по делу. Нельзя говорить, что всё плохо, и ваше решение никуда не годится. Аргументированно и без негатива объясняйте, почему конкретное решение не подойдет, и предлагайте альтернативы.
• Говорите на одном языке. Обсуждайте задачи и просите резюмировать. Одна из полезных практик, попросить инженера рассказать о решении задачи и как он всё понял. Для вас может быть много открытий: иногда то, что поняли они, сильно отличается от того, что говорили вы. Лучше потратить время на обсуждение, чем потом с удивлением обнаружить результат выполненной задачи, который совершенно не соответствует задуманному.
• Умейте упреждать и научите этому коллег. Это относится к ошибкам. Надо, чтобы люди сами подходили и говорили о затруднениях или неудачах в процессе, а не в конце спринта. Доносите, что важно найти оптимальное решение, а не просто закрыть конкретную задачу. В будущем это возможно повлияет на что-то, будет важно с точки зрения архитектуры. Поэтому лучше сразу делать правильно, пусть это и может отнять больше времени. У каждого члена команды должна быть привычка думать вперёд на несколько шагов, а не втыкать костыль, потому что горят сроки.
• Обсуждайте задачи с командой, а не с коллегами-исполнителями наедине. Во-первых, это будет их вовлекать в процесс, во-вторых, они могут предложить действительно хорошие решения, до которых вы сами не догадались. И помните, хороший программист — это не транслятор логики в код, а тот, кто целиком решает проблему. Программирование — это отчасти творчество, так дайте команде свободу для этого. Такой подход снова и снова будет давать вам действительно изящные и грамотные решения.
• Создайте выручай-комнату. У вас должно быть место, где вы можете поговорить с любым сотрудником и выяснить, какие у него есть проблемы в работе, что получается, а что нет. Важно, чтобы вы слушали человека, а он это понимал. Таким образом можно выявлять причины недостаточной эффективности его работы. Например, у него могут быть некорректно поставлены задачи, или просто стул разваливается. Систематически общайтесь с коллегами, держите руку на пульсе жизни команды. Так вы сможете предотвращать конфликтные ситуации и сглаживать рабочий процесс. Если все молча кодят и ни с кем не общаются, то в команде проблемы — отсутствует коммуникация.
• Говорите «спасибо». Если люди что-то делают хорошо, обязательно благодарите их. Эта мелочь очень важна, всем приятно, когда тебя ценят. Но не злоупотребляйте, а то благодарность быстро обесценится.
• Рассказывайте о достижениях компании. Команда или конкретные люди должны знать о своём вкладе в общее дело. Совсем здорово, когда отзывы об успехах программисты получают из других отделов. Например, маркетолог может рассказать о повышении продаж после доработки сайта или менеджер об оптимизации сервиса, которая ускорила его работу. Это поднимает боевой дух команды. Хорошая практика, когда время от времени CTO или даже CEO собирает рядовых сотрудников и отчитывается о достижениях.

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

Тонкости управления

Как-то я прочитал занимательные теории об оптимальном размере команды. Джордж Миллер занимался исследованиями памяти и в результате экспериментов смог заключить, что в кратковременной памяти человека обычно умещаются от 5 до 9 бессвязных элементов. То есть человеку их не надо группировать их по каким-то принципам и характеристикам, чтобы легче запомнить. Джефф Сазурленд, отец Scrum, который повторил успех компании Toyota, считает, что в команде должно быть не более 7 человек, из чего вытекло правило «7 человек на один проект». По его мнению, только такие команды достигают эффекта гиперпродуктивности, они могут быть эффективнее в 8 раз!

Я удивился, но эти теории сработали. У меня была одна команда из 12-13 человек, я её поделил на две и, о чудо, продуктивность заметно выросла. С ростом штата программистов я создал третью команду из 6 человек.

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

• Комбинируйте команды, чтобы им было куда расти. Одной из моих ранних ошибок было распределить коллег на две команды по уровню: в одной я собрал сильных программистов, а в другой менее опытных. После перетасовки продуктивность повысилась. И все начали более интенсивно развиваться: новички набирались технического опыта, а сильные инженеры пробовали себя в качестве наставников.
• Учитесь грамотно распределять задачи. Программист — это дорогой для компании сотрудник. Перед ним всегда должен быть вызов. Давайте задачи чуть сложнее, чем он может решить сходу. Это поможет ему расти. Опытный senior не должен сидеть над лёгкими задачами, даже если он делает их быстрее начинающего специалиста. Не забивайте гвозди микроскопом! Конечно, задачи нужного уровня сложности трудно подбирать, поэтому соблюдайте баланс и комбинируйте с рутинными.
• Правильно мотивируйте сотрудников. Здесь необходим индивидуальный подход: для одного это деньги, для другого — карьерный рост, третий хочет стать суперпрофессионалом, чтобы к нему все приходили за советом. То есть дайте им то, что действительно нужно. Это будет работать дольше и эффективнее, чем какая-то разнарядка, спущенная сверху от начальства. Кроме того, так проще соблюдать баланс между тем, что нужно компании и сотруднику.
• Комфортный график работы. Я долго боролся с начальством за гибкий график, но в итоге в цифрах доказал его преимущество. Мы договорились с командой о часах присутствия, при этом все могли приходить в удобное для себя время, отлучаться по делам, когда это было необходимо.
• Не пытайтесь контролировать каждый шаг. Люди должны осознавать свою ответственность. Человек, который это понимает, гораздо эффективнее и самостоятельнее.
• Не экономьте на обучении. Отправляйте коллег на конференции, мастер-классы и прочие мероприятия. Дорого? Устраивайте их сами в неформальной обстановке за чашкой чая и пиццей. Пусть люди делятся опытом, рассказывают о новых подходах или вместе решают какие-нибудь хитрые задачи.
• Управлять не управляя. На мой взгляд — это высший пилотаж. Легко раздавать прямые указания, но надолго ли хватит тим лида, который контролирует каждый шаг команды? В хорошей команде руководитель — это такой же сотрудник отдела, как и остальные. Только он думает не о конкретных задачах, а о развитии компании. Время от времени он сообщает о проблемах или о новых направлениях работы, а остальные накидываются на них и решают. На мой взгляд, это самый эффективный подход к управлению, только для этого уже должна быть построена хорошая команда и отлажены все процессы в ней.

Удивительно, но факт

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



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

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

Выводы

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

Люди, понимающие цель фич, которые они пишут, больше мотивированы и могут предлагать решения проблемы, которые другие не увидят.

Обязательно надо заниматься выстраиванием процессов разработки в команде и уделять максимум внимания коммуникации. Я считаю, что тим лиду достаточно кодить 10–20% времени, всё остальное — это процессы и люди.

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

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

Спасибо за внимание! В следующей статье я расскажу о нюансах ввода нового сотрудника в команду.

Мои другие статьи о менеджменте в IT:
Что такое быть Team Leader
Dream team из ничего: найм специалистов в IT