Собрал из журнала номеров единое место хранения документов по проекту

САТЕЛ ведёт проекты для крупных заказчиков. По каждому копится документация: договоры, техническая документация, учебные и маркетинговые материалы, исходный код, контакты представителей. Лежало это где придётся — у одного на диске, у другого в почте, сделки и договоры в 1С. Документы терялись.

Связывает всё децимальный номер — код вида САБУ.620112.022, который получает проект и каждый документ к нему. Правила выдачи описаны в ГОСТ и внутреннем регламенте: два одинаковых номера ломают учёт.

Номера вели в Excel, потом — в первой версии Ариадны. Она умела завести номер и найти заведённый, дублируя запись из 1С. Собрали её разработчики без дизайнера, на дефолтных компонентах Material Design, и работало это плохо: номер собирался неправильно, поиск не работал.

Бизнес отказывался пользоваться сервисом: нужного функционала в нём не было.

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

• Закрытый контур. Система работает только внутри компании, доступ есть не у всех сотрудников. Внешних пользователей и открытой аналитики нет.
• Существующее техническое решение. Работа шла на уже написанном прототипе: архитектуру и стек я не выбирал.
• Правила нумерации заданы извне. Упрощать порядок из ГОСТ и регламента было нельзя — только перенести его в интерфейс.
• Проблема была сформулирована до меня. Бизнес назвал конкретные поломки, а правила предметной области лежали в регламенте. Поэтому вместо исследования — разбор регламента вместе с аналитиками и разговор с техническими писателями.

Количество пользователей — приблизительная оценка команды.

Заполнение я проектировал под технических писателей: чем меньше решений они принимают руками, тем меньше ошибок попадёт в общую базу. Поиск — под руководителей: они приходят за готовым результатом и не должны разбираться в устройстве нумерации.

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

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

Фильтры по статусу и дате применяются ко всей таблице и работают вместе с поиском. На иконке столбца, по которому применён фильтр, появляется точка: без неё человек видит меньше строк и не понимает почему.

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

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

Теперь всё привязано к проекту. Документ прикладывается ссылкой на источник или загрузкой файла, не больше пяти на проект. PDF и изображения открываются внутри Ариадны.

К проекту относятся не только документы по ГОСТ: учебные и маркетинговые материалы, рабочее пространство, исходный код, представители заказчика. Одним списком это нечитаемо, поэтому разнёс по вкладкам и поставил документы первыми.

Заказчики, сделки и договоры уже заведены в 1С. Раньше их переносили руками: человек шёл в другую систему, находил нужное, вводил заново — с опечатками и расхождениями. Заведение проекта я начал с интеграции: указываешь сделку, и заказчик, руководитель, договор подтягиваются сами.

Дальше — номер. Раньше его тоже собирал человек: технический писатель держал регламент в голове, складывал значения в строку и вводил вручную. Ошибиться можно было на любом шаге, и ошибка уходила в документы.

Правила я вынес в справочники — ГОСТ, стадия, код, том. Человек выбирает признаки, строку собирает система. При заведении проекта номер назначается автоматически; ручной ввод остался отдельным переключателем — для номеров, выданных до появления системы.

Справочники, которые всё это питают, разделены по ответственности:

• системные — проекты, продукты, сделки, договоры. Приходят из 1С, внутри Ариадны не редактируются. Обмен может не пройти, поэтому у него есть отдельные состояния успеха и ошибки;
• пользовательские — ГОСТы, документы по ним, организации, главные архитекторы. Ведут технические писатели.

Тот же принцип — человек выбирает признаки, номер собирает система — работает и на уровне документа. Форма разбита на три шага. Первый — развилка: документ по ГОСТ или любой другой. Для «другого» номер не нужен, и вся логика нумерации дальше не появляется. Второй шаг — выбор документа из справочника с поиском по коду. Третий — том и ссылка, номер уже подставлен, человек видит его до нажатия «Сохранить».

Первая версия умела два действия. Что изменилось:

Продукт презентовали руководству компании и передали техническим писателям. По словам коллег, после правок по багам они пользуются системой до сих пор.

Метрик по проекту не собирали: продукт внутренний, аналитики в контуре не было. Если бы измеряли, показателями были бы доля номеров, выданных вручную, число исправлений номера после выдачи и полнота комплекта документов по проекту — всё это считается по данным самой системы.

Полная документация проекта — макеты, правила системы, состояния и сценарии: файл в Figma.