Как управлять командой на проекте

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

27
Как управлять командой на проекте

Я пять лет проработала менеджером проектов в креативных агентствах.

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

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

В чем проблема с управлением командой

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

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

  • я сказал им сделать, а они не сделали. Теперь я теряю деньги, время, клиента и веру в людей;
  • я сказал им сделать, они сделали, но не то, что надо было;
  • я сказал им сделать, они сделали, но ничего не сказали. Поэтому я думал, что не сделали;
  • все поругались и не разговаривают друг с другом;
  • непонятно, где найти последнюю правку макета;
  • дизайнер посмотрел правки, обиделся и не хочет ничего исправлять;
  • заказчик передал комментарии, которые никто не понял. Уточнять не стали, но на всякий случай что-то исправили. Потом выяснилось, что заказчик хотел совсем другого;
  • наш редактор — на удаленке. Он вообще работает или на пляже отдыхает?
  • разработчики простаивают, потому что ждут макеты от дизайнера, а тот никак не может согласовать их с арт-директором;
  • через месяц после того, как мы сдали проект, заказчик попросил внести правки. А исходные файлы куда-то пропали, и мы неделю их искали.

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

Планируйте проект вместе с командой

Я не сторонник диктаторского подхода, когда руководитель спускает план сверху и ставит сотрудников перед фактом: «Это нужно сделать до вторника, а вот это — уже к завтрашнему дню. Что значит „нереально успеть“? Я вам плачу за работу, а не за рассуждения о том, что реально, а что нет».

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

А еще такой подход добавляет команде мотивации и ответственности. Специалисты работают не по моему плану, а по своему: они придерживаются сроков, которые сами предложили.

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

Схема обычно такая:

  1. Я описываю задачу.
  2. Специалист дает оценку.
  3. Я задаю уточняющие вопросы, если не понимаю, почему оценка именно такая.
  4. Если нужно, корректируем оценку.

Вот как я это делаю:

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

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

  1. Договориться с заказчиком об изменении объема: «Давайте сделаем одну страницу, самую важную».
  2. Изменить глубину проработки: «Сделаем обе страницы, но без проработки деталей макета».
  3. Договориться с еще одним дизайнером или арт-директором, чтобы они работали в четыре руки и сделали оба макета за неделю.
  4. Найти подрядчика, который справится за неделю.
  5. Попробовать договориться с другими менеджерами об изменении приоритетов, если дизайнер отодвигает сроки из-за того, что занят на других проектах.
  6. Попросить дизайнера выйти в выходной. Я очень не люблю такие случаи, но иногда это единственный вариант. Главное правило: все переработки должны быть добровольными и оплачиваемыми.
Больше историй о бизнесе — у вас в почте
Подпишитесь на рассылку для предпринимателей: раз в неделю присылаем важные новости и истории успеха

Обозначайте роли на проекте

Если упростить, то на любом проекте можно выделить три роли:

  1. Заказчик — отвечает за бизнес-задачу.
  2. Руководитель проекта — управляет командой так, чтобы получить классный результат и при этом уложиться в срок и бюджет.
  3. Специалисты, которые делают работу.

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

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

Планируйте нагрузку специалистов

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

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

Скриншот из сервиса планирования команды. Розовым цветом выделены мои проекты, фиолетовым — проекты коллеги, серым — отпуска, а рыжим — время на обучение и помощь членам команды. Красный значок с надписью 2 over означает, что объем задач на два часа превышает продолжительность рабочего дня. Это простительно, ведь план составлен на три недели — мы его еще пересмотрим
Скриншот из сервиса планирования команды. Розовым цветом выделены мои проекты, фиолетовым — проекты коллеги, серым — отпуска, а рыжим — время на обучение и помощь членам команды. Красный значок с надписью 2 over означает, что объем задач на два часа превышает продолжительность рабочего дня. Это простительно, ведь план составлен на три недели — мы его еще пересмотрим

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

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

