Управление требованиями и проектирование в СППР с использованием методологии AIM

Меня зовут Вера Кокотова, я расскажу про управление требованиями и проектирование в СППР с использованием методологии AIM.

 

 

Я уже более 10 лет работаю в КРОКе и за это время принимала участие в девяти крупных проектах. Некоторые из них велись с использованием СППР, поэтому я на личном опыте могу судить о преимуществах его использования.

 

 

КРОК – это крупная ИТ-компания. Мы давно работаем на рынке.

В год в КРОКе выполняется более 2500 проектов. Не только 1С, конечно.

 

 

Направлению 1С в КРОКе уже более 10 лет. Наша практика выросла из практики Oracle. Поэтому многие подходы к проектному управлению были наследованы оттуда.

 

Связь этапов проекта и получаемой на них документации при использовании AIM

 

Внедрение крупной системы – это долгий сложный процесс, в котором принимает участие большое количество специалистов.

За длительное время работы с крупными проектами мы выработали единые методологические принципы. Так как наше управление выросло из направления Oracle, мы использовали для себя методологию AIM с доработкой под специфику проектов 1С. Также наша методология перекликается с «Технологией корпоративного внедрения проектов» от фирмы «1С».

На слайде вы видите основные этапы в проекте, и работы, которые выполняются на этих этапах.

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

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

Здесь вы видите этапы проекта и документацию, которую каждый этап дает на выходе.

Естественно, написание качественной и непротиворечивой документации – это сложная задача, она требует много сил.

Мы искали пути сокращения затрат на написание такой документации и решили использовать для этой задачи СППР. Жирным шрифтом на слайде выделены те документы, которые мы сейчас получаем из СППР.

Кроме СППР мы также используем ряд других инструментов и практик для поддержки процесса разработки. На этом слайде вы видите их в разрезе этапов проекта.

• На этапе анализа и проектирования используется СППР – он сейчас для всех проектов единый.

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

• Для хранения исходного кода конфигураций, внешних отчетов и обработок мы используем сервис управления версиями GitLab – он также позволяет анализировать изменения между разными версиями и проводить код-ревью.

• Хранилище раскладывается в Git-репозиторий посредством сервиса синхронизации на базе gitsync.

• Также используется сервис проверки качества кода SonarQube с опенсорсным плагином для 1С.

• Jenkins все эти сервисы интегрирует.

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

История внедрения и развития СППР в КРОК

 

Вернемся к СППР.

В 2013 году, когда я пришла в компанию, СППР вообще не использовался. Документы создавались вручную, и в этом были определенные минусы.

• Во-первых, были сложности с консолидацией требований в едином месте – обычно это реализовывалось через какой-то общий документ, что не очень удобно.

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

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

Эти проблемы формировали цели, которые указаны на слайде.

 

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

Сейчас у нас СППР используется в каждом крупном проекте – при этом полностью поддерживается и процесс моделирования, и процесс проектирования.

Мы не собираемся останавливаться в развитии и продолжаем дорабатывать СППР – реализуем в нем новые функции.

 

Автоматизируем сбор требований и этап моделирования в СППР

Перейдем непосредственно к демонстрации процесса моделирования в СППР.

На этапе создания технического задания на систему в СППР формируется каталог бизнес-процессов – это происходит путем добавления элементов в типовой справочник «Процессы».

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

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

На этапе моделирования по AIM каждая модель должна быть подробно описана консультантом и согласована с заказчиком. Для этой цели консультант заполняет форму с определенными полями. Фиксированный состав полей дает нам унификацию, плюс некоторые поля имеют ссылочный тип, поэтому консультант ограничен еще и списком предопределенных классификаторов.

Возвращаясь к AIM, мы должны продемонстрировать несколько прототипов работы системы. Первая демонстрация происходит как раз на этапе моделирования. Аналитик перед встречей с заказчиком должен описать, как бизнес-процесс реализуется в типовой системе, и сделать такую заготовку в СППР. Далее на встрече они уже совместно обсуждают, какие изменения требуется внести в этот процесс, и сразу же фиксируют все требования и шаги.

Самыми важными с точки зрения СППР атрибутами модели является схема, шаги и требования:

