Для 1С-аналитиков: какие практики сделают вас востребованным в 2022?

В статье речь пойдет о лучших практиках моделирования, которые пригодятся вам в текущем году. Рассказывает Сергей Наумов, руководитель проектного офиса WiseAdvice.

Сначала придем к общему знаменателю и выясним, что подразумевается под термином «моделирование». В отрасли есть два варианта толкования.

Первый, моделирование — это один из процессов проектной технологии для обеспечения одинакового понимания предлагаемых решений заказчиком и исполнителем.

Второе — упрощенное представление объектов автоматизации.

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

Что будет, если не строить модель?

Коротко — ничего хорошего. Если более развернуто, то вот малая часть того, что вас ждет:

• На ОПЭ может вскрыться «забытый» процесс.
• Может не «взлететь» техническая реализация.
• Если не построить модель всех процессов, а действовать итерационно, можно прийти к нерабочей системе.
• Можно упустить важные вводные данные.
• Можно довести заказчика до того, что он не будет понимать, как работает система.

А как нужно делать?

Первое и самое важное — модель должна быть целостной.

Скорее всего, многие слышали про EPC, но не все знают, что это целая методология связанных моделей: организационной, представления о данных, функционального представления и на пересечении — та самая EPC. То есть когда вы построили функциональное и организационное представление, вы всегда можете понять, какие же функции в ваших процессах вы не промоделировали.

Целостная модель позволяет увидеть, что вы могли упустить.

Артефакты аналитика

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

Итак, сохранимся: требования, модели, решения — все вместе это артефакты аналитика. Конечно, в контексте проектной технологии.

Для себя я вывел такое определение. Артефакты — это задокументированный результат, описанный и согласованный, и который помогает нам продвигаться дальше по проекту.

Очень важно наладить учет артефактов. Все требования, все решения, все модели — они должны быть систематизированы.

Если вы используете один большой документ, в котором сплошным полотном перечислено множество процессов, то очень скоро вам станет непонятно, откуда и какой процесс «вырос».

Чтобы этого избежать, используют разные инструменты. Выбор нашей компании пал на Confluence, например. Каждый артефакт нашей проектной технологии — это отдельная страница с определенными свойствами.

Документирование артефактов

Мы реализовали у себя следующим образом. У нас в Confluence есть документ тех.задания с пунктами, которые относятся не только к проектным решениям. В документе все подчиненные страницы «включаются» с помощью специального плагина.

Таким образом, получается с одной стороны — привычный рынку документ, с другой — комфортная среда для работы аналитиков с выделенными артефактами.

Что это и зачем?

Если вы убеждены, что требования — это пользовательская «хотелка», немедленно разубедитесь. Требование — это характеристика будущего объекта автоматизации.

Их нужно уметь правильно формулировать. По опыту WiseAdvice-IT есть два основных приема, которые подходят для проектов автоматизации. Это:

• Описание сценария.

Когда вы пишите техническое решение, и, например, у вас есть какая-то обработка: вы рисуете ее форму, ставите цифры кнопок и даете по каждой цифре пояснения. Например, для кнопки под номером 1:

• Система обращается в базу данных.
• Записывает данные.
• Выводит отчет X и так далее.
• Формализованное описание.

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

И, конечно, важно учитывать реквизиты требований: важность, срочность, связи. Обратите внимание, что с одной стороны, нам нужно «навесить» формальный набор требований, а с другой — совокупность требований это какой-то документ. И Confluence здесь определенно незаменим.

Уровни и типы требований

Требования делятся на типы и уровни. Верхнеуровневым может быть бизнес-требование. Давайте рассмотрим на примере, так будет понятнее.

Система должна давать возможность обеспечивать получение план-фактного отчета. При описании требований к функциям автоматизированной системы уже можно детализировать:

• откуда система должна брать данные;
• какие должны быть дополнительные функции;
• время формирования отчета;
• макет;
• фильтры и так далее.

Примеры типов:

• функциональные;
• требования к надежности;
• требования к документированию и так далее..

Наглядно это выглядит так:

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

И когда вы включаете требования определенного типа в документ, неплохо сопроводить их какой-нибудь моделью. Она должна соответствовать тому уровню погружения в процессы заказчика и объект автоматизации, который у вас сейчас имеется. То есть на раннем этапе нет смысла пытаться описать конкретное детальное поведение какой-то кнопки, которая сейчас есть у заказчика.

Учитывая два этих подхода — деление на уровни и типы и выбор соответствующего документа для определенного уровня — в WiseAdvice-IT мы разработали систему уровней и типов требований наиболее подходящую для создания автоматизированных систем на платформе 1С. Вот так они выглядят.