Долгосрочное планирование времени всей команды — удобная и полезная вещь. Она позволяет предсказать и предотвратить следующие проектные проблемы:

  1. Сотрудник внезапно ушел в отпуск. Если в планировщике забронировать отпуска заранее, то внезапности не будет. Мы видим, кто когда отдыхает и как это влияет на сроки проекта.
  2. Два проекта наложились друг на друга, никто ничего не успевает. При планировании видно, хватает ли ресурсов для решения всех задач. Если нет, то можно заранее нанять еще одного сотрудника или перераспределить ресурсы.
  3. Специалисту нечем заняться. Если мы заранее знаем о простое, то можем придумать, как использовать это время с пользой для сотрудника и компании. Например, потратить на обучение или внутренний проект фирмы.

Внятно ставьте задачи

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

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

  1. Конкретной (specific) — понятно, что именно нужно сделать и зачем. Объясняйте максимально подробно, потому что люди не умеют читать ваши мысли. Представьте, что загадываете желание злому джину: не давайте шансов исказить смысл и сделать что-то не так.
  2. Измеримой (measurable) — есть ясные критерии выполнения задачи. Без этих критериев исполнитель может думать, что все сделал, а на самом деле нет. Или же, наоборот, будет ждать правок, хотя менеджер уже давно закрыл эту задачу.
  3. Согласованной (agreed) — исполнитель четко и однозначно подтвердил, что все понял и забрал задачу в работу. Иначе возможны дурацкие ситуации. Например, менеджер написал дизайнеру, что нужно сделать макет, а тот промолчал. Менеджер решил, что молчание — знак согласия, и принялся ждать, но макета все не было и не было. В итоге выяснилось, что дизайнер просто не прочитал письмо, так как оно улетело в спам.
  4. Реалистичной (realistic). При постановке задачи учитывайте мнение команды: если специалист уверяет, что сроки нереалистичные, то стоит прислушаться и изучить его доводы.
  5. Ограниченной во времени (time bound). Если руководитель не согласовал с командой сроки, то проект обречен. «Не срочно» сначала превращается в «когда-нибудь», а потом — в «никогда».

Пример постановки задачи

ЗадачаПример
Даем конкретную задачуВася, нужно сделать баннер 3 × 6 м, согласованное ключевое изображение и слоган — во вложении. Верстка макета — на основе гайдлайна, он тоже во вложении
Ставим критерии выполнения задачиСначала делаем концепт — просто джипег и мокап, показываем клиенту. Потом доделываем и готовим к печати
Определяем ограничения по времениКонцепт нужен завтра до 16:00. Вечером покажем клиенту и послезавтра доработаем
Определяем, достижима ли задачаЧто думаешь по срокам, успеешь?
Согласуем задачу с исполнителемВсе понятно? Если нет, то жду вопросов. Если да, то отпишись, что взял задачу

Пример постановки задачи

ЗадачаПример
Даем конкретную задачуВася, нужно сделать баннер 3 × 6 м, согласованное ключевое изображение и слоган — во вложении. Верстка макета — на основе гайдлайна, он тоже во вложении
Ставим критерии выполнения задачиСначала делаем концепт — просто джипег и мокап, показываем клиенту. Потом доделываем и готовим к печати
Определяем ограничения по времениКонцепт нужен завтра до 16:00. Вечером покажем клиенту и послезавтра доработаем
Определяем, достижима ли задачаЧто думаешь по срокам, успеешь?
Согласуем задачу с исполнителемВсе понятно? Если нет, то жду вопросов. Если да, то отпишись, что взял задачу

Письменно фиксируйте задачи и договоренности

Когда все договоренности устные, получаются примерно такие диалоги:

  • — Игорь, сегодня уже десятое. Ты обещал запустить сайт девятого, а он до сих пор не работает. Почему?
  • — Саша, ты что-то путаешь. Я обещал не девятого, а девятнадцатого. И не октября, а ноября. Наверное, ты меня неправильно поняла.

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

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

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

Как ставить задачу: чек-лист для менеджера

Одной реальной задаче соответствует одна задача в таск-менеджере. Не стоит плодить лишние сущности и путать коллег.

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

Неверно: «Правки № 136 от Иван Иваныча».

Верно: «Внести изменения в логотип интернет-магазина игрушек для собак».

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

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

