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

Комментарий специалиста Сергея Спевака, ведущего разработчика ПО компании PIP (Professional Intelligent Programming):

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

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

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

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

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

Многие из данных моментов должны найти свое отражение в договоре, который заключается с разработчиками ПО.

Конечно, писать контракты сложно, скучно и не доставляет удовольствия. Но цель оправдывает средства. Если, заказывая ПО, компания хочет получить именно то, что хочет, то без договора и другой важной документации, которая должна составляться в ходе ведения проекта и в результате сдачи программного обеспечения, ей не обойтись.

Разработка технического задания

Первым этапом работы при создании готового программного продукта может стать разработка технического задания, на основании которого, собственно, и будет разрабатываться программный продукт. Разработка технического задания не является обязательным этапом работы с конкретным программистом либо IT-компанией, а может (по мнению же некоторых специалистов) являться самостоятельным предметом договора с последними.

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

Примечание. Независимо от того, разрабатывалось ли ТЗ в рамках отдельного проекта (порой не менее длительного, чем сама разработка ПО) либо будет разрабатываться в рамках общего проекта по созданию программного продукта, в договоре с разработчиком необходимо предусмотреть порядок внесения изменений в техническое задание. В процессе создания ПО у заказчика часто появляются новые идеи, как можно улучшить программу, дабы она в максимальной степени соответствовала потребностям компании и протекающим в ней бизнес-процессам. Редко какой проект заканчивается в точном соответствии с первоначальным ТЗ. Если в результате изменений ТЗ у разработчика увеличивается объем работы, необходимо определить, как будут оцениваться эти изменения. Кроме того, скорее всего, придется изменить и сроки завершения проекта.

Комментарий специалиста:

Существует множество стандартов, которые описывают методологию создания программного обеспечения и документацию, которая должна присутствовать в проекте. Одним из таких стандартов является Microsoft Solutions Framework (MSF) от компании Microsoft.

Данная методология подразумевает несколько типов документов, каждый из которых описывает определенный этап разработки программного обеспечения. Поэтому классический термин «Техническое задание» в данной технологии разделен на несколько документов, каждый из которых наиболее полно отвечает конкретному этапу.

Тестирование

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

Большая часть работ по тестированию программы ложится на разработчика. Перед тем, как «сдать» работу заказчику, он должен проверить все ли работает так, как надо. Но и заказчик не может принять работу, не проверив ее как следует. Заказчик может проводить тестирование самостоятельно (при условии, что у него есть компетентный для этого персонал), а может привлечь независимых экспертов.

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

Комментарий специалиста:

Существует множество стандартов, которые описывают методологию создания программного обеспечения и документацию, которая должна присутствовать в проекте. Одним из таких стандартов является Microsoft Solutions Framework (MSF) от компании Microsoft.

Данная методология подразумевает несколько типов документов, каждый из которых описывает определенный этап разработки программного обеспечения. Поэтому классический термин «Техническое задание» в данной технологии разделен на несколько документов, каждый из которых наиболее полно отвечает конкретному этапу.

Гарантии

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

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

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

Комментарий специалиста:

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

Развертывание и обучение

Готовую программу необходимо установить (развернуть) на оборудование заказчика. Как указано выше, еще в самом начале работы в договоре (или спецификации) нужно указать конфигурацию компьютеров заказчика и установленную у него операционную систему. Разработчик создает программу с учетом этих данных и, обычно, его задача — установить программу на оборудование заказчика.

К вопросу об обучении. При относительно небольших проектах обучение персонала заказчика может происходить на месте при установке программы. Но если проект довольно сложный, со многими функциями, или, если у заказчика большой штат персонала, желательно наличие инструкции пользователя (user manual). В договоре в таком случае нужно указать, что разработчик обязан подготовить и передать заказчику также и инструкцию.

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

Кто собственник?

Программное обеспечение является авторской программой и защищается законами об авторских правах как художественное произведение.

С момента, когда программный код записан в память компьютера или на бумагу, возникают авторские права на него. В тот же момент кто-то становится владельцем этих прав. Кто это будет — разработчик или заказчик? Все зависит от того, что записано в договоре. Факт, что клиент является заказчиком программы и платит за нее деньги, не означает, что ему принадлежат и авторские права.

Примечание. Авторские права (как явствует из их названия) — это права, принадлежащие автору произведения, то есть возможность осуществлять определенные действия с этим произведением.

