Личный блог Дмитрия Подлужного: о работе и около нее

Проектирование системы автоматизации процессов

Записки о работе, 24 октября 2014

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

Информация по задаче поступила в виде двух текстов технических заданий, нескольких набросков интерфейса на бумаге, набора таблиц в Excell. Я называю это хаосом. Самое негативное впечатление оказало на меня тотальное сокращение терминов, которым был пронизан текст одного из технических заданий. Русский язык настолько хорош, что незачем сокращать его до ЮЛ, ЛК, ФК, ИС, АП и т.д. Поэтому приходилось вначале переводить текст на понятный для меня язык, а потом заниматься его анализом для выделения существенных элементов системы.

20141021-tz-color

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

Честно говоря, два технических задания для одного проекта – это дорога к провалу (и такое встречается, к сожалению, нередко). Если вы наивны, то может показаться, что это упрощает проектирование, но в реальности — усложняет его на порядок.

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

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

Схема процессов

Мне было важно определить, как будет работать система. И текст, в такой ситуации, остается средством низкой эффективности обсуждения. Поэтому я перешел на визуализацию схем.

20141021-first-cmap

Я использую Cmap, как самое простое и удобное средство для визуализации идей. Простота и отсутствие условностей позволяет концентрироваться на сути. Получается, может быть, не очень красиво, но очень эффективно.

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

20141021-all-cmap

Пользователи

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

User X

Вводит учетные документы
Наблюдает за процессом прохождения заявок
Регистрирует новых пользователей
Редактирует данные пользователей и условия доступа к системе
Отвечает на сообщения

User Y

Формирует заявки к системе
Получает результат
Пишет сообщения по разным темам
Редактирует часть персональных данных

Основываясь на функциональных требованиях, мной были разработаны вайрфреймы системы. Отдельно страницы для функций администратора, отдельно для пользователей. Соотношение получилось 11 к 8. Часть из страниц приведена на иллюстрации снизу.

20141021-ap

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

Личные наблюдения и выводы по работу

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

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

Подлужный Дмитрий Арнольдович

Об авторе

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