Вот так не надо: «Миша, поправь макеты в соответствии с гайдлайном. Макеты я скидывала на файлообменник, ссылка должна быть у тебя на почте, поищи. А сам гайдлайн был где-то на сайте. Если не найдешь, то свяжись с Васей: он вроде говорил, что у него все есть».

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

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

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

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

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

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

Есть просьба подтвердить, что задача принята. Нужно получить от исполнителя однозначное свидетельство, что он взял задачу в работу. Молчание — это не знак согласия. Согласие выглядит примерно так: «Все понял, материалов достаточно, вопросов нет, по срокам — ок, задачу забрал». Или в виде плюсика, как договоритесь.

Оберегайте команду от комментариев заказчика

Заказчик не обязан уметь формулировать комментарии так, чтобы они были понятны техническим специалистам. Если ему не нравится цвет, он может сказать: «Этот красный какой-то не такой, давайте что-то повеселее». Дизайнер читает эту правку и думает, что повеселее — это, например, желтый. Но на самом деле заказчик хотел просто сделать красный более ярким.

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

И задача менеджера проектов — перевести замечания с языка клиента на тот, что будет понятен команде. Когда я получаю правки, то делаю три вещи:

  1. Выясняю, что на самом деле означают комментарии клиента. Например, спрашиваю его: «А чем вам не нравится цвет? А какие цвета вы считаете веселыми? А вот посмотрите макет, который мы делали для одного банка. Там мы использовали желтый — как вам? А почему? А вы все макеты посмотрели или будут еще правки?»
  2. Снимаю неважные комментарии — бывают и такие. При обсуждении с заказчиком иногда выясняется, что это уже не нужно. Или нужно, но когда-нибудь потом. Или комментарии не очень важны, потому что их оставил не он, а кто-то еще. Или клиент внес замечания, поскольку думал, что нужно обязательно хоть что-то написать, а так-то ему все нравится.
  3. Важные комментарии дополняю, раскрываю и перефразирую так, чтобы было понятно, что с ними делать. Потом собираю их в кучку и отдаю команде.

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

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

Организовывайте рабочие процессы и общение на проекте

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

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

Обычно я организую три пространства для общения: доска проекта в «Эктив-коллабе», канал в «Слаке» и видеоконференции в «Зуме».

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

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

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

Канал проекта в корпоративном мессенджере «Слак» — здесь мы обсуждаем текучку и мелкие вопросы. Этот мессенджер не хранит переписку, поэтому все серьезные дискуссии и решения мы переносим из «Слака» в «Эктив-коллаб».

«Зум» используем для созвонов. Здесь есть свои правила: нельзя просто взять и позвонить человеку. Предварительно нужно списаться в «Слаке»: договориться о времени звонка и теме разговора. Это делается, чтобы не застать собеседника врасплох и не отвлечь от других важных дел.

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

Контролируйте работу над проектом

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

Контроль важен, даже если в вашей команде одни гении. Особенно если в ней одни гении.

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

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

Неправильно:

Правильно:

Разрешайте конфликты и проблемы

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

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

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

Задача руководителя — вовремя выявлять и разрешать проблемы и конфликты. Вот как я это делаю.

Решаю проблемы своевременно. Если вопрос возник сегодня, то и обсуждать его нужно сегодня. Бывает, что руководитель внезапно вспоминает о какой-то ситуации, которая произошла полгода назад, и вызывает работника на разговор. Обычно конструктивного диалога не получается, так как сотрудник уже забыл, в чем там было дело, — или делает вид, что забыл.

Неправильно:

  • — Юра, ты задолбал опаздывать, рабочий день начинается в 10:00, пора уже запомнить. С тобой одни проблемы!
  • — А какие еще проблемы?
  • — А помнишь, в позапрошлом месяце ты проигнорировал правки заказчика и сдал макеты, которые пришлось переделывать?!
  • — Да толком-то и не помню. О каком проекте речь? Вроде бы мне никаких правок не присылали.

Правильно:

  • — Юра, привет. Я хочу обсудить ситуацию на проекте «Ромашка»: вчера ты сдал макет без учета части вводных из задания. Давай обсудим, почему так произошло.

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

Неправильно:

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

