Управление проектами: выполнение

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

Частый вопрос HR-ов при собеседовании менеджеров проектов: “как вы видите процесс ведения проектов” – начинающему менеджеру статья поможет ответить на вопрос.

Самый сложный этап выполнения проекта – запуск. Здесь мы вводим в курс дела исполнителей, планируем с ними формат работы, форму предоставления результатов и сроки. Если ты не поленился на этапе планирования, это происходит безболезненно – раскидываешь задачи по таскам и вперед. Только что потребуется рассказать о контексте и первую неделю быть в процессе – пока возникают вопросы, на которые нужно давать оперативные ответы. Работа с исполнителями на этапе выполнения самая важная – вспоминаем, что менеджмент все же о работе с людьми, а не с сайтами/приложениями.

Увы, пункт “выполнения” нельзя подписать под один строгий стандарт – здесь все зависит от типа проекта, состава участников (доступных и требующихся прямо сейчас), методологии ведения проекта. Не смогу рассказать о том, что одновременно подойдет и для хадкорных проектов и для попроще, типа диджитала. Работаю с диджиталом, речь пойдет о нем – с учетом роадмапа, принятого конкретно в нашей компании. Говорить будем о разработке сайта. Чтобы было проще, сразу определим состав участников проекта: креативный директор, дизайнер, технолог (верстальщик), программист, тестировщик и менеджер проекта – все по одному. Отталкиваемся от того, что разработку ведем по ватерфолу.

Роадмап (“дорожная карта”) – путь проекта, как он идет со старта до сдачи готового продукта. При разработке сайта (или приложения – они похожи в разработке), роадмап примерно один: нарисовать, заверстать, спрограммировать, протестировать и запустить – по нему и пойдем далее.

Дизайн

На первом этапе, “нарисовать”, рассказываем дизайнеру о целях проекта, пожеланиях клиента. Отдаем все, что получили от клиента, реагируем на запросы дополнительной информации. Первый результат, что ожидаем от дизайнера – концепт дизайна. Это одна-две страницы (чаще, продуктовая и контентная – посложнее и полегче), которую будем утверждать с клиентом. От того, что дизайнер сделает на этом этапе, зависит чуть ли ни половина проекта. Здесь дизайнер может придумать что-то из ряда вон выходящее, и ребята-исполнители следующих этапов получат в несколько раз больше работы, чем если бы дизайнер придумал что-то стандартное. Последнее – причина, почему при планировании и оценке проекта сложно оценить время работы технолога – разброс может быть большим. На этапе дизайна, работа дизайнера курируется по-большей мере креативным директором или ведущим дизайнером – человеком с большим опытом, который подскажет, в каком направлении двигаться и поправит дизайнера, если что-то пойдет не так. То есть, после запуска процесса, влияние менеджера на результаты процесса минимальны – менеджер может лишь отслеживать моменты, когда дизайнер с креативным директором в своем креативе намекают на выход за границы рентабельности проекта. У нас в компании менеджер не влияет на сам креатив – если есть люди компетентнее, лучше передать эту задачу им.

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

Концепты редко утверждаются сразу – на то они и концепты. Их главная задача – откалибровать ожидания клиента, чтобы в будущем не было недопонимания. Допустим, прошло две итерации (больше двух-трех их не бывает), и мы утвердили концепт. Далее начинается более рутинная работа – рисуем все остальные страницы. На остальные страницы потребуется примерно столько же времени, сколько потребовалось на концепт – там все происходит быстрее.

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

Верстка

На этапе верстки человеческий фактор примерно в миллион раз выше, чем при дизайне или программировании. Во-первых, верстальщик сам по себе как дизайнер, и какие-то интерактивные вещи может продумать самостоятельно. Во-вторых, сама передача проекта дизайнером верстальщику – трудоемкий процесс, и качество его сильно зависит от степени профессионализма первого и второго. Здесь не получится передать макеты, типа “на, верстай” – при нормальном процессе дизайнер передает верстальщику с макетами нюансы проекта, может рассказать о собственных задумках, которые верстальщику предстоит воплотить. Менеджер в этом процессе – фасилитатор, настраивающий коммуникацию между двумя профессионалами. Особенно это актуально, если один из исполнителей находится вне офиса – работает в другом офисе, либо фрилансер: у нас несколько офисов, распределенная команда и группа крепких фрилансеров, с которыми постоянно работаем.

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

