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

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

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

• Создавать оценки предстоящих проектов.
• Бронировать специалистов на проекты и фиксировать потраченное время.
• Отслеживать планируемые и фактические затраты по проектам.
• Смотреть аналитику по проектам и сотрудникам (количество костшитов и оценок от разных менеджеров, ресурсы специалистов, количество часов на проекте и т. д.).
• Вовремя закрывать проекты и подготавливать документы.
• Согласовывать их с руководителями и финансовым отделом.
• Прогнозировать рентабельность.

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

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

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

• Аккаунт-менеджеры;
• Проджект-менеджеры;
• Руководители сервисов;
• Бухгалтеры и финансовые менеджеры;
• HR-менеджеры и другие специалисты.

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

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

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

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

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

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

• Какая цель? Зачем мы разрабатываем новый функционал?
• Какие проблемы пользователей он решает?
• Как пользователь решает свою проблему сейчас?
• Какие действия пользователь совершает чаще всего?

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

• цели и задачи бизнеса и пользователей;
• функциональные и нефункциональные требования;
• результаты веб-аналитики текущей версии;
• целевая аудитория и анализ конкурентов;
• KPI;
• интеграции.

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

• В любой удобной таблице создаём колонку «Изменения/новый функционал».
• Напротив по горизонтали перечисляем все объекты, которые есть в сервисе, их разбиваем по разделам.
• Все изменения, которые повлияют на текущие объекты, записываем в первую колонку. В пересечениях прописываем суть влияния и учитываем её при написании ТЗ и проектировании.

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

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

• Сайтами с UX-паттернами. Среди них: Really Good UX, UX Archive и CollectUI.
• Интерфейсами сложных систем. Например, таск-трекеры, банковские решения, сервисы Google и Яндекс.
• Демо версиями сайтов и приложений, благодаря которым можно изучить их функционал

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

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

• Сайтами с UX-паттернами. Среди них: Really Good UX, UX Archive и CollectUI.
• Интерфейсами сложных систем. Например, таск-трекеры, банковские решения, сервисы Google и Яндекс.
• Демо версиями сайтов и приложений, благодаря которым можно изучить их функционал

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

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

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

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

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

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