Апр. 01

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

Приветствую. Меня зовут Константин, тружусь в DataArt, занимаюсь фронтендом. В разработке с 2011 года и за это время прошел путь от создания сайтов на коленке до полноценной разработки больших и сложных штук, преимущественно клиентской части. Есть опыт работы как в маленьких компаниях, так и в крупном аутсорсе, а также на фрилансе. И за это время сталкивался с «менеджерами здорового человека» и с «менеджерами курильщика» или вовсе с курильщиками без менеджеров. В статье попробуем разобраться в том, как менеджеры могут подружиться с разработчиками ради общего результата, а не «эффективно» менеджить.

Иллюстрация Марии Рыбак

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

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

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

Итак, поехали.

Чего ожидает команда от коммуникации с клиентом

В работе над проектом участвуют две стороны — заказчик и исполнитель. Сторону клиента для вас может представлять PO (Product Owner), PM (Product Manager) или владелец бизнеса, это не так важно. Главное не забывать, что в мире всегда есть человек, для которого вы делаете проект, и он ожидает определенного результата. Даже если вы напрямую общаетесь с клиентом, это еще не означает, что вы знаете того, кто заказал проект. Ведь человек, с которым контактируете вы, может также служить исполнителем для своего клиента. Но мы для простоты будем считать, что заказчик — это тот (клиент), от которого мы получаем всю первичную информацию по продукту, из чего формируем техническое задание, выделяем задачи и так далее. Даже если мы делаем какой-то собственный продукт или даже пет-проект, заказчик у нас все равно есть — в таком случае мы сами в его роли и выступаем.

С другой стороны находится исполнитель. Это команда, куда могут входить не только разработчики, но и дизайнеры, тестировщики и другие специалисты. Все они заинтересованы в том, чтобы выполнить работу и добиться запланированного результата с минимальными потерями [шутка. Или не совсем?].

В качестве исполнителя будем рассматривать условную команду разработчиков, состоящую из: Front-end, Back-end, QA, UI/UX и Project Manager.

Менеджер обычно находится рядом с командой. Но временами только территориально. Иногда команда или клиент видят роль менеджера в том, чтобы отстаивать интересы одной из сторон. Это, как по мне, не очень полезная для проекта позиция. В словосочетании «клиент и команда» менеджер — это «и»: связующее звено между хотелками первого и возможностями второй. Не все требования или пожелания можно реализовать в силу специфики конкретного проекта или, к примеру, недостаточной квалификации специалистов. Нужно уметь вовремя это понять и честно признать. По крайней мере между собой.

Задача менеджера в процессе коммуникации — понять, чего именно хочет заказчик, донести общие идеи до команды разработки и сформулировать конкретные задания. Без этого «кина не будет». Многие разработчики привыкли к режиму солдата-срочника: могу копать — могу не копать, и это нормально. Выходить за рамки своих компетенций и ответственности бывает похвально, но не всегда одинаково полезно для проекта. Задача разобраться в том, какими ресурсами располагает команда, и распределить их наиболее правильным образом ложится на плечи менеджера. При этом он должен максимально точно сформулировать требования бизнеса, оставив технические детали тимлиду.

Рассмотрим ожидания сторон на простых примерах.

Вопросы, которые стоят перед клиентом:

Чего именно я хочу?
Какого результата я жду от команды?
Насколько я готов слушать команду?
Каков минимальный допустимый уровень качества продукта?

Вопросы, которые стоят перед командой:

Чего клиент хочет от нас?
Какой функционал критически важно реализовать?
Насколько гибкие требования заказчик предъявляет к продукту?
Каков необходимый объем тестирования?

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

К примеру, вашей команде, которая разрабатывает веб-приложение с поддержкой мобильных устройств, поступает срочная задача. Клиенту понадобился лендинг для промо, сроки сжатые, успеть к назначенной дате запуска очень важно. Вы сдаете работу вовремя, но заказчик неприятно удивлен: выглядит она криво. Оказывается, Product Owner или, скажем, CTO на той стороне привык заходить на сайт с айфона, а ваш дизайнер не дал задание на адаптацию. Теперь придется разбираться, кто виноват и что делать.

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

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

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

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

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

Зачем менеджеру знать о технологиях и уметь пользоваться инструментами

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

При этом о написании кода или настройке деплоя я не говорю. Если менеджер вашего проекта этим занимается, да еще не имея такого опыта в прошлом — что-то определенно идет не так.

Но если менеджер может отличить фреймворк от библиотеки, это поможет:

лучше владеть ситуацией;
понимать сферы ответственности в команде;
быстрее и адекватнее реагировать на запросы/вопросы клиента или изменения в команде;
быстрее понимать новые процессы и оставаться с командой на одной волне.

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

Типичные варианты таких «заруб»:

Front vs Back;
Front vs Design;
Dev vs QA.

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

К примеру, бэку лень чинить свое и он сваливает работу на фронта. Фронт говорит, что сбой происходит на бэкенде. Если никто не признает, что проблема возникла на его стороне, разбираться, кто же должен ее решить, придется PM. Определить источник бывает несложно, если мы понимаем, за какую часть проекта отвечает конкретный разработчик и какие технологии используются. Допустим, если после открытия ссылки с вашим веб-приложением вы видите ошибку 500 или 502, проблема однозначно на стороне сервера и решать ее бэкенд-разработчику. Перевести стрелки не получится, если менеджер четко обозначит, что он не просто поверил одной из сторон конфликта, но и сам прекрасно видит источник неполадок.

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

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

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

Как получить от команды адекватную оценку

