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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Больше статей у нас на канале: https://t.me/truebusiness