I Вступление

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

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

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

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

Но эта тема получила новый импульс после ухода с рынка РФ части игроков.

Обсуждению концепции организации производства ИТ-продуктов и посвящена данная статья.

II Платформа для организации производства ИТ‑Продуктов

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

1. Определение цифровой платформы

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

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

У платформы принято выделять 3 аспекта применимости:

• Платформа как технологическая конструкция (программная интеграция данных и приложений для их обработки);

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

• Платформа как открытая, общедоступная инфраструктура (площадка, маркетплейс и т.п.) для взаимодействий между производителями и потребителями.

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

2. Модель платформы организации производства ИС

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

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

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

В следствии того, для автоматизации подобного рода деятельности можно выделить, как минимум 2 макро-сервиса:

1. «Учет требований к ИТ-Продукту»;

2. «Организация производства ИТ-Продукта»;

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

III Сервис управления требованиями к ИТ-Продукту

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

Опыт разработки показывает, что при любом итерационном подходе реализации продукта (Scrum, RUP, MSF и т.д.) удобнее управляться не с отдельными задачами, а с метриками, группирующими работы в некую продуктовую функциональность. В RUP — это Прецеденты, в Agile методиках – это Feature (полезность) или Store (совокупность возможностей) и прочие. Обусловлено это спецификой самого процесса, когда невозможно протестировать или продемонстрировать отдельную выполненную задачу (алгоритм, часть кода и т.д.), но можно анализировать результат группы работ, воплотившей в конечной сборке: функциональную возможность взаимодействия пользователя с ИС.

1. Представление ИТ-Продукта в виде Требований

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

Исходя из вышесказанного, не взирая на зрелость и формат представления Требований командой проектирования, в сервис «Организация производства Продукта» они должны попадать в виде описания возможностей ИТ-Продукта или его компонентов, или условий их функционирования. В следствии того Требования должны различаться типом, определяющим способы их реализации. Тип может принимать значения: 1) «Продукт»; 2) Компонент; 3) «Возможность»; 4) «Условие применения»; 5) «Поведение»; 6) «Алгоритм»; 7) «Визуальное представление» и прочее. Например:

2. Способы представления Требований к ИТ-Продукту

Часто удобно выводить контекст разрабатываемого продукта вокруг набора визуальных прототипов форм. Это естественно и легко воспринимается большинством заинтересованных лиц. Например, требование:

1.3.2. Представление формы версии Требования — Визуальное представление

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

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

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

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

Поскольку Требования представляют собой сложную согласованную структуру, то помимо иерархических связей необходимо учитывать и логические см. Рис.2, сущность - "Связь требований". Например, фиксация факта замещения одного Требования другим под влиянием внешних факторов, или взаимовлияния группы требований друг на друга. Такой прием позволит избежать неконтролируемое возникновение ошибок в ИТ-продукте, при попытке изменить одно из связанных требований, не оценив степень необходимости - менять связанные.

3. Моделирование жизненного цикла Требования

Для того, чтобы отслеживать прогресс воплощения Требования в целевой Информационной системе, сформированное Требование должно поступать в сервис «Организация производства ИТ-Продукта», в виде контекста задачи на его реализацию. В сервисе производства будут организованы работы претворяющие Требование в функциональность ИТ-продукта, фиксироваться их результат, а в ответ возвращаться текущая стадия его Жизненного цикла (далее ЖЦ). Так мы сможем в самом сервисе Учета требований, наблюдать за степенью его готовности в целевом Продукте см. Рис 3.

В связи с этим у Требования должен фиксироваться статус, определяющий текущий этап его обработки и степень готовности в текущей версии ИТ-продукта. Например, «Создано», «В разработке», «Реализовано», «Аннулировано», «Замещено» см. Рис.2.

Поскольку Требования сформированы иерархически и восходят в вершине к целевому Продукту, то этим инструментом можно эффективно управлять ходом реализации выборочных функций (Требований) в целевом ИТ-продукте. Например:

4. Сложная организация Требований для линеек продукта

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

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

Но эту тему мы разовьем в следующей части, где детально рассмотрим сервисы, поддерживающие организацию процесса реализации Требований в ИТ-продукте см. Часть 2