В нашей компании мы применяем:

• пользовательские требования;
• требования на разрывы (многофункциональные, организационные, инфраструктурные).

Сначала мы собираем пользовательские требования — сразу же при первом знакомстве. Далее, по итогам моделирования, пользовательские требования могут уточняться. Но главное, появляются новые — на функциональные разрывы.

Какие модели мы делаем

На уровне концепции мы делаем модель функциональной структуры.

«Функциональная структура — это перечень автоматизированных процессов, связи между этими процессами, модель логической структуры (как система будет развернута, доступ к ней, компоненты).»

Далее идет модель процессов на типовом решении. Ее мы делаем с помощью решения BPMN. Эта же модель уточняется в проектном решении. То есть в модельном примере мы делаем BPMN как это может быть в типовом решении, а в проектном решении мы делаем как это будет после всех доработок. И, конечно, делаем модель взаимосвязи объектов с применением одной из диаграмм UML. Реализуем это в техническом решении.

С заказчиком очень важно договориться о том, как будут строиться модели. Другими словами, описать нотацию моделирования. Моделирование бизнес-процессов мы составляем следующим образом.

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

Однако без расширений не обошлось. Мы сделали вот так:

Объекты автоматизированной системы также отображаются на диаграммах, и мы их все раскрашиваем. Если типовой объект — он зеленый, если есть немного изменений — желтый, ну а «есть пара правок, все переделываем» или новый — красный. И когда мы смотрим диаграмму, мы сразу понимаем, что нас ждет и как правильно приоритезировать разработку.

Вот пример — здесь мы видим процесс расчета бонусов поставщику.

Сразу понятно, какие изменения будут в новом процессе — здесь, например, три новых объекта.

• Что это за процесс?
• Процесс расчета бонусов поставщиков. Многие крупные поставщики так делают, если у них достаточно большие закупки, то они по итогам периода дают возможность получить некоторую скидку.

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

Нотация технического моделирования

Как я говорил, это упрощенный UML.

Нотация позволяет показать связи между объектами, связи объектов с функциями и изменения в учетных регистрах.

Так выглядит техническое решение.

Оно позволяет:

• заказчику: увидеть, какие будут объекты;
• разработчику: проверить все ли учтено и что является источника данных.

Типы решений в WA:

• модельный пример;
• проектное решение;
• техническое решение.

Физически проектное решение представляет из себя страницу в Confluence. Свойства в шапке позволяют выводить списки, делать мепинг и даже писать SQL-запросы.

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

У нас есть результаты, значимые для Заказчика — модельный пример, проектные решения, техническое решение. А вот оформлять эти результаты мы можем по-разному, в зависимости от конфигурации проекта, которую выбрал руководитель проекта.

Мы можем одни и те же элементы включать в разные документы в зависимости от проекта.

Например, в чистом Waterfall-проекте у нас есть все документы. А вот в маленьком проекте может быть нецелесообразно делать технический проект, но зафиксировать способ доработки важно — тогда техническое решение можно включить непосредственно в техническое задание.

Проверка на покрытие требований

В Confluence есть макрос «Свойства страницы», который позволяет понять, где есть ссылка на текущую страницу.

Мы его приспособили под свои нужды — в проектном решении есть ссылка на требования. Дальше простой выборкой мы определяем, обработанное это требование или нет.

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

То есть все, что нам заказчик наговорил, мы закрепляем подчиненными страничками.

Таким образом, мы видим требования и в протоколе интервью, и общий реестр выявленных требований, с которым можем работать в таблице.

Документ технического задания у нас содержит стандартный раздел — его заполняют аналитики и подчиненные страницы для проектных решений.

Как работать с артефактами в ходе этапа разработки?

Мы работаем по технологии, близкой к SCRUM. Есть два беклога:

• проектных решений;
• технических решений.

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

Вместо заключения

Больших выводов не будет, есть краткое резюме:

• Мы не делаем модель AS IS — используем текстовое описание.
• Ядром технологии являются минимальные значимые результаты: «проектные» и «технические» решения, которые затем объединяем в документы.
• Моделирование «проектных» и «технических» решений позволяет существенно сократить риски на последующих этапах.
• Для реализации проектной технологии и процессов моделирования при создании автоматизированных систем эффективно использовать Confluence.

Спасибо, что прочитали материал. Мы активно набираем аналитиков в команду, если вам интересно поработать над подобными проектами — отправляйте резюме.

Опубликовано на vc.ru