Питер Друкер, один из отцов-основателей менеджмента, считал самым важным и трудным не поиск правильного ответа, а поиск правильного вопроса. И мы вам скажем, что в компьютерно-технической, да и любой другой экспертизе так же. Но откуда же взять эти самые «правильные вопросы», дающие реальную пользу?
Суд вполне может поставить любые вопросы, какие посчитает нужным. Он, в идеале, беспристрастен. Однако, в арбитражных спорах суд вполне в рамках правового поля готов выслушать предложения по вопросам от сторон. Ведь это собственно, они хотят подтвердить свою точку зрения сложным исследованием. Поэтому подготовка вопросов на экспертизу – это задача именно стороны спора, причем не обязательно той, кто экспертизу прям-таки хочет.
Тут вам скорее всего хочется увидеть список из 10-15 четких вопросов на все случаи жизни СКТЭ. А еще лучше 3-5. Но нет, так это не работает. Очень много случаев если уж не «уникальных», но с особенностями и нюансами. Но вот зато у нас есть список самых распространенных ошибок при составлении вопросов.
1. Объемные общие вопросы. Постановка вопроса о работоспособности «в целом» сложной ИТ-системы, которая разрабатывалась несколько месяцев одной крупной компанией по заказу другой – не лучшее решение. Такие, без конкретики, вопросы несут целый ряд рисков, причем для обеих сторон спора.
Во-первых, количество и объем ошибок не всегда имеет прямо пропорциональную взаимосвязь с работоспособностью результата. Сложный ИТ-продукт состоит из большого числа отдельных элементов. И по практике недостатки будут распределены не равномерно по всем элементам/блокам, а выражены только в отдельных. Например, часто большая система не работает не потому, что некачественно выполнены все десять блоков в ней, а потому, что плохо сделан один, влияющий на работу остальных девяти условно «хороших».
Во-вторых, выглядит странным, что одному эксперту, иногда даже без опыта самостоятельного программирования, доверяют найти все ошибки, которые могли допустить сотни программистов ответчика. Ведь софт может быть действительно масштабным.
Ну и вдобавок, через такие общие вопросы иногда пытаются подменить работой эксперта обязанности разработчиков по проведению итогового тестирования программного продукта. На эту тему есть целый ГОСТ.
В итоге, помимо огромных стоимости и сроков проведения экспертизы, все это может привести к запросам экспертом доп. материалов и документов (которых часто нет у сторон) и, как следствие, появлению ответов типа «НВП» или «выходит за пределы компетенции». Оно вам надо?
Также велик риск ситуации, когда по итогам объемной экспертизы по всей системе действительно будет установлено наличие ошибок и недоработок, но их объем в общей массе, по мнению эксперта, будет «условно небольшим». И придется отдельно доказывать, почему и насколько этот «небольшой» объем недоработок действительно критичен для истца. Ну то есть дополнительная экспертиза.
Чтобы убрать эти риски можно ставить четкие вопросы именно к «целевым» блокам. Ведь, как правило, на входе в судебную стадию спора стороны уже понимают, в чем конкретно претензии к качеству продукта: отсутствует или не работает какая-то функция, возникает какая-то повторяющаяся ошибка и т.д. А последующий ответ эксперта о том, насколько критична такая ошибка или недоделка даже в одном блоке, позволит показать серьезность недостатки системы в целом.
2. Множество частных вопросов. Другая крайность – ставить перед экспертом необоснованно большое количество вопросов. Иногда это происходит просто потому, что стороны не могут договориться по вопросам, а суд решает отдать на разрешение эксперту все вопросы и той, и другой стороны – просто смешав их и не убирая дублирующиеся по смыслу. Хороший пример – весьма знаковое дело А40-18827/17 (VK против Double Data), где на СКТЭ было вынесено 59 вопросов. Только на одну из двух экспертиз.
На ответы у эксперта (одного, не комиссии) было 30 рабочих дней. Предсказуемо сроки поехали и пришлось неоднократно продлевать. Определение о назначении было вынесено 1 февраля 2019 года, а заключение от эксперта было представлено в суд 23 июня 2020 года. То есть экспертиза длилась полтора года, что слишком даже с учетом тогдашнего COVID-карантина.
Чтобы упредить подобный сценарий важно сконцентрироваться на том, что действительно является проблемной областью и непосредственно связано с предметом спора. Убрать все лишнее, что лишь запутает и, при невнимательном прочтении, может быть истолковано неверно или не однозначно.
3. Отсутствие логики и последовательности в вопросах. Прямое продолжение проблемы №2. Ответы эксперта на вопросы важны для дела своей ясностью, конкретикой и последовательностью изложения. Зачем суду ответы, которые никому непонятны и не несут никакой пользы для разрешения дела?
Дело конечно в знаниях и опыте эксперта, но чтобы повысить КПД его ответов у стороны также есть действенный инструмент. Вопросы крайне желательно выстраивать в логической последовательности. Например: ответ на первый вопрос может стать вводным для второго. Третий объясняет почему это именно так, а четвертый – заранее обосновывает, почему иногда ситуации отличаются и почему сейчас – «не тот редкий случай».
Изучая ответы на такие вопросы, суду проще двигаться по повествованию и понять логику выводов эксперта, даже если суд далек (что в принципе то и нормально) от тяжелых технических тонкостей конкретной ИТ-технологии.
4. Смешение вопросов из нескольких сфер науки. Что делает экспертизу, по сути, комплексной. Подобное часто встречается в спорах о правах на софт и в спорах о выполнении работ по созданию софта. Перед экспертом ставятся одновременно вопросы технического характера со смыслом «создано ли?», «создано ли по ТЗ?», «работает ли?» и вопросы из экономической сферы – «сколько стоила разработка?», «сколько стоит софт?», «есть ли экономическая польза от создания?».
Да, безусловно, есть эксперты, которые одновременно на высоком уровне обладают знаниями в обеих областях. Но в подавляющем большинстве случаев, которые попадают нам на рецензирование, это не так.
При этом найти двух экспертов, обладающих специальными знаниями, каждый в своей области, гораздо проще. И результат будет качественней. Поэтому лучше сразу предугадать комплексный характер экспертизы и подавать соответствующее ходатайство при назначении.
Ну и чтобы убрать все эти риски крайне полезно до выхода на судебную экспертизу консультироваться со специалистами. Вам будет проще простроить логику, подсветить действительно проблемные и спорные места, обозначить причинно-следственные связи и обосновать свои претензии.
Суд вполне может поставить любые вопросы, какие посчитает нужным. Он, в идеале, беспристрастен. Однако, в арбитражных спорах суд вполне в рамках правового поля готов выслушать предложения по вопросам от сторон. Ведь это собственно, они хотят подтвердить свою точку зрения сложным исследованием. Поэтому подготовка вопросов на экспертизу – это задача именно стороны спора, причем не обязательно той, кто экспертизу прям-таки хочет.
Тут вам скорее всего хочется увидеть список из 10-15 четких вопросов на все случаи жизни СКТЭ. А еще лучше 3-5. Но нет, так это не работает. Очень много случаев если уж не «уникальных», но с особенностями и нюансами. Но вот зато у нас есть список самых распространенных ошибок при составлении вопросов.
1. Объемные общие вопросы. Постановка вопроса о работоспособности «в целом» сложной ИТ-системы, которая разрабатывалась несколько месяцев одной крупной компанией по заказу другой – не лучшее решение. Такие, без конкретики, вопросы несут целый ряд рисков, причем для обеих сторон спора.
Во-первых, количество и объем ошибок не всегда имеет прямо пропорциональную взаимосвязь с работоспособностью результата. Сложный ИТ-продукт состоит из большого числа отдельных элементов. И по практике недостатки будут распределены не равномерно по всем элементам/блокам, а выражены только в отдельных. Например, часто большая система не работает не потому, что некачественно выполнены все десять блоков в ней, а потому, что плохо сделан один, влияющий на работу остальных девяти условно «хороших».
Во-вторых, выглядит странным, что одному эксперту, иногда даже без опыта самостоятельного программирования, доверяют найти все ошибки, которые могли допустить сотни программистов ответчика. Ведь софт может быть действительно масштабным.
Ну и вдобавок, через такие общие вопросы иногда пытаются подменить работой эксперта обязанности разработчиков по проведению итогового тестирования программного продукта. На эту тему есть целый ГОСТ.
В итоге, помимо огромных стоимости и сроков проведения экспертизы, все это может привести к запросам экспертом доп. материалов и документов (которых часто нет у сторон) и, как следствие, появлению ответов типа «НВП» или «выходит за пределы компетенции». Оно вам надо?
Также велик риск ситуации, когда по итогам объемной экспертизы по всей системе действительно будет установлено наличие ошибок и недоработок, но их объем в общей массе, по мнению эксперта, будет «условно небольшим». И придется отдельно доказывать, почему и насколько этот «небольшой» объем недоработок действительно критичен для истца. Ну то есть дополнительная экспертиза.
Чтобы убрать эти риски можно ставить четкие вопросы именно к «целевым» блокам. Ведь, как правило, на входе в судебную стадию спора стороны уже понимают, в чем конкретно претензии к качеству продукта: отсутствует или не работает какая-то функция, возникает какая-то повторяющаяся ошибка и т.д. А последующий ответ эксперта о том, насколько критична такая ошибка или недоделка даже в одном блоке, позволит показать серьезность недостатки системы в целом.
2. Множество частных вопросов. Другая крайность – ставить перед экспертом необоснованно большое количество вопросов. Иногда это происходит просто потому, что стороны не могут договориться по вопросам, а суд решает отдать на разрешение эксперту все вопросы и той, и другой стороны – просто смешав их и не убирая дублирующиеся по смыслу. Хороший пример – весьма знаковое дело А40-18827/17 (VK против Double Data), где на СКТЭ было вынесено 59 вопросов. Только на одну из двух экспертиз.
На ответы у эксперта (одного, не комиссии) было 30 рабочих дней. Предсказуемо сроки поехали и пришлось неоднократно продлевать. Определение о назначении было вынесено 1 февраля 2019 года, а заключение от эксперта было представлено в суд 23 июня 2020 года. То есть экспертиза длилась полтора года, что слишком даже с учетом тогдашнего COVID-карантина.
Чтобы упредить подобный сценарий важно сконцентрироваться на том, что действительно является проблемной областью и непосредственно связано с предметом спора. Убрать все лишнее, что лишь запутает и, при невнимательном прочтении, может быть истолковано неверно или не однозначно.
3. Отсутствие логики и последовательности в вопросах. Прямое продолжение проблемы №2. Ответы эксперта на вопросы важны для дела своей ясностью, конкретикой и последовательностью изложения. Зачем суду ответы, которые никому непонятны и не несут никакой пользы для разрешения дела?
Дело конечно в знаниях и опыте эксперта, но чтобы повысить КПД его ответов у стороны также есть действенный инструмент. Вопросы крайне желательно выстраивать в логической последовательности. Например: ответ на первый вопрос может стать вводным для второго. Третий объясняет почему это именно так, а четвертый – заранее обосновывает, почему иногда ситуации отличаются и почему сейчас – «не тот редкий случай».
Изучая ответы на такие вопросы, суду проще двигаться по повествованию и понять логику выводов эксперта, даже если суд далек (что в принципе то и нормально) от тяжелых технических тонкостей конкретной ИТ-технологии.
4. Смешение вопросов из нескольких сфер науки. Что делает экспертизу, по сути, комплексной. Подобное часто встречается в спорах о правах на софт и в спорах о выполнении работ по созданию софта. Перед экспертом ставятся одновременно вопросы технического характера со смыслом «создано ли?», «создано ли по ТЗ?», «работает ли?» и вопросы из экономической сферы – «сколько стоила разработка?», «сколько стоит софт?», «есть ли экономическая польза от создания?».
Да, безусловно, есть эксперты, которые одновременно на высоком уровне обладают знаниями в обеих областях. Но в подавляющем большинстве случаев, которые попадают нам на рецензирование, это не так.
При этом найти двух экспертов, обладающих специальными знаниями, каждый в своей области, гораздо проще. И результат будет качественней. Поэтому лучше сразу предугадать комплексный характер экспертизы и подавать соответствующее ходатайство при назначении.
Ну и чтобы убрать все эти риски крайне полезно до выхода на судебную экспертизу консультироваться со специалистами. Вам будет проще простроить логику, подсветить действительно проблемные и спорные места, обозначить причинно-следственные связи и обосновать свои претензии.