Мы практически ежедневно сталкиваемся с огромным количеством запросов, касающихся взаимоотношения заказчика и разработчика ПО. В большинстве случае разработка ПО либо оформляется очень плохо, либо не оформляется вообще никак. Как следствие, обе стороны получают массу проблем, если дело доходит до конфликта, поскольку разобрать кто, кому и что должен практически невозможно.
Эта статья направлена на то, чтобы помочь обеим сторонам не совершить самые критичные ошибки, которые в будущем могут аукнуться полной потерей всего и вся, а также длительными судебными разбирательствами, долгами и испорченной репутацией с обеих сторон.
С чего начать заказ разработки ПО?
А начать надо с технического задания. Уже на этапе обсуждения между будущим разработчиком и заказчиком должно быть какое-то техническое задание, которое даст программистам понимание, что от них требуется и насколько сложна будет задача.
Если технического задания нет и у вас недостаточно навыков, чтобы его правильно оформить, то можно либо обратиться за его разработкой в отдельную компанию, либо включить его разработку и согласование в перечень работ, который будет согласован в договоре с разработчиком. Таким образом, самой первой задачей разработчика будет написание технического задания, а уже дальнейшая разработка будет идти именно в соответствии с ним. В идеале, конечно, было бы неплохо привлечь независимого эксперта, который по итогам написания технического задания, смог бы его проверить и сказать, что с ним всё хорошо, но этого никто не делает. Поэтому лучше самому иметь какое-то понимание того, что требуется от программистов и в каком виде.
Чем более подробное будет техническое задание, тем более определённый результат может ожидать заказчик. Существуют стандарты разработки технических заданий, например, достаточно свежий и вступивший в силу с 1 января 2022 года ГОСТ 34.602-2020 «Информационные технологии (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы», или международный аналог — ISO/IEC/IEEE 29148:2018 «Systems and software engineering — Life cycle processes — Requirements engineering», однако их мало кто придерживается и в нашей практике технические задания, сделанные с оглядкой на подобные стандарты, были только у невероятно масштабных проектов.
В тексте договора с разработчиками следует отдельно оговорить какие-то упрощённые способы корректировки технического задания, если такие корректировки не влекут изменения объёма работ и, соответственно, стоимости разработки. Например, можно предусмотреть уточнения и изменения в техническое задание путём обмена письмами по электронной почте.
Что с конфиденциальностью?
Если вы только в поиске идеального разработчика для вашего проекта, то следует иметь под рукой форму соглашения о неразглашении. Его ещё называют соглашением о конфиденциальности, или на английский манер — NDA (non-disclosure agreement).
Очевидно, что в процессе общения с разными компаниями или индивидуальными разработчиками у вас возникнет необходимость показывать всем свои идеи, какие-то наработки, быть может уже готовое техническое задание. Иногда не просто показывать, а даже передавать на какое-то время, чтобы программисты оценили объём и рассказали о своих условиях.
Будет очень обидно, если попавшиеся программисты окажутся нечистыми на руку, откажутся от разработки, но при этом через полгода-год выдадут свой вариант приложения, очень похожего на ваше.
Так вот чтобы избежать такой ситуации, следует подписывать с каждой компанией или программистом, претендующими на ваш проект, соглашение о неразглашении. В нём нужно чётко оговорить, какие каналы используются для обмена информацией, что вся передаваемая информация является конфиденциальной, а также может являться интеллектуальной собственностью и защищаться авторским правом.
Также следует указать на конкретные последствия разглашения конфиденциальной информации — штраф, возмещение убытков и т.д. Иногда в такое соглашение включают условия о неконкуренции, но это по желанию, т.к. в РФ такие условия пока не нашли своего понимания в судебной практике и по большей части считаются противоречащими закону, если вся суть конкуренции сводится к аналогичной деятельности или иной реализации аналогичной идеи без использования конфиденциальной информации.
В процессе передачи конфиденциальной информации следует избегать ненадёжных каналов связи, информацию в которых можно изменить уже после её отправки, или и вовсе удалить. К таким каналам связи мы относим по большей части мессенджеры, т.к. именно там очень любят общаться программисты, но именно там как раз и реализованы функции по удалению или изменению ранее отправленных сообщений. Кроме того, в мессенджерах зачастую затруднена идентификация сторон переписки. В том же Telegram можно скрыть всё — номер телефона, логин, убрать фото (аватар). И в итоге будет совершенно неясно, с кем велась переписка и имела ли она вообще какое-то отношение к сторонам соглашения о неразглашении.
Помимо этого передаваемая информация должна быть идентифицирована. Если она передаётся по электронной почте, например, то с этим никаких проблем не будет, т.к. всё сохранится на серверах оператора электронной почты или в почтовой программе на локальном компьютере. Но если же информация передаётся на материальных носителях — на флэшке или DVD-диске, то следует оформить акт приёма-передачи, в котором максимально конкретно описать, что именно передаётся, на каком носителе и в каком объёме, по возможности указав серийные номера или другие опознавательные знаки таких носителей. Если информация передаётся через ссылку на облачное хранилище, то следует эту ссылку в электронном письме сопроводить конкретным перечнем файлов, которые передаются и, желательно, их контрольной суммой, чтобы подтвердить, что это те самые файлы, которые вы имели в виду в письме.
А что нужно предусмотреть в договоре на разработку?
Про техническое задание мы уже сказали. Оно должно быть профессиональным и максимально детализированным, чтобы результат работы программистов максимально соответствовал ожиданиям заказчика. В свою очередь для разработчиков такое техническое задание тоже будет хорошим подспорьем — они будут обладать максимальной информацией о том, что именно требуется заказчику.
Любой договор следует подписывать с таким расчётом, что он рано или поздно может попасть в суд. Соответственно, по вопросу качества и полноты выполненных работ будет проводиться экспертиза, которая предполагает сравнение фактически выполненного объёма работ с тем, что предусмотрено договором и техническим заданием. Если техническое задание будет скудным, то и сравнивать эксперту будет попросту не с чем и в такой ситуации почти любой результат работы формально будет подходить к такому техническому заданию. Либо, суд попросту признает предмет договора несогласованным, т.к. из технического задания непонятно, что именно предполагалось к разработке. Это может повлечь признание договора незаключённым, что почти то же самое, что недействительным.
Помимо технического задания в договоре следует особое внимание уделить процессу сдачи-приёмки работ, тестированию результата работ и устранению выявленных ошибок. Нужно предусмотреть раздельные сроки для разных этапов процедуры приёмки, тестирования и устранения ошибок, последствия их несоблюдения и порядок обмена файлами разработанного ПО. Ключевым моментом должна быть тотальная прозрачность. Читая договор любой посторонний и незнакомый с ним наблюдатель (тот же судья) должен сразу же понять, что, куда, кому и в какой срок передаётся, что и от кого требуется и что будет, если это не будет сделано.
Рекомендуем в договоре прописывать конкретные этапы разработки ПО, сроки этапов и порядок их оплаты (аванс и постоплата), а также ответственность за их просрочку — пени, штрафы. Помимо этого стоит предусмотреть порядок несения сторонами сопутствующих разработке расходов — аренда хостинга, доменного имени, услуги СМС-центра и т.п., а также предусмотреть, что с ними будет, когда разработка закончится — оформляются ли новые хостинг и доменное имя, меняется ли СМС-центр, или всё это изначально регистрируется на заказчика. Касательно сроков очень рекомендуем прописывать разные ситуации, когда сроки могут приостанавливаться или продлеваться — задержка в тестировании, несвоевременное предоставление каких-то материалов и т.д.
Не следует забывать прописывать также ответственность за важные для сторон действия, которые они ожидают друг от друга — предоставление материалов и информации, открытие доступа к серверу и т.д. Это будет стимулировать не нарушать сроки и в принципе дисциплинировать стороны.
Обязательно следует прописывать условия о переходе исключительного права на разработанное ПО. Как правило прописывается, что исключительное право переходит к заказчику с момента подписания актов сдачи-приёмки работ, но можно этот момент отрегулировать так, как удобно (с момента полной оплаты, например). Если не планируется приобретать полностью исключительное право на ПО, то важно прописать, что исключительное право остаётся у разработчика, и указать, на каких условиях право использования ПО предоставляется заказчику.
Рекомендуем также прописывать, что в разрабатываемом ПО могут использоваться только согласованные заказчиком сторонние компоненты, чтобы избежать включения в ПО такого кода, который распространяется под жёсткими лицензиями, типа GPL, которые не позволяют закрывать код и лицензировать его на своих условиях.
Что не забыть при сдаче-приёмке работ?
Акты сдачи-приёмки работ, подписываемые сторонами по результатам выполнения работ или отдельных этапов работ, должны в себе содержать не общее описание работ (работы по программированию, например), а конкретику — перечень конкретных работ, желательно в соответствии с тем, как они описаны в техническом задании, время, затраченное на их выполнение, и их стоимость. В судебной практике существует позиция, согласно которой если из актов нельзя установить содержание и объём выполненных работ, то такие акты вообще не подтверждают выполнение работы по договору. А именно этого нам следует избегать.
Помимо описания выполненных работ следует особое внимание уделить передаче файлов ПО. Мы всегда рекомендуем в актах описывать конкретные имена передаваемых файлов с указанием их контрольных сумм, чтобы в любой момент времени можно было взять два файла у заказчика и у исполнителя, вычислить их контрольную сумму и со спокойной душой сказать, что это действительно два одинаковых файла, а раз их контрольные суммы совпадают с указанными в акте, то значит именно эти файлы были переданы по акту.
Также в договоре на разработку исключительно важно предусмотреть каналы обмена юридически значимой информацией, по аналогии с тем, как это мы рекомендовали описывать в соглашении о неразглашении. Прописывание конкретных каналов обмена информацией (избегая мессенджеры) поможет вам ускорить процессы обсуждения проекта и согласование каких-то оперативных вопросов. Если же возникает необходимость в онлайн обсуждении чего-либо, то рекомендуем организованные конф-коллы записывать и хранить их запись, чтобы потом использовать, например, в суде.
А если вдруг всё станет плохо?
Если программисты или заказчик тянут кота за хвост, нет внятной обратной связи, или постоянные кормления «завтраками», то надо иметь запасной план в виде возможности безопасно отказаться от договора и расторгнуть его в одностороннем порядке. Законом некоторые случаи такого отказа прописаны, но мы рекомендуем их детализировать в договоре и предусмотреть возможность расторгнуть его в одностороннем порядке при гораздо более широком спектре ситуаций.
Кроме того, следует указать, какие последствия повлечёт такое расторжение — возврат аванса, передача недоработанного кода и прав на него, возмещение убытков и т.д. Особенно следует обратиться внимание на судьбу авторских прав на код при расторжении договора, т.к. часто этому вопросу не уделяется достаточно внимания и мы сталкиваемся с ситуацией, когда код вроде как частично готов, но договор был расторгнут, передача кода никак не была оформлена и фактически никаких прав у горе-заказчика даже на такой недо-код попросту нет.
Мы составили далеко не полный список того, что следует учитывать при подписании договора на разработку ПО, но это довольно базовые положения, которые следует иметь в виду при заказе разработки ПО. Лучше всего доверить разработку и сопровождение подписания договора профессиональным юристам, которые знают своё дело. Также, как и написание технического задания. Пренебрежение этим правилом может причинить серьёзные убытки и превратить инвестирование в незапланированную благотворительность.
| Хотите узнать больше? Нужна юридическая помощь? Звоните и пишите нам, не откладывая!
Городской телефон: +7-495-201-68-31 Мобильный телефон: +7-960-444-68-31 Электронная почта: inbox@shewzov.ru |