Авторские права делятся на две группы: имущественные и личные неимущественные. Имущественные права одним словом можно охарактеризовать как право на использование произведения. Виды использования могут быть самыми различными: опубликование, размещение в Интернете и так далее. Основным критерием здесь является стремление к получению имущественной выгоды от использования произведения. В соответствии со статьей 14 Закона Азербайджанской Республики «Об авторском праве и смежных правах» личные неимущественные права связаны с личностью автора и включают в себя: право авторства — право признаваться автором произведения; право на имя — право подписывать или разрешать подписывать произведение своим именем, псевдонимом или использовать его без обозначения имени (то есть анонимно); право на защиту репутации — право на защиту произведения, включая его название, от всякого искажения или иного посягательства, способного нанести ущерб чести и достоинству автора. Данное право подразумевает обязанность лиц, вносящих какие-либо изменения в произведение, согласовывать все изменения с автором в его варианте произведения. Несогласованные изменения являются нарушением данного права. Право на обнародование — это право делать произведение доступным широкому кругу лиц. Обнародование может происходить в любой форме. При этом наемный работник не вправе препятствовать обнародованию служебного произведения его работодателем.

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

Далее в статье под «авторскими правами» понимаются именно имущественные права автора-разработчика ПО.

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

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

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

Специфика работы программиста заключается в том, что она нацелена не на процесс (он не сидит и тупо программирует что-то целый день), а на результат (конечный программный продукт). А этот результат, точнее его видение (описание) содержится в указании работодателя. Работодатель так или иначе формулирует, описывает программисту то, что хочет от него получить. Нет задания — нет продукта.

Здесь нужно отметить, что авторские права не являются чем-то единым и неделимым. Авторские права состоят из множества различных прав — права преобразовывать код программы, изготовлять, распространять и сдавать в аренду копии программы и других прав. И каждое такое право может передаваться отдельно. Более того, авторские права могут переданы эксклюзивно и неэксклюзивно.

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

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

Еще существенный момент — в своей работе программист часто использует одни и те же повторяющиеся в разных программах элементы. Обычно, это стандартный код (также именуемый как «исходный код», «исходник») для выполнения одних и тех же функций. Эти наработки экономят программисту много времени, так как их не надо каждый раз создавать заново. Но если по договору заказчик получает эксклюзивные авторские права на программу, он будет владеть и правами на эти наработки. А это значит, что программист в дальнейшем не сможет их использовать.

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

Лидия Спевак

ИНФО

В соответствии со статьей 4 Закона АР «Об авторском праве и смежных правах» — «Основные понятия», компьютерная программа (программа для ЭВМ) — совокупность инструкций в виде слов, кодов, схем и ином виде, которая будучи выражена в машиночитаемой форме, приводит компьютер в действие для достижения определенной цели или результата. Компьютерная программа включает также подготовительные материалы, полученные в ходе ее разработки, и порождаемые ею аудио-визуальные отображения.

Статья 6 закона гласит: «Компьютерные программы охраняются как художественные произведения. Охрана компьютерных программ распространяется на все виды программ, в том числе операционные системы, которые могут быть выражены на любом языке и в любой форме, включая исходный текст и объектный код».

Статья 13 Закона АР «Об авторском праве и смежных правах» — «Авторское право на произведение, созданное в порядке выполнения служебных обязанностей или служебного задания работодателя»:

1. Авторское право (то есть «личные неимущественные права» комментарий автора) на произведение, созданное в порядке выполнения служебных обязанностей или служебного задания работодателя (служебное произведение), принадлежит автору служебного произведения.

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

3. При использовании служебного произведения в какой-либо форме (повторное издание служебного произведения, перевод на другой язык, переработка и так далее) автор служебного произведения вправе получать гонорар (если это предусмотрено договором между автором и работодателем — комментарий автора). Размер авторского вознаграждения за каждый вид использования служебного произведения и порядок его выплаты устанавливаются договором между автором и работодателем.

4. В случае безосновательного неиспользования работодателем (заказчиком) служебного произведения в течение 3 лет, исключительные права на использование произведения переходят к автору. Данный срок может быть сокращен по соглашению сторон.

5. Работодатель вправе при любом использовании служебного произведения указывать свое наименование либо требовать такого указания.

6. На создание в порядке выполнения служебных обязанностей или служебного задания работодателя коллективных произведений (статья 10 настоящего закона) положения настоящей статьи не распространяются.