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

Есть ещё исполнители, бригадиры и прочие роли, в нашем приложении информация о них содержится в справочниках и помогает технадзорам и прорабам в выполнении их непосредственных обязанностей.
Нужен удобный инструмент для хранения и обмена данными. Сейчас люди используют онлайн-таблицы от иностранного провайдера, доступ к которым в любое время могут в одностороннем порядке ограничить. Таблицы называют шахматками.
Шахматка — это привычный и удобный инструмент для ведения записей о производимых работах, занятых исполнителях, объёмах, материалах, выплатах и пр. Чаще всего представляет из себя таблицы, настроенные в произвольной форме, которые выполняют роль примитивного BIM (англ. Building Information Model). В столбцах номера квартир или названия помещений, в строках номера этажей. На пересечении информация о работах в помещении. Таблица может быть транспонирована.
Понятие «Шахматка» на стройке знакомое, по этой причине выбирать название для приложения долго не пришлось.
К моменту как я присоединился к команде, приложение уже разрабатывали пять лет. Наблюдался кризис в информационной архитектуре, компонентной базе с точки зрения применяемых паттернов, описании базовых сценариев, подготовке и передаче требований в разработку.

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

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

Нужно избавиться от всего, что не несёт ценности и и замедляет работу. Вот и первая метрика: от первоначального входа до ввода данных о работе, должно быть менее пяти минут. Изначально мы планировали что-то в пределах пятнадцати минут, но на мой взгляд, для мобильной версии продукта — это вечность.
Когда мы приступили к работе и отладке процессов, позволяющих улучшить анализ и качество требований, в мире начались глобальные изменения. Причём такого масштаба, что пришлось в экстренном порядке отказываться от иностранных облачных сервисов, а где-то нам в этом помогли и сами поставщики. Позднее мы потеряли ощутимую часть команды, а разработка замедлилась настолько, что могло показаться будто бы она и вовсе не ведётся.
Тогда же мне пришлось вернуться к Sketch вместо Figma. Не скажу, что меня это сильно расстроило, ведь мой ноутбук теперь мог работать на одном заряде батареи не полтора-два часа, а все шесть или семь.

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

Так получилось, что функция наполнения беклога в какой-то момент досталась мне. Появилась возможность написать глоссарий и начать разговаривать на одном языке не только в интерфейсе и с пользователями, но и между собой. Отдельной функции технического писателя нам не выделили. Дело в том, что у каждой команды, в которой мне доводилось работать немного, но отличалась терминология. Иногда это связано с предметной областью, а на стройке полно акронимов и аббревиатур. Это несколько осложняло работу.
Нам предоставили таблицы, сделанные руками технадзоров и прорабов. Так мы узнали, что на разных объектах процесс ведения шахматки как и её форма отличались друг от друга. Совпадали лишь некоторые наборы полей, но местами отличалась даже терминология.
Что мы поняли:
- Нам нужны массовые операции, для ввода информации о выданном наряде, например, на этаж.
- Представление данных и их ввод должны быть привычными для пользователя.
- Нужен простой, удобный и настраиваемый инструмент просмотра всех полей, связанных с работами. Это позволит покрыть пользовательские запросы в зависимости от распределения функций на разных объектах.
- От первоначального входа до ввода данных о работе, должно быть менее пяти минут.
- Настройка второй и последующих шахматок должна занимать ещё меньше времени, чем при первоначальном входе.







В нашей шахматке есть совместная работа. Можно пригласить коллегу с правами на чтение или полный доступ. Сама таблица отображает изменения в реальном времени. Теперь у нас есть возможность вести учёт. Постепенно мы подошли к главному вопросу: вести учёт чтобы...?
Логично предположить, что всё упирается в документооборот и отчётность. Дальше встаёт вопрос интеграции и выгрузки данных. В первой версии мы заложили функциональность формирования реестров на выплату за выполненные работы и выгрузку данных о работах с учётом фильтрации.
Отчёты и реестры на выплату представляют из себя слепки данных. Это означает, что, сформировав реестр на выплату, вы не имеете зависимостей от настроек таблицы и списка работ. Единственное, что нужно оставить — это отображение оплаченных объёмов в форме ввода, если конкретно эта работа в этом помещении уже оплачивалась.
Это открывает дорогу к относительно безболезненному версионированию. Ведь сама таблица превращается в своего рода форму для выпечки отчётов (слепков данных), помогающих заполнить первичку или реализовать интеграцию с другим программным продуктом.









Программное обеспечение должно учитывать несовершенство реального мира. Цифровизация и цифровые двойники должны отображать не идеальную картину, а реальную. Интерфейс, в том числе, нужен для того, чтобы приводить цифровой мир в соответствие с реальным. В противном случае программа становится бесполезной или сложной в использовании.
Наша реальность заключается в том, что все пользовательские истории крутятся вокруг строящегося объекта. В нём нет уютного офиса с быстрым и стабильным доступом в сеть. По зданию нужно ходить ногами, а в руках носить бумаги, чертежи, инструменты и прочее.
Мы понимаем, что часть пользовательских историй, реализуется на объекте. Например, когда технадзор, принимая работы, фиксирует замечания. Удобно, когда можно сфотографировать или снять видео и сохранить в шахматку, снабдив его комментарием.
Мы реализовали функциональность работы с замечаниями в веб версии и спроектировали дизайн мобильного приложения с оффлайн режимом и функцией синхронизации.



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


Для удобства работы, мы реализовали механизм, сохраняющий последнюю шахматку с которой работал пользователь и выбранный в ней пункт меню в левом списке. Таким образом, если пользователь закрывает вкладку браузера или разлогинивается, при последующем входе система автоматически перенаправит его на таблицу с которой он последний раз работал.
Команда разработки использовала готовую библиотеку компонентов MUI С моей же стороны были небольшие запросы по доработке стилей.


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


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





Библиотека для переноса слов:
https://github.com/sergeysolovev/hyphenated
https://github.com/denisotree/hyphenated-ru
Для работы с классификаторами:
https://jakezatecky.github.io/react-checkbox-tree/
Для вывода дат:
https://date-fns.org/docs/Getting-Started
Можно также ознакомиться с упрощёнными требованиями к выводу дат и чисел.
Проект дошёл до полевых испытаний на пользователях, но, к сожалению, не пережил кризисные явления. В процессе работы я отточил навык системного подхода к проектированию интерфейсов, немного обновил знания по языкам разметки и обзавёлся новыми в области строительства и отделки.
13 марта, 2023
Пётр Лутов
Дизайн в разработке программного обеспечения