Всё, везде и сразу про управление командами12.02.2024 12:30

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

Общее — нужен крутой бренд компании, чтобы кандидаты хотели у вас работать. Эту часть IT-компании закрывают с успехом — печенюхи, релакс-комната, кухня, отсутствие дресс-кода и неформальное общение. Я бы даже сказал, что эта тема устарела и сегодня картина развернулась на 180. Сегодня наличие плюшек считается нормой и не вызывает эмоций. А вот отсутствие — сразу вызывает негативное отношение. Подробно часть про бренд рассмотрена в книге Лорейн Грабс-Уэст.

Другое общее — нужно нанимать приятных людей. Тут я согласен. Мы часто берем сотрудников, которых обучаем сами. Поэтому для нас в первую очередь важно умение учиться, добросовестность и в целом первое впечатление. За 4 года у нас было 40+ наймов. Из них с таким подходом нам не подошли 4–8 (я дед и не выпил таблетки для памяти) человек. Можно по-разному оценивать, много это или мало. Но не, кто остался, стали хорошей эффективной частью компании.

Прописная истина — в команде важно доверие, личные отношения, настроение. Но что делать для достижения этих целей? Тут уже становится интереснее. Особенно в контексте IT-разработчиков. Само собой всё не придет. Нужно по-честному выделять время.

В книгах предлагается много подходов:
1. Для новичков выделяется ментор, помогающий сориентироваться в команде
2. Собираются неформальные встречи, чтобы кратко поговорить про личные интересы
3. Создается инструмент для обратной связи коллегам
4. Проводятся тимбилдинги. Нужно смотреть на тимбилдинг, релевантный именно вашей команде.
5. Культура компании выстраивается так, чтобы люди не боялись критики, а критика была обоснованной
6. Сюрпризы, дни рождения, чаепития и прочие мелочи

И много другого. Наша компания использует практически всё из этого. За стенами офиса большая часть команды — друзья. Мы ходим на дни рождения друг друга, в бильярд и просто тусить.

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

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

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

Что для этого предлагают:

1. Составляются матрицы компетенций. Да, отдельная история про их объективность и постоянную актуализацию. Мы их используем и не сказал бы, что очень довольны.

2. На их основании составляются карты развития сотрудников. У себя не пробовали, не знаю.

3. Покупаются книги, оплачиваются курсы.

4. Проводятся встречи 1 на 1. Полезно, легко, можно погуглить. Я использую метод бутерброда — хвалим, даём критику, заканчиваем позитивно.

5. Постоянное улучшение процессов на основе пожеланий команды

6. Командные обучения. Тоже аккуратно, чтобы не уйти в карго-культ. Нужно отталкиваться от пожеланий и готовности команды.

Мне не близок беспощадный подход Netflix и Дж. Рейнвотер «Как пасти котов». И я не согласен, что безупречность/элегантность решения всегда лучший путь. Не всегда мы влияем на сроки. Не ко всем решениям нужно быть столь требовательным. Но в общем случае соглашусь.

Причем тут годовое планирование? Оно непосредственно влияет на планы развития команд. Горизонт более квартала полон неопределенности. Например, не стоит планировать карту развития компетенций разработчика на год вперед. Через квартал вы можете начать писать на Go. Можно ставить общие цели компании на год, но не стоит планировать глубоко. Вы потратите время, а через квартал всё перепишете. Особенно это актуально в IT-компаниях, где конкуренты, рынок, технологии меняются по щелчку (не Таноса, но путь в IT — сама неотвратимость).

Говорят, что у кого-то планирование на год вперед работает. Иногда это удача, а иногда особенность специфики компании. Например, если вы B2G, то иногда (никакой политики) в чем-то можно быть уверенным.

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

Всего два тикета. Но чёрт возьми, да! Зачем плодить постоянные встречи, отнимающие время. Всё просто — если нужны периодические встречи, то делайте раз в неделю, не чаще. Иные встречи согласуйте в чатике со своей командой.