Правильно:

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

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

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

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

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

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

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

Неправильно:

  • — Ваня, бесишь меня! Нельзя было, что ли, нормально сделать?

Правильно:

  • — Ваня, привет. Я хочу обсудить ситуацию на проекте «Ромашка»: у нас с тобой сорвались сроки. Давай обсудим? У тебя есть минут пятнадцать?
  • — Ну давай.
  • — Пойдем в переговорку тогда.
  • — Пойдем.
  • — Ваня, как ты знаешь, у нас был план проекта. Ты обещал сверстать две страницы до среды. Сегодня четверг, у нас нет ни одной страницы. Клиент немного в ужасе. Расскажи, что случилось? Почему не получилось?

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

Неправильно:

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

Правильно:

  • — Ваня, давай вместе разбираться, что именно не вышло. Боюсь, что если такое повторится — клиент от нас сбежит. Расскажи, с какими проблемами ты столкнулся, что непонятно? Покажи прямо на макете.
  • — Ну смотри, макеты какие-то кривые. Вот тут нет правильного шрифта и сетка странная.
  • — И правда. А чего ты сразу не спросил об этом меня или дизайнера?
  • — Думал, что разберусь, но не вышло.
  • — Ладно, поняла тебя. Давай так: сейчас я позову дизайнера, организуем созвон, обсудим твои вопросы. Потом перепланируем неделю, и я предупрежу клиента об изменении сроков. Договорились?
  • — Да, Саш, ок.
  • — Ваня, еще кое-что. Давай на будущее договоримся: если в задаче что-то неясно, ты сразу приходишь ко мне и говоришь. Не хочу, чтобы ты три дня пытался понять, что делать, и переживал из-за этого.
  • — Ну да, понял. Стеснялся просто.

Принимайте ответственность за все, что происходит на проекте

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

Звучит он так: менеджер отвечает за все, что происходит на проекте. Когда я это поняла и приняла, мне стало легче работать с командой, а команде — со мной. Если сотрудник не выполнил задачу или сдал результат с опозданием, отвечает менеджер. Если работа не устроила заказчика, то виноват не «криворукий дизайнер», а менеджер.

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

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

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

В итоге работник даст какое-то объяснение. Менеджер должен внимательно выслушать и понять, в чем ошибка и как ее исправить.

Как перевести объяснения сотрудников на менеджерский язык

Почему сотрудник не выполнил задачуНеправильный подход: виноваты все вокругПравильный подход: виноват менеджерЧто делать менеджеру
Думал, что нужно сделать что-то другоеСпециалист тупой и не понял задачуЯ не объяснил задачу по-нормальномуНаучиться ставить задачи и проверять, что они поняты
Не получилось, думал, что разберусь, но не смогСпециалист ничего не умеет, понабирают тут всякихЯ поставил задачу не тому специалисту

Я не предупредил специалиста, что нужно сообщать о проблемах и просить о помощи
Научиться правильно ставить задачи. Так, чтобы люди знали: в подобных ситуациях нужно не молчать, а бить в колокола и просить о помощи
Не нашел материалыНадо было в папке поискать, там же все есть. Эх, никто ничего не соображает, вот если бы все были умные, как яЯ не сделал так, чтобы у специалистов под рукой было все для работыОрганизовать систему хранения задач и материалов. Убедиться, что каждый сотрудник знает, как она работает. Внедрить шаблоны проектов
Не успелА в курилку сходить успел?!Я не распланировал нагрузку

Я не прописал четкий план с контрольными точками

Я не согласовал или не зафиксировал сроки проекта

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

Поработать над постановкой задач в части договоренностей о сроках

Объяснить работникам, что о возможном опоздании нужно предупреждать как можно раньше — до дедлайна, а не после

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

Как перевести объяснения сотрудников на менеджерский язык

Думал, что нужно сделать что-то другое
Неправильный подходСпециалист тупой и не понял задачу
Правильный подходЯ не объяснил задачу по-нормальному
Что делать менеджеруНаучиться ставить задачи и проверять, что они поняты
Не получилось, думал, что разберусь, но не смог
Неправильный подходСпециалист ничего не умеет, понабирают тут всяких
Правильный подходЯ поставил задачу не тому специалисту

