Госты в ИТ

В мире agile, scrum и гибкой разработки есть слово, от которого у многих IT-команд кровь стынет в жилах. И это не «баг», не «дедлайн», а «ГОСТ». Для одних — это синоним качества, для других — камень преткновения, который мешает двигаться вперед. Кто же прав? Давайте разберемся и без громких заявлений рассмотрим нужно ли использовать ГОСТы в ИТ. 

Меня зовут Максим Дмитриев, я руководитель проектов в компании RDN Group. Наша команда специализируется на разработке сложных и высоконагруженных решений: корпоративных порталов, торговых площадок, личных кабинетов и интеграционных проектах. Являясь одним из немногих партнеров «1С-Битрикс» с компетенцией «Крупные корпоративные внедрения» расширенного уровня, мы на практике видим, как бизнес переходит от экспериментов с удалёнкой к построению целостных, безопасных и автоматизированных цифровых офисов.

Что такое ГОСТы в ИТ и зачем они вообще нужны?

ГОСТы в ИТ можно условно разделить на два больших блока.

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

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

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

Камень преткновения: почему ГОСТы стали проблемой?

Представьте себе современный гибкий проект, который развивается по методологии Scrum. Требования к продукту меняются каждые две недели по итогам спринта, команда постоянно получает обратную связь и адаптируется. А теперь попробуйте вписать в этот процесс требование «соответствовать правилам», которые предполагают, что все технические требования должны быть полностью описаны и зафиксированы в самом начале, на стадии технического задания.

Возникает фундаментальное противоречие. Жизненный цикл разработки по формализованным требованиям напоминает неспешный и предсказуемый процесс, в то время как реальность ИТ — это быстрая процесс, постоянно меняющий направления.

Чем это грозит на практике?

1. Риск срыва приемки. Если в договоре или ТЗ жестко прописано соответствие конкретным нормам, а какая-то часть документации или продукта им не соответствует, заказчик имеет полное право признать работу выполненной некачественно. Парадокс в том, что сам продукт при этом может быть лучше, чем планировалось. Но формально — он «бракованный».
2. Колоссальные трудозатраты. Подготовка документации по нормативной базе— это отдельный сложный процесс, который часто требует привлечения технического писателя со специализированными знаниями. Бывают случаи, когда написание документов отнимает больше времени и сил, чем написание кода.
3. Эффект «снежного кома». В техническом задании может быть указан один стандарт. Вы открываете его, а там — ссылки на еще три норматива. Вы открываете эти три, а в них — ссылки еще на десять. Путешествие по этой бесконечной ветке может затянуться очень надолго. Причем некоторые уже могут потерять свою актуальность. 
4. Субъективизм при приемке. Когда наступает время сдавать результат работ, приемочная комиссия может сфокусироваться не на сути продукте, а на формальных мелочах в документации: «здесь отступ не пять сантиметров, а два». И это может стать формальным поводом для затягивания приемки.

Уроки из горького опыта

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

Бывало и наоборот: в техническом задании мы обнаруживали ссылки на ГОСТы, которые уже несколько лет как не действуют. А при обсуждении выяснилось, что сам заказчик не в курсе, что именно требуют эти стандарты. Их просто скопировали из старой документации «для галочки».

Так когда же без ГОСТов не обойтись?

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

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

Что необходимо учесть, если вы решили использовать ГОСТЫ? 

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

Выполняя работы, подрядчик следует правилам следующих нормативных документов:

• ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания;
• ГОСТ 21552-84. Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспортирование и хранение;
• ГОСТ Р ИСО/МЭК 15289. Информационная технология. Системная инженерия. Процессы жизненного цикла систем;
• ГОСТ Р 55241.1-2012. Эргономика взаимодействия человек-система;
• ГОСТ Р ИСО/МЭК 15504-1-2009. ИТ. Оценка процессов;
• ГОСТ Р – 2000 г: ИТ. Требования к качеству и тестирование.

Вывод: использовать ГОСТы на ИТ-проектах или нет?

Однозначного ответа «да» или «нет» не существует. Это решение, которое зависит от конкретной ситуации, специфики заказчика и отрасли.

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

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

“Использование устаревших регламентов в ИТ-процессе — это как попытка загнать живую, динамичную систему в прокрустово ложе. Это лишает её главных преимуществ: гибкости и скорости. Однако в некоторых случаях эти требования становятся важной гарантией стабильности”, - Максим Дмитриев, руководитель проектов.