1С СППР, как инструмент по внедрению, разработке и сопровождению информационных систем

Тема доклада – система проектирования прикладных решений от 1С. Ей недавно исполнилось 6 лет. Эта система предназначена для ведения очень больших, сложных, длительных проектов большим числом людей и очень сложным составом команды.

Ключевая функция СППР

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

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

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

Допустим, на одном крупном проекте с нами работали методологи, которые знали SAP, а мы собирались внедрять 1С. И методологи говорили: «Мы ваш 1С не знаем, у нас основной бэкграунд – бухгалтера и аудиторы». Их задачей было собрать проводки, которые нужно передать в SAP. Там огромная компания, огромное количество филиалов – методологи собрали три тысячи строк проводок в файле Excel. Потом к этой работе подключились методологи МСФО, и стало уже 10 тысяч строк проводок. Что делать разработчику в итоге с этими проводками? Как выкручиваться? Методологи сделали свою работу за полгода и ушли. А разработчики 1С остаются непонятно, с чем.

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

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

Работа в СППР и сферы ответственности

Посмотрите – обычная структура большой команды. 

• Руководитель проекта – управляет проектом по теории управления проектами. 

• Дальше работают методологи и аналитики. Обычно, они первые общаются с клиентом, получают огромные кипы документов по корпоративной учетной политике. Начинают во что-то это превращать.

• ИТ-консультанты (проектировщики и консультанты) обрабатывают собранные требования – обычно ИТ-консультанты это подчиненные архитектора проекта.

• Архитектор проекта определяет структуру проектного решения.

• И разработчики это проектное решение реализуют. 

Требование на реализацию переходит от одного участника команды к другому, и этот переход делается за счет методологии общего языка. Вы, наверное, слышали про Эрика Эванса и его «Предметно-ориентированное проектирование (DDD)». Это – оттуда. Всю разнородную команду должен объединять общий язык. И СППР дает этот общий язык для команды, в этом ее сила.

Бизнес-процесс работы в СППР

Рассмотрим общий бизнес-процесс работы в СППР. 

Руководитель проекта стартует бизнес-процесс, создает проект, шаги проекта. Все стандартно. И в конце принимает работу ото всей команды. 

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

Что делает архитектор проекта? Он – главный в рамках СППР. Он, как раз, и задает общий язык.

Для разработчиков используется словарь общего языка, который называется «Объекты метаданных». Это – объекты конфигурации. Они их понимают, они их знают. Это – без вопросов. 

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

Я вернусь к исходному слайду.

Видите, аналитики собрали требования, которые надо детализировать до объектов методологии. Соответственно, объекты методологии должны конвертироваться в объекты конфигурации (в элементы справочника «Объекты метаданных»). И задача архитектора на проекте – написать этот общий язык и предоставить его людям. 

Справочник «Объекты метаданных» собирается практически автоматом из любой конфигурации 1С. Это объекты вашей конфигурации и их реквизиты. Но вы также можете заполнять этот справочник с нуля, если вы делаете проект с нуля (может быть, даже не на 1С). 

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

Задача архитектора на проекте с СППР

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

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

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

Тогда получается сквозное видение:

• от требования, которое привязано к объекту данных;

• объект данных ссылается на объекты метаданных;

• а объекты метаданных указываются в каждом задании программисту. 

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

Интеграция СППР в ИТ-среду организации

Как внедрить СППР в вашу компанию?

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

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

• СППР очень удачно между ними ложится. Из СППР в Jira выгружаются задачи программистам. Там идет жесткая связка со всеми требованиями, ссылками на все объекты конфигурации и на переписку в том числе. Программист может видеть все, что мы обсуждали в рамках задачи СППР – ему не нужно ничего ни у кого спрашивать. Он не должен ничего спрашивать. Вы можете настроить такую интеграцию.

Если у вас нет СУП, нет Jira, то СППР с этими блоками прекрасно справится:

• В СППР есть СУП – нельзя сказать, что идеальный и очень мощный, но управлять проектами там можно.