Я не предупредил специалиста, что нужно сообщать о проблемах и просить о помощи
Что делать менеджеруРазобраться с компетенциями своих коллег. Брать в команду тех, кто может решать поставленные задачи

Научиться правильно ставить задачи. Так, чтобы люди знали: в подобных ситуациях нужно не молчать, а бить в колокола и просить о помощи
Не нашел материалы
Неправильный подходНадо было в папке поискать, там же все есть. Эх, никто ничего не соображает, вот если бы все были умные, как я
Правильный подходЯ не сделал так, чтобы у специалистов под рукой было все для работы
Что делать менеджеруОрганизовать систему хранения задач и материалов. Убедиться, что каждый сотрудник знает, как она работает. Внедрить шаблоны проектов
Не успел
Неправильный подходА в курилку сходить успел?!
Правильный подходЯ не распланировал нагрузку

Я не прописал четкий план с контрольными точками

Я не согласовал или не зафиксировал сроки проекта

Я как-то дал понять специалисту, что задача не очень важная, и этим его демотивировал
Что делать менеджеруПроанализировать причины опоздания

Поработать над постановкой задач в части договоренностей о сроках

Объяснить работникам, что о возможном опоздании нужно предупреждать как можно раньше — до дедлайна, а не после

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

Проводите ретроспективу проекта

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

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

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

Как руководить командой на проекте

  1. Планируйте проект вместе с командой, не будьте диктатором. Люди охотнее следуют плану, если сами участвовали в его создании.
  2. Прислушивайтесь к экспертным оценкам ваших коллег: они работают руками и знают, сколько времени занимает та или иная задача.
  3. Четко распределяйте роли и ответственность в команде, чтобы не допустить дезорганизации: она способна погубить проект.
  4. Организуйте рабочие процессы: команда должна понимать, где хранятся задачи и материалы, по каким правилам вы работаете, через какие каналы можно общаться.
  5. Ставьте задачи письменно. Не жалейте времени на их объяснение: лучше потратить час и все разжевать, чем потом потерять неделю на переделки и доработки.
  6. Не пересылайте специалистам сообщения от клиентов без обработки. Выступайте фильтром, который защищает команду от непродуманных задач и правок.
  7. Без контроля проект обречен на провал. Сложные задачи дробите на мелкие и для каждой подзадачи устанавливайте контрольные сроки.
  8. Не психуйте при решении конфликтов. Команда должна знать, что у руководителя всегда холодная голова.
  9. Используйте любые провалы, чтобы улучшить рабочие процессы и выполнять будущие проекты эффективнее.
  10. Руководитель несет ответственность за все, что происходит на проекте, — примите этот факт.
Расскажите, какие у вас обычно возникают сложности при работе в команде?
Комментарии проходят модерацию по правилам журнала
Загрузка
0

Добавил в закладки!
Очень интересная статья.
Я сам хоть и менеджер, но не проджект, хотя постоянно веду 3-5 проектов по работе, где координирую других людей. Просто заплакал дочитав "все поругались и не разговаривают друг с другом" - это прям вот иногда один из главных челенджей.

21
0

