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

Рассказывает Ольга Цыганова, руководитель проектов в CUSTIS

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

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

Шаг 1. Оцениваем текущую ситуацию

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

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

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

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

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

Время. Человек, с которым вы общаетесь, должен быть в рабочем состоянии. Так что не назначайте встречи жаворонкам на конец дня, а совам — на раннее утро.

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

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

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

Шаг 2. Составляем «карту местности»

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

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

Шаг 3 (или 0). Описываем внешний контекст: задачи заказчика и продукт

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

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

• Canvas Business Model,
• Глубинные/пользовательские интервью,
• Customer Journey Map,
• Customer Development,
• Service Design,
• Story Map,
• User Story,
• Jobs-To-Be-Done.

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

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

Шаг 4. Определяем различия между желаемым и действительным

Вам нужно сопоставить желаемую и реальную ситуацию в проекте по двум направлениям:

• продукт,
• организационная структура внутри команды.

Продукт

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

Организационная структура

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

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

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

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

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

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

Шаг 5. Доносим контекст до команды

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

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

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

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

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

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

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

Шаг 6. Контролируем все организованные процессы

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