В мире agile, scrum и гибкой разработки есть слово, от которого у многих IT-команд кровь стынет в жилах. И это не «баг», не «дедлайн», а «ГОСТ». Для одних — это синоним качества, для других — камень преткновения, который мешает двигаться вперед. Кто же прав? Давайте разберемся и без громких заявлений рассмотрим нужно ли использовать ГОСТы в ИТ.
Меня зовут Карина Верещагина, я юрист в компании RDN Group. Наша команда специализируется на разработке сложных и высоконагруженных решений: корпоративных порталов, торговых площадок, личных кабинетов и интеграционных проектах. Являясь одним из немногих партнеров «1С-Битрикс» с компетенцией «Крупные корпоративные внедрения» расширенного уровня, мы на практике видим, как бизнес переходит от экспериментов с удалёнкой к построению целостных, безопасных и автоматизированных цифровых офисов.
Что такое ГОСТы в ИТ и зачем они вообще нужны?
ГОСТы в ИТ можно условно разделить на два больших блока.
”Стандарты — это хорошо, но надо понимать тонкую грань, где они помогают развитию, устанавливают границы и необходимые правила для разработки, а где могут стать обузой и только мешают сделать цифровой продукт лучше”, - Дмитрий Паламарчук, руководитель проектов.
Первый блок — это нормы, которые описывают требования к самому программному обеспечению. Сюда входят критерии качества, надежности и, что особенно важно, конфиденциальности данных. В некоторых областях, например, в криптографической защите, без строгого следования стандартам действительно не обойтись — это вопрос национальной безопасности.
Второй блок — это правила, регламентирующие требования к документации. И вот здесь начинается самое интересное. Эти регламенты предписывают, каким шрифтом, с какими отступами и в каком порядке должны быть оформлены технические задания, программы испытаний, отчеты и прочие документы. Они диктуют не только форму, но и жесткую структуру содержания.
Камень преткновения: почему ГОСТы стали проблемой?
Представьте себе современный гибкий проект, который развивается по методологии Scrum. Требования к продукту меняются каждые две недели по итогам спринта, команда постоянно получает обратную связь и адаптируется. А теперь попробуйте вписать в этот процесс требование «соответствовать правилам», которые предполагают, что все технические требования должны быть полностью описаны и зафиксированы в самом начале, на стадии технического задания.
Возникает фундаментальное противоречие. Жизненный цикл разработки по формализованным требованиям напоминает неспешный и предсказуемый процесс, в то время как реальность ИТ — это быстрая процесс, постоянно меняющий направления.
Чем это грозит на практике?
- Риск срыва приемки. Если в договоре или ТЗ жестко прописано соответствие конкретным нормам, а какая-то часть документации или продукта им не соответствует, заказчик имеет полное право признать работу выполненной некачественно. Парадокс в том, что сам продукт при этом может быть лучше, чем планировалось. Но формально — он «бракованный».
- Колоссальные трудозатраты. Подготовка документации по нормативной базе— это отдельный сложный процесс, который часто требует привлечения технического писателя со специализированными знаниями. Бывают случаи, когда написание документов отнимает больше времени и сил, чем написание кода.
- Эффект «снежного кома». В техническом задании может быть указан один стандарт. Вы открываете его, а там — ссылки на еще три норматива. Вы открываете эти три, а в них — ссылки еще на десять. Путешествие по этой бесконечной ветке может затянуться очень надолго. Причем некоторые уже могут потерять свою актуальность.
- Субъективизм при приемке. Когда наступает время сдавать результат работ, приемочная комиссия может сфокусироваться не на сути продукте, а на формальных мелочах в документации: «здесь отступ не пять сантиметров, а два». И это может стать формальным поводом для затягивания приемки.
Уроки из горького опыта
Однажды наша команда столкнулась с задачей, где изначально договорились не придерживаться предписаний. Но когда в процессе работы возникли неизбежные для сложных проектов трудности и недопонимания, заказчик воспользовался формальным условием из ТЗ и потребовал переделать всю документацию в соответствии со правилами. Это привело к огромным незапланированным затратам, срыву сроков и, конечно, испорченным нервам.
Бывало и наоборот: в техническом задании мы обнаруживали ссылки на ГОСТы, которые уже несколько лет как не действуют. А при обсуждении выяснилось, что сам заказчик не в курсе, что именно требуют эти стандарты. Их просто скопировали из старой документации «для галочки».
Так когда же без ГОСТов не обойтись?
Однозначно — в работе с государственными заказчиками. Для них ссылка на нормативы— это стандартная практика, обеспечивающая предсказуемость и качество результата. Также обязательные к применению нормы критически важны в областях, связанных с безопасностью и обороной, где любая неточность недопустима.
При этом есть и современные крупные компании, которые, оставаясь в правовом поле, разрабатывают собственные, более гибкие критерии документации. Они понятны, логичны и адекватны сути agile-разработки, не утопая в формальностях.
Что необходимо учесть, если вы решили использовать ГОСТЫ?
- Изучите нормативы, которые требуете. Убедитесь, что они действующие и действительно релевантны для ваших задач.
- Будьте избирательны. Возможно, не вся разработка, а только ее ключевой, фундаментальный модуль должен строго соответствовать регламенту.
- Рассмотрите рекомендательный статус. Указание в ТЗ, что ГОСТы носят рекомендательный, а не обязательный характер, спасет обе стороны от многих проблем и конфликтов.
- Помните о цене. Строгое следование требованиям — это всегда увеличение бюджета и сроков. Заранее закладывайте эти затраты.
Выполняя работы, подрядчик следует правилам следующих нормативных документов:
- ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания;
- ГОСТ 21552-84. Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспортирование и хранение;
- ГОСТ Р ИСО/МЭК 15289. Информационная технология. Системная инженерия. Процессы жизненного цикла систем;
- ГОСТ Р 55241.1-2012. Эргономика взаимодействия человек-система;
- ГОСТ Р ИСО/МЭК 15504-1-2009. ИТ. Оценка процессов;
- ГОСТ Р – 2000 г: ИТ. Требования к качеству и тестирование.
Вывод: использовать ГОСТы на ИТ-проектах или нет?
Однозначного ответа «да» или «нет» не существует. Это решение, которое зависит от конкретной ситуации, специфики заказчика и отрасли.
ДА, если вы работаете с госсектором, в сферах, связанных с безопасностью, или если ваш продукт требует максимальной стандартизации и предсказуемости на десятилетия вперед.
НЕТ (или «да, но с оговорками»), если ваш цифровой продукт живет в условиях быстро меняющегося рынка, использует гибкие методологии разработки и нацелен на скорость и инновации.
“Использование устаревших регламентов в ИТ-процессе — это как попытка загнать живую, динамичную систему в прокрустово ложе. Это лишает её главных преимуществ: гибкости и скорости. Однако в некоторых случаях эти требования становятся важной гарантией стабильности”, - Максим Дмитриев, руководитель проектов.