• В другом блоке СППР можно проектировать и ставить задачи.

• Также в СППР есть блок для ведения разработки программистами – там есть измерители трудозатрат.

Отдельный вопрос: «СППР только для работы с 1С?» Нет. Если вы можете взять выгрузить из SAP структуру объектов метаданных и их реквизитов, то вы можете работать и в SAP-овскими проектами, если они у вас есть. Вы можете хоть руками завести объекты данных. Нет проблем построить привычную среду.

Объекты методологии

Теперь смотрите – я упоминал объекты методологии. Это то, через что методологи и аналитики связаны со всей системой в целом. Объектами методологии в СППР будут группы справочника «Объекты данных».

На слайде собраны объекты методологии из конкретного примера. 

Если вы посмотрите, здесь вам все знакомо. Например, одной из групп справочника «Объекты данных» будет «Бизнес-модель» – в ней будут храниться описанные бизнес-процессы. 

В группе «Аналитики данных» находится объект методологии «План счетов». Это означает, что проект был по учетной системе. Если бы вы делали проект по системе CRM, то там не нужен план счетов. Что там нужно, а что не нужно, определяет архитектор в зависимости от того, какой проект делается.

Еще я вам рекомендую обратить внимание на группу «Выходные данные проекта», которая является оглавлением проектного документа. Одна из конкретных жалоб, что в СППР никак не помогает делать проектные документы. В ходе проекта очень часто происходит перетасовка – сначала решили делать так, потом – иначе. Меняются связки – эти объекты создаем, эти не создаем. Проектные документы нужно перезаполнять снова. И люди хотели бы, чтобы СППР выдавала уже готовые проектные документы. Если вы работаете по госконтракту, там обычно ГОСТы. Может быть, проектные документы заложены в договоре. И этот момент мы рассмотрим чуть позже.

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

Теперь смотрите – общая схема модели проектирования в СППР.

Привычная каскадная водопадная модель:

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

• Требования нужно детализировать. Надо разбираться – какая функция связана с требованием, какие объекты. Насколько детализировать, когда остановиться? Это определяет, как раз, архитектор, когда задает вам список объектов данных (объектов методологии). Каждое требование должно быть детализировано до плана счетов (если требование касается плана счетов), или до какого-то первичного документа (если он решает эту задачу). Пока такой прямой привязки нет, работы не сдали. Эта формализация работ очень важна. Вы можете заворачивать и аналитиков, и методологов, пока они не обработали все требования, не привязали их к объектам данных.

• Точно так же аналитики описывают в СППР процессы. Там есть справочник «Процессы», простая иерархическая структура – это тоже определенный результат. Выдается модель процессов, с помощью которой также могут быть детализированы требования. 

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

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

• В результате, разрабатываем задачи – конечный итог работы СППР. 

• Пакет из задач – это техническое задание. Обычно задачи связаны по какому-то принципу. Допустим, печатные формы – это один пакет задач. Отчетность – другой. И т.д. Комбинации произвольные, как вы считаете правильным.

• В результате вы должны пройти контроль качества проектирования непрограммного кода – в СППР есть функция «Контроль качества проектирования». 

• И на выходе у вас будут проектные решения.

Схема модели проектирования

Здесь на этом слайде в очень простой форме приведена схема модели проектирования. 

Вы ищете в системе все входы и определяете, во что это в результате выльется. 

А вот этот конвертер «Бизнес-процессы» (то, что вы делаете на проекте), конвертирует вход в выход для клиента. 

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

В этом блоке СППР эту информацию и записывает.

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

Обратите внимание, здесь красным выделена зона возможной работы Agile и Scrum. Когда она начинается? Когда вы архитектору и разработчикам передаете все полностью собранные данные. Им не нужно никуда обращаться, никуда бегать, все собрано в системе, включая перечень объектов, описание, методологические документы, документы заказчика – все под рукой. Вот тогда может начаться нормальный Scrum и Agile. Вы уже разрабатываете функции своей системы.

