Краткий анализ

Различие типов задач при создании автоматизированных систем

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

Сравнение типов задач

• Цель:
o Сеть: обеспечение информационного обмена.
o Приложение: качественное достижение функционала.
o Система: количественная (конкретный функционал для заданного числа пользователей с требуемой производительностью).
• Характер рисков:
o Сеть: недостатка сведений (данные отправлены, но не получены).
o Приложение: сложность реализации требуемого функционала.
o Система: несовместимость компонентов.
• Роль пользователя:
o Сеть: прозрачна для пользователя. Если он о ней вспомнил — сеть не работает.
o Приложение: выполняет операции без прямой бизнес-ценности (например, ввод числа в поле формы).
o Система: решает целевую бизнес-задачу.
• Изменения в данных:
o Сеть: изменений нет, данные только доставляются.
o Приложение: изменений в бизнес-данных нет, есть набор вводимых сведений.
o Система: изменения происходят постоянно, порождая промежуточные результаты, имеющие ценность.
• Изменения в настройках:
o Сеть: только при изменении требований.
o Приложение: могут относиться к оптимизации (память, временные файлы).
o Система: вносятся для оптимизации, но критически важна их согласованность.
• Изменения в компонентах:
o Сеть: при изменении требований к характеру задачи или росте нагрузки.
o Приложение: при изменении требований или обнаружении ошибки.
o Система: при изменении целевой задачи, нагрузки или ошибках в совместной работе компонентов.

Эти задачи настолько разные, что требуют различных методологий. Системы и приложения лучше всего создавать с помощью ГОСТ 34-й серии и ГОСТ 19-й серии соответственно.

Механизм снижения рисков за счет стадийности

Стандарты ГОСТ обеспечивают предсказуемость (снижение рисков проектирования и реализации) и рациональность. Частый вопрос заказчиков: «Почему так много стадий?» Разбиение на этапы — один из самых эффективных способов снижения рисков.

Согласно теории управления проектами, риск — это произведение вероятности неблагоприятного события на величину последствий (ущерб).

Если выполнить всю работу за один этап, ожидаемый ущерб равен произведению вероятности риска (R) на сумму ущерба ($). Если разбить задачу на два этапа и допустить, что риски и затраты делятся пополам, ожидаемый ущерб становится вдвое меньше.

Наибольший эффект достигается при оптимизации разбиения: на первом этапе концентрируется максимум рисков при минимуме затрат, а на втором — максимум затрат при минимуме оставшихся рисков. При соотношении 90% рисков и 10% затрат на первом этапе (и наоборот на втором) суммарный ожидаемый ущерб может быть в пять раз меньше, чем при одноэтапном подходе.

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

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

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

Обследование, изучение и аудит

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

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

Решение дает аналогия с нефтедобычей:
1. Обследование подобно геологоразведке. Изучается вся предметная область «широко, но неглубоко», чтобы найти проблемные зоны.
2. Изучение подобно бурению скважины в найденных перспективных местах. Проблемные зоны исследуются глубоко и детально.

Такой подход резко сокращает затраты.

Иногда заказчик предлагает заменить обследование и изучение аудитом. Согласно стандарту ISO 19011, аудит — это систематический, независимый и документированный процесс получения свидетельств аудита и их объективной оценки для определения степени соответствия критериям аудита.

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

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

Практические рекомендации по управлению проектом

1. Не пренебрегайте сбором сведений. Попытка «угадать» недостающие данные подобна лотерее. Например, вероятность угадать произвольный IP-адрес (32 бита) составляет 1 к 4 миллиардам. Отсутствие сведений из-за пропуска стадий делает вероятность успеха проекта практически нулевой.
2. Определите точку входа в проект. Проанализируйте, какие документы (технические требования, концепция) и результаты работ уже есть, а какие сведения отсутствуют. Начинайте с этапа, для которого нет результатов.
3. Используйте ГОСТ для построения структуры работ. ГОСТ 34.601-90 является готовым шаблоном для Иерархической структуры работ (WBS). Первый уровень — стадии, второй — этапы, а из приложения берутся конкретные работы.
4. Не работайте «с голоса» и не проектируйте «на лету». Решения, принятые голосованием на совещаниях, часто бывают политически мотивированными и технически нецелесообразными.
5. Оформляйте замечания заказчика как отдельный документ с указанием авторства. В перечне работ по ГОСТ нет «внесения замечаний в проектную документацию» на ранних стадиях, что защищает исполнителя от неформализованных изменений требований.
6. Утверждайте документы на высоком уровне. Неутвержденный документ — это лишь проект, не имеющий юридической силы. Получение подписи руководителя высокого уровня может потребовать усилий, но это избавит от необходимости доказывать те же самые вещи множеству его подчиненных.

Итоговые положения

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

Важно помнить, что:
• Техническое задание (ТЗ) разрабатывается только после концепции.
• ГОСТ в первую очередь ориентирован на внедрение новой системы, и для описания процессов эксплуатации и вывода из нее необходимо использовать рекомендации ITIL и стандарты BS 15000 и ISO 20000.

Краткие итоги

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

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

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