В период нестабильной экономической ситуации желание бизнеса сэкономить на разработке системы там, где это возможно, вполне справедливо. В итоге какие-то роли заказчик берёт на себя, по другим идет совмещение. В некоторых случаях специалиста и вовсе не подключают на проект из-за кажущейся простоты задачи.
Аналитик SimbirSoft Евгения расскажет об одном кейсе, когда исключение роли аналитика из проекта именно с такой задачей привело к трудностям реализации, затягиванию сроков и … Но не будем раскрывать все карты. Подробности – ниже.
С точки зрения процесса разработки статья будет полезна руководителям проектов, аккаунт-менеджерам и тимлидам, а заказчикам поможет сформировать более чёткие ожидания.
Исходная ситуация
Задача – заказчик решил «освежить» сайт с технологической и пользовательской точек зрения, то есть провести замену стека и дизайна.
Он принёс готовый макет обновленного дизайна от стороннего подрядчика. От нашей команды требовалось выполнить замену стека и дизайна, запустить обновлённую версию в прод и в дальнейшем развивать продукт. Критически важным для заказчика был быстрый time-to-market, поэтому на данном этапе новую функциональность внедрять не планировали.
Заказчик решил не привлекать на проект аналитика, поскольку была работающая система, функции и данные которой надо перенести, и готовый дизайн, который требовалось «натянуть» поверх переписанной системы. При этом документация к системе отсутствовала.
Что повлияло на изменение решения
Вскоре после старта работ начались проблемы. Для реализации системы в новом дизайне требовалось переписать API и заложить логику под новую функциональность. Хотя, напомню, задача изначально заключалась только в переносе текущих данных и функций.
У команды быстро накопилось порядка 30 вопросов, решение которых предполагало составление спецификации на доработку системы, описание новой бизнес-логики и доработку эндпойнтов. Без аналитика это было сделать невозможно, и заказчик принял решение подключить специалиста, поскольку сложившаяся ситуация могла затянуть сроки релиза.
Просмотрев весь перечень проблемных моментов, я решила разобраться в их первоисточнике. Аудит интерфейса и функциональности существующего сайта и нового дизайна показал, что последний и был «источником зла». Выяснилось, что 90% новых задач вытекают из того, что дизайн не соответствовал текущей функциональности системы и пожеланиям заказчика.
Большая часть вопросов была снята за счет удаления элементов дизайн-макета или небольших корректировок. Какие-то решения потребовали несущественных доработок, дополнительного обсуждения и согласования с заказчиком, а некоторые – внесения серьёзных корректировок.
Например, пользователю предлагалось оформить страницу, выбрав для шапки изображение из банка системы или загрузив собственное.
Какие проблемы это вызвало? Новый дизайн предполагал изменение вида шапки, превью страниц и фона, а также загрузку собственных иллюстраций. По сути оно становилось «темой». Но существующая система была не готова загружать пользовательские изображения в качестве темы оформления. Не говоря о том, что блоки под них имели специфические параметры, а значит большинство загруженных иллюстраций могли либо плохо смотреться, либо требовалась их обрезка, но в текущей системе не предусмотрен кроппер.
Какое решение мы предложили? По согласованию с заказчиком решили доработать функциональность под отображение выбранного изображения в качестве превью страницы, а также убрать возможность загрузки пользовательской фотографии для оформления.
Помимо очевидных проблем, связанных с разработкой, в процессе анализа были выявлены существенные нюансы, связанные с бизнес-задачами и генерацией прибыли заказчика.
Например, пользователь мог продвинуть страницу за счет платной подписки и таким образом выделить ее на главной странице сайта и в каталоге.
Какие проблемы это вызвало? Возможности платной подписки были спрятаны в глубине страниц. А страницы с платной подпиской вынесены в каталоге на отдельную вкладку, то есть посетитель мог и не просматривать ее. Выгода от такой опции выглядела сомнительной.
Какое решение мы предложили? Существенное изменение структуры каталога и страниц пользователей для продвижения платных услуг. В данном случае я смогла пересобрать раздел в Figma из имеющихся в дизайне компонентов. Но когда требуется серьезная переработка, советую привлекать профессионального дизайнера.
Это только несколько примеров проблем, которые могут возникнуть у команды, когда заказчик исходит из гипотезы, что перетянуть дизайн на работающую систему – простая задача. На самом деле это кропотливая работа, которая требует большого внимания, а главное – глубокого понимания потребностей заинтересованных лиц: бизнеса, пользователей системы и разработчиков.
Как бы мы рекомендовали поступить в данной ситуации:
1. Аналитик проводит анализ существующей системы. Параллельно с этим бэкенд-разработчики приступают к переносу системы. Конечно, к кодингу лучше приступать после завершения этапа аналитики, а в идеале – после проектирования архитектуры на основе требований. Но мы живём в реальном мире, и когда на проекте поджимают сроки, вариант запараллеливания работ допустим.
2. Аналитик обсуждает с заказчиком требования по улучшению интерфейса с точки зрения пользовательского пути, бизнес-целей заказчика и фиксирует их.
3. Аналитик готовит прототип пользовательского интерфейса системы и согласовывает его с заказчиком.
4. Аналитик передаёт прототипы и требования заказчика дизайнеру.
5. Дизайнер приступает к разработке макетов.
6. Если от заказчика поступили новые требования к функциональности, аналитик пишет спецификации для доработки системы и передаёт в разработку.
7. Дизайнер предоставляет готовый макет, который после проверки аналитиком соблюдения требований передаётся на согласование заказчику.
8. Заказчик согласовывает макет или передаёт новые требования на доработку. Если требования «косметические» – только дизайнеру, а если они касаются функциональности или информационной архитектуры – аналитику.
9 Согласованный дизайн-макет передаётся фронтенд-разработчикам.
10. Фронтенд- и бэкенд-разработчики дорабатывают систему.
11. Запуск в продакшн.
Резюмируем
Хотите ускорить time-to-market? Не игнорируйте этап аналитики. В зависимости от системы и применяемой методологии этап аналитики может занять несколько дней или недель, а может идти параллельно с разработкой. Попытки сэкономить на трудозатратах специалиста могут затянуть выпуск продукта и снизить прибыль.
Аналитик – одна из ключевых фигур на проекте. Он является связующим звеном между заказчиком и командой, может выявить требования и определить, как лучше их реализовать в проекте. Аналитик – гарант эффективной работы команды. Благодаря четко определенным задачам, актуальности документации и минимизации возможных ошибок в разработке команда сможет работать динамично.
Помните, отсутствие аналитика на проекте может привести к нежелательным ошибкам и решениям, не соответствующим требованиям заказчика, потере времени и ресурсов на их исправление, что, в свою очередь, влечет за собой и финансовые последствия. Прежде чем исключать роль аналитика из проекта, убедитесь, что у вас есть:
исчерпывающая актуальная документация,
опытный дизайнер,
чёткое понимание бизнес-целей и требований к системе,
а также время, чтобы внимательно следить за соблюдением требований при реализации.
А в вашей практике случались подобные ситуации? Поделитесь своим опытом, как выходили из них.
Спасибо за внимание!
Авторские материалы для разработчиков и аналитиков мы также публикуем в наших соцсетях – ВКонтакте и Telegram.