На этапе верстки есть подэтап с тестированием – когда дизайнер смотрит на верстку и собирает чек-листы с правками из полутора сотен пунктов. Иногда не собирает – в этом случае чек-листы с правками может собрать менеджер. Объем правок по верстке зависит от степени профессионализма технолога. Как правило, без правок не обходится – даже если все собрано идеально (“пиксель-к-пикселю”), при верстке могут всплыть упущения в UX или логике работы сайта – в таком виде на следующий этап верстка не пойдет. После того, как все чек-листы закрыты (или не все, в зависимости от критичности правок), верстка готова, передаем ее программисту на “прикручивание” к бэкэнду.

Разброс того, как может идти работа на этапе верстки, достаточно большой – верстка на React и обычная (HTML/CSS) – две большие разницы, сценариев построения процесса может быть несколько. Не будем углубляться в дебри здесь – если есть вопросы по конкретным сценариям, расскажу в комментариях.

Программирование

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

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

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

Сценарии, которые могут возникнуть при программировании – необъятная вселенная. Степень непредсказуемости стремиться к небесам, даже если техническое (функциональное) задание прописано четко. Можно потратить пару недель работы на то, что описано одним пунктом, можно сделать за пару часов то, что расписано целой главой. Чем дальше мы отходим от модели “запилить админку на Yii2 и подвязать верстку”, тем проект становится интереснее. Например, прямо сейчас у нас в разработке проект, в котором целых три одновременные ветки разработки бэкэнда и две ветки фронта (React). Все это на разных серверах, а общается посредством API. Это не считая боевой (development) части проекта, где свой отдельный фронт и бэкэнд. А еще отдельный сервер для API. Весело, в общем, бывает.

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

Тестирование

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

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

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

Завершение проекта

Все согласовано, нет комментариев у коллег и клиента – проект закрывается. Передаем клиенту параметры доступа к административной панели и делаем файл-мануал по ее управлению. Но даже после передачи параметров доступа проект не считается завершенным. Завершен он после того как получены все оплаты, подписаны все документы.

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

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

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

• Задачи должны передаваться четко – если требуется, с дополнительным описанием сверх того, что указано в техническом задании.
• Задачи должны передаваться порционно – если свалить на голову программиста все техническое задание и предоставить свободу действия, по плану ничего не пойдет – ибо нет этого плана.
• Брифуя дизайнера (креативный отдел) нужно рассказывать о проблемах, которые стоят. Рассказать, почему ее нужно решить, как ее решают сейчас, и так далее и тому подобное. Предоставить максимум доступной информации. Не предлагать решений проблемы – это ограничит дизайнера, либо вызовет сопротивление. Представь, если бы клиент тебе рассказывал, в каком месте у него должно быть меню и почему на главной странице обязательно должен быть слайдер. Для дизайнера ты точно такой же клиент.
• Маяковать исполнителя вопросом “ну как дела?” – моветон. Это раздражает, отвлекает и никак не мотивирует. Лучше договоритесь о времени и формате статуса проекта.

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

Для управления проектами мы используем Trello – я к нему настолько привык, что Jira или ActiveCollab вызывают боль. Трелло не идеален и мало подходит под сложные проекты – в том самом проекте о котором писал выше, где пара серверов и пять веток разработки, это чувствуется очень даже.

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

В общем, набор инструментов при управлении выглядит так:

• Трелло – основной инструмент постановки и контроля задач.
• Телеграм – оперативные обсуждения, сообщения из которых не жалко потерять в потоке.
• Электронная почта – с исполнителями фактически не используется, но через нее исполнителя можно подключать к диалогу с клиентом (случается крайне редко).

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