Лето – прекрасная пора для отдыха. Кто на море, а кто и на даче. Правда, сперва надо бы дачу построить. Нанять работяг рукастых, если конечно сам не DIY-любитель. Само собой не по объявлению со столба, а по рекламе в интернете. Договор заключить для надежности. Вдруг поможет чем-то. Ну и ждать, когда закончат. И надеяться, что закончат с таким же качеством, с каким обещали и по такой же цене, что и в начале.
Нет, ну если и не закончат, тоже не совсем прям беда. Можно же принять хотя бы то, что успели построить, если оно не совсем плохое. А потом (в теории) уже разбираться с убытками, неустойками и прочими страшными словами. А в следующем году – уже с новыми силами (и бюджетом) найти уже кого-то проверенного и рекомендованного (из другого интернета), и все доделать. Какая, в конце концов, разница кто конкретно достроит дачу, если сделает это качественно. Строительство дачного домика – то ведь работа, никак не зависящая от личности исполнителя.
Да ну что мы все про домики да про лето. Давайте про софт. Вот заказали вы, как компания, разработку софта у другой компании. Они его разрабатывали-разрабатывали, да недоразработали. Сроки вышли, а качества не случилось. Точнее как – качество случилось, но местами. Из пяти блоков готово три с половиной. Но, если посмотреть по-айтишному, все эти 3,5 блока вполне себе качественный код. Правда не работает. Но только потому, что к нему еще оставшиеся 1,5 не подсоединили. А вот потом – кааааак полетит. Но нужно доделать. И вот тут есть пара тонких моментов в плане отличия дачного домика от софта.
Во-первых, что значит «доделать», кто этим будет озадачен и что, собственно, доделывать. Получается, что надо сперва согласиться и получить от исполнителя не на 100% качественный заказ, а на 70%. Такое вообще возможно или качество итогового результата разработки ПО – это, все-таки, бинарная категория? Либо разработал ПО согласно ТЗ, либо нет. Домик нам может, по идее, любой строитель нужной квалификации достроить. А софт?
Напомним, что софт в России – это «литературное произведение», авторское право и так далее. То есть, получается, творчество. А творчество оно такое, на полпути творца сложно заменить. Иначе может письмо дяди Федора родителям получиться.
То есть выходит, услуги по разработке софта, даже если это не договор авторского заказа с физиком, а вполне себе договор оказания услуг между двумя компаниями, это услуги, которые сильно завязаны на личность непосредственного исполнителя. Это немного странно. С такой точки зрения, можно ли вообще кому-то передать эти 70%, чтобы их доделали до 100%? Или новому исполнителю нужно будет переделывать все с нуля? Не всегда очевидно, особенно по кастомизированным задачам.
Есть еще и во-вторых. Оно в том, что хорошая дача нужна всегда. Хоть самому пользоваться, хоть внукам оставить, хоть в аренду сдавать. После прикрытия массового инотуризма это опять стало очевидно. И с этой точки зрения два года ее строить, три или год – не особо критично, главное, чтобы хорошо и на века.
А вот с софтом, разработку которого заказывали под конкретную бизнес-задачу, все не так однозначно. ИТ-ложка нужна к ИТ-обеду, для этого и были конкретные сроки установлены. И после – может уже и задачи такой нет, а интерес, так сказать, утрачен. И тут, вроде бы, вырисовывается «вследствие просрочки должника исполнение утратило интерес для кредитора» из 405 ГК РФ.
Однако тут тоже не все так просто. Вот на днях ВС РФ определил, что «сама по себе утрата интереса заказчика к дальнейшему выполнению работ, в отсутствие доказательств прекращения договорных отношений по иным основаниям, не может являться основанием для отказа в оплате уже выполненных и принятых заказчиком работ, также как нарушение срока выполнения работ не является основанием для вывода об утрате интереса…». Так что тут нужно будет доказывать что-то еще, кроме самого факта просрочки исполнения договора.
А что если попробовать подойти к утрате интереса с технической стороны? Вот, например, есть такая штука, как цикл жизни и актуальность технологии и созданного на ее основе софта. Сегодня уже совершенно другие подходы и решения для многих ИТ-задач, чем были 5-7 лет назад. И, если ТЗ не создавалось с огромным футуро-запасом или сфера его применения не суперстабильная в технологическом и процессном смысле, каждый день затягивания с разработкой делает прикладную полезность результата этой разработки для заказчика все ниже. Такая вот зависимость.
Вывод тут следующий: споры, связанные с разработкой софта, сроками, качеством и применимостью результата – это сфера со многими особенностями. Тут и ИТ-право, и договоры с обязательствами, и, само собой, технологии. Сложное. Но иногда очень интересное.
Нет, ну если и не закончат, тоже не совсем прям беда. Можно же принять хотя бы то, что успели построить, если оно не совсем плохое. А потом (в теории) уже разбираться с убытками, неустойками и прочими страшными словами. А в следующем году – уже с новыми силами (и бюджетом) найти уже кого-то проверенного и рекомендованного (из другого интернета), и все доделать. Какая, в конце концов, разница кто конкретно достроит дачу, если сделает это качественно. Строительство дачного домика – то ведь работа, никак не зависящая от личности исполнителя.
Да ну что мы все про домики да про лето. Давайте про софт. Вот заказали вы, как компания, разработку софта у другой компании. Они его разрабатывали-разрабатывали, да недоразработали. Сроки вышли, а качества не случилось. Точнее как – качество случилось, но местами. Из пяти блоков готово три с половиной. Но, если посмотреть по-айтишному, все эти 3,5 блока вполне себе качественный код. Правда не работает. Но только потому, что к нему еще оставшиеся 1,5 не подсоединили. А вот потом – кааааак полетит. Но нужно доделать. И вот тут есть пара тонких моментов в плане отличия дачного домика от софта.
Во-первых, что значит «доделать», кто этим будет озадачен и что, собственно, доделывать. Получается, что надо сперва согласиться и получить от исполнителя не на 100% качественный заказ, а на 70%. Такое вообще возможно или качество итогового результата разработки ПО – это, все-таки, бинарная категория? Либо разработал ПО согласно ТЗ, либо нет. Домик нам может, по идее, любой строитель нужной квалификации достроить. А софт?
Напомним, что софт в России – это «литературное произведение», авторское право и так далее. То есть, получается, творчество. А творчество оно такое, на полпути творца сложно заменить. Иначе может письмо дяди Федора родителям получиться.
То есть выходит, услуги по разработке софта, даже если это не договор авторского заказа с физиком, а вполне себе договор оказания услуг между двумя компаниями, это услуги, которые сильно завязаны на личность непосредственного исполнителя. Это немного странно. С такой точки зрения, можно ли вообще кому-то передать эти 70%, чтобы их доделали до 100%? Или новому исполнителю нужно будет переделывать все с нуля? Не всегда очевидно, особенно по кастомизированным задачам.
Есть еще и во-вторых. Оно в том, что хорошая дача нужна всегда. Хоть самому пользоваться, хоть внукам оставить, хоть в аренду сдавать. После прикрытия массового инотуризма это опять стало очевидно. И с этой точки зрения два года ее строить, три или год – не особо критично, главное, чтобы хорошо и на века.
А вот с софтом, разработку которого заказывали под конкретную бизнес-задачу, все не так однозначно. ИТ-ложка нужна к ИТ-обеду, для этого и были конкретные сроки установлены. И после – может уже и задачи такой нет, а интерес, так сказать, утрачен. И тут, вроде бы, вырисовывается «вследствие просрочки должника исполнение утратило интерес для кредитора» из 405 ГК РФ.
Однако тут тоже не все так просто. Вот на днях ВС РФ определил, что «сама по себе утрата интереса заказчика к дальнейшему выполнению работ, в отсутствие доказательств прекращения договорных отношений по иным основаниям, не может являться основанием для отказа в оплате уже выполненных и принятых заказчиком работ, также как нарушение срока выполнения работ не является основанием для вывода об утрате интереса…». Так что тут нужно будет доказывать что-то еще, кроме самого факта просрочки исполнения договора.
А что если попробовать подойти к утрате интереса с технической стороны? Вот, например, есть такая штука, как цикл жизни и актуальность технологии и созданного на ее основе софта. Сегодня уже совершенно другие подходы и решения для многих ИТ-задач, чем были 5-7 лет назад. И, если ТЗ не создавалось с огромным футуро-запасом или сфера его применения не суперстабильная в технологическом и процессном смысле, каждый день затягивания с разработкой делает прикладную полезность результата этой разработки для заказчика все ниже. Такая вот зависимость.
Вывод тут следующий: споры, связанные с разработкой софта, сроками, качеством и применимостью результата – это сфера со многими особенностями. Тут и ИТ-право, и договоры с обязательствами, и, само собой, технологии. Сложное. Но иногда очень интересное.