С другой стороны — общаться и делиться опытом нужно для поддержания атмосферы в команде и снижения бас-фактора. Просто не переусердствуйте.

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

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

Можете тут почитать про породы программистов из Дж. Рейнвотер «Как пасти котов». Довольно интересно, часть даже помогла мне.

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

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

Лидер и руководитель — роли, часто совмещенные в одном человеке. Но не всегда это так. А если не так, то сигнал ли это, что у нас проблемы? Не всегда. Но важно, чтобы лидер команды и руководитель двигались в одном направлении. Один говорит, куда идти, другой — мотивирует команду идти туда вместе.

И все мысли из книг примерно об одном. Помогайте команде, будьте рядом, не отдаляйтесь от специфики, не бойтесь делегировать, не бойтесь показать слабость (аккуратно). Неустаревающая иллюстрация:

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

Обратная связь — это тоже столп для процессов коммуникаций. Мы проповедуем ОСВК — обратную связь высокого качества. Важно отметить старания человека, даже если цель не достигнута. А критику стоит давать объективно, безэмоционально. Желательно сразу с предложением решения проблемы.

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

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

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

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

1. По направлению. Давление снаружи команды от руководства — это плохо. А давление изнутри (требовательность членов команды друг к другу) — это хорошо.

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

3. По частоте. Редкое слабое давление снаружи и сверхурочная работа могут помочь команде сконцентрироваться. Если делать это часто — эффект пропадет и демотивирует.

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

Интересное предположение из Deadline — команды без жестких сроков заканчивают быстрее. Тут на моей практике согласиться сложно. Срок нужен, но можно использовать его в своих интересах. Например через Objectives and Key Results ставить мотивирующий команду срок. Или ставить их нежестко, определяя период.

Том ДеМарко подсвечивает, что иногда бороться с давлением сверху очень сложно. Иногда невозможно. И здесь появляется единственный пример, когда практика избегания конфликта оправдана. Попробуйте его разрешить пару раз. Но если сверху злюка/тиран, то нужно искать другие пути решения. Прочитайте роман Тома ДеМарко — там интересный пример решения этой ситуации — там выделили 2 команды. Одна решала задачи так, как просило руководство — с бюрократией, ненужными обучениями, плохими процессами. А вторая по-настоящему двигалась к цели. Если итог такого эксперимента не изменит ситуацию, то надежды и правда нет.

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

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

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

Также можно мотивировать сильными целями. Например, OKR (Objectives and Key Results) мотивирует больше, чем SMART. Важно поставить цель выше, чем вас могло бы удовлетворить. Например, решение нужно через полгода, а по OKR можно попробовать сделать за 3 месяца. Но тут есть ловушка. OKR очевидно работает лучше для компаний, старающихся делать инновационные продукты. Цель «сделать ChatGPT первыми в мире» мотивирует бесконечно. Тут нужно подобрать свой подход и смотреть, работает ли.

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

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

Пока не могу понять, управление рисками правда так всемогуще или нет. Про риски я читал десяток статей и наша компания проходила обучение. Однозначно, выписывание рисков — это очень полезно. Мы можем найти критический путь задач, лучше оценить сроки, понять стейкхолдеров и составить план Б. И мы это используем. Отдельно отмечу, что простой матрицы вероятности рисков недостаточно. Для каждого риска стоит расписать силу влияния, вероятность, причину, способ избегания, реакцию в случае происшествия и ответственного. Но достаточно ли этого для управления проектом?

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

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

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

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

Компания никогда не станет инновационной и сильной, если люди боятся риска и ответственности.

Желание брать ответственность следует за доверием в команде и способностью решать конфликты. Обратите внимание на иерархию пороков в 5 пороках команды. Не разобравшись с пороками внизу по иерархии будет невероятно сложно бороться с пороками сверху.

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

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

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

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

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