Решение конфликтов
Управление командой разработчиков — это очень непростая задача. Давайте сегодня поговорим, какими скилами должен обладать лидер команды? Когда, где и как применять их.
Так кто же этот лидер?
Прежде чем начнем рассуждать о скилах руководителя, давайте постараемся ответить на очень важный вопрос. Из кого может получиться лучший руководитель? Это совсем не простой вопрос, так как от него зависит очень многое, в том числе настроение, эффективность работы команды и т.д.
Обычно лидом назначают одного из разработчиков с самыми выдающимися результатами и большим опытом. И это как бы логично, так как такой специалист в команде обладает большим авторитетом и огромным опытом, который помогает другим разработчикам и, как следствие, тут будет всё, что поможет карьерно продвигаться. Но есть и НО… У специалиста может не быть необходимых скилов, таких как: сочувствие, умение убеждать, решать конфликты и прочее. В этом случае ничего толкового из такой затеи не выйдет. У таких специалистов намного лучше получается отвечать за определенную часть проекта, технологию, выступать в роли эксперта. Их стоит использовать для консультаций или экспертных работ.
Если же возьмем случай, когда назначается руководителем опытный менеджер со всеми нужными качествами, то и здесь возникают сложности. Когда у специалиста окажется мало знаний в разработке, то для него окажется просто невозможным контролировать работу разработчиков на полную мощь. Менеджер, у которого получается только управлять, но у которого маленький технический стек, чаще всего будет принимать ошибочные решения, связанные с техническими задачами, так как нет нужной компетенции. И еще одно. На такого менеджера очень просто получается надавить как клиенту, так и руководству. И, как следствие, такой руководитель будет спешить сделать задачу, вследствие чего напринимает много ошибочных решений, которые приведут к плохому настроению в команде и плохим результатам проекта.
Исходя из вышесказанного получается, что лучший вариант — это найти специалиста с отличной технической базой, большим опытом и очень выраженными лидерскими качествами.
В разных компаниях список того, с чем сталкивается лидер, может быть разным, но есть некоторые общие обязанности:
Работа с командой. Это как найм, так и увольнение сотрудников, онбординг, назначение задач, лидерство, решение конфликтов и тд и тп.
Работа с продуктом. Это разбирательство в бизнес-процессах, целях, понимание того, что нужно клиенту, управление бэк-логом.
Поддержка функционального качества. Это тестирование и устранение проблем.
Поддержка технического качества. Это обеспечение оптимизации и поддержки кода, работа с техническим долгом, разработка архитектуры проекта, написание технической документации, обеспечение отказоустойчивости и производительности проекта.
Автоматизация разработки. Это поднятие и настройка CI и CD.
Административные обязанности. Это ведение проекта, улучшение этого процесса и метрики этого.
Обеспечение крепких, доверительных связей внутри команды. Это и сочувствие, и нахождение компромиссов, и умение отстоять интересы компании.
Если у специалиста есть нужные качества или хотя бы задатки лидера, то подтянуть себя до хорошего уровня руководителя он может за срок от 5–6 месяцев до года интенсивной работы над собой, конечно если есть еще и наставник. И по прошествии этого срока, вероятнее всего, он осознает, что делал многое не так, поэтому захочет пересмотреть свой метод управления и принимаемые им решения.
Пару примеров:
Когда лидер не уверен в себе.
В некотором государстве… В одной компании работал хороший программист. Он показывал супер результаты и постоянно проявлял инициативу. И как следствие, его выдвинули в тимлиды. Ну и он не отказался от такой чести и дал свое добро на это., но шло время и он частенько сомневался в принятых им управленческих решениях и всё чаще старался обходить стороной необходимость принятия решений. С ним приходилось постоянно обсуждать разные проблемы, чтобы помочь найти корректное решение.
По итогу, пришлось провести с ним беседу, где обсуждались не его задачи по проекту, а те цели, которых он стремиться достичь. Также рассмотреть методы, которые он собирается применять для достижения этих целей. Обговорить всё, что входит в его ответственность и что он должен сделать, для достижения цели — стать хорошим тимлидом. Как надо решать конфликты в команде, согласовывать спринты с ПМ-ом, обсуждать с ребятами повышения и тд и тп. После такого общения, тимлид вышел окрыленным, законспектировал большое количество заметок и отправился все это переваривать, чтобы начать применять все это со следующего дня.
Но… Утром следующего дня, тимлид пришел, поблагодарил за всё и попросил вернуть его на стези своя, то есть обратно в сеньоры. Он понял, что не готов стать тимлидом.
Тимлид с малым тех-стэком.
В очередной компании, на большой и сложный проект, решили назначить тимлидом мидла с хорошим менеджерскими скилами. И, через короткое время, стало ясно, что с этим назначением поспешили. Тимлид не обладал нужным авторитетом для того, чтобы управлять остальными разработчиками. У него не получалось принимать важные для команды технические решения, поскольку он раньше с такими не сталкивался. Банально не хватило технического опыта для управления процессами, и с этой стороны возникли проблемы. В итоге компании пришлось с ним расстаться.
Тимлид, который любил поплакать.
В следующей компании разработчик стал тимлидом и со старта начал все критиковать и возмущаться на то, как все ужасно устроено на проекте, вместо того, чтобы начать руководить и управлять процессами. Он постоянно ожидал, чтобы кто-то пришел и решил имеющиеся проблемы вместо него. В принципе, он был хорошим исполнителем и хорошо реализовывал задачи, главное, чтобы кто-то уже продумал и расписал их. Но он не был готов делать это все сам. Проработал он недолго…
Идеальный тимлид.
В компании появился новый разработчик. У него получилось с самого начала проявить себя с лучшей стороны. Он постоянно проявлял инициативу, ответственность, старался подсказывать где что и как надо сделать лучше для разных процессов. Ему предложили стать тимлидом на другом проекте и не пожалели. Он проявил себя хорошим руководителем. Так, с самого старта он смог принять несколько важных решений, внес в процесс разработки автоматические тесты, откорректировал метрики производительности команды и взял на проект новых хороших разработчиков. И за небольшое время у него получилось откалибровать все процессы. Команда работала без заминок, заказчик был счастлив от прогресса. Заметив такие результаты, новоиспеченного тимлида повысили до руководителя отдела, прогнозируя, что он сможет применить свои подходы и навыки и на других проектах.
Делаем вывод:
Хороший руководитель обязан:
Хорошо ощущать необходимость в принятии того либо иного технического решения и уметь ответить за него.
Уметь хорошо управлять людьми и повышать этот навык.
Всегда быть готовым к:
распределению задач, а не все пытаться сделать сам.
общению с командой, а не просто отписаться в тикете.
принятию решений в разных условиях, даже если нет необходимой информации и брать на себя ответственность.
принятию сложных решений: повысить в должности, уволить сотрудника, переводы сотрудников из проекта в проект.
замечать и минимизировать риски.
Если хоть по какому-то пункту тимлид не справляется, вполне законно можно ожидать проблем. Например, если есть проблемы при управлении временем, то тимлид может браться за много задач, ручаясь, что сможет выполнить их за короткое время. И когда станет ясно, что это не выполнимо, сразу начнут портиться отношения с командой, руководством. И как следствие, человек начнёт много перерабатывать и быстро выгорит, либо разочаровавшись в себе уволится.
Если у тимлида нет достаточного опыта для решения конфликтов, то ему придется прибегать постоянно к помощи других, у которых есть подобный опыт. А команда, под его началом, станет неэффективной, атмосфера станет нездоровой, члены команды станут увольняться.
А ведь это только пару примеров, в которых видны проблемы, которые возникают у слабо-прокаченного руководителя.
Как специалист, он может быть суперменом, но это никак не поможет при решении организационных и бизнес процессов.
Скилы руководителя
Теперь, учитывая все выше написанное, мы можем сформулировать список тех скилов, которые так необходимы для руководителя:
Сочувствие. Так как надо постоянно работать с разными людьми. Пытаться помочь им, поддержать в сложной ситуации, давать фидбэк, решать конфликтные ситуации.
Решительность. Руководитель обязан быстро решать появляющиеся проблемы, несмотря на то, что может не хватать нужной информации.
Контроль времени. Так как всегда задач больше, чем мы можем решить, надо четко понимать, что мы можем сделать, а что нет. И мы обязаны реально оценивать время, необходимое для решения задач.
Назначение задач. Это жестко связано с контролем времени. И надо научиться говорить «нет».
Устойчивость к стрессам. Без этого просто не реально долго и успешно работать сразу с кучей задач. Руководителей постоянно дергают. Зовут на обсуждения разных вопросов, звонят по телефону, скайпу и тд, пишут во всевозможные мессенджеры и на почту.
Системное мышление. Надо видеть реальную картину того, что происходит в команде, чтобы выявлять и решать проблемы и повышать качество процессов.
Планирование.
Самостоятельность. Надо уметь принимать решения не ожидая помощи извне, что кто-то придет и сделает все необходимое и проблема разрешится сама собой.
Несколько советов:
Не бойтесь ошибок. Лучше принять какое-то неверное решение, чем ничего не принимать вообще.
Не бойтесь признаваться команде, руководству в том, что вы что-то не поняли или не знаете. Не надо стесняться просить о помощи. А при возникновении сложных ситуациях стоит взять перерыв и отправиться к коллегам или руководству за советом. Чаще всего это помогает разрешить проблему.
Научитесь принимать критику, советы и предложения.
Отмечайте удачные решения ваших коллег и руководства. Берите их на вооружение и используйте их когда возникнет такая необходимость.
Старайтесь постоянно повышать ваши скилы, как сами, так и с помощью ваших коллег или курсов.
Современный мир — сложный, динамичный и постоянно меняющийся. И именно в таком мире нам надо организовывать процессы по разработке ПО. Причем не просто какие-то, а успешные процессы, которые обеспечат повторяемость результата и стабильность, которые будут устойчивы к масштабированию и будут на 100% использовать потенциал сотрудников. Приглашаю вас на бесплатный вебинар, который уже 13 апреля проведут мои коллеги. На вебинаре поговорим о том, какие подходы, парадигмы и модели используются при разработке ПО, и как выбрать адекватную модель. Затем мы разберем принципы Agility гибкого подхода к разработке и посмотрим на устройство Scrum framework. Регистрация доступна по ссылке.