• схема позволяет наглядно показать последовательность шагов в процессе;

• шаги уже детализируют элементы схемы;

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

 

 

Вот так, например, выглядит схема.

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

Далее каждый блок этой схемы, за исключением служебных, расшифровывается шагами.

Шаги – это тоже типовой справочник СППР:

• здесь дается подробное описание шага;

• указывается, кто этот шаг выполняет – роль исполнителя в системе;

• в какой системе он выполняется, потому что у нас в скоупе проекта может быть несколько систем, и какие-то шаги выполняются в смежных системах;

• на вкладке «Интерфейс» аналитик указывает объект системы, с помощью которого этот шаг реализуется. Например, если вводится какой-то документ, отмечается этот документ; если используется обработка, выбирается обработка. Объекты выбираются из дерева метаданных, которое уже загружено в СППР. А если планируется создание нового документа или обработки, аналитик прямо здесь его сразу и добавляет.

Вот так выглядит форма требования. В требовании много атрибутов. Самыми важными являются:

• приоритет;

• способ реализации;

• система, к которой это требование зафиксировано;

• инициатор со стороны бизнеса, чтобы мы понимали, кто является заказчиком, кто это требование заказывал;

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

 

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

На слайде показано, как он выглядит. Все поля, которые были введены в СППР, выводятся в документ – лишнего мы ничего не вводим.

 

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

 

Проверяем требования на сходимость и целесообразность реализации

 

 

 

Тут мы получаем еще один важный плюс от использования СППР – так как аналитик может использовать СППР прямо на встрече с заказчиком, то с меньшей вероятностью он забудет что-то внести в систему и какое-то требование будет потеряно.

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

Для этого в СППР есть типовая форма, где требования группируются по разделам и ответственным. Ответственный в данном случае – это аналитик, ответственный за блок.

Здесь выводится:

• статус требования;

• его приоритет;

• к какой системе оно было выдвинуто;

• и информация, важная для формирования списка доработок – включено ли это требование в технический проект.

 

 

Работа с требованием проводится по нескольким направлениям.

Одно из направлений – это анализ требований по объему реализации.

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

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

 

 

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

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

Конечно, за этим должен следить функциональный или технический архитектор, точнее они вместе.

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

 

 

После того как мы провели работу со списком требований, мы какие-то требования переносим на следующие релизы, а какие-то вообще отстреливаем.

После получения проработанного списка требований мы переходим к формированию списка доработок.

Группировка требований в доработке может производиться по разным критериям.

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

• Более частый вариант – это когда требования группируются по функциональности. Например, в одном блоке консультант добавляет в документ новые реквизиты, чтобы вывести их в специфическую печатную форму для заказчика. А в другом блоке аналитик проектирует новую процедуру заполнения этого же документа. Если новая процедура заполнения не использует новые реквизиты, эти доработки не связаны. В противном случае между отработками нужно определить зависимость.

• Никто не отменял группировку требований по очередности реализации. Бывает такое, что сразу на этапе начала проекта все понимают, что к желаемому сроку все требования с нужным уровнем качества выполнить невозможно. Поэтому изначально требования делятся на релиз 1 и релиз 2.

• Также может сложиться ситуация, когда мы сначала замоделировали систему, собрали все требования (например, мы внедряем систему бюджетирования), а потом заказчик говорит, что хочет каждый бюджет прорабатывать и внедрять последовательно. Тогда мы делим доработки на своеобразные спринты и проектируем, реализуем и внедряем их последовательно.

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

 

Автоматизируем проектирование в СППР

 

С точки зрения СППР проектирование реализуется через технический проект – это также типовой справочник. Этот объект намного сложнее, чем модель, здесь намного больше атрибутов.

В частности, указывается:

• Отказ от требования (отказ от доработки);

• Обходной путь – что будет, если мы эту доработку не будем реализовывать;

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

 

С точки зрения методологии, основными артефактами технического проекта являются:

• Требования, которые данная доработка покрывает.

