Разработка

Коммуникация с заказчиком и внутри команды

Катерина Семенова, Lead Project Manager компании Rademade, описывает полный цикл работы над новым проектом — от стадии анализа до процесса разработки. Вы  узнаете, как выстраивается коммуникация на разных этапах работы и как ее качество влияет на финальный результат.

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

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

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

С точки зрения коммуникации эти этапы принципиально разные:

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

Чтобы было понятней, рассмотрим каждый этап отдельно.

Воркшопы на стадии проектного анализа

Вначале ничего сложного — первое знакомство, первое «I would like to add you as a contact in Skype». Мы общаемся с клиентом, обмениваемся информацией друг о друге, а когда понимаем, что нам по пути — планируем серию воркшопов для анализа проекта.   

Воркшоп 1: Определяем эпики (epics) и приоритетность

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

  • Каталог спортивных площадок (по видам спорта/локациям),
  • Возможность бронирования,
  • Функционал для проведения оплаты,
  • Профили пользователей,
  • Профили провайдеров.

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

Для запуска MVP и генерации трафика достаточно создать каталог площадок. Дальше можно взяться за профили провайдеров, функционал оплаты (пока без возможности бронирования), а потом добавить все остальное.

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

Воркшоп 2: Детализируем эпики до user stories

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

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

Коммуникация внутри команды

Например, чтобы заработал поиск, нам понадобится:

  • создать страницы с результатами поиска,
  • разместить информацию о площадке,
  • реализовать поиск по локации (выдача наиболее релевантных),
  • добавить фильтрацию по атрибутам (размер и тип площадки, виды спорта и др.).

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

Воркшоп 3: Финализируем scope of work

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

Воркшоп 4: Обсуждаем результаты оценки

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

Кроме проектных задач на этапе анализа согласовывается будущий формат работы. Зачастую заказчик нанимает в команду до 3 разработчиков, а проектный менеджер совмещает в себе несколько ролей — бизнес-аналитика, scrum-мастера (который отвечает за планирование) и прокси владельца продукта (Proxy Product Owner) — человека, который посвящен во все бизнес-процессы и может отвечать на вопросы от имени заказчика.

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

Реализация проекта по Sсrum

Для работы над проектами мы применяем 2 методологии семейства Agile — Scrum (удобно использовать на этапе разработки) и Kanban (подходит для этапа сервисной поддержки). Расскажу о первой, так как именно она помогает нам запускать проекты с нуля.

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

Как это работает:

  • Планирование релиза (planning, до 4 часов) — в начале спринта мы планируем и обсуждаем задачи на последующие недели,
  • Ежедневные короткие встречи (daily stand-up, 10 минут каждый) — по утрам синхронизируется работа команды, обновляются планы на день,
  • Ретроспектива (sprint retrospective meeting, до 4 часов) — анализируем результаты законченного периода.

Scrum методология

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

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

А если заказчик меняет задачи?

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

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

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

Тройственная ограниченность

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

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

Коммуникация внутри команды

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

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

Поэтому я настаиваю,что команда должна присутствовать на всех уровнях коммуникации:

  • Высокий уровень — воркшопы (скоуп, эпики, глобальные цели)
  • Средний уровень — детализация user story, планирование спринта, ретроспективы
  • Низкий уровень  — ежедневные короткие встречи, уточнение деталей (как должна работать кнопка?)

Важно осознавать, что люди воспринимают информацию через призму. И если кто-то что-то понял по-своему, он может не так реализовать. Именно поэтому мы проводим планирование в начале спринта, во время и после.

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

Стоит отметить, что по Scrum у нас работают только программисты. У этих специалистов T-shaped skills — они эксперты в своей сфере, но разбираются в смежных. К примеру, тот, кто пишет код для бэкенда, понимает как разрабатывается фронтенд и немного разбирается в верстке. Таким образом, при отсутствии какого-то члена команды не теряется скорость разработки (velocity). Из-за этого дизайнеры и верстальщики работают отдельной командой.

Т-ообразне способности

Мы сталкиваемся еще и с тем, что производительность у всех специалистов непропорциональная: дизайн делается 3 недели, верстается то же самое 1 неделю, а программируется — 5. Чтобы этого избежать, верстка и дизайн работают немного на опережение, они тоже участвуют в «дейли», но план у них свой.

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

Preview photo: Martynova.Katie / Depositphotos.com

Header photo: Rawpixel / Depositphotos.com

Другие статьи этого этапа

Рекомендуем почитать

Хочешь запустить свой маркетплейс или получить консультацию?