Реализация процесса учета договоров с использованием нон-код платформы HoneyCode и метода Agile Scrum (часть 1)
- Подробности
- Опубликовано: 29.04.2022 09:00
- Автор: Стаценко Михаил Николаевич
- Просмотров: 1130
Аннотация: в статье автоматизируется процесс учета договоров в общеобразовательной организации на базе нон-код платформы. Выполнен анализ нон-код платформ и выбрано решение HoneyCode. Реализация проекта ведется с использованием метода Agile Scrum. Описываются детали метода Scrum. Далее идентифицируются и группируются в темы пользовательские истории, формируется и оценивается сложность бэклога продукта, создаются и планируются бэклоги спринтов.
Скачать: PDF (статья), PDF (выпуск №18).
Ключевые слова: учет договоров, реестр договоров, программа учета договоров, автоматизация договоров, low-code платформы, система управления контрактами, управление проектами по Agile, Agile и Scrum, автоматизация контрактов, программа контракты.
Введение
В настоящее время в России наблюдается рост заинтересованности в применении ERP-систем для управления и, в частности, автоматизации бизнес-процессов предприятием [1]. В большинстве случаев компании малого и среднего бизнеса не могут позволить полномасштабное внедрение таких систем из-за большой продолжительности внедрения и как следствие его дороговизны [2]. Одним из вариантов решения подобного вопроса видится разработка собственного программного обеспечения для критически важных, профильных процессов силами штатных сотрудников. Для снижения затрат автоматизации можно использовать платформы по созданию приложений «без кода», ориентированные на специалистов без знаний языков программирования и опыта разработки.
С момента появления первых нон-код платформ, датирующихся серединой 90-х, многое изменилось: их возможности сильно увеличились, что это связано с изменениями ИТ-рынка, а также высокой стоимостью их работ. Существует потребность в большом количестве высококвалифицированных специалистов, которых не всегда хватает, поэтому разработчики начали развивать платформы для автоматизации работы самих программистов. Цель данной статьи состоит в разработке приложения по учёту договоров с использованием нон-код платформ на основе метода Agile Scrum.
1. Agile Scrum в проектах разработки программного обеспечения
1.1. Описание метода Agile Scrum
Метод Scrum является одним из самых популярных способов управления проектами по созданию программного обеспечения (далее – ПО). Scrum входит в семейство методов гибкой разработки Agile. Он представляет собой способ реализации и внедрения программного обеспечения на основе итерационной модели. Методология и сам метод базируется на соблюдении основных ценностей и принципов, описанных в манифесте Agile [3-4].
Действующими лицами в Scrum-проекте являются профильные технические специалисты, участвующие в нём от первой встречи и до полного завершения проекта. Scrum-команда, в центре которой находится владелец продукта, состоит из аналитиков, программистов, тестировщиков, администратора и скрам-мастера. Владелец продукта ведёт коммуникацию с заказчиком и собирает бизнес-требования, соединяет команду исполнителей с заказчиком и следит за ходом проекта.
Наиболее важным элементом Scrum является бэклог продукта, включающий собранные владельцем продукта пользовательские истории на основе информации, полученной от заинтересованных лиц заказчика, ранжированной по приоритету и сложности реализации. По завершении формирования бэклога продукта ведется планирование спринтов, а именно: выбор задач, включаемых в бэклог спринта на основе оценки размера (в пунктах или идеальных человеко-днях), группировка в темы, определение длительности и скорости выполнения работ. Приоритет выполнения задач ведется на основе комментариев заказчика, бизнес целесообразности и преимущества реализации базовых функций [5].
Стоит отметить, что в процессе реализации проекта допустимо вносить изменения в бэклог продукта. Обычно бэклог продукта создается на начальных этапах проекта, а бэклог спринта формируется командой на фазе планирования нового спринта. Поэтому, первый бэклог существует на протяжении всей разработки продукта, а бэклог спринта – только в рамках текущего спринта. По завершении каждого спринта производятся презентация работающего продукта заказчику, а также обзор и ретроспектива, что позволяет оценить эффективность команды за время итерации, спрогнозировать ожидаемую скорость и выявить имеющиеся проблемы (рисунок 1.1).
Рис. 1.1. Схема реализации проекта Scrum
Scrum и его принципы позволяют достичь максимальной гибкости, прозрачности, простоты и отслеживаемости проделанной работы, то есть произвести переоценку приоритетов и внедрить новые функции или отказаться от них [6]. Верхнеуровневая последовательность действий для выполнения Scrum-проекта будет включать следующие шаги:
- собрать информацию от заказчика;
- сформировать бэклог продукта;
- выполнить приоритизацию бэклога;
- разбить бэклог на спринты;
- реализовать спринт;
- презентовать работающую часть приложения заказчику;
- провести встречу с целью оценки скорости выполнения работ (при необходимости выполнить переоценку спринтов);
- возвращаться на пятый этап до тех пор, пока не будет разработан продукт в полном объёме.
1.2. Анализ нон-код платформ
С момент появления первых нон-код платформ их возможности значительно продвинулись вперёд. Нон-код платформы позволяют пользователям без опыта программирования создавать веб-сайты, приложения и организовать информационное взаимодействие. Несмотря на то, что нон-код-инструменты не способны решить абсолютно все задачи разработки программных проектов, подбор и использование адекватного набора подобных инструментов, без сомнения, упрощает и ускоряет решение некоторых программных задач [7]. Анализ существующих платформ для разработки «без кода» дан в таблице 1.1.
Табл. 1.1. Сравнение популярных нон-код платформ
| Наименование платформы | Возможность применения платформы интеграции | Количество бесплатных записей | Стоимость корпоративного тарифа (долл./мес.) |
Функциональность платформы для реализации функционала будущего приложения |
| Bubble | нет | до 2500 | 88 | достаточна |
| Glide | нет | до 1000 | 90 | недостаточно |
| Webflow | нет | до 2500 | 73 | достаточна |
| Adalo | нет | до 3000 | 70 | достаточна |
| Bravo Studio | есть | до 3500 | 100 | достаточна |
| HoneyCode | есть | до 4500 | 70 | достаточна |
| Thunkable | нет | до 3000 | 85 | достаточна |
2. Идентификация требований
В качестве объекта автоматизации выбрана организация, занимающаяся деятельностью по дополнительному профессиональному образованию. Компания принадлежит к предприятию малого бизнеса, 70% сотрудников составляют преподавательский состав, остальные – специалисты финансового, правового, административного отделов и отдела маркетинга, а также директор компании. Критичный для компании бизнес-процесс – это учёта договоров, входящий в блок управления договорами. Существуют два подхода для работы с договорами: централизованный и децентрализованный. Первый вариант подразумевает наличие специального структурного подразделения, которая занимается исключительно договорами, второй – предполагает самостоятельное ведение контрактов конкретным исполнителями. В рассматриваемой компании применяется второй подход, зафиксированный в договорном регламенте, где описаны зоны ответственности и зависимости мероприятий.
Процесс ведения договоров делится на три этапа: подготовительный, на котором заключается, продлевается, расторгается или согласуется контракт; исполнения договорных обязательств, подразумевающий уведомление ответственных сотрудников, а также этап учёта и хранения. Отличительными особенностями управления контрактами являются: чёткая, зафиксированная регламентом, последовательность действий между четырьмя группами исполнителей, наличие юридического статуса договора, оперативное уведомление и передача информации ответственным сотрудникам.
2.1. Формирование бэклога продукта
Для идентификации требований к разрабатываемому продукту владельцы продукта применяют определённые механизмы сбора потребностей – предоставление в письменной форме описания того, чего требуется пользователю в виде: «Я как *должность/роль* хочу *требование* потому что *причина*». Подобный подход позволяет определить примерные характеристики продукта, поскольку в большинстве случаев при устном опросе конечные пользователи не могут описать конкретные функции продукта. В ходе рассмотрения специфики процесса управления договорами было выявлено четыре роли потенциальных пользователей будущего приложения: генеральный директор, менеджер по работе с клиентами, юрист и главный бухгалтер. По результатам окончания сбора требований, владелец продукта представил сформулированные пользовательские истории от за-интересованных отделов, представленных в таблице 2.1.
Скрам-команда дала оценку каждой истории в пунктах с использованием чисел Фибоначчи (1, 2, 3, 5, 8), где 8 – история, реализация, которая подразумевает наиболее массивный объём работ, 1 – история, не требующая больших затрат для реализации. Также истории были расставлены в приоритетном порядке в соответствии с бизнес-требованиями заказчика.
Табл. 2.1. Оценка пользовательских историй
| № | Пользовательские история | Оценка сложности (пункт) |
| 1 | Как генеральный директор я хочу иметь доступ к приложению с мобильных устройств (планшет, телефон) для ускорения процесса согласования и первичного ознакомления с данными договора | 1 |
| 2 | Как менеджер по работе с клиентами я хочу иметь доступ к приложению с мобильного устройства (планшета, телефона) с целью внесения данных в любых условиях | 1 |
| 3 | Как менеджер по работе с клиентами я хочу иметь возможность вводить информацию, соответствующую пунктам утвержденного стандартного печатного бланка договора для учёта договоров | 8 |
| 4 | Как менеджер по работе с клиентами я хочу иметь возможность удаления данных о договоре, контрагенте для отмены ошибочно внесённой информации | 8 |
| 5 | Как менеджер по работе с клиентами я хочу вносить информацию об ответственном за исполнение договорных обязательств с целью его оперативного оповещения | 5 |
| 6 | Как генеральный директор я хочу иметь возможность получать уведомления о статусе договоров для оперативного принятия решений и общей осведомленности | 5 |
| 7 | Как менеджер по работе с клиентами я хочу иметь возможность получать автоматические уведомления за неделю до окончания договора для проработки вопроса о продлении или конечном завершении контракта | 5 |
| 8 | Как генеральный директор я хочу, чтобы непосредственный исполнители по договору получали уведомления о поступившем договоре и о статусе уже имеющегося | 5 |
| 9 | Как юрист я хочу оперативно получать уведомления о поступивших на меня договорах и о их статусе для понимания приоритета выполнения своих задач | 5 |
| 10 | Как менеджер по работе с клиентами я хочу иметь возможность применения фильтров и сортировки для навигации среди имеющихся договоров | 5 |
| 11 | Как менеджер по работе с клиентами я хочу иметь возможность поиска по уникальному значению для нахождения конкретного договора среди всех остальных | 5 |
| 12 | Как генеральный директор я хочу знать, какой сотрудник был определён ответственным за договор с целью осведомленности о занятости сотрудников | 3 |
| 13 | Как генеральный директор я хочу иметь возможность определять уровень доступа для сотрудников из соображения информационной безопасности | 1 |
| 14 | Как генеральный директор я хочу импортировать имеющиеся записи в электронном формате (.CSV) для учёта прошлых договоров | 1 |
| 15 | Как менеджер по работе с клиентами я хочу иметь возможность прямого доступа к скан-копии физического договора для использования в работе | 3 |
После окончания формирования бэклога продукта начинается этап планирования ближайших спринтов, их наполнение и определение продолжительности.
2.2. Формирование спринтов
В таблице 2.1 можно заметить несколько логических групп пользовательских историй, которые обычно называют темами. Темы позволяют легко ориентироваться в требованиях к будущему продукту, в таблице 2.2 представлены истории, сгруппированные в темы.
Табл. 2.2. Группировка пользовательских историй по темам
| История | Тема |
| Как генеральный директор я хочу иметь доступ к приложению с мобильных устройств (планшет, телефон) для ускорения процесса согласования и первичного ознакомления с данными договора | Вход с любого устройства, у которого есть доступ к интернету |
| Как менеджер по работе с клиентами я хочу иметь доступ к приложению с мобильного устройства (планшета, телефона) с целью внесения данных в любых условиях | |
| Как менеджер по работе с клиентами я хочу иметь возможность вводить информацию, соответствующую пунктам утвержденного стандартного печатного бланка договора для учёта договоров | Внесение и удаление информации |
| Как менеджер по работе с клиентами я хочу иметь возможность удаления данных о договоре, контрагенте для отмены ошибочно внесённой информации | |
| Как менеджер по работе с клиентами я хочу вносить информацию об ответственном за исполнение договорных обязательств с целью его оперативного оповещения | |
| Как генеральный директор я хочу иметь возможность получать уведомления о статусе договоров для оперативного принятия решений и общей осведомленности | |
| Как менеджер по работе с клиентами я хочу иметь возможность получать автоматические уведомления за неделю до окончания договора для проработки вопроса о продлении или конечном завершении контракта | Отслеживание и получение статуса договора и информации об ответственном |
| Как генеральный директор я хочу, чтобы непосредственный исполнители по договору получали уведомления о поступившем договоре и о статусе уже имеющегося | |
| Как юрист я хочу оперативно получать уведомления о поступивших на меня договорах и о их статусе для понимания приоритета выполнения своих задач | |
| Как менеджер по работе с клиентами я хочу иметь возможность применения фильтров и сортировки для навигации среди имеющихся договоров | |
| Как менеджер по работе с клиентами я хочу иметь возможность поиска по уникальному значению для нахождения конкретного договора среди всех остальных | |
| Как генеральный директор я хочу знать, какой сотрудник был определён ответственным за договор с целью осведомленности о занятости сотрудников | Ориентации в списках |
| Как генеральный директор я хочу иметь возможность определять уровень доступа для сотрудников из соображения информационной безопасности | |
| Как генеральный директор я хочу импортировать имеющиеся записи в электронном формате (.CSV) для учёта прошлых договоров | Определение уровня доступа для сотрудников |
| Как менеджер по работе с клиентами я хочу иметь возможность прямого доступа к скан-копии физического договора для использования в работе | Импорт данных |
Бэклоги спринтов требуют детализации, поэтому требуется указать конкретные технические задачи по их реализации. Кроме того, скрам-команда должна определить временные затраты на их выполнение, измеряемые в часах (таблице 2.3).
Табл. 2.3. Определение задач и времени реализации
| Тема | Задачи | Время реализации (часы) |
| Вход с любого устройства, у которого есть доступ к интернету | Нахождение наиболее подходящего решения (выбор нон-код платформы) | 5 |
| Изучение документации по использованию платформы | 7 | |
| Внесение и удаление информации | Реализация базы данных, соответствующим экранам | 20 |
| Реализация интерфейса экранов | 13 | |
| Отслеживание и получение статуса договора и информации об ответственном | Настройка всех требующихся видов уведомлений | 25 |
| Проведение функционального тестирования | 7 | |
| Ориентации в списках | Создание и настройка полей для фильтрации | 5 |
| Определение уровня доступа для сотрудников | Сбор информации с целью заведение учётных записей пользователей | 5 |
| Заведение учётных записей пользователей в приложении | 3 | |
| Настройка уровня доступа | 3 | |
| Импорт данных | Приведение накопленных данных к единой форме и их импорт | 5 |
На этапе формирования бэклога продукта было принято решение о выставлении наибольшего приоритета для тех историй, которые задают скелет продукта и несут основной функционал приложения. После всех преобразований последовательность спринтов изменилась и дана в таблице 2.4. Кроме того, было принято решение об определении продолжительности спринта в одну неделю при пятидневной рабочей неделе и продолжительности рабочего дня в восемь часов.
Табл. 2.4. Разбивка задач по спринтам
| Спринт | Тема | Дополнительные задачи |
| I | Вход с любого устройства, у которого есть доступ к интернету | Проектирование процессов, данных и приложения в AS-IS и TO-BE моделях |
| II | Внесение и удаление информации | |
| III | Отслеживание и получение статуса договора и об ответственном | |
| IV | Ориентации в списках, определение уровня доступа для сотрудников, импорт данных | Нагрузочное тестирование |
Как можно увидеть из таблицы 2.4 в первый спринт были добавлены такие задачи как: проектирование моделей AS-IS и TO-BE, построение архитектуры данных и структуры приложения. Последний четвертый спринт включает допзадачу по нагрузочному тестированию. Метод Scrum позволяется декомпозировать задачи и переносить на следующие спринты те активности, которые не помещаются в рамках одного спринта. Поэтому было принято решение о реализации задачи построения базы данных и пользовательского интерфейса для заключения договоров в первом спринте, а создание таблиц данных и формы для ввода информации карточки контрагента, адреса организации и удаления сведений было отнесено на второй спринт. Ссылка на 2-ю часть статьи.
Литература
- Scrum Glossary [Электронный ресурс] // https://www.scrum.org/resources/scrum-glossary (дата обращения 10.04.2021).
- Cвистунова Ю.В. Современная структура корпоративной информационной системы // Компьютерные технологии в моделировании, управлении и экономике. – 2021. - № 13. – С. 67-70.
- Larman C., Basili V.R. Iterative and Incremental Development: A Brief History // Computer. – 2003. – vol. 36, №6. – p. 47-56.
- Основополагающие принципы Agile-манифеста [Электронный ресурс] // Agile Alliance – Режим доступа: http://agilemanifesto.org/iso/ru/principles.html (дата обращения 10.12.2021).
- Степанов Д.Ю., Вельсовский А.В. Применение Аgile Scrum в проектах SAP // Корпоративные информационные системы. - 2018. - №1. - C. 9-17.
- Кон М. Agile: оценка и планирование проектов. – М.: Альпина Паблишер, 2019.
- Магомадов В.С. Платформы low-code и no-code как способ сделать программирование более доступным для широкой общественности // Международный научно-исследовательский журнал. – 2021. – № 6-1(108). – С. 100-103.
Выходные данные статьи
Стаценко М.Н. Реализация процесса учета договоров с использованием нон-код платформы HoneyCode и метода Agile Scrum (часть 1) // Корпоративные информационные системы. – 2022. – №2 (18) – С. 1-11. – URL: https://corpinfosys.ru/archive/issue-18/194-2022-18-noncodehoneycode.
Об авторе
 |
Стаценко Михаил Николаевич – выпускник кафедры корпоративных информационных систем института информационных технологий РТУ МИРЭА. Тема выпускной квалификационной работы магистра «Разработка приложения по учету договоров с использованием нон-код платформ на основе метода Agile Scrum». Электронная почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. |
Статьи выпуска №18
- Учет договоров с использованием HoneyCode (часть 1);
- Становление корпоративных информационных систем в России;
- Автоматизация процессов транспортной логистики (часть 2);
- Стратегия поддержки продуктивного запуска ERP-системы;
- Импортозамещение в проектах внедрения ERP-систем.