Кейс №1: Contrust
Кратко
Компания
Дочерняя IT-компания крупного девелопера. Занимается развитием IT в сфере строительства.
Продукт
Бывший «СККС» (Система комплексного контроля строительства), ныне Contrust — многомодульная веб-система по автоматизации строительных процессов.
Моя роль
Web-дизайнер, UI/UX дизайнер, после формирования продукта — продуктовый дизайнер.
Какие были задачи
- Структурировать все возможности и потенциал системы,
- Обернуть в единый продукт, контролировать дизайн-процесс,
- Следить за консистентностью дизайна в модулях,
- Анализировать и улучшать процессы.
Что делал
- Пересматривал и улучшал процессы,
- Предлагал идеи по автоматизации,
- Отрисовывал макеты,
- Следил за UI-китом и, в последствии, дизайн-системой,
- Коммуницировал с бизнесом и разработкой,
- Контролировал и ревьюил подрядчиков,
- Общался с конечными пользователями,
- Защищал результаты перед бизнесом.
Результат
Многомодульный продукт со своим именем и брендом, позволяющий контролировать ключевые процессы строительных проектов, такие как:
- Документооборот,
- Безопасность на стройобъекте,
- Передача квартир покупателям,
- Строительный контроль,
- Пожарная безопасность,
- Работа с BIM-моделями.
Продукт всё ещё находится в разработке и под NDA. Все продемонстрированные ниже материалы — часть продукта, которую мне разрешили демонстрировать. Имена, названия и другие личные данные скрыты.
При демонстрации опускаются базовые элементы системы, такие как процессы регистрации и авторизации, ЛК пользователя, отдельные разделы каждого модуля и навигация по модулям, реестры, таблицы, пустые состояния и т.д. Показано то, что важно для понимания кейсов.
Вводная
Ситуация
Внутри девелопмента с каждым годом всё активнее развивается цифровизация. Один из передовых застройщиков, базирующийся в Санкт-Петербурге и Москве начал развивать своё IT направление и в 2019-ом году. На базе научно-технического центра сформировалась команда, которая уже имела ряд наград в сфере BIM и несколько функционирующих сервисов, которые нужно было развивать. Им потребовался дизайнер, которым стал я. Первые задачи были нетривиальными — иконки, базовые экраны, приведение в порядок существующего функционала. Около полугода я приводил в порядок то, что уже было и дизайнилось «по наитию».
Спустя почти год стало понятно, что сервис разрастается — появляются новые модули, а ранние уже активно эксплуатируются. Мной было предложено объединить их все в единую экосистему, которую можно будет использовать как внутри контура компании, так и продавать «коробкой» в будущем.
Спустя почти год стало понятно, что сервис разрастается — появляются новые модули, а ранние уже активно эксплуатируются. Мной было предложено объединить их все в единую экосистему, которую можно будет использовать как внутри контура компании, так и продавать «коробкой» в будущем.
Продукт
Бренд
Мной был разработан и защищён перед бизнесом бренд Contrust.
При разработке бренда учитывались следующие вводные:
Необходим запоминающийся но сдержанный, серьёзный стиль.
У группы компаний уже был объёмный брендбук, нужно учитывать его правила.
Необходимо отделиться от существующего общего стиля всех девелоперов («стабильный синий», чрезмерная строгость, аскетичность), чтобы выделяться на выставках и конкурсах.
У продукта есть задел на B2B, соответственно бренд должен покрывать вариант коробочных решений.
При разработке бренда учитывались следующие вводные:
Необходим запоминающийся но сдержанный, серьёзный стиль.
У группы компаний уже был объёмный брендбук, нужно учитывать его правила.
Необходимо отделиться от существующего общего стиля всех девелоперов («стабильный синий», чрезмерная строгость, аскетичность), чтобы выделяться на выставках и конкурсах.
У продукта есть задел на B2B, соответственно бренд должен покрывать вариант коробочных решений.
Contrust — сочетание слов construction, control, trust. Итоговое слово звучное и легко запоминающееся. Шрифтовая часть логотипа была «подогнана» под общий стиль группы компаний, чтобы комфортно вставала рядом с логотипом группы на разных носителях. Цветовая гамма фиолетово-зелёная, а основные паттерны не монолитные цвета, а матричные градиенты с грэйн-эффектом.
Формат и позиционирование
Основная задача Contrust: собрать в себе все удобные инструменты и механизмы для управления строительством и строительной площадкой. Начиная от покупки строительного пятна и заканчивая заселением жильцов — все этапы можно так или иначе контролировать с помощью продукта.
Contrust задумался как многомодульный веб-сервис, в котором каждый модуль независим (кроме связи между «ядром» — модулем с ролевой системой и основными методами обмена данными, и функциональными модулями).
Подключать модули можно в зависимости от потребностей отдельного строительного проекта или желания заказчика. Один модуль — одна цельный процесс со всеми необходимыми подпроцессами. Например, модуль «Охрана труда» отвечает за все механизмы, способствующие повышению индекса безопасности на объекте.
Сервис работает в вебе, нативных приложений не требуется.
Contrust задумался как многомодульный веб-сервис, в котором каждый модуль независим (кроме связи между «ядром» — модулем с ролевой системой и основными методами обмена данными, и функциональными модулями).
Подключать модули можно в зависимости от потребностей отдельного строительного проекта или желания заказчика. Один модуль — одна цельный процесс со всеми необходимыми подпроцессами. Например, модуль «Охрана труда» отвечает за все механизмы, способствующие повышению индекса безопасности на объекте.
Сервис работает в вебе, нативных приложений не требуется.
UI-кит и дизайн-система
При формировании базового UI-кита я отталкивался от дизайн-системы Ant — она располагала практически всеми необходимыми элементами, закрывающими наши нужды. Слово «практически» сыграет злую шутку с нами в дальнейшем при рассмотрении вариантов дизайн-систем (см. раздел «факапы»).
Одной из ключевых трудностей при работе с UI-элементами стали иконки. В сфере девелопмента много уникальных случаев и сущностей, для которых иконки пришлось отрисовывать руками. Если они и были в готовых наборах, то наборы эти — графические, а не UI-ные, и ставить эти иконки в интерфейс было нельзя.
Иконки самой разной техники
Иконка риска «Падение с высоты»
Сабкейс № 1:
Стройконтроль
Стройконтроль
Дано
Строительный контроль — один из важнейших процессов на строительной площадке. Инженеры контроля ежедневно проводят аудит десятков работ — от заливки бетона до установки окон. Если работа сделана некачественно — работы не принимаются и отправляются на доработку. Если всё хорошо, то работы принимаются и объёмы (сколько единиц и в каком объёме сделано) заносятся в реестр.
Важнейшие артефакты процесса: акт о приёмке выполненных работ (КС-2) и КС-6 (справка о стоимости выполненных работ и затрат). Условно говоря, сколько построили и сколько за это должны заплатить.
Процесс проводится вручную, на бумаге, а коммуникации проводятся либо лично, либо по телефону.
Важнейшие артефакты процесса: акт о приёмке выполненных работ (КС-2) и КС-6 (справка о стоимости выполненных работ и затрат). Условно говоря, сколько построили и сколько за это должны заплатить.
Процесс проводится вручную, на бумаге, а коммуникации проводятся либо лично, либо по телефону.
Задачи
Моя основная задача заключалась в осмысленной трансформации процесса контроля.
Нужно было:
Нужно было:
- Изучить конкурентные решения, проанализировать и полностью пересмотреть текущие процессы, выявить слабые места и возможности для оптимизации, предложить более эффективную систему, способную выдерживать нагрузку динамичного строительного процесса.
- Ускорить прохождение каждой стадии контроля и упростить управление объёмами выполненных работ.
- Оцифровать весь процесс, избавиться от бумажной волокиты и сделать его прозрачным, свести к минимуму личное взаимодействие и влияние человеческого фактора.
- Внедрить механизм автоматической генерации документов, интегрированный в систему Contrust, и обеспечить его удобство для всех участников.
Действие № 1: Анализ процессов
Первым шагом было проведение интервью с ключевыми участниками процесса — четырьмя инженерами и двумя представителями генподрядчика. Я стремился вникнуть в каждую деталь их работы, чтобы понять основные боли. Результаты подтвердили наличие различных проблем: инженеры тратили огромное количество времени на работу с бумагами, сверяясь с чертежами и стараясь не потерять важные данные.
Генподрядчики страдали от постоянных изменений в расписании, а также необходимости держать в голове множество деталей, связанных с разными этапами работ.
Генподрядчики страдали от постоянных изменений в расписании, а также необходимости держать в голове множество деталей, связанных с разными этапами работ.
На момент оптимизации процесса на рынке почти не было аналогов. Те, которые мне удалось найти, были собраны на бизнес-конструкторах по типу Creatio (бывший BPM-online), т.е. по факту были обычные связанные таблицы и списки, которые руками или простыми наборами функций проводили по процессу, а на выходе всё равно получалась бумага.
На этом этапе я выделил несколько ключевых проблем:
- Бумага как источник и как результат: всё было на бумаге и зависело от неё.
- Потеря информации: документы легко портились или терялись, особенно на фоне большого объёма данных.
- Неудобные коммуникации: генподрядчики и инженеры тратили драгоценное время на телефонные звонки и личные встречи.
- Множество однотипных задач: работы часто были похожи друг на друга, и инженеры не всегда могли точно вспомнить, какие задачи уже были приняты или отправлены на доработку.
Действие № 2: Определение минимальной сущности и архитектура решения
Я решил упростить процесс, сфокусировавшись на «работе» как минимальной единице контроля. Это означало, что каждую задачу можно было рассматривать как независимую сущность с фиксированными параметрами: что это за работа, её объём, временные рамки и статус. Эта единица должна была стать основой для всей системы контроля.
Опираясь на эту концепцию, я предложил создать не просто цифровой эквивалент таблиц, а гибкую платформу для работы с данными. Я понимал, что простое копирование существующих процессов в цифровую среду не даст нужного эффекта. Нужен был подход, ориентированный на удобство работы с большими объёмами информации.
Опираясь на эту концепцию, я предложил создать не просто цифровой эквивалент таблиц, а гибкую платформу для работы с данными. Я понимал, что простое копирование существующих процессов в цифровую среду не даст нужного эффекта. Нужен был подход, ориентированный на удобство работы с большими объёмами информации.
Гипотеза:
Если мы переведём процесс строительного контроля на уровень управления минимальной сущностью — «работой» — и предоставим пользователям гибкий интерфейс для управления данными, то это позволит инженерам и подрядчикам быстрее обрабатывать задачи, сократит количество ошибок и улучшит прозрачность процесса за счёт упрощённого доступа к актуальной информации. Мы ожидаем, что это снизит затраты времени на коммуникации и ручное управление задачами минимум на 30%, повысив общую эффективность строительного контроля.
Если мы переведём процесс строительного контроля на уровень управления минимальной сущностью — «работой» — и предоставим пользователям гибкий интерфейс для управления данными, то это позволит инженерам и подрядчикам быстрее обрабатывать задачи, сократит количество ошибок и улучшит прозрачность процесса за счёт упрощённого доступа к актуальной информации. Мы ожидаем, что это снизит затраты времени на коммуникации и ручное управление задачами минимум на 30%, повысив общую эффективность строительного контроля.
Действие № 3: Интерфейсы и MVP
Основной моей задачей было не переносить эксель в веб-интерфейс, а придумать способ более комфортно работать с кучей данных в одном месте.
Тогда я разбил процесс на крупные блоки, и стал искать наиболее комфортное представление для каждого из них:
Тогда я разбил процесс на крупные блоки, и стал искать наиболее комфортное представление для каждого из них:
С подготовкой работ всё было понятно: в зависимости от решения руководителя строительства, работы вносятся в систему через окно создания сущности. Это могут делать субподрядчики, а генподрядчик — проверять итоговый пул и отправлять инженерам стройконтроля. Либо генподрядчик сам собирает данные и вносит их. Я считал это нелогичным, но не все руководители готовы были выдавать субподрядчикам доступ. Я всё же настоял на полной матрице ролей, чтобы учесть всех участников.
Для разных полей ввода предусмотрены разные условия: проект и объект может подтягиваться из профиля, даты начала и конца работ зависят от текущего этапа строительства (н.р. этап отделки не может быть раньше этапа монолита), генподрядчик и субподрядчик определяются в зависимости от профиля автора и типа работ и т.д.
Моя цель была не просто автоматизировать процесс, но сделать его интуитивно понятным и удобным для пользователей. Я решил отказаться от стандартных таблиц в пользу системы карточек, похожей на канбан.
Карточки в их первом варианте
Каждая карточка представляла собой отдельную работу, проходящую через несколько ролей: субподрядчик, генподрядчик, инженер стройконтроля и руководитель проекта.
- Генподрядчик (с субподрядчиком или без) мог создать карточку, собрать набор задач и отправить их инженеру для проверки.
- Инженер стройконтроля мог просматривать задания, заворачивать их для переноса времени, принимать к осмотру, и, в итоге, аппрувить работы или отправлять на устранение дефектов.
- Руководитель строительства наблюдал за всеми работами.
- Все участники могли видеть текущий статус задач в реальном времени, что значительно ускоряло процесс и устраняло необходимость в долгих личных встречах.
Отображение карточек идентично для всех участников, меняются только действия
Придя с прототипом одновременно к генподрядчику и стройконтролю, получил положительный фидбек, но и без разочарований не обошлось: попросили таблички как второе представление. Некоторым людям критично было видеть реестры — привычка. Собрались с командой и постарались изобразить комфортные таблички с гибкой настройкой:
Карточки не ушли — они остались как вариант отображения работ, а в будущем эволюционировали в элемент нового представления — календаря.
Действие № 4: Интерфейс приёмки работ
Один из ключевых вызовов заключался в том, как сделать процесс не только быстрым, но и визуально понятным для всех участников. Посовещавшись с ПМ-ом, мы предложили внедрить BIM-модель, которая позволяла бы инженерам и руководителям видеть строительный объект в любом виде и в любой момент времени согласно плану строительства. Каждый элемент модели содержал всю необходимую информацию — от типа объекта до его текущего статуса.
Вьювер моделей — полноценная копия строительного объекта в любой момент времени строительства, отображённая согласно любым необходимым фильтрам и параметрам.
В центре вьювера — модель строительства, которую можно вращать, зумить и фильтровать. Слева — дровер со свойствами выбранных объектов, справа — «корзина» для элементов с принятыми или непринятыми работами. Модель хранит всё: объёмы, местоположение, тип и этапы работы. Чтобы отличать похожие элементы, я добавил кнопку «мишени», которая подсвечивает нужный объект, и позже внедрил цветовое кодирование для отображения статусов и этапов работ.
Это решение значительно упростило процесс приёмки работ. Инженеры могли не только просматривать модель, но и быстро находить нужные элементы, используя цветовую кодировку статусов.
Ограничения
Мы предусмотрели использование мобильных версий сервиса, хотя на первом этапе акцент был сделан на десктопные решения. Система позволяла инженерам вернуться в бытовку и внести все необходимые данные в сервис, не теряя времени на ручное заполнение бумаг.
Модель тоже была не идеальна. Она не могла отразить некоторые элементы (проводка, заклёпки и прочие мелкие части), и работа с ней сильно зависела от её качества. Наши инженеры и проектировщики подходили к моделированию скрупулёзно, но это не значило, что любая попавшая в процесс модель будет работать стабильно. Здесь спасало табличное представление, которое мы проработали ранее и оно фоном присутствовало всегда.
Модель тоже была не идеальна. Она не могла отразить некоторые элементы (проводка, заклёпки и прочие мелкие части), и работа с ней сильно зависела от её качества. Наши инженеры и проектировщики подходили к моделированию скрупулёзно, но это не значило, что любая попавшая в процесс модель будет работать стабильно. Здесь спасало табличное представление, которое мы проработали ранее и оно фоном присутствовало всегда.
Взаимодействие с разработкой
В разработке участвовала внутренняя команда: один бэкендер, два фронтендера, один из которых занимался исключительно вьювером BIM-моделей. Критических затыков удалось избежать, весь новый функционал, который мы предлагали, был реализуем:
Функционал поиска элемента на модели через клик по «мишени» рядом с его именем был впоследствии внедрён в другие модули, использующие модель. Фича оказалась востребованной и широко применяемой.
- Дровер уже использовались у нас во вьювере как окно свойств объекта, осталось его продублировать и сделать метод накопления в нём данных об объектах.
- Метод обращения к конкретному элементу модели тоже был, благодаря нему мы получали информацию об объекте и могли управлять его свойствами — цветом, ракурсом камеры при выделении элемента и т.д.
- На первом этапе отказались от очень гибкой настройки таблиц (ручная сортировка столбцов, видимость столбцов и прочее), утвердили с пользователями наиболее комфортный набор столбцов и их порядок, реализовали в таком виде.
- С нуля разработали лишь вид карточки в двух состояниях: мини-версия на общей «доске» и
Функционал поиска элемента на модели через клик по «мишени» рядом с его именем был впоследствии внедрён в другие модули, использующие модель. Фича оказалась востребованной и широко применяемой.
Результат
На выходе мы получили функционирующий базовый процесс строительного контроля. Процесс вместе с разработкой занял 7 месяцев. После прогонки процесса на данных, максимально приближённых к реальным, мы сделали замеры времени и провели опрос среди подрядчиков и инженеров стройконтроля. Цифры получились следующие (в день):
~
180→40 минут
180→40 минут
на сбор пула работ генподрядчиком
~
90→60 минут
90→60 минут
на звонки и переписки между для уточнений
~
180→70 минут
180→70 минут
на оформление стройконтролем итоговых результатов проверок
- Вместо поиска нужных чертежей и данных о той или иной конструкции теперь всё можно было посмотреть в модели.
- Вместо рукописных отчётов всё заполнялось в системе, а большая часть полей подтягивались автоматически.
- Не нужно было звонить с спрашивать свободные слоты — всё было видно в расписании.
- Вместо кипы бумаг на выходе — фильтруемый и полный накопительный отчёт, по которому можно составлять КС.
- Для руководителя строительства повысилась прозрачность того, как работы проверяются и что вообще происходит у него на объекте. Он мог в любой момент посмотреть сколько раз не принимали какую‑либо стенку, почему её не принимали и т.д.
Мы посчитали гипотезу частично подтверждённой. Разработав базовую сущность и завязав на неё основные действия, нам удалось упростить рабочий процесс для всех его участников, снизить временные затраты на один экземпляр процесса, повысить прозрачность процесса.
На этом этапе мы закончили первый проект по разработке процесса для стройконтроля.
А дальше?
На момент релиза базового процесса в бэклоге лежало около 150 задач разной степени важности. Нам предстояло решить, как быть с выходными днями, т.к. выход на объект в выходной день должен был быть согласован со многими инстанциями согласно ТК РФ; были запросы от инженеров электрики и сетей — их работы в основном были «немоделируемыми», т.е. не вносились в BIM-модель; руководители строительства очень впечатлились возможностями цифровизации и просили добавить им рычаги управления подрядчиками и ещё много-много всего.
Но это тема отдельно описанных кейсов.
Но это тема отдельно описанных кейсов.
Сабкейс № 2:
Исполнительная документация
Исполнительная документация
Дано
Исполнительная документация — это набор документов, фиксирующих фактическое состояние строительного объекта и этапы его строительства, подтверждающих соответствие проекту и строительным нормам. Эти документы необходимы для ввода объекта в эксплуатацию и обслуживания.
Одним из ключевых документов является акт освидетельствования скрытых работ, который фиксирует работы, закрытые следующими этапами. Он содержит более 40 сущностей для заполнения и оформляется вручную, на бумаге или в Word. Несмотря на множество подобных документов, процесс был решено строить на основе именно этого акта.
Одним из ключевых документов является акт освидетельствования скрытых работ, который фиксирует работы, закрытые следующими этапами. Он содержит более 40 сущностей для заполнения и оформляется вручную, на бумаге или в Word. Несмотря на множество подобных документов, процесс был решено строить на основе именно этого акта.
Задача
Упростить и сделать максимально комфортным процесс заполнения акта освидетельствования скрытых работ (далее АОСР), предусмотреть масштабируемость способа на другие подобные документы.
Действие № 1: Смотрю на то, что есть
Начал как всегда с описания и анализа процесса. Проанализировав пару тройку актов, я выделил следующее:
- У одного акта большое количество связей «один ко многим»: один акт — много ответственных, много подрядчиков, много схем и т.д.
- Есть одна устойчивая связь «один к одному»: один акт — одна запись общих работ.
- Многие поля заполнены по строгой маске, а значит их можно стандартизировать для автозаполнения.
- Много полей имеют вспомогательный характер, в них редко что‑то вписывают, но они зафиксированы на уровне требований законодательства.
- Некоторые наборы полей повторяются по акту два, а то и три раза. Например, блок полей с ответственными, которых на один акт пять человек и две организации, дублируется три раза.
Для того, чтобы разобраться, откуда растут ноги и берутся все данные, да ещё и в таком упорядоченном виде, пошёл на короткое интервью с инженером, который регулярно участвует заполнении актов как представитель застройщика. Оказывается, все акты формируются на записях общих работ. Таких записей может быть несколько, но базовая, первая запись, всегда одна — «основная запись общих работ». Это список всех последовательных операций, которые были произведены на строительной площадке: все этапы, все даты, все разгрузки, весь монтаж и т.д. Список вёлся в крупных реестрах, которые могли отдавать данные в нужном виде. Инженеры выгружали себе .xls и из него копировали в акты нужные им сущности. Отсюда и идентичный вид всех данных в каждом акте.
Данных в основной записи общих работ было достаточно, чтобы заполнить как минимум 40% данных в АОСР.
Создаю полный список полей и определяю их свойства, чтобы понимать масштаб:
По итогу исследования я выяснил, что 30 полей акта мы можем заполнять автоматически при выборе основной записи работ. Реестры ведутся ответственно, т.к. требования законодательства жёсткие, соответственно крайне мала вероятность того, что какая‑то сущность не подтянется или подтянется некорректно.
Здесь я начал подозревать о нескольких корнер-кейсах, проработал их далее, уже на этапе макетов.
Действие № 2: Продумываю UF по созданию акта
Я выделил два места, из которых пользователь может создать АОСР:
- Реестр всех актов — через кнопку «+ создать акт» над реестром.
- Реестр записей общих работ — через кнопку «+ создать АОСР» в контекстном меню любой записи общих работ в списке.
Заполнение обязательных полей оказался довольно громоздким куском процесса:
Все обязательные поля — разных типов.
Три поля требуют нетипичный функционал и визуал.
Имеется набор из пяти полей, которые идут в связке и должны уметь «клонироваться».
Все обязательные поля — разных типов.
Три поля требуют нетипичный функционал и визуал.
Имеется набор из пяти полей, которые идут в связке и должны уметь «клонироваться».
Действие № 3: Рисую форму
Если пользователь создаёт акт из реестра актов, сначала ему предлагается выбрать тип акта и запись основных работ, на основании которой будет создан акт:
После чего его встречает основное окно формы:
Внутри блока «Запись общих работ» пользователь видит, по какой записи формирует акт. Это важно, т.к. во время заполнения ему нужно иметь перед глазами данные из записи. Тут же он может изменить запись, если он понял, что формирует по неактуальной записи. В таком случае система вернёт его на выбор записи общих работ, поля из новой записи переподтянутся, а поля с работами, связками и датой с номером акта — останутся.
Набор полей «Основные данные» наиболее сложный. К одному акту могут быть подтянуты несколько дополнительных записей общих работ кроме базовой, ещё нужны схемы и протоколы испытаний. Их количество внутри одного акта варьируется, самый распространённый диапазон — 2–8.
При вводе номеров или данных внутри полей, анализируется справочник и предлагаются релевантные результаты в дропдауне. При клике по нужной сущности — она фиксируется под полем, после чего операция повторяется, накапливая, таким образом, все нужные основные данные:
При вводе номеров или данных внутри полей, анализируется справочник и предлагаются релевантные результаты в дропдауне. При клике по нужной сущности — она фиксируется под полем, после чего операция повторяется, накапливая, таким образом, все нужные основные данные:
Набор полей «Работы» содержит набор стандартных полей, по функционалу отличается лишь поле «Разрешается производство последующих работ». Дело в том, что именно это поле может присутствовать в количестве 1–15 экземпляров с минимальными различиями в заполненных данных. Пример:
Для этого мной была введена кнопка копии, которая создаёт полную копию уже заполненной работы. Ситуация, когда нужно ввести работы из разных направлений очень редка, если отличающаяся работа есть — то она одна и идёт в самом конце.
Остаётся блок полей «Заполнено автоматически». В нём находятся 20–30 полей (в зависимости от типа акта), которые заполняются из записи общих работ. Для информирования я добавил дисклеймер о том, что тут все остальные поля, поставил счётчик полей. По кнопке их все можно посмотреть и проверить. Их два типа: справочники и поля ввода в несколько строк.
Таким образом, для составления акта пользователю нужно внимательно заполнить 10 полей вместо 20–40.
Корнер-кейсы
Во время вытягивания данных из записи общих работ и заполнения полей в акте произошла ошибка: либо формат данных не подошёл, либо метод отработал неправильно. В общем какое‑то из полей в блоке «Заполнено автоматически» заполнилось неверно.
Выход: если данные, попавшие в поле, не подходят по маске или передаётся значение null — поле остаётся пустым. Маски регламентированы, мы можем позволить себе жёсткую проверку. А т.к. все поля в скрытых — обязательные, пользователь не сможет сохранить акт. Форма развернётся и покажет пустые поля. Конец процесса интеграции сопровождается тостом о том, что не все поля заполнились корректно. Это редкий случай, у инженеров есть регламентированные действия на такой случай — если данные в записи общих работ указаны некорректно или не указаны вовсе, это может повлечь серьёзные проблемы для стройки.
Выход: если данные, попавшие в поле, не подходят по маске или передаётся значение null — поле остаётся пустым. Маски регламентированы, мы можем позволить себе жёсткую проверку. А т.к. все поля в скрытых — обязательные, пользователь не сможет сохранить акт. Форма развернётся и покажет пустые поля. Конец процесса интеграции сопровождается тостом о том, что не все поля заполнились корректно. Это редкий случай, у инженеров есть регламентированные действия на такой случай — если данные в записи общих работ указаны некорректно или не указаны вовсе, это может повлечь серьёзные проблемы для стройки.
Во время заполнения акта пользователь понимает, что ему нужно закрыть окно создания акта, чтобы потом продолжить. Это может случиться, например, в ситуациях:
Нужный документ или подобная сущность ещё не заведены в систему и на них нельзя сослаться.
Пользователь уволился/перевёлся/отсутствует в системе по другой причине.
Нужно уточнить иную важную информацию.
Для этого я ввёл отдельную вкладку черновиков в списках актов. Туда сохраняются недозаполненные акты, решение о сохранении принимает пользователь через диалоговое окно при закрытии формы создания акта. Никаких сверх гибких механизмов в черновиках нет — метод берёт название акта и добавляет к нему дату+время создания.
Нужный документ или подобная сущность ещё не заведены в систему и на них нельзя сослаться.
Пользователь уволился/перевёлся/отсутствует в системе по другой причине.
Нужно уточнить иную важную информацию.
Для этого я ввёл отдельную вкладку черновиков в списках актов. Туда сохраняются недозаполненные акты, решение о сохранении принимает пользователь через диалоговое окно при закрытии формы создания акта. Никаких сверх гибких механизмов в черновиках нет — метод берёт название акта и добавляет к нему дату+время создания.
Результат
Благодаря тому, что сотрудникам больше не приходится тратить время на ручное заполнение акта, остаётся достаточно времени для согласования и подписания документа.
Это позволяет всем участникам завершить процесс в течение одного рабочего дня, что значительно ускоряет работу и минимизирует возможные задержки на этапе согласований.
~
16–24 часа→3–5 часов
16–24 часа→3–5 часов
на заполнение и согласование акта
А дальше?
Результат первой итерации улучшения процесса был крайне положительным, но, поговорив с инженерами и командной разработки, я выяснил, что мы можем сделать ещё лучше. Если ввести жёсткую нумерацию актов и уникальные идентификаторы, чтобы отслеживать каждый акт в системе по связке «дата+идентификатор+типа акта+номер записи общих работ», то нам не придётся заполнять блок «Работы». Мы так же можем автоматизировать заполнение блока «основные данные», если на этапе заполнения записей общих работ проставлять связи между ними. Таким образом, мы сможем прийти к форме вида:
Положили задачи в бэклог.
Остальные модули
Среда Общих Данных
Охрана труда
Передача квартир
Строительный контроль
Пожарная безопасность
Ещё 10
Всего на платформе планировалось около 15 модулей. Какие‑то работали до создания продукта, какие‑то всё ещё в планах.
Одновременно активные работы велись по 5–6 модулям.
Ещё пара небольших примеров ниже.
Ещё пара небольших примеров ниже.
Среда общих данных
Модуль, призванный обеспечить комфортный и быстрый документооборот. В нём создавались, циркулировали, проверялись, подписывались, отклонялись документы различных видов.
С ним была связана интересная задача по пересмотру UI. Модуль создавался на Material 2 ещё до ввода собственной дизайн-системы. Когда мы пришли к общему представлению о дизайне, модуль уже был в промышленной эксплуатации. Нам нужно было переехать на нашу дизайн-систему, при этом не сломав привычки пользователей, но и не забыть про консистентность всех модулей системы. Меню навигации в первой версии модуля было горизонтальным, а боковые дроверы отвечали за навигацию по папкам и этапы согласования.
С ним была связана интересная задача по пересмотру UI. Модуль создавался на Material 2 ещё до ввода собственной дизайн-системы. Когда мы пришли к общему представлению о дизайне, модуль уже был в промышленной эксплуатации. Нам нужно было переехать на нашу дизайн-систему, при этом не сломав привычки пользователей, но и не забыть про консистентность всех модулей системы. Меню навигации в первой версии модуля было горизонтальным, а боковые дроверы отвечали за навигацию по папкам и этапы согласования.
Вариант на проде
Предложения по редизайну
Охрана труда
Модуль-флагман всей системы. Он появился первым, с него начался Contrust. Модуль отвечает за отслеживание безопасности на строительной площадке. Опасные случаи фиксируются на BIM-модели силой инженеров по безопасности, которые обходят строительную площадку. Нам нужно было предоставить им максимально комфортный интерфейс на планшетах, а данные, которые они собирают — показывать в виде графиков и цифер.
Процесс обхода, интерфейс модуля на планшете
Страница отчётов по безопасности и уровню риска
Передача квартир покупателям
Когда покупателю отдают ключи — ему нужно принять квартиру и подтвердить её надлежащее состояние. Зачастую внутри квартиры клиента что‑то не устраивает, так что все недочёты должны быть зафиксированы и исправлены. Модуль ПКП ориентирован на это — сотрудник компании проводит осмотр вместе с покупателем, заносит дефекты в систему, составляет акты осмотра и т.д. Обход происходит с планшета, так же есть десктоп версия.
Процесс осмотра квартиры
Шахматка по состоянию квартир и осмотров
Это лишь малая часть всего, что мы сделали за три года работы над продуктом. Описать всё в рамках кейса — нереально. Мы через многое прошли и многому научились. И всё ещё не дошли до нижних слоёв айсберга под названием «стройка».
Я закончил работу над продуктом летом 2024 года, оставив после себя все наработки и талантливого дизайнера на своём месте. Продукт успел поездить по конференциям и начать светиться в инфополе девелоперского комьюнити.
Будущее
Выставка-форум в начале 2024 года. Один из стейкхолдеров рассказывает положительную динамику за последние 10 лет, которая достигнута в том числе благодаря IT решениям
Сейчас продукт всё ещё скрывается внутри группы компаний. Выше представленные кусочки продукта — всё, что мне удалось вытащить из под NDA.
Надеюсь, что продукт реализует весь свой потенциал в будущем.
Отдельное спасибо дизайнерам, трудившимся над продуктом вместе со мной, часть представленных макетов принадлежит им. Благодаря их усидчивости и профессионализму, мы смогли добиться значимых результатов на рынке, где красивый и удобный дизайн всегда был где-то позади.
Кирилл Гаврилов
Андрей Каргельс
Игорь Устинов
Руслан Пронин
Владислава Кузмич
Алия Федосеева
Анастасия Никифорова
Роман Неведомский
Любая работа рано или поздно спотыкается о суровую действительность. Не обошлось и у нас с Контрастом без факапов. Расскажу о двух, которые оставили в моей памяти (и опыте) наибольший след.
Факапы
«Нам нужна своя дизайн-система!»
Не нужна.
И если вы думаете иначе, работая над несформированным продуктом — подумайте ещё десять раз.
На тот момент нам казалось, что существующие решения, такие как Material, Ant или Carbon, не смогут полностью покрыть наши специфические требования, особенно для работы с BIM-моделями. Мы предполагали, что для управления этими сложными (нет) элементами нам нужны будут уникальные компоненты, и ни одна существующая система не сможет справиться с такой задачей.
Мы вложили массу ресурсов — как временных, так и финансовых — в разработку собственной дизайн-системы, думая, что это даст нам больше гибкости. Однако, спустя несколько месяцев и значительно углубившись в процесс, стало очевидно, что мы знатно про***сь. Оказалось, что существующие системы могли легко адаптироваться под наши нужды, сэкономив нам массу времени и средств.
Иногда стремление к полной кастомизации только вредит, особенно когда на рынке уже есть проверенные решения. Вместо того чтобы переизобретать колесо, мы могли бы сосредоточиться на более важных задачах — например, на пользовательских сценариях и улучшении UX, а не на создании базовых компонентов с нуля.
И если вы думаете иначе, работая над несформированным продуктом — подумайте ещё десять раз.
На тот момент нам казалось, что существующие решения, такие как Material, Ant или Carbon, не смогут полностью покрыть наши специфические требования, особенно для работы с BIM-моделями. Мы предполагали, что для управления этими сложными (нет) элементами нам нужны будут уникальные компоненты, и ни одна существующая система не сможет справиться с такой задачей.
Мы вложили массу ресурсов — как временных, так и финансовых — в разработку собственной дизайн-системы, думая, что это даст нам больше гибкости. Однако, спустя несколько месяцев и значительно углубившись в процесс, стало очевидно, что мы знатно про***сь. Оказалось, что существующие системы могли легко адаптироваться под наши нужды, сэкономив нам массу времени и средств.
Иногда стремление к полной кастомизации только вредит, особенно когда на рынке уже есть проверенные решения. Вместо того чтобы переизобретать колесо, мы могли бы сосредоточиться на более важных задачах — например, на пользовательских сценариях и улучшении UX, а не на создании базовых компонентов с нуля.
«Почему бы не отдать это подрядчикам?»
К началу 2023 года IT-гонка добралась и до девелоперов: иметь своё IT было модно и необходимо. Рынок был перенасыщен псевдо-специалистами, которые вышли после курсов и просились в уютные офисы на большую зарплату. А обосновывать каждую рабочую единицу перед бизнесом всё ещё было трудно. Все эти факторы негативно влияли на наращивание команды, но сбавлять обороты было нельзя — бизнес уже купил идею и ввязался в гонку за первенство на рынке. Требований много, людей мало.
К началу 2024 года задачами по продукту занимались четыре команды: одна инхаус, три — аутсорс. Не буду говорить про методы выбора подрядчиков и их опыт, скажу лишь, что возникало много вопросов и ситуаций разной степени конфликтности. Я следил одновременно за восемью дизайнерами в четырёх разных окружениях, ревьюил макеты, следил за консистентностью, масштабировал дизайн-систему по требованиям. Количество тайных знаний стремилось к бесконечности, мы были близки к «комбинаторному взрыву». Тем не менее, с точки зрения дизайна, tone of voice и редполитики, сохранить «общность» и консистентность нам удавалось. Но работать в состоянии постоянного контроля было крайне деструктивно как для инхаус команды в общем, так и для ментального состояния каждого члена команды по отдельности.
К началу 2024 года задачами по продукту занимались четыре команды: одна инхаус, три — аутсорс. Не буду говорить про методы выбора подрядчиков и их опыт, скажу лишь, что возникало много вопросов и ситуаций разной степени конфликтности. Я следил одновременно за восемью дизайнерами в четырёх разных окружениях, ревьюил макеты, следил за консистентностью, масштабировал дизайн-систему по требованиям. Количество тайных знаний стремилось к бесконечности, мы были близки к «комбинаторному взрыву». Тем не менее, с точки зрения дизайна, tone of voice и редполитики, сохранить «общность» и консистентность нам удавалось. Но работать в состоянии постоянного контроля было крайне деструктивно как для инхаус команды в общем, так и для ментального состояния каждого члена команды по отдельности.
Связаться со мной
Отсюда через форму
Denya Design,
©
Другими способами