Модель оценки времени и затрат по COCOMO II

А теперь интересный момент, который связан с вопросом – как же выдавать проектные документы? 

Желательно этот момент автоматизировать, потому что там толстенные тома, которые никто не читает. В больших проектах, особенно, если вы делаете документацию по ГОСТам, назначение этих документов в том, что они определяют, кто будет «сидеть», и с кого будут брать деньги. Особенно, если вы работаете с госконторами. 

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

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

Что можно сделать? Я вам уже говорил про структуру проектных документов. Она очень помогает оценивать по методике COCOMO. Что такое COCOMO? Это когда в 60-х годах один американец собрал статистику по количеству строк программного кода в своих проектах (всего у него был 161 проект), и получил статистическое знание, сколько примерно строк программного кода займет следующий проект.

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

Метод COCOMO общеизвестен, но он предназначен для разработчиков – он считает строки программного кода. А команда-то у вас гораздо больше – там методологи, аналитики, какой у них программный код? У них нет программного кода. Но, тем не менее, у них есть формализованный результат работы. Они выдают кипы документов – это их «псевдокод». Их базис – структура проектных документов (оглавление, тексты, рисунки, таблицы), количество строк в них. И затраты их времени вы тоже можете оценивать формализовано по модифицированному COCOMO. У программистов – строки программного кода, а у этих – строки проектных документов.

Очень существенный момент – как бы СППР вам в этом помогло?

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

А делается это вот так. 

На слайде показано оглавление одного из проектных документов. Вы это оглавление заносите в качестве элементов иерархии справочника «Объекты данных». Выделяете в этом справочнике группу «Выходные проектные документы». Внутри нее – подгруппы под каждый вид документов, далее еще подгруппы под каждый отдельный документ, а внутри уже этих подгрупп как элементы справочника строки оглавления проектного документа.

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

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

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

Именно так вам может помочь методика COCOMO. Иначе получается, что проектные документы надо писать параллельно – или в Excel или в Word. Это очень трудоемко. Здесь же вы можете попытаться сделать выгрузку. Кто может – сделает сразу хороший готовый формат, кто-то отдаст дизайнеру, чтобы все красиво оформить. Но там уже не надо писать текст, все в уже СППР набрано, структурировано, описано – вы это уже сделали в ходе проекта.

Контроль качества проектирования в СППР

И вот очень важный элемент, который есть в СППР, – вы можете проверить качество проектирования системы. Не программного кода, а проектирования. В СППР нет программного кода, там вообще не работают разработчики. 

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

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

Но, когда архитектор работу выполнил, были заполнены справочники «Процессы» и «Функции», то вообще-то надо проверить качество. Чтобы это сделать, в СППР есть справочник «Правила проверки объектов», с помощью которого вы можете каждый справочник запросом проверить на тот или иной параметр. Какие параметры – вы сами решаете. 

Например, я решил, что в структуре справочника «Процессы» ни один процесс не должен входить более чем в одну ветку, и хочу, чтобы при записи элемента справочника «Процессы» мое правило проверялось. Это означает, что я хочу получить незамкнутый направленный граф. Это – важный момент в СППР. Вы, когда получаете в итоге справочник «Процессов» и «Функций» системы, вы получаете примитивную, но формализованную структуру. Это означает, что вы можете применять к ней математический аппарат. В частности, теорию графов для необходимых вам анализов. В этом соль. 

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

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

Вопросы

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

• Можно, пожалуйста. Вы можете использовать СППР для управления сопровождением системы. Там есть блок сбора ошибок – собираются тикеты и ведется фиксация исправлений. Но чтобы работать с разработкой в целом, вам нужно описывать справочник функций системы. А представьте, как вы опишите функции системы ERP? Это очень трудоемко. 

• Насколько, по-вашему, реально вести полностью разработку в СППР?

• А сколько у вас людей на это есть? Если вам не выделяют людей, в этом нет смысла.

• Людей мало.

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

