Что такое программирование мышкой? Это принцип создания пользовательского интерфейса, который позволяет уйти от написания кода. Многие критикуют данный подход: дескать, программирование мышкой недостойно настоящего разработчика, все должно быть в коде. Но ведь раньше даже чтобы нарисовать круг, нужно было знание основ синтаксиса того же Basic. Сейчас любой пользователь может нарисовать любую фигуру в любом простейшем графическом редакторе, и это даже не назовут программированием, поскольку операция слишком проста. Это и есть развитие пользовательского интерфейса, позволяющего облегчить взаимодействие с компьютером. В этом материале я поделюсь нашим опытом максимизации принципов «программирования мышкой» в CRM Dynamics.
В создании новых сервисов мы всегда ориентируемся на максимизацию “принципа программирования” мышкой. То есть при решении задачи надо подумать: как сделать так, чтобы потом она снова не вернулась к тебе при последующих функциональных доработках? Стремление уйти от рутины ускорит развитие продукта. Если пользователь хочет часто менять какую-то визуальную часть формы, дайте ему механизм, который позволит делать это самостоятельно и не отвлекать вас от основной цели, но при этом и не будет мешать работе системы. Если на этапе проектирования руководствоваться самым прямолинейным решением и все закладывать в код, первые шаги будут реализованы, безусловно, быстрее. Но со временем, на стадии поддержки продукта, вы можете утонуть в операционной работе — правке отчетов, добавлении справочников и формируемой из системы шаблонов бизнес-документации. В конечном счете развитие системы может просто остановиться.
CRM Dynamics предлагает графический интерфейс построения последовательности бизнес-процессов — можно без всякого кода передвигать мышкой блоки и строить определенные последовательности и зависимости. Но что еще более интересно — здесь можно создавать пользовательский интерфейс с помощью одной мышки, так же просто, как во встроенном дизайнере форм. Таким образом разработчики могут формировать обширные формы в единой стилистике буквально за минуты. Это, конечно же, ускоряет разработку. Приведу несколько примеров наших решений.
В подавляющем большинстве бизнес-систем есть верификация данных, которые пользователь вносит в систему. Многие подходят к задаче прямолинейно — записывают в коде алгоритмы проверки наличия и валидности внесенных данных. Мы же пошли через реализацию отдельного сервиса, который позволяет бизнес-администраторам (нашим привилегированным пользователям) настраивать верификацию с помощью простых механизмов в пользовательском интерфейсе. Да, первый шаг в нашей реализации (формирование методов проверки) — это пока что все-таки код, который пишет программист. Но пишет уже на простом языке построения запросов внутри пользовательской формы — а значит продвинутый пользователь с базовыми навыками построения запросов тоже может сформировать аналогичный метод. После этого обычный пользователь уже самостоятельно собирает полный путь проверки и задает условия его использования.
Рассмотрим на конкретном примере. Делаем проверку наличия заведенного в систему паспорта физического лица. Описываем ее в коде и отдаем этот метод бизнес-администраторам. При этом все базовые связи уже прописаны в соответствующих объектах. Бизнес-администраторы уже самостоятельно настраивают мышкой все связи, используя базовый интерфейс и функциональность системы, определяют, на каком этапе жизненного цикла бизнес-продукта и для какого именно продукта используется этот метод, а именно: нужно ли проверить директора организации-заемщика, бухгалтера организации поручителя или прочие роли и связи внутри заявки. Сам паспорт при этом проверяется одинаково, а условия и отношения, с этим связанные, определяются бизнес-администратором. Мы в этом процессе не участвуем.
Пользователь создает Стоп-условие, указывая: Имя, Этап, Продукт и Объект проверки
Настраивает связку Объекта проверки с Методом проверки
Настройка метода проверки все еще проводится разработчиками, но и здесь пользователь может чекбоксами выключать и затем включать проверяемые атрибуты
Еще один наш пример функции с максимизацией принципов «программирования мышкой» — это печатные формы. В Dynamics изначально можно формировать шаблон печатных форм для договоров, бланков согласия и других документов клиента, извлекая данные из системы. Но стандартная реализация этой возможности имеет большое количество ограничений, с которыми бизнес не смирился, поэтому нам пришлось построить более гибкий механизм.
Первое быстрое решение — сформировать печатные формы через механизм построения отчетов в системе с помощью SQL и SSRS. С таким способом я встречался неоднократно и в прочих решениях. Но чем дальше мы работали над развитием нашей системы, тем больше и сложнее становились печатные формы. В итоге мы пошли по пути, схожему с предыдущим примером: реализовали обработку SQL-запроса и построения из него набора тегов с помощью Open XML. Бизнес-пользователи могут использовать данный запрос повторно, создавая и быстро меняя формы договоров, анкет и прочей бизнес-документации путем размещения мышкой тегов в статичном тексте шаблона.
В итоге у нас есть один большой запрос на все базовые атрибуты, который будет меняться только в момент появления новых. С его помощью пользователь сможет в любое время в режиме онлайн собрать нужную печатную форму. Для ускорения выполнения запроса мы всегда можем подключиться позже, в удобное для нас время, не нарушая принципов scrum, запланировать и сделать более оптимальный запрос под конкретные нужды, если это потребуется.
Вот готовый шаблон в Word
А это пользовательская настройка печатной формы
С печатными формами в Excel потребовалось дополнительное решение для формирования тегов, но и с этой задачей мы справились. Внешне же для пользователя сделали все так же, как и в работе с шаблонами Word.
И в верификации данных, и в создании печатных форм нижний уровень сервисов остается хоть и частично, но на нашей стороне. Но в перспективе мы планируем создать удобный графический построитель запросов. Тогда мы сможем отдать бизнес-администраторам 99% работы с этими изменчивыми компонентами системы.
При подходе, который использовали мы, первичные трудозатраты, конечно же, значительно больше — ведь написать полноценный сервис сложнее. Но мы работаем не как подрядчики-интеграторы, которые хотят отдать готовый продукт и забыть о нем. Мы понимаем, что нам и далее предстоит работать с этим продуктом, развивать его. Соблюдая принципы «программирования мышкой», мы экономим на дальнейшей поддержке системы.
Стоит упомянуть еще одну деталь. Чтобы следовать принципам максимизации функциональности с элементами «программирования мышкой», необходимы специалисты со сравнительно более высокой квалификацией — разработчики и аналитики, которые решают не только текущие функциональные требования, но и могут заглядывать в будущее, чтобы в итоге закрыть максимум потенциальных задач дальнейшего развития.
Конечно же, реализация возможностей для «программирования мышкой» ставит определенный ряд ограничений, по сравнению с использованием кода, так как в нашем случае вся функциональность будет предопределена разработчиками. Но это становится стимулом к развитию функциональности, гибкости и удобства инструментов для пользователя.
В создании новых сервисов мы всегда ориентируемся на максимизацию “принципа программирования” мышкой. То есть при решении задачи надо подумать: как сделать так, чтобы потом она снова не вернулась к тебе при последующих функциональных доработках? Стремление уйти от рутины ускорит развитие продукта. Если пользователь хочет часто менять какую-то визуальную часть формы, дайте ему механизм, который позволит делать это самостоятельно и не отвлекать вас от основной цели, но при этом и не будет мешать работе системы. Если на этапе проектирования руководствоваться самым прямолинейным решением и все закладывать в код, первые шаги будут реализованы, безусловно, быстрее. Но со временем, на стадии поддержки продукта, вы можете утонуть в операционной работе — правке отчетов, добавлении справочников и формируемой из системы шаблонов бизнес-документации. В конечном счете развитие системы может просто остановиться.
Возможности CRM Dynamics
CRM Dynamics предлагает графический интерфейс построения последовательности бизнес-процессов — можно без всякого кода передвигать мышкой блоки и строить определенные последовательности и зависимости. Но что еще более интересно — здесь можно создавать пользовательский интерфейс с помощью одной мышки, так же просто, как во встроенном дизайнере форм. Таким образом разработчики могут формировать обширные формы в единой стилистике буквально за минуты. Это, конечно же, ускоряет разработку. Приведу несколько примеров наших решений.
Верификация данных
В подавляющем большинстве бизнес-систем есть верификация данных, которые пользователь вносит в систему. Многие подходят к задаче прямолинейно — записывают в коде алгоритмы проверки наличия и валидности внесенных данных. Мы же пошли через реализацию отдельного сервиса, который позволяет бизнес-администраторам (нашим привилегированным пользователям) настраивать верификацию с помощью простых механизмов в пользовательском интерфейсе. Да, первый шаг в нашей реализации (формирование методов проверки) — это пока что все-таки код, который пишет программист. Но пишет уже на простом языке построения запросов внутри пользовательской формы — а значит продвинутый пользователь с базовыми навыками построения запросов тоже может сформировать аналогичный метод. После этого обычный пользователь уже самостоятельно собирает полный путь проверки и задает условия его использования.
Рассмотрим на конкретном примере. Делаем проверку наличия заведенного в систему паспорта физического лица. Описываем ее в коде и отдаем этот метод бизнес-администраторам. При этом все базовые связи уже прописаны в соответствующих объектах. Бизнес-администраторы уже самостоятельно настраивают мышкой все связи, используя базовый интерфейс и функциональность системы, определяют, на каком этапе жизненного цикла бизнес-продукта и для какого именно продукта используется этот метод, а именно: нужно ли проверить директора организации-заемщика, бухгалтера организации поручителя или прочие роли и связи внутри заявки. Сам паспорт при этом проверяется одинаково, а условия и отношения, с этим связанные, определяются бизнес-администратором. Мы в этом процессе не участвуем.
Пользователь создает Стоп-условие, указывая: Имя, Этап, Продукт и Объект проверки
Настраивает связку Объекта проверки с Методом проверки
Настройка метода проверки все еще проводится разработчиками, но и здесь пользователь может чекбоксами выключать и затем включать проверяемые атрибуты
Печатные формы
Еще один наш пример функции с максимизацией принципов «программирования мышкой» — это печатные формы. В Dynamics изначально можно формировать шаблон печатных форм для договоров, бланков согласия и других документов клиента, извлекая данные из системы. Но стандартная реализация этой возможности имеет большое количество ограничений, с которыми бизнес не смирился, поэтому нам пришлось построить более гибкий механизм.
Первое быстрое решение — сформировать печатные формы через механизм построения отчетов в системе с помощью SQL и SSRS. С таким способом я встречался неоднократно и в прочих решениях. Но чем дальше мы работали над развитием нашей системы, тем больше и сложнее становились печатные формы. В итоге мы пошли по пути, схожему с предыдущим примером: реализовали обработку SQL-запроса и построения из него набора тегов с помощью Open XML. Бизнес-пользователи могут использовать данный запрос повторно, создавая и быстро меняя формы договоров, анкет и прочей бизнес-документации путем размещения мышкой тегов в статичном тексте шаблона.
В итоге у нас есть один большой запрос на все базовые атрибуты, который будет меняться только в момент появления новых. С его помощью пользователь сможет в любое время в режиме онлайн собрать нужную печатную форму. Для ускорения выполнения запроса мы всегда можем подключиться позже, в удобное для нас время, не нарушая принципов scrum, запланировать и сделать более оптимальный запрос под конкретные нужды, если это потребуется.
Вот готовый шаблон в Word
А это пользовательская настройка печатной формы
С печатными формами в Excel потребовалось дополнительное решение для формирования тегов, но и с этой задачей мы справились. Внешне же для пользователя сделали все так же, как и в работе с шаблонами Word.
И в верификации данных, и в создании печатных форм нижний уровень сервисов остается хоть и частично, но на нашей стороне. Но в перспективе мы планируем создать удобный графический построитель запросов. Тогда мы сможем отдать бизнес-администраторам 99% работы с этими изменчивыми компонентами системы.
При подходе, который использовали мы, первичные трудозатраты, конечно же, значительно больше — ведь написать полноценный сервис сложнее. Но мы работаем не как подрядчики-интеграторы, которые хотят отдать готовый продукт и забыть о нем. Мы понимаем, что нам и далее предстоит работать с этим продуктом, развивать его. Соблюдая принципы «программирования мышкой», мы экономим на дальнейшей поддержке системы.
Стоит упомянуть еще одну деталь. Чтобы следовать принципам максимизации функциональности с элементами «программирования мышкой», необходимы специалисты со сравнительно более высокой квалификацией — разработчики и аналитики, которые решают не только текущие функциональные требования, но и могут заглядывать в будущее, чтобы в итоге закрыть максимум потенциальных задач дальнейшего развития.
Конечно же, реализация возможностей для «программирования мышкой» ставит определенный ряд ограничений, по сравнению с использованием кода, так как в нашем случае вся функциональность будет предопределена разработчиками. Но это становится стимулом к развитию функциональности, гибкости и удобства инструментов для пользователя.