Мы готовы поверить, что цифровая трансформация коренным образом изменит технологии, модели ведения и управления в бизнесе. Но когда доходит до конкретики, оказывается, что дело это хлопотное, дорогостоящее и не всегда проходит гладко. А иногда даже порождает проблемы и конфликты.
Одна такая история приобрела известность после того, как 2 октября на заседании Республиканского клуба директоров, директор ЗАО «Гомельлифт» Валерий Корниенко заявил, что «95% ИТ-компаний в Беларуси — мошенники» и он ищет управу на одну из них в суде. Оказалось, что судиться с айтишниками – дело непростое. Зато весьма поучительное.
Каша заварилась еще в 2017 году, когда «Гомельлифт» заказало у ООО «Элитсофт» комплекс работ по вводу в эксплуатацию, внедрению и тестированию ПО «1С: Предприятие 8». Стоимость проекта по белорусским меркам немалая. В процессе эксплуатации ПО обнаружились проблемы. Эксперт, нанятый заказчиком, пришел к выводу, что работы выполнены всего на 30%, а потому пользоваться этим ПО невозможно. Поскольку исполнитель с таким мнением не согласился, ЗАО обратилось в суд, требуя взыскать с ответчика 70% суммы по договору (по белорусским меркам немалой) и проценты за пользование чужими денежными средствами.
Решение Верховного суда – настоящий бестселлер. Ответчик не выполнил работы по всем этапам календарного плана, за исключением обучения, утверждали представители истца. Но они признали подписание актов сдачи-приёмки работ «без проверки выполненных работ – на доверии». В свою очередь, представители ответчика уверяли, что все сделано надлежащим образом и в срок. Позднее, после суда, директор «Элитсофта» жаловался, что работы затягивались по вине заказчика, который потом еще и не заплатил за выработанные часы по договору техсопровождения.
Проблема в том, что качество автоматизации управления и бухучета затруднительно подогнать под «требования, обычно предъявляемым к работам соответствующего рода». А доказать отступления от договора, ухудшившие результат, или иные недостатки, делающие его непригодным для использования, чтобы получить дарованное п.2 п.1 ст.676 ГК право требовать соразмерного уменьшения оплаты, можно лишь в том случае, если в нюансы работы ПО вникнет суд. Но для него существуют лишь нормы главы 37 ГК и очевидные задокументированные факты. Вот подписанные сторонами договор, вот спецификация ПО, календарный план-график выполнения работ и концептуальный проект, требованиям которого должны соответствовать объём и качество выполненных работ. Есть протоколы заседания комиссии, товаросопроводительные документы и акты сдачи приемки по этапам «полностью и в срок», также подписанные сторонами без всяких претензий. Все дополнения к ПО, не вошедшие в утверждённые концептуальные проекты, заказчик согласило оформлять отдельными протоколами и выполнять в ходе опытной эксплуатации. По сути это значит, что целый ряд функций повисает в воздухе. А если работы приняты без проверки, то это, согласно ГК, вообще лишает заказчика права предъявлять претензии.
К тому же через год после принятия работ ЗАО заключило с заказчиком договор по техническому сопровождению части ПО, находящейся в опытной эксплуатации. По мнению суда это тоже свидетельствует, что работы выполнены и приняты. Впрочем, это с тем же успехом может говорить о том, что ПО не работает без постоянного устранения текущих косяков и «вбивания» вручную операций, не содержащихся в лицензионной версии программы. Неудивительно, что пытаясь судиться, заказчик запутался в том, что функционирует, а что нет. Об отсутствии конкретики проекта можно догадаться из фразы в решении суда: по проекту техническое задание не составлялось, поскольку «заказчик, на момент заключения договора не смог определить полный объём задач». А потому стороны договорились, что «объём и качество работ должны соответствовать концептуальному проекту, который вместе с уставом проекта комплексной автоматизации и календарным планом были подготовлены с участием представителей сторон и «надлежащим образом» утверждены заказчиком.
Это – ключевой момент конфликта.
Публика напрасно хихикала по поводу помянутых в интервью В. Корниенко старых советских стандартов. ГОСТы 34.602-89 и 19.201-78 конечно, устарели. Но при правильной интерпретации на их основе получаются вполне приличные техзадания на создание автоматизированных систем. Любители модерна могли бы принять к сведению IEEE STD 830-1998 IEEE 1233-1998, IEEE 1362-1998, еще более современный ISO/IEC/IEEE 29148-2011, рекомендации Вигерса и тд. Можно даже и без ТЗ обойтись – если, скажем, разработчик исповедует подходы Agile и неукоснительно претворяет в каждом проекте принципы его манифеста: Working software over comprehensive documentation – работающее ПО превыше всеобъемлющей документации. Иными словами, если вы качественно работаете, нет нужды прятаться за пачку бумажек.
Заказчик никогда не знает всех возможностей ПО, которое намерен приобрести. Он может даже слабо представлять, какие расчеты, отчеты и показатели, ему нужны, какие данные и по какому графику должны передаваться между подразделениями. Для того и существуют бизнес-аналитики. Они вместе с представителями заказчика составляют функциональное описание необходимых задач, делают на его основе ТЗ, которое утверждается заказчиком и воплощается в жизнь. В данном случае проблемы были неизбежны с того момента, когда «Гомельлифт» согласился обойтись без техзадания. Между прочим, на обследование бизнес-процессов и подготовку плана отводилось 50 рабочих дней, которые обошлось заказчику в 12,3 тыс. рублей. Полюбопытствовали ли суд, что сделано за это время и деньги?
К примеру, вы хотите, чтобы в доме был лифт. Надо ясно знать, какой груз на сколько этажей он повезет, двери должны открываться-закрываться вовремя, кабина – ехать куда надо и т.п. Если лифт без работников изготовителя регулярно застревает где попало, никакие акты сдачи-приемки не избавят подрядчика от обязанности исправлять свои косяки. Жильцов дома интересуют не реле, кабеля и тросы лифта, а возможность без приключений доехать до нужного этажа. Но если речь идет об управленческом ПО, все совершенно иначе. Заказчика тоже интересуют не коды и изящество алгоритмов, а их способность обрабатывать и представлять информацию. Но сначала вам никак не удается справиться с кнопками, затем приходится платить за доработку функций – необходимых, но не учтенных заранее, потом – регулярно оплачивать техподдержку и настройку любых изменений. Все это делает автоматизацию очень долгой и весьма дорогостоящей. Это весьма приятным образом сказавается на выручке и зарплате айтишников (а заодно на кое-каких макроэкономических показателях). Но финансовые результаты и производительность труда в реальном секторе явно не улучшатся. Но ехать-то людям в лифте, а не на алгоритме.
В нашей истории реальная работоспособность ПО суд вообще не интересовала. Настолько, что он отказался вызывать эксперта, признал его выводы предположительными, а заключение – необоснованным, не содержащим «самостоятельно проведенные исследования в области программирования». Зато суд благосклонно принял заверения ответчика о том, что часть замечаний эксперта устранена, а остальное – всего лишь дополнительные пожелания заказчика, не относящиеся к договорному объёму работ. Который, замечу, без ТЗ – тоже категория предположительная.
Итак, попытка доказать, что «с айтишниками можно судиться» провалилась. Кому-то с юридической точки зрения решение кажется правильным. Но не странно ли, что для правосудия куча сдуру подписанных актов гораздо важнее фактического результата работ? Ведь заказчик-то остался с не работающим в полном объеме ПО. Которую заказчик милостиво предлагает доделать – за отдельную плату.
Конечно, В. Корниенко погорячился огульно обвиняя чуть ли не всех айтишников-внедренцев в обмане клиентов. Ведь никто не пытается привлекать их по ст. 209 УК за мошенничество. Хотя бы потому, что затруднительно доказать намерение обманом завладеть деньгами клиента – авторитетные юристы подтвердят. Но кого-нибудь затерзают смутные сомнения: как это опытные айтишники берутся за проект, по которому даже техзадание невозможно составить?
Интересно, каким был бы вердикт суда, если бы истцом оказалось госпредприятие, а проект финансировался из бюджета? Такие вопросы неизбежно возникнут, когда под флагом «цифровой пятилетки» начнется повальная цифровая трансформация, в т.ч. в госсекторе. Ведь сформулировать в деталях свои пожелания смогут единицы. А для остальных бесценным будет урок «Гомельлифта». Будущие заказчики теперь знают: не надо обольщаться волшебной силой информационных технологий. Все что для вас делает и, тем более, не делает разработчик, надо вписать в рамки главы 37 ГК. Каждая ее статья может сработать против заказчика, если он окажется слишком доверчивым и зашоренным. Или защитить – если позаботиться об этом заранее. А потому составлять договора и техзадания, а также принимать результаты каждого этапа и проекта лучше с помощью опытных независимых консультантов. Тоже недешево, но окупится. Не надо подписывать акты без оговорок, если есть малейшие сомнения. Мы платим не за отработанные часы и устные обещания, а за результат, которого ожидаем.
И еще один совет – строго между нами. Если часов планируется очень много, а результат непредсказуем или кто-то в приемочной комиссии шибко лояльно настроен – будьте бдительны. Впору начинать выяснять, не заинтересован ли в заключении такого договора и приемке этапов "на доверии" кто-то из ваших менеджеров – слишком личным образом. Мало ли куда проникнут щупальца коррупция и соблазн откатов.
Несоблюдение этих правил повышает риск потратить зря время, деньги, нервы и остаться с расчетами в Excel «на коленке». А потом можете пенять на самих себя и тихо ненавидеть привилегированное сословие айтишников, разговорчики об IT-стране и светлом цифровом будущем...
Справка:
Источник - Белстат