• И функции, которые эта доработка реализовывает. Причем эти функции раскрываются с двух сторон:

  • действия бизнес-пользователя при работе с добавленными функциями;

  • и логика доработки с точки зрения работы системы – информация, которая важна разработчику для реализации этой функциональности;

  • таким образом, в определенных разделах технического проекта мы можем сразу согласовывать с бизнесом, как это будет выглядеть для пользователей, и использовать их в качестве технического задания на доработку системы.

• Плюс важным разделом технического проекта является дизайн объектов. Здесь мы указываем, какие объекты мы добавляем. Или какие новые реквизиты мы добавляем в типовые объекты.

 

С точки зрения формы СППР это выглядит вот так.

На слайде показана закладка с функциями.

Вверху указывается функция с событием-инициатором.

А ниже она описывается с точки зрения действий и логики.

Причем шаги в действиях и логике не обязательно будут парными. Какие-то действия в системе выполняются без участия пользователя. Например, регламентные задания – от пользователя потребуется только сделать настройку.

 

Вот это закладка с объектами метаданных. Здесь мы тоже указываем новые объекты.

По галочкам видно, какие объекты являются запроектированными, а какие – уже реализованными.

Здесь возникает важное преимущество от использования СППР. Когда мы уже дали разработчику техническое задание на доработку, за счет того, что у нас в СППР постоянно подтягивается конфигурация, мы можем проанализировать:

• насколько вообще разработчик правильно добавил наши объекты;

• все ли он добавил, ничего ли не забыл;

• не ошибся ли с наименованием и не нафантазировал ли чего-то своего.

Такая первая грубая проверка.

 

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

Здесь интересными разделами являются:

• Периодичность запуска – актуально для регламентных заданий.

• Обработка исключительных ситуаций – важно прописать, как система должна реагировать на некорректные данные или некорректные алгоритмы.

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

• И раздел «Сценарии тестирования» – его можно использовать в двух качествах:

  • Мы можем построить процесс таким образом, чтобы разработчик сдавал свою доработку только после прохождения этого сценария тестирования. Если консультант заходит в базу разработчика и видит, что разработчик не выполнил этот сценарий тестирования, он может сразу ему задачу переоткрыть.

  • Второй кейс использования – это сдача доработки заказчику.

 

Формирование инструкций для пользователей из СППР

 

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

Инструкции мы генерируем на базе той же модели бизнес-процесса.

В качестве разделов используются ровно те же шаги, где указаны исполнитель и система.

Также прикладывается схема.

Консультант лишь дополняет описание шага скриншотами с уже готовой системы.

 

Управление новыми требованиями

 

 

Перейдем к управлению новыми требованиями.

Ни один инструмент не может вас защитить от появления дополнительных требований:

• Возможно, вы на этапе проектирования поймете, что на этапе моделирования не все было хорошо проработано.

• Или на этапе демонстрации доработки заказчик скажет, что он хотел вообще не этого. Что все выглядит не так, и вы его не так поняли.

• Или, может, бизнес-заказчик в процессе проекта сменится – от этого никто не застрахован.

• Или, в принципе, у нас бизнес-заказчик и пользователь – это разные люди. И пользователь, когда входит в опытную эксплуатацию и начинает с этим работать, ему вообще неудобно. Его мнение при моделировании и проектировании не учли.

 

 

Договориться с пользователями по результатам функционального тестирования – это ключевой вопрос.

• Если нам удалось убедить пользователя, что работать нужно именно так, мы новую доработку не делаем.

• А если нет, мы вынуждены будем зафиксировать новое требование.

С точки зрения СППР при этом ничего не меняется:

• Мы также должны требование зафиксировать. Возможно, мы вообще какой-то новый бизнес-процесс будем описывать, если это развитие системы. Или это будет дополнение к какому-то существующему процессу.

• Также мы его должны запроектировать – определить либо в существующую, либо в новую доработку.

• Реализовать.

• Внедрить.

• И запустить в эксплуатацию.

 

Преимущества СППР

 

Основные преимущества, которые мы получаем от управления требованиями в СППР, это то, что:

• Требование является связующим звеном между моделированием и проектированием. Мы сразу на этапе общения с бизнес-заказчиком уходим в контекст объектов метаданных. И на этапе проектирования мы уже работаем с требованием, которое как-то привязано к объекту метаданных.

• Плюс по каждому требованию у нас есть история, откуда оно взялось, кто его заказывал.