Оценка задач — отдельное умение, которым не всегда владеют даже самые опытные специалисты. При этом от ее точности может зависеть успех всего проекта, а значит и команды. Ведь если мы попали в нужную оценку, клиент доволен. Если нет — недоволен. А довольный клиент лучше недовольного. Заявляю со всей ответственностью!

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

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

На что стоит обратить внимание при оценке:

Что нужно сделать?
Как это должно работать?
На что повлияют нововведения?
Где может поломаться?

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

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

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

Какие вопросы менеджеру стоит задать разработчикам, принимая у них оценку новой задачи:

Все ли нужные доступы у вас есть?
Вы уверены, что учли все возможные факторы?
Мы точно уложимся в срок?
Что будет, если в срок мы не уложимся?

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

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

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

Чем помочь команде в момент аврала

Наверняка каждый из нас бывал в ситуации, когда нужно срочно запилить/допилить важный функционал или поправить что-то важное, но поломанное, на проде. То есть вокруг все горит, команда загружена на 100 %. Здесь хороший РМ задает себе вопрос: чем я могу помочь, если все в мыле? Вся нагрузка ложится на плечи технических специалистов, задач непосредственно для менеджера вроде бы не остается. У тех из них, кто не склонен задумываться, реакция на эту неопределенность простая и эмоциональная — они бегают между разработчиками и рвут на себе волосы. Но если остановиться и выдохнуть, вполне можно найти, куда приложить силы и что полезного для проекта сделать.

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

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

Что остается в этом случае:

Не мешать.
Следить за уровнем стресса в команде.
Оперативно реагировать на запросы клиента.

Конечно, просто не мешать — совет простой, даже очевидный. Но я серьезно. Иногда ничего не делать — лучшее, что мы можем сделать.

Как РМ может мешать?

Каждые 15 минут интересоваться: «Ну как там дела?»
Просить ускориться, потому что сроки горят!
Просить перепроверить еще раз то, что все уже и так перепроверили.

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

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

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

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

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

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

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

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

Мы умеем работать руками

Тестирование.
Проверка спецификаций.
Зачистка логов.

Маловероятно, что менеджер достаточно подготовлен, чтобы писать код или заниматься UI/UX, даже если он из «бывших». Даже при наличии соответствующего бэкграунда быстрая реакция на проблемы, возникающие в режиме аврала, требует слишком глубокого погружения в проект.

Однако PM, хорошо знакомый с технической стороной работы, точно может помочь — прежде всего с мануальным тестированием. Я сам работал в проекте, где была всего одна QA-специалист, хотя команда состояли из 10 человек. Но в ситуациях максимальной загрузки подключалась наша РМ: проводила мануальное тестирование, составляла баг-репорты с описанием, скриншотами и видосиками — все как положено. Потому что могла, потому что нормально оформляла стори/таски, вникала в технические спецификации и была готова помочь, когда в этом возникала необходимость. Хотя формально могла в это время гулять в парке или просто нервно пить кофе. То есть заниматься действительно важными делами, а не вот это вот все.

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

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

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

С каким менеджером команда будет работать эффективнее

Если совсем коротко, можно процитировать классику: «Нормально делай — нормально будет». Но я попробую немного раскрыть тему.

Нам всем хотелось бы видеть рядом с собой профессионалов. Если разработчику кажется, что менеджеры в принципе не нужны, скорее всего, у него просто ни разу не было нормального менеджера. Или последний опыт взаимодействия с плохим PM оказался настолько травмирующим, что прочие просто забылись. Я уверен, что позицию менеджера проекта придумали не просто так. Более того, если вдруг у вас в команде она не предусмотрена, это значит только то, что обязанности PM выполняет кто-то другой. Между тем каждый должен заниматься своим делом.

С каким же менеджером команда будет работать эффективнее? Ответ на поверхности — с хорошим. Только кого можно таким назвать?

Хороший менеджер профессионально выполняет свои обязанности, он не процессит, а стремится к результату и всегда отстаивает интересы проекта. Да-да, именно проекта, а не команды или клиента. Если менеджер помогает тянуть одеяло на одну из сторон, проект непременно пострадает. Это как в спорте: если судья подсуживает одному из участников соревнований, жертвой становится не только его соперник, но и вид спорта в целом.

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

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

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

С клиентом договорились, обсудили, а все равно допустили грубейшую ошибку. Это не было зафиксировано в переписке! Ну вот так получилось.

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

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

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

К чему это я? Конкретно в этой ситуации принять сторону проекта означало поддержать команду. Я говорю так не потому, что сам был ее частью, а потому что предложенное ей решение было обоснованным и действительно пошло проекту на пользу. Менеджер при этом имел возможность слиться при появлении недовольного CTO, сделав крайними технических специалистов. Но наш был не из таких и всячески старался разрешить возникший конфликт. После нескольких горячих митингов мы ситуацию разрулили. Хотя осадочек, как говорится, остался.

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

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

Для команды важно и то, как ведет себя менеджер, если пришлось засидеться допоздна, допиливая что-то к релизу. Мой товарищ из РМ’ов делал следующее: если разработчики остались в офисе до позднего вечера пятницы (ну бывает, что и так нужно), он вместо того, чтобы убежать домой и задалбывать их по скайпу, шел в ближайший магазин. Там он на личные средства покупал пиво и снеки, а дальше рубился вместе с командой до конкретного результата. Разработчики при этом «топили» даже яростнее, чем в обычных условиях. Они искренне старались сделать все как надо и показать менеджеру, что они оценили его жест. Тоже вполне искренний.

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

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

P. S. Если вам интересно, с каким менеджером команды работают менее эффективно, об этом был отдельный материал.