Проектный офис Uplab: как мы управляем проектами и выстраиваем отношения с клиентами

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

Чтобы лучше понимать, о каких проектах речь, приведем пример. На проект по созданию системы из 16 сайтов для НЛМК мы потратили 6200 человеко-часов, на Клиентский портал для компании Северсталь — 4 000 чел./ч, а на систему сайтов Аэропорты Регионов — 2 500 чел./ч. Общий срок разработки проекта может составлять от 6 месяцев до 1,5 лет.

1) С чего начинается проект?

2) За что отвечает руководитель проекта?

3) На какие этапы делится работа над проектом?

4) Какие инструменты используются для управления проектами?

5) Как мы формируем команду проекта?

6) Как измеряется результат?

7) Как строится коммуникация с заказчиком проекта?

8) Может ли не хватить людей в проекте?

9) Как учитываются другие риски в проекте?

10) Могут ли сдвинуться сроки?

11) Может ли поменяться руководитель проекта?

12) Секреты управления проектами от команды Uplab

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

Наш приоритет — как можно быстрее создать продукт, который принесет бизнесу пользу и прибыль. Рынок диджитал очень динамичный, поэтому важно не потерять время. Клиент не должен сидеть 2 года со старым сайтом и ждать, пока мы закончим разработку — это наш принцип. Поэтому мы используем концепцию создания минимального жизнеспособного продукта (MVP) и дальнейшей его доработки релизами. Разработка MVP занимает 3-5 месяцев.

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

Руководитель проекта — специалист, который следит за проектом и поддерживает коммуникацию с клиентом на всех стадиях реализации.

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

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

Работа руководителя проекта начинается задолго до старта разработки. Он может подключиться на следующих этапах:

Новый проект — это всегда новый «вызов»‎. 60% успеха обеспечивает правильный старт, поэтому мы уделяем очень много времени подготовке и инициации проекта.

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

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

RACI — матрица для определения роли каждого члена команды с обеих сторон и распределения ответственности, где:

R (Responsible) — исполнитель задачи; на каждую задачу — не менее одного R.

A (Accountable) — ответственный; ему отчитываются о результате, на каждый проект/задачу — не более одного A.

С (Consulted) — консультант; с ним консультируются и согласуют принимаемые решения.

I (Informed) — информируемый, ему поступает итоговая информация о проделанной работе.

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

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

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

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

Для описания бизнес-процессов мы пользуемся Confluence — это внутренняя вики-система для создания единой базы знаний.

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

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

Мы начинаем собирать команду за 2-3 недели до старта, пока идет подписание договора. Сразу подключаем РП и сообщаем о новом проекте техлидам, чтобы они спланировали и выделили ресурсы.

Как мы отслеживаем нагрузку на команду руководителей проектов?

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

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

С точки зрения клиента мы обращаем внимание на такие качественные метрики:

Внутри компании мы каждый месяц обязательно измеряем рентабельность проекта.

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

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

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

Контролировать ход работы клиент может двумя путями:

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

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

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

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

Эскалация — один из инструментов управления. Это «подъем наверх» важного вопроса, который вы не можете разрешить самостоятельно в рамках своей роли или своих полномочий.

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

Этот план презентуем клиенту. Если руководитель на стороне заказчика неопытен в управлении проектами в диджитал, то промежуточное планирование и презентацию проводим чаще.

Сроки проекта могут сдвигаться в нескольких случаях:

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

Минимум за 2 недели до смены сообщаем клиенту, что будет новый руководитель проекта. Чтобы вызвать доверие к его профессионализму, дополнительно о смене сообщает проектный директор, групп хеды или техлиды.

Групп хед (Group head) — управляющий группой руководителей проектов. У нас есть 4 команды РП.

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

У себя внутри проводим максимально детализированную передачу проекта. Все проекты ведутся в Confluence, поэтому новый РП черпает необходимую информацию там. Отдельным блоком он изучает планируемые работы/задачи в разделе «‎Статус проекта»‎.

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

После начала работы нового РП, переходный период продолжается. Еще 2-3 недели групп хед поддерживает руководителя проекта, держит руку на пульсе, смотрит, как «‎отгружаются»‎ задачи клиента.

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

Net Promoter Score — индекс определения приверженности потребителей товару или компании (индекс готовности рекомендовать). Является одним из главных индексов измерения клиентской лояльности.

Мы озадачили членов команды небольшим опросом. И они щедро поделились секретами по управлению не только проектами, но и своим днем.

Не нужно успевать всё. Важно успевать ровно то, что важно! Сделай 20% эффективных задач, которые принесут тебе 80% результата. И оставь все важные, но несрочные задачи в календаре.

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

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

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

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

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

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

Чем большим знанием ты обладаешь, тем лучше ты умеешь управлять и применять свои знания!

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

Главное работать без паники/эмоций. И тогда может обнаружиться, что «пожаров» не так много, как казалось. При возникновении «пожара» в первую очередь необходимо заниматься решением вопроса/ов с командой, а не искать виноватых в ситуации/ях. Это можно будет сделать уже после решения проблемы на ретроспективе.

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

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

Нужно быть собранным, ответственным и в меру требовательным :)

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

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

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

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

Соблюдать баланс между качественно и срочно практически невозможно. Обычно всё равно страдает один из параметров. Так работает правило. Если не можешь сдвинуть сроки, значит нужно сделать максимально качественно в условиях того времени, которое отводится. Но если ты страдаешь синдромом «отличника», то всегда есть возможность сделать задачу более качественно, но во внерабочее время, просто посидеть часик другой после работы. Главное, чтобы это было скорее исключением, нежели правилом, иначе можно «сгореть на работе».

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

Благодарим за прочтение статьи. Успешных вам проектов! ❤