Добавить в корзинуПозвонить
Найти в Дзене
Samoylov Consulting Group

Включение модулей и обновлений в реестр

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

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

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

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

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

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

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

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

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