• И можем проследить связь с другими процессами и доработками.

 

 

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

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

• Мы моделируем и проектируем сразу в контексте дерева объектов метаданных конфигурации.

• У нас все решения собраны в одном месте, так как зачастую удачные решения мы повторяем в других проектах.

• И получаем из СППР готовую к отгрузке документацию.

Тут важно отметить, что СППР для нас – это прежде всего инструмент. Все-таки под его использованием лежит определенная проектная методология, которая вырабатывалась не один год.

Мы не перерабатывали его в значительной мере – не реализовывали для него каких-то невзлетевших функций.

 

Вопросы

 

А есть ли какие-то недостатки в использовании СППР?

Есть очевидный недостаток – его использование требует дополнительное время на фиксацию информации.

Вы говорили про переход на СППР 2.0. С какими сложностями столкнулись?

Я говорила о том, что мы долго дорабатывали СППР. И переход на 2.0 мы сделали только в этом году. Каких-то сложностей особенных не было. Новые реквизиты не мешают при обновлении. Только пришлось немного привести в порядок старые первоначальные доработки, потому что они делались в режиме MVP.

Вы показали работу с требованиями. В СППР 2.0 идеология поменялась, там вместо требований теперь идеи. Не было здесь проблем никаких?

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

Это был доработанный СППР, не типовой?

Он доработан под методологию AIM – именно с учетом того, что нам нужно было получить на выходе. Добавлены новые реквизиты, и немного отличается у нас подход.

У КРОКа всегда крупные проекты, поэтому вы всегда применяете именно этот подход. А если на рынок в целом посмотреть, то какие ограничения вы видите с точки зрения бюджетов и сроков? Если у нас проект меньше полугода, стоит ли идти в эту методологию? И если у нас проект меньше какого-то бюджета, стоит ли идти в эту методологию?

Для нас нет таких метрик, чтобы мы принимали решение об использовании СППР на основе бюджета или сроков. Наверное, все зависит от объема кастомизации.

Например, если заказчику требуется автоматизация журнала хозяйственных операций, ему не нужны схемы – его бизнес-процессы понятны, и они не меняются.

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

А есть ли какие-то экспертные метрики, что, например, если проект меньше 10 или 100 миллионов, его в СППР описывать не нужно?

Мы для себя не выделяем таких метрик.

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

Тут речь не столько про объем одного проекта, сколько в целом о наличии у вас большого количества крупных и сложных проектов. Потому что на доработку самой СППР тоже может уйти много ресурсов. Нужно учитывать эту целесообразность.

Правильно ли я понимаю, что ту доработку, которую сделал КРОК, себе получить нельзя? Нам нужно потратить какие-то ресурсы и сделать такое же самим? Или КРОК планирует распространять это каким-то образом?

Мы продаем это как сервис.

СППР – это у вас моделирование и проектирование. При этом вы обозначили, что модель у вас описывается в произвольной форме, не в определенной нотации. Вопрос первый: по окончании проекта вы этот инструмент и эти модели передаете каким-то внутренним службам заказчика, чтобы они их держали в актуальном состоянии? Второй вопрос: зачастую, особенно в крупном бизнесе, проект моделирования бизнес-процессов предопределяет проект автоматизации. Заходит какая-то команда и моделирует в той же Business Studio в определенных нотациях. Вы как автоматизаторы заходите и видите эти модели в нотациях. Вы начинаете их перерисовывать в СППР на произвольные кубики? Как вы разруливаете эту ситуацию?

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

В этом случае вы настаиваете, что процессы моделирования нужно проходить заново?

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

Вы идете на это, и по правилам заказчика в его нотации начинаете моделировать?

Честно говоря, такого кейса не было. Все, с кем мы работаем, были согласны моделироваться в нашей нотации.

Вы эти модели отдаете заказчику?

Да, конечно. Мы можем передать их в физическом виде, потому что СППР позволяет нам их распечатать и выдать.

А инструментарий передаете?

Да, если он готов приобрести его.

Обычно готов?

30 процентов из 100 готовы и интересовались этим.

А зачем, если через год-два все модели устарели и остались на полках пылиться?

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.