Проектирование и прототипирование сложных систем на примере Kozara: лайфхаки от digital-агентства Convergent

Привет! На связи диджитал-агентство Convergent, мы уже 21 год создаём цифровые решения, которые облегчают жизнь нам и нашим клиентам.

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

Но в итоге тогда, в 2009, мы ничего подходящего не нашли. Поэтому мы разработали решение под себя. Так появилась Kozara — многофункциональная платформа учёта и прогнозирования ресурсов.

Почему Kozara? Так в Хорватии (где располагается один из офисов Convergent) называлась палатка, которая легко адаптировалась под количество размещаемых людей. Собрать её можно было только коллективными усилиями, как и любой эффективный проект. Идея сочеталась с тем, что мы собирались строить.

Решение сразу упростило жизнь всем сотрудникам нашего агентства, это более 100 человек: от 70 на старте до 300+ с приростом офисов. Системой на ежедневной основе пользуются все роли бизнеса:

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

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

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

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

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

Все договорённости после устного обсуждения мы фиксируем «на бумаге». Это сэкономит время на доработках в дальнейшем и помогает составить ТЗ по функционалу. В описании функционала мы указываем:

Прежде, чем перейти к разработке, мы продумываем алгоритм работы нового функционала и то, как он встроится в систему. Взаимосвязь мы визуализируем при помощи BPMN (нотация и модель бизнес-процессов) и блок-схем. Ещё мы используем упрощённый вариант матрицы трассирования. Она поможет оценить, как новый функционал повлияет на текущий. Алгоритм такой:

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

Новые способы решения задачи можно найти на сервисах с референсами. Кроме известных Dribbble и Behance мы пользуемся:

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

На этом этапе мы создаём кликабельный прототип из варфреймов, грубых набросков структуры. Его показываем инициаторам функционала, и их мнение помогает исправить ошибки.

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

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

Чтобы проверить, какой из двух вариантов работы одной функции выбирают пользователи, мы запускали их параллельно и подключали к ним сервисы Google Analytics и Яндекс. Метрика. Этот способ помог понять, какое из решений пользователям нравится больше.

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