Бизнес как море: 5 советов по управлению командой, чтобы не потопить проект

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

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

Почему я считаю роли шкипера и менеджера похожими:

• Шкипер и менеджер управляют командой из 5-7 человек.
• В обоих случаях у команд есть цель, маршрут к ней, ограниченные ресурсы и дедлайны. 
• Лидер опирается на регламенты, но в остальном лавирует между компромиссами.
• В управлении командой больше индивидуального подхода.

Убедитесь в готовности инфраструктуры и ресурсов команды

В море можно положиться только на лодку и на себя

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

Двигатель работает, система охлаждения в норме, паруса целы, масло и топливо запасли. Остается главное — команда.

Каждый человек должен понимать, за что отвечает, как пользоваться общими территориями лодки и куда она «плывет». 

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

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

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

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

Допустим, проект стартует завтра. Кто из перечисленных специалистов должен выйти в проект на full-time: инженер, дизайнер, верстальщик?

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

По моему опыту, верстальщик первые два-три месяца вообще не задействован — работать-то не с чем. У него начнется аврал, когда клиент согласует все макеты. 

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

Читайте также:

«Не отправляйте такого сотрудника в отпуск»: 5 советов для руководителей, как работать с человеком в депрессии

7 методик, чтобы находить выход из сложностей — на случай кризиса и резких изменений

Не теряйте голову в критических ситуациях и ищите компромиссы

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

В море. В море случается всякое, например, лодка потеряет основной парус. Неприятно, но поправимо. Среди очевидных решений шкиперу на ум придет два варианта:

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

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

Скорее всего, инженеры будут обеими руками за новый парус, но отвечать за раздутый бюджет не им. Для справки: вызов вертолета на короткую дистанцию стоит примерно $3 тысячи, плюс не забываем про парус.

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

Повторюсь: важно быть честным с заказчиком, командой и самим собой. Если курс на Магадан, не надо делать вид, что плывем на Майорку.

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

Логика такая: честные цели → адекватный план → реалистичное риск-планирование → нормальные компромиссы. Между нормальной сборкой сегодня и идеальной завтра практически всегда лучше выбрать первый вариант. 

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

Контролируйте и направляйте, даже отстающих

Лучше не рубить с плеча, а спокойно поговорить с «отстающим»

В море. Если член команды не справляется, с этим придется что-то делать. За борт человека не выкинешь — здесь только разбираться, переучивать, мотивировать, кричать. В общем, подчеркните понравившийся вариант. 

В проекте. Новая команда — это всегда минное поле. Может оказаться, что конкретный сотрудник показывает низкий KPI потому что нормально работать не умеет. Что делать?

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

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

Однако прогресс по спринтам не всегда очевиден. На старте код только пишется и «пощупать» функционал получится не сразу. 

Здесь возможны два варианта:

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

Обе опции возможны, все зависит от состава команды.

Читайте по теме: Можно или нельзя? 4 правила сокращения и увольнения сотрудников

Видеть слабые звенья

Детальный просчет рисков съест драгоценное время, но ощутимого результата не принесет

В море. Смотрим на критические места, где у нас потенциально может возникнуть сложность. Заметьте: мы говорим не «что пойдет не по плану», а «где скорее всего пойдет не по плану».

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

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

Верно: понимать, что делать, если паруса не станет, якорь потеряем, а команда заболеет.

В проекте. Мы запросили доступы к «боевому» серверу клиента, на котором планировали тестировать сборку продукта. 

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

В другом проекте клиент кормил завтраками полгода, а в итоге ничего не дал. Точнее, поделились доступом на уровне «читатель». Естественно, развернуть сборку не получилось. 

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

Общайтесь с командой как друзья

В небольших проектах команда становится практически семьей и это нормально

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

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

В проекте. Частное мнение: большинству команд не нужны бесконечные тимбилдинги, акценты на ментальном здоровье и прочая HR-магия. Команду насильно не подружить.

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

Идеально, когда руководитель видит не «Разработчика №1» и «Инженера №2», а живых людей с именами, уникальным характером.

Как получить максимум

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

Скачать чек-лист можно здесь.

Фото на обложке и в тексте предоставлены автором