Сколько нужно программистов, чтобы сделать форму для пользователя? Ни одного! Для этого достаточно создать инструмент, с помощью которого создавать формы для web-решений смогут даже домохозяйки.
Представьте себе портал, с огромным количеством различных пользовательских форм. Например, такой как gosuslugi.ru, где имеется порядка 10 000 электронных форм получения государственных услуг. Представили? А теперь представьте, что людей, которые генерят требования для создания этих форм, то есть заказчиков, примерно в 10 раз меньше чем самих форм — всего-то около тысячи. Ну и, наконец, представьте сколько нужно разработчиков, чтобы сделать около 300 уникальных, со своими тараканами, форм за месяц? Около 100! Причем они должны быть высококвалифицированные, чтобы самостоятельно могли все сделать. Стажеры тут не справятся. А еще каждую форму надо перед разработкой проанализировать, после — протестировать, дать заказчику на приемку, поправить замечания и передать на установку. А это значит, что нужны еще тестировщики и аналитики.
Итого получается около 200 высококвалифицированных человек на месяц. Если предположить, что такую команду и получится собрать, что само по себе почти невозможно, себестоимость такой разработки будет зашкаливать и многократно превышать адекватную на рынке стоимость такой работы. Очевидно, чтобы решить такую задачу, необходимо что-нибудь автоматизировать. Но что?
Чтобы понимать масштаб бедствия, давайте посмотрим что необходимо сделать, чтобы разработать и передать на установку работающую форму получения услуги.
По-любому надо что-то автоматизировать, скажете вы. И будете правы. Первый кандидат – пункт 4. Надо сделать сервис, который будет принимать на вход готовый к отправке XML и отправлять его на СМЭВ. ОК, готово, сделали. Еще? Да черт возьми, пункт 3! Процесс подписания-то одинаковый всегда. ОК, готово сделали еще один сервис. На входе XML, на выходе подписанный XML. Круто! Больше автоматизации, Карл! Осталось два пункта – создание формы и генерация XML документа по формату ведомства. Хм, а вот и проблема…
Как можно автоматизировать действия, которые каждый раз разные? Ведь ТЗ на услугу (форма и XML) пишут ведомства, а ожидать однотипность требований в ситуации, когда заказчики соревнуются между собой «кто круче» не приходится.
Было решено, что нужен инструмент, позволяющий:
— максимально просто описать внешний вид формы, форматно-логический контроль для полей, логические связи между полями.
— дать возможность максимально просто на основе заполненной формы сгенерировать XML-документ нужного формата.
Что скажет опытный разработчик про такую задачу? Надо писать фреймворк. Сформировали основные требования к нему и побежали кодить:
– Стандартизация внешнего вида форм, создание набора виджетов
– Легкая кастомизация, настройка виджетов
– Возможность подключать к разработке младших разработчиков и стажеров
– Наследование разработанными ранее формами всех последующих изменений в ядре
– Автоматическая генерация выходного XML документа по шаблону
В качестве технологий было выбрано:
– Слой БД: Oracle Database
– Слой приложений: Java 1.6
– Backend-шаблонизатор: Freemarker
– Frontend-фреймворк: набирающий в то время популярность jQuery
Результаты не заставили себя ждать. Буквально через месяц после начала разработки фреймворка выстроилась достаточно простая схема работы:
Какие основные плюсы мы получили? Для разработки самих форм больше не требовались backend и фронтэнд-разработчики. Основное, что требовалось от специалиста – знать синтаксис и возможности Freemarker и уметь пользоваться готовой библиотекой. Для большинства форм таких навыков хватало. Для сложных случаев подключались более опытные разработчики, где могло потребоваться покопаться с html, javascript или наоборот с java. Наиболее опытные занимались разработкой ядра фреймворка, где уже требовались глубокие знания фронтовых и бэковых технологий.
Команда разработки ядра состояла в разное время из 4-8 человек – 2 фронта, 2 бэка, тестировщик и тимлид. Минимальная команда разработки услуг составляла 2 человека – половина аналитика, разработчик и половина тестировщика. Внедрение фреймворка позволило сформировать несколько независимых команд разработки услуг, а в последствии и несколько десятков таких команд, распределенных территориально. Каждая команда могла создавать 1-3 услуги в месяц, в зависимости от их сложности, а time-to-market каждой формы составлял в среднем 35-50 дней.
Таким образом производительность двадцати команд (~50 человек) составляла около 40 услуг в месяц. Неплохо. Но недостаточно. Задача была – 300 в месяц. Наращивать состав команды было уже экономически не выгодно, нужно было более оптимальное техническое решение.
Несчетное количество разработчиков и аналитиков проводили дни и ночи перед своими мониторами, кодили, анализировали, звонили заказчикам, потом снова кодили, потом опять анализировали, потом исправляли ошибки и, наконец, получалась готовая услуга. Количество услуг, которые надо было делать, возрастало в геометрической прогрессии и проблема стала очевидна. Требовалось какое-то её решение. Злейшие враги существовавшего подхода были известны: сложность, скорость (точнее, её отсутствие), необходимость технических знаний в области разработки, а также человеческий фактор – чем больше человек участвовало в разработке услуги, тем больше ошибок можно было допустить, как из-за невнимательности, так и по причине недопонимания и «сломанного телефона» при путешествии постановки задачи от заказчика к разработчику.
Итак, задача стояла следующая:
– уменьшить время разработки услуги
– сократить количество человек, участвующих в процессе разработки формы
– еще больше снизить требования к необходимой квалификации разработчиков
Есть такое выражение – «если хочешь чтобы было хорошо – сделай сам». Совершенно неверное с точки зрения проектного управления, но именно оно легло в основу следующего витка развития системы разработки форм.
«Зачем тут вообще разработчики?», спросили мы себя. И действительно, что в нашем случае делал разработчик? Собирал страницу с вызовами виджетов и указывал настройки для них. Почему бы не сделать для этого пользовательский интерфейс? Как в Delphi или Visual Studio.
Забегая вперёд, скажу, что результаты были фантастические, но для этого пришлось потратить некоторое время и усилия. Всем командам разработки мы объявили о прекращении развития старого фреймворка, оставив его на поддержке и занялись разработкой нового.
Отличием в части технологий было строгое разделение модели данных и представления. Бэкенд шаблонизатор больше не требовался, сервер приложений фреймворка представлял из себя набор REST сервисов, с минимальной бизнес-логикой внутри. Основная часть логики находилась на клиенте – в браузере.
Фреймворк состоял из двух основных компонентов: конструктор форм и проигрыватель форм. В конструкторе формы создаются и редактируются в визуальном режиме, а в проигрывателе исполняются – отрисовывается сама форма, работают правила валидации, связей между полями.
Основные функции конструктора:
Основные типы полей (виджеты):
Основные функции проигрывателя:
Основная идея, заложенная в новый фреймворк – абстрагирование от всего, кроме непосредственно экранной формы. Если представить его в виде человека, то он будет из тех, кто говорит: «К пуговицам претензии есть?» Принцип архитектуры очень простой: «Моя задача отобразить форму, выполнить все действия, описанные в конструкторе, отправить данные. Остальное мне неважно, особенно что там с этими данными потом произойдет». За счет такого подхода мы достигли поразительной гибкости, и смогли использовать любые системы-контрагенты, в которые направляются промежуточные и финальные запросы, смогли использовать любую систему аутентификации для обеспечения доступа к формам, встраивать проигрыватель на любую web-страницу любого приложения в любое окружение.
Создание формы в конструкторе выглядит примерно следующим образом:
– Создаем форму
– Выбираем из выпадающего меню нужные нам элементы, размещаем на форме
– В инспекторе атрибутов настраиваем поля, как нам требуется с помощью галочек, кнопочек и списочков
– Настраиваем валидацию полей, выбирая нужный метод проверки или набор методов из списка доступных
– Настраиваем взаимосвязи между полями
– Подкладываем XSLT шаблон формирования результирующего XML документа
– Указываем реквизиты системы-получателя
– Форма готова!
Еще одно огромное преимущество — независимость описания формы от платформы исполнения. За счет того, что форма хранится в виде метаописания в формате JSON, которое лишь описывает состав компонентов формы и их взаимосвязи, но не описывает представление, достаточно один раз разработать форму в конструкторе и ее можно исполнять на любом устройстве, для которого существует проигрыватель форм: например, на платформе iOS или Android, SmartTV и других.
Какие основные плюсы мы получили на втором витке развития фреймворка? Для разработки самих форм больше не требовались разработчики вообще. От специалиста, создающего формы требовалось только уметь пользоваться графическим интерфейсом конструктора форм и уметь написать простое XSLT-преобразование. Этого хватало для большинства форм. Были, конечно, и сложные случаи, тогда обращались к команде разработки ядра, которая по заказу за неделю-две разрабатывала необходимую функцию или виджет.
Таким образом состав команды разработки услуг удалось сократить до 1-го человека, так как никакой разработки по сути не требовалось. Создавать формы смогли аналитики, не имеющие навыков разработки. За месяц один человек смог делать 5-7 форм, а time-to-market сократился до десяти дней. В итоге производительность тех же пятидесяти человек составила уже около 300 форм в месяц. То что нужно!
Вот отзывы нескольких представителей команд разработки услуг после пилотного периода использования нового фреймворка:
А это отзыв руководителя группы разработки фреймоворка:
В чем главный инсайт этой истории? Я выделил для себя 3 главных момента.
А что для себя отметили вы? Будет круто услышать в комментариях. Если тема интересна, то я готов продолжить цикл статей о Конструкторе форм.
Про что ещё можем поговорить:
– О технологической составляющей – архитектура, используемые инструменты, взаимосвязи между компонентами, точки расширения и кастомизации.
– Об организации работы большого количества человек для решения задачи «разработать 10 тысяч услуг», о создании community разработки форм, об обучении, сертификатах, стажерах, студентах и так далее.
– О развитии функций фреймворка и как из узкоспециализированного инструмента для разработки услуг он стал универсальным внутренним продуктом компании для решения различных задач.
10 тысяч электронных услуг
Представьте себе портал, с огромным количеством различных пользовательских форм. Например, такой как gosuslugi.ru, где имеется порядка 10 000 электронных форм получения государственных услуг. Представили? А теперь представьте, что людей, которые генерят требования для создания этих форм, то есть заказчиков, примерно в 10 раз меньше чем самих форм — всего-то около тысячи. Ну и, наконец, представьте сколько нужно разработчиков, чтобы сделать около 300 уникальных, со своими тараканами, форм за месяц? Около 100! Причем они должны быть высококвалифицированные, чтобы самостоятельно могли все сделать. Стажеры тут не справятся. А еще каждую форму надо перед разработкой проанализировать, после — протестировать, дать заказчику на приемку, поправить замечания и передать на установку. А это значит, что нужны еще тестировщики и аналитики.
Итого получается около 200 высококвалифицированных человек на месяц. Если предположить, что такую команду и получится собрать, что само по себе почти невозможно, себестоимость такой разработки будет зашкаливать и многократно превышать адекватную на рынке стоимость такой работы. Очевидно, чтобы решить такую задачу, необходимо что-нибудь автоматизировать. Но что?
А что такое услуга?
Чтобы понимать масштаб бедствия, давайте посмотрим что необходимо сделать, чтобы разработать и передать на установку работающую форму получения услуги.
- Разработать пользовательскую форму
Страница(ы) портала, на которой пользователь заполняет необходимую информацию для подачи заявления на получение услуги
- Подготовить XML документ запроса в информационную систему ведомства
Перед отправкой во внешнюю информационную систему данные, которые ввел на форме пользователь, должны быть преобразованы в XML-документ специального формата. Какого – определяет ведомство, которое и является заказчиком разработки услуги.
- Обернуть и подписать XML-документ электронной подписью
Сформированный XML-документ отправляется не напрямую в ИС ведомства, а в специальную шину, которая называется СМЭВ – система межведомственного электронного взаимодействия. Эта система также требует, чтобы входящие XML документы были определенного формата. Поэтому перед отправкой мы должны сформированный на этапе 2 XML документ «завернуть» в другой XML формат по требованиям СМЭВ, и вдогонку еще и подписать электронной подписью портала госуслуг.
- Отправить подготовленный XML документ
Только после всех этих магических действий происходит отправка документа в информационную систему ведомства через СМЭВ.
Автоматизация, Карл!
По-любому надо что-то автоматизировать, скажете вы. И будете правы. Первый кандидат – пункт 4. Надо сделать сервис, который будет принимать на вход готовый к отправке XML и отправлять его на СМЭВ. ОК, готово, сделали. Еще? Да черт возьми, пункт 3! Процесс подписания-то одинаковый всегда. ОК, готово сделали еще один сервис. На входе XML, на выходе подписанный XML. Круто! Больше автоматизации, Карл! Осталось два пункта – создание формы и генерация XML документа по формату ведомства. Хм, а вот и проблема…
Классика жанра
Как можно автоматизировать действия, которые каждый раз разные? Ведь ТЗ на услугу (форма и XML) пишут ведомства, а ожидать однотипность требований в ситуации, когда заказчики соревнуются между собой «кто круче» не приходится.
Было решено, что нужен инструмент, позволяющий:
— максимально просто описать внешний вид формы, форматно-логический контроль для полей, логические связи между полями.
— дать возможность максимально просто на основе заполненной формы сгенерировать XML-документ нужного формата.
Что скажет опытный разработчик про такую задачу? Надо писать фреймворк. Сформировали основные требования к нему и побежали кодить:
– Стандартизация внешнего вида форм, создание набора виджетов
– Легкая кастомизация, настройка виджетов
– Возможность подключать к разработке младших разработчиков и стажеров
– Наследование разработанными ранее формами всех последующих изменений в ядре
– Автоматическая генерация выходного XML документа по шаблону
В качестве технологий было выбрано:
– Слой БД: Oracle Database
– Слой приложений: Java 1.6
– Backend-шаблонизатор: Freemarker
– Frontend-фреймворк: набирающий в то время популярность jQuery
Результаты не заставили себя ждать. Буквально через месяц после начала разработки фреймворка выстроилась достаточно простая схема работы:
- Аналитик получает ТЗ на разработку услуги, валидирует его и при необходимости прорабатывает с заказчиком, после чего передает разработчику.
- Разработчик используя Freemarker набрасывает необходимые виджеты на страницу просто размещая в коде вызов необходимого макроса из ядровой библиотеки виджетов. При вызове указывает необходимые атрибуты виджета: например, код поля, обязательность поля, валидаторы итд. После этого разработчик на основе требований к формату выходного XML, используя тот же Freemarker, формирует шаблон документа, указывая код поля в нужном месте.
- Форма отдается в тестирование, отлаживается после чего передается заказчику на тестирование. После получения ОК от заказчика формируется релиз с готовыми на текущий момент формами и передается на установку.
Какие основные плюсы мы получили? Для разработки самих форм больше не требовались backend и фронтэнд-разработчики. Основное, что требовалось от специалиста – знать синтаксис и возможности Freemarker и уметь пользоваться готовой библиотекой. Для большинства форм таких навыков хватало. Для сложных случаев подключались более опытные разработчики, где могло потребоваться покопаться с html, javascript или наоборот с java. Наиболее опытные занимались разработкой ядра фреймворка, где уже требовались глубокие знания фронтовых и бэковых технологий.
Команда разработки ядра состояла в разное время из 4-8 человек – 2 фронта, 2 бэка, тестировщик и тимлид. Минимальная команда разработки услуг составляла 2 человека – половина аналитика, разработчик и половина тестировщика. Внедрение фреймворка позволило сформировать несколько независимых команд разработки услуг, а в последствии и несколько десятков таких команд, распределенных территориально. Каждая команда могла создавать 1-3 услуги в месяц, в зависимости от их сложности, а time-to-market каждой формы составлял в среднем 35-50 дней.
Таким образом производительность двадцати команд (~50 человек) составляла около 40 услуг в месяц. Неплохо. Но недостаточно. Задача была – 300 в месяц. Наращивать состав команды было уже экономически не выгодно, нужно было более оптимальное техническое решение.
Инновациям дорогу!
Несчетное количество разработчиков и аналитиков проводили дни и ночи перед своими мониторами, кодили, анализировали, звонили заказчикам, потом снова кодили, потом опять анализировали, потом исправляли ошибки и, наконец, получалась готовая услуга. Количество услуг, которые надо было делать, возрастало в геометрической прогрессии и проблема стала очевидна. Требовалось какое-то её решение. Злейшие враги существовавшего подхода были известны: сложность, скорость (точнее, её отсутствие), необходимость технических знаний в области разработки, а также человеческий фактор – чем больше человек участвовало в разработке услуги, тем больше ошибок можно было допустить, как из-за невнимательности, так и по причине недопонимания и «сломанного телефона» при путешествии постановки задачи от заказчика к разработчику.
Итак, задача стояла следующая:
– уменьшить время разработки услуги
– сократить количество человек, участвующих в процессе разработки формы
– еще больше снизить требования к необходимой квалификации разработчиков
Есть такое выражение – «если хочешь чтобы было хорошо – сделай сам». Совершенно неверное с точки зрения проектного управления, но именно оно легло в основу следующего витка развития системы разработки форм.
«Зачем тут вообще разработчики?», спросили мы себя. И действительно, что в нашем случае делал разработчик? Собирал страницу с вызовами виджетов и указывал настройки для них. Почему бы не сделать для этого пользовательский интерфейс? Как в Delphi или Visual Studio.
Забегая вперёд, скажу, что результаты были фантастические, но для этого пришлось потратить некоторое время и усилия. Всем командам разработки мы объявили о прекращении развития старого фреймворка, оставив его на поддержке и занялись разработкой нового.
Отличием в части технологий было строгое разделение модели данных и представления. Бэкенд шаблонизатор больше не требовался, сервер приложений фреймворка представлял из себя набор REST сервисов, с минимальной бизнес-логикой внутри. Основная часть логики находилась на клиенте – в браузере.
Фреймворк состоял из двух основных компонентов: конструктор форм и проигрыватель форм. В конструкторе формы создаются и редактируются в визуальном режиме, а в проигрывателе исполняются – отрисовывается сама форма, работают правила валидации, связей между полями.
Основные функции конструктора:
- Визуальное конструирование формы.
- Настройка форматно-логического контроля (валидации) полей.
- Настройка взаимосвязей между полями формы (например, скрыть какой-нибудь блок или поле в зависимости от значения другого поля).
- Создание и редактирование справочников для использования в выпадающих списках.
- Сохранение и последующее использование собственных виджетов.
- Режим предпросмотра формы.
Основные типы полей (виджеты):
- текстовое поле
- виджет ввода даты
- радиокнопка, чекбокс
- выпадающий список
- поле загрузки файла
- виджет ввода адреса по КЛАДР или ФИАС
- кнопка
- таблица
Основные функции проигрывателя:
- исполнение формы
- выполнение правил валидации, взаимосвязи между полями, промежуточных и окончательных запросов во внешние системы, описанных в конструкторе при разработке формы
- возможность встроить в любое место на любой web-странице
- настраиваемые темы визуального оформления
Основная идея, заложенная в новый фреймворк – абстрагирование от всего, кроме непосредственно экранной формы. Если представить его в виде человека, то он будет из тех, кто говорит: «К пуговицам претензии есть?» Принцип архитектуры очень простой: «Моя задача отобразить форму, выполнить все действия, описанные в конструкторе, отправить данные. Остальное мне неважно, особенно что там с этими данными потом произойдет». За счет такого подхода мы достигли поразительной гибкости, и смогли использовать любые системы-контрагенты, в которые направляются промежуточные и финальные запросы, смогли использовать любую систему аутентификации для обеспечения доступа к формам, встраивать проигрыватель на любую web-страницу любого приложения в любое окружение.
Создание формы в конструкторе выглядит примерно следующим образом:
– Создаем форму
– Выбираем из выпадающего меню нужные нам элементы, размещаем на форме
– В инспекторе атрибутов настраиваем поля, как нам требуется с помощью галочек, кнопочек и списочков
– Настраиваем валидацию полей, выбирая нужный метод проверки или набор методов из списка доступных
– Настраиваем взаимосвязи между полями
– Подкладываем XSLT шаблон формирования результирующего XML документа
– Указываем реквизиты системы-получателя
– Форма готова!
Еще одно огромное преимущество — независимость описания формы от платформы исполнения. За счет того, что форма хранится в виде метаописания в формате JSON, которое лишь описывает состав компонентов формы и их взаимосвязи, но не описывает представление, достаточно один раз разработать форму в конструкторе и ее можно исполнять на любом устройстве, для которого существует проигрыватель форм: например, на платформе iOS или Android, SmartTV и других.
Какие основные плюсы мы получили на втором витке развития фреймворка? Для разработки самих форм больше не требовались разработчики вообще. От специалиста, создающего формы требовалось только уметь пользоваться графическим интерфейсом конструктора форм и уметь написать простое XSLT-преобразование. Этого хватало для большинства форм. Были, конечно, и сложные случаи, тогда обращались к команде разработки ядра, которая по заказу за неделю-две разрабатывала необходимую функцию или виджет.
Таким образом состав команды разработки услуг удалось сократить до 1-го человека, так как никакой разработки по сути не требовалось. Создавать формы смогли аналитики, не имеющие навыков разработки. За месяц один человек смог делать 5-7 форм, а time-to-market сократился до десяти дней. В итоге производительность тех же пятидесяти человек составила уже около 300 форм в месяц. То что нужно!
Вот отзывы нескольких представителей команд разработки услуг после пилотного периода использования нового фреймворка:
Спасибо большое за вашу помощь по конструктору, нам удалось с его помощью закрыть большой контракт. Фактически было реализовано больше 120 форм за неделю с небольшим, выведено в продуктив порядка 110 форм.
С использованием новой платформы разработка идет гораздо быстрее, аналитик может сам полностью контролировать весь процесс и очень быстро вносить правки. Аналитик может сделать сам, практически на 90-100%
Хочу сказать спасибо разработчикам — насколько ускоряет процесс! У меня за день по 4 формы на выходе. С нашими сроками по ХМАО это было бы нереально сделать вручную одному разработчику.
А это отзыв руководителя группы разработки фреймоворка:
Проект запомнился магией, точнее ощущением, что ты волшебник. По крайней мере, реакция многих людей, кому мы демонстрировали продукт, была схожа с реакцией на фокус. Очень приятно, когда у тебя получается при помощи сделанного тобой инструмента удивить скептика. Сразу понимаешь, что ты и твоя команда делают правильные вещи.
Показатели эффективности
| Показатель | Старый фреймворк | Новый фреймворк |
| Размер команды разработки ядра, человек |
4-8 |
4-8 |
| Размер команды разработки услуг, человек |
2-3 |
1 |
| Производительность команды форм/месяц |
2-3 |
5-7 |
| Среднее время разработки одной формы, дней |
25 |
4 |
| Time-to-market, дней |
35-40 |
10 |
| Среднее кол-во форм/месяц при 50 человек |
40 |
300 |
Insight
В чем главный инсайт этой истории? Я выделил для себя 3 главных момента.
- В коммерческой компании любые инновации технологические, организационные или какие-то другие должны быть экономически востребованы и обоснованы.
- Делать задачу «в лоб» в быстро развивающемся IT-мире значит мгновенно потерять конкурентоспособность. Чаще всего из-за завышенной себестоимости и/или сроков.
- Необходимо «точить пилу» (С.Кови «7 Навыков высокоэффективных людей»). Если вы занимаетесь развитием инструментов, то имеете конкурентное и технологическое преимущество на рынке.
А что для себя отметили вы? Будет круто услышать в комментариях. Если тема интересна, то я готов продолжить цикл статей о Конструкторе форм.
Про что ещё можем поговорить:
– О технологической составляющей – архитектура, используемые инструменты, взаимосвязи между компонентами, точки расширения и кастомизации.
– Об организации работы большого количества человек для решения задачи «разработать 10 тысяч услуг», о создании community разработки форм, об обучении, сертификатах, стажерах, студентах и так далее.
– О развитии функций фреймворка и как из узкоспециализированного инструмента для разработки услуг он стал универсальным внутренним продуктом компании для решения различных задач.
