Найти тему
DFCenter

4 проблемы при постановке вопросов для СКТЭ

Один из отцов-основателей менеджмента, Питер Друкер, говорил, что самое важное и трудное – это не поиск правильного ответа, а поиск правильного вопроса. Компьютерно-техническая экспертиза, конечно, не менеджмент. Но и здесь ответ начинается с вопроса.

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

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

Что же такого сложного в подготовке вопросов?

1. Объемные общие вопросы. Постановка истцом вопроса о работоспособности «в целом» сложной ИТ-системы, которая разрабатывалась несколько месяцев одной крупной компанией по заказу другой – не всегда лучшее решение. Такие, без конкретики, вопросы несут целый ряд рисков, причем для обеих сторон спора.

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

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

В-третьих, такие общие вопросы пытаются подменить работой эксперта обязанности разработчиков по проведение итогового тестирования программного продукта. На эту тему есть целый ГОСТ 34.603-92.

Все это может привести к увеличению сроков и стоимости проведения экспертизы, к запросам экспертом доп. материалов и документов (которых часто нет), появлению ответов типа «НВП» или «выходит за пределы компетенции».

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

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

2. Множество частных вопросов. Другая крайность – ставить перед экспертом необоснованно большое количество вопросов. Иногда это происходит просто потому, что стороны не могут договориться по вопросам, а суд решает отдать на разрешение эксперту все вопросы и той, и другой стороны – просто смешав их и не убирая дублирующиеся по смыслу. Хороший пример – весьма знаковое дело А40-18827/17, где на СКТЭ вынесено 59 вопросов.

На ответы у эксперта (изначально одного, не комиссии) было 30 рабочих дней. Предсказуемо сроки поехали и пришлось неоднократно продлевать. Определение о назначении было вынесено 1 февраля 2019 года, а заключение от эксперта было представлено 23 июня 2020 года. Все существенно затянулось, даже с учетом карантина.

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

3. Отсутствие логики и последовательности в вопросах. Прямое продолжение проблемы №2. Ответы эксперта на вопросы важны для дела своей ясностью, конкретикой и последовательностью изложения. Зачем суду обращаться к «сведущему лицу», ответы которого никому непонятны и не несут никакой пользы для разрешения дела? Дело конечно в знаниях и опыте эксперта, но чтобы повысить КПД его ответов у стороны также есть действенный инструмент. Вопросы желательно выстраивать в логической последовательности. Например, ответ на первый вопрос может стать вводным для второго. Третий объясняет почему это именно так, а четвертый – заранее обосновывает, почему иногда ситуации отличаются и почему сейчас – «не тот редкий случай».

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

4. Смешение вопросов из нескольких сфер науки. Что делает экспертизу, по сути, комплексной. Подобное часто встречается в спорах о правах на софт и в спорах о выполнении работ по созданию софта. Перед экспертом ставятся одновременно вопросы технического характера со смыслом «создано ли?», «создано ли по ТЗ?», «работает ли?» и вопросы из экономической сферы – «сколько стоила разработка?», «сколько стоит софт?», «есть ли экономическая польза от создания?». Да, безусловно есть эксперты, которые одновременно на высоком уровне обладают знаниями в обоих областях. Но в подавляющем большинстве случаев, которые попадают нам на рецензирование, это не так.

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

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

#dfcenter #научпоп #арбитражная_форензика #компьютерная_криминалистика #компьютернаякриминалистика #форензика_для_юристов #форензика #КТЭ #СКТЭ