Я оооооочень надеюсь, что примеры общения с разработчиком/дизайнером/другим_членом_команды - это очень утрированные диалоги. Ибо я ощущал колоссальное эмоциональное давление, читая эти вопросы и способы согласования.
Может, конечно, я глубоко и не прав, но будучи разрабом, мне было очень тяжело от вопросов, вроде « а почему так долго», на которые я не знал правильного ответа, ибо рассказывая о рефакторинге, я мог натолкнуться на идею: «ну так давай забьем на рефакторинг». Если тимлид вовремя не включал музыку для драки с пиэмом, я утопал в потоке непонимания технических аспектов, прогибаясь - осознавал, что дальше мне будет еще сложнее вносить следующий пакет правок, а аргументируя, зачем мне вот нужно еще пару дней на правки - снова сталкивался с тем, что пиэм не может вникнуть в суть моей работы. Можете, конечно, сказать, что пиэм плохой достался - но нет, вполне обычный.
Став уже в дальнейшем сам пиэмом, я всегда старался придерживаться правила: «больше вопросов заказчику и меньше команде». Думать наперед, думать за заказчика, думать вместо заказчика, что будет, если захотят что-то еще добавить или убрать, чего не будет, что с чем будет взаимодействовать, что сломается и перестанет работать. Может, это и не работа пиэма, но в момент, когда это не надо, думать об этих вещах никто больше не будет. И команда потом будет чувствовать, что задача была опять сырой, и опять переделывать.
К команде я уже несу не хотелки заказчика, а тз, которое, мы будем вместе шлифовать, а если, возникают вопросы, о которых я не предусмотрел, то я их аккумулирую, и старюсь разобраться в области, в которой был задан вопрос, а не транслирую ответ исполнителя заказчику, иначе такая игра в испорченный телефон доводит до того, что заказчик ожидал «как-бы чуть-чуть другое, а не вот прям это вот». А так заказчик получит то, что ожидает, и команда меньше выгорает от этих ваших бизнес-требований.
Ну, и беграунд. Пиэм это не человек, умеющий в софтскилы и рисующий десять видов диаграмм Ганта, и замещающий ими все остальное, а человек, подкованный во всех производных ресурсах команды, и понимающий, зачем нужны компоненты в фигме, и что такое компоненты во вьюжс. Перт-таблички, это, конечно, красиво и хорошо, но слаженная работа команды, без поиска виноватых - вот это прям куда лучше.

21
0

23.11.20, 11:56

Отредактировано

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

Александра, вы сделали мою жизнь чуточку легче! Спасибо 💙

18
0

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

7
0

Класс, полезно) Спасибо!)

2
0

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

2

Olga, с позиции разработчика. ПМ не знающий базовых принципов, как делаются базовые вещи, горе в команде

5
0

— Ваня, привет. Я хочу обсудить ситуацию на проекте «Ромашка»: у нас с тобой сорвались сроки. Давай обсудим? У тебя есть минут пятнадцать?

Таких менеджеров с «Я хочу обсудить ситуацию» закопать хочется уже после второго захода)))

2

Денис, а вы как предлагаете решать вопрос?

3
0

Как глава из книги, которую хочется прочесть полностью.

2
0
Легенда

+6

23.11.20, 18:40

Отредактировано

"Руководитель несет ответственность за все, что происходит на проекте, — примите этот факт." - вы забыли еще один важный пункт: успех проекта - это успех команды, а не руководителя.
Не освещено делегирование (а грамотное делегирование - это важно). А в целом - на штирлица пахнуло родиной, как же хорошо, что я больше не на галере)

1

Pavla, не "пахнуло родиной", а "рвало на Родину" ))

0

ilya, не переживайте, я использую штирлица и в неточных цитатах, если мне этого хочется)

0

Pavla, эго чтобы не лопнуло от хотелки

0

Павел, мое эго ваши претензии на сарказм ест на завтрак)

2
0
Герой

23.11.20, 21:08

Отредактировано

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

1

Artur, почитайте https://www.amazon.de/Drive-Surprising-Truth-About-Motivates/dp/1594484805 Пинка, очень полезная книжка

3

Jane, прочитал первые 20 страниц. Уже открыл для себя новое

1

Jane, спасибо, почитаю

1

Artur, что вы знаете о видах мотивации?

0

Pavla, знаю, что есть материальная и нематериальная. Это слишком общий вопрос, нужна конкретика

0

Artur, какие виды нематериальной мотивации вы знаете, какие из этих мотивов у ваших сотрудников и удается ли вам их использовать?

0
0

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

1
0

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

1
0
Герой

23.11.20, 19:13

Отредактировано

Вопрос по подписке ActionCollab. Там написано, что 7 долларов за один месяц для одного человека. То есть, если в моей команде 10 человек, то каждому надо покупать подписку и тогда это станет 70 долларов в месяц?

Или я что-то не так понял?

0
0

Великолепное описание специфики данной работы. Читаешь и перед глазами личный опыт, очень схожий. Пожалуй одна из лучших статей ТЖ. Желаю автору успехов!

0

Вот что еще мы писали по этой теме

Сообщество