• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Как собрать ИС с гарантированными свойствами

Последнее время довольно активно обсуждается тема неопределенности в проектной деятельности, к коей относится и построение ИС.

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

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

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

Как видим, максимально устраивающее заказчика решение может быть сформировано только в результате продолжительной (и плодотворной) дискуссии с исполнителем, в результате которой должны родиться требования к проектируемой ИС, снижающие неопределенность проекта до приемлемой.

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

Словом, в проектной деятельности все, как в жизни, и нужна твердая рука, которая взяла бы на себя всю полноту ответственности за проект. Лучший вариант, когда такой человек (или коллектив с лидером) еще и что-то умеет. Только профессионал может уменьшить указанную неопределенность на каждом этапе проекта. Сначала же нужно определиться относительно будущей системы по следующим вопросам:

1. Инфраструктура (сети, объекты, человеческие ресурсы, информационные ресурсы).
2. Архитектура (распределенная, централизованная, гибридная).
3. Программно-аппаратная платформа (СВТ, ОС, ОПО).
4. Назначение ИС (интеграция ресурсов, сбор и обработка данных, оперативная работа ДЛ).
5. Среда функционирования ИС.
6. Обеспечивающие процессы (мониторинг, контроль, управление).
7. Прикладные процессы.
8. Каталог ИС (пользователи, ресурсы, сервисы).
9. Защита информации в ИС (требования регуляторов, каталог продуктов).
10. Проектные ресурсы (разработчики, сроки, средства).

Чем подробнее эти позиции будут отработаны коллективом разработчиков изначально и далее, тем реальнее будет выполнение работы в срок, очерченный в ТЗ. А это и есть устранение неопределенности в паре «сроки – деньги», которая всегда особенно беспокоит заказчика.

Валерий Андреев, заместитель директора по науке и развитию, ИВК