• Тогда вопрос – какую другую систему можно применять для контроля разработки? Не глобально, для ведения проектов, а именно для контроля разработки с точки зрения 1С, с точки зрения решения задач на уровне конфигурации.

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

• На одном из слайдов вы сказали, что можно применять Scrum и Agile. А где здесь участвует владелец продукта, который должен ставить задачи в бэклог и как это применимо с использованием СППР?

• Вообще-то задача – это результат Agile в СППР. Agile начинается, когда методологи и бизнес-аналитики собрали данные. У них есть определенный набор объектов, набор требований, и из этого делаются задачи. Но прежде чем делать задачи, надо понять, покрывает ли ваша система по функциям собранные процессы и требования или нет? Здесь Agile в таком смысле – это не Agile по разработке. Получается, что здесь задачи сформированы, и они должны передаваться в другую систему, где вы как-то отслеживаете Agile для программистов. Вообще для задач в СППР аналитики достаточно – вы можете проставить для них какие-то обозначения через доп. реквизиты, доп. сведения, чтобы организовать ход задачи внутри СППР. Пожалуйста.

• Получается, что здесь владелец продукта будет взаимодействовать с методологами и ставить задачи в СППР? 

• Если вы работаете в СППР, вы должны взаимодействовать со всей линейкой команды – от методологов, до проектировщиков и разработчиков. Если неполное взаимодействие – зачем СППР? Вы с ним будете мучиться, как многие мучаются. Скорее, вы будете там отслеживать те требования, которые были сформированы методологом, и их ранжировать. Не он сам, потому что необходимо связывать объекты данных с объектами системы, которые методолог, скорее всего, не знает.

• Вы показывали три этапа – система управления проектами, 1С:СППР и Jira. Насколько возможно интегрировать в качестве первого и третьего этапа систему 1С:Документооборот? Просто мы сейчас ведем весь учет наших проектов и задач в системе 1С:Документооборот. Очень удобно, мы ее немного под себя доработали. Я знаю, что СППР интегрируется с 1С:документооборотом. Насколько это будет типовое решение? Не придется ли какие-то доработки делать? Насколько объем доработок будет большим?

• У вас в Документообороте собираются требования?

• Сейчас в Документообороте ведутся все проекты. Требования мы там не ведем. Как раз для того, чтобы собирать требования, я и хотел использовать СППР.

• Но вы сказали, что вместо Jira используете Документооборот, что там вы хотите ставить задачи программистам. Я даже не пытался СППР интегрировать с Документооборотом, но то, что вы описываете, звучит, как уже хвостик процесса – вы уже собрали задачи. СППР нужен для того, чтобы к задачам были привязаны объекты метаданных, объекты данных, требования, процессы и шаги проектов. Получается, что вам этот кусок не нужен. Зачем тогда вам гнать в СППР задачи? Вы и в документообороте можете ошибки регистрировать. Создайте документ «Регистрация ошибки» и используйте его.

• Но система документооборота не предназначена для регистрации ошибок.

• Система документооборота не предназначена и для сбора задач. Я думаю, что интеграция с документооборотом слишком усложнит эту систему. По логике, источником из Документооборота будет требование. Но если вы фиксируете в Документообороте ошибки, значит, вы занимаетесь сопровождением системы, вам нужно реакцию программиста – исправление ошибки. Получается, у вас уже есть в Документообороте регистрация ошибок, а из СППР вы хотите получить реакцию программиста на поставленную задачу. По описанию это выглядит трудоемко. Если бы вы сделали это целиком на стороне документооборота, было бы проще. СППР для вас будет тяжелым.

• От какого числа человек в команде есть смысл внедрять СППР?

• Я думаю, это несколько десятков человек – порядка 20-30 человек и более в команде. Важнее не количество, а структура команды, чтобы там была вся цепочка – методологи, аналитики, архитектор, проектировщик, консультанты. И только в конце разработчики. Для сборной солянки из 6-ти человек может быть и выгодно. Но команде, состоящей только из разработчиков, СППР не нужен.

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.