Подход к проектам: убрать боль из сложной веб-разработки

Марина Донцова, проджект-менеджер digital-агентства «Атвинта», поделилась рекомендациям, как управлять сложной разработкой, чтобы не было мучительно больно команде и заказчику. Материал будет полезен менеджерам digital-проектов и всем, кто хочет узнать процесс создания сложных веб-продуктов изнутри.

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

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

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

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

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

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

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

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

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

Тогда на проекте не будет боли на этапе сборки фронтенда.

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

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

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

Поэтому нужно договариваться с клиентом о приоритетности задач:

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

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

Утренние десятиминутные планёрки задают темп дня. На них каждый участник команды рассказывает:

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

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

При разработке сайта для родильного дома в Кемерове рисовали 3D-иконки. Сам процесс отрисовки иконок занял несколько недель. Мы решили не ждать этих элементов. отрисовали основные макеты с плоскими иконками и запустили разработку параллельно работе над иконками. Иконки мы добавили уже в конце разработки.

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

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

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