Как открыть компанию по разработке программного обеспечения

Обновлено: 30.06.2024

Лучше всего рассматривать структуру команды в компаниях от 10 человек. В ней, как правило, также есть и второстепенные функции (бухгалтерия, юристы, клининг и т. д.). Их чаще всего отдают на аутсорс. Кроме того, в компании должны быть продавцы, маркетологи и HR.

На начальном этапе директор может справляться с частью функций сам (продавать, продвигать услуги, искать и нанимать сотрудников). Такая ситуация характерна, прежде всего, для стартапов, где команда может брать на себя все функции сразу. Так как это недавно запущенный проект, и его цель – окупить инвестиции и получить прибыль в максимально короткие сроки, директор может быть и продавцом, и разработчиком, и курьером. Однако чаще всего там уже есть деление на сферы ответственности. Например, в команде LICA (разрабатывают ИТ-продукт по подбору станков и тканей для текстильной промышленности), которую я курирую на программе Moove, кто-то взял на себя роль CEO, кто-то — CTO, а кто-то занялся продажами и общением с клиентами.

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

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

Этапы создания ПО

  • создание концепции/ТЗ;
  • проработка архитектуры программного обеспечения;
  • создание технической документации;
  • реализация проекта;
  • тестирование и приемка;
  • внедрение;
  • техническая поддержка.

На каждом этапе должен быть свой отдел со своими задачами:

  • проектный офис;
  • отдел проектирования программного обеспечения;
  • отдел тестирования и документирования;
  • отдел разработки;
  • отдел внедрения и сопровождения.

Основной состав группы — это специалисты, полностью занятые в создании нового программного продукта:

  • менеджеры проекта;
  • программисты;
  • тестировщики;
  • разработчики документации;
  • инженерные психологи;
  • технологи по разработке ПО.

Вспомогательная группа — это специалисты, не занимающиеся созданием программ, но, тем не менее, играющие важную роль в реализации проекта:

  • группа менеджмента и маркетинга продукта;
  • специалисты по технической поддержке ПО;
  • администраторы бета-тестирования.

По сути в любой команде, занимающейся разработкой продукта, можно выделить следующие роли в команде:

Developer

Занимается производством программных продуктов.

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

1. По разделению ответственности:

  • Backend developer — разработчик программно-аппаратной части комплексного ПО;
  • Frontend developer — разработчик клиентской стороны пользовательского интерфейса к программно-аппаратной части.

2. По платформам:

  • Web;
  • Mobile;
  • Server-Side;
  • и так далее.

User Experience Designer (UX)

Занимается производством карт пользовательского опыта.

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

Эту роль ошибочно путают, а порою и совмещают с ролью UI Designer. UX и UI Designer отличаются не только предметной областью, но и спецификой мышления. UX Designer больше про аналитику и систематизацию, чем про эргономику и эстетику.

User Interface Designer (UI)

Занимается производством графической составляющей интерфейсов.

Этот человек разрабатывает визуальную часть пользовательского интерфейса. Основными целями работы UI дизайнера являются: интуитивность восприятия, простота, юзабилити и эстетика интерфейса ПО.

Quality Assurance (QA)

Занимается проверкой результата.

QA занимается тестированием всего, как бы странно это ни звучало.

Системный подход специалиста QA позволяет тестировать как программный код, так и продуманность карт пользовательского опыта.

Human Resource (HR)

Занимается первичным подбором кандидатов.

Он обеспечивает прозрачное прохождение всех этапов собеседований при трудоустройстве.

Team Leader

Отвечает за работу группы специалистов.

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

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

Tech Leader

Отвечает за грамотный аргументированный выбор технических решений:

  1. Ответственный выбор стороннего ПО для проекта;
  2. Рекомендация по выбору конкретного алгоритма или архитектурного решения при производстве ПО;
  3. Определение технических особенностей в процессах производства.

Scrum Master

Scrum, Agile, KanBan, гибкие методологии, и прочие теоретические знания, которые крайне бесполезны без практики и опыта.

Scrum Master — это специалист, который помогает команде применять методологию Scrum правильно, объясняет правила методологии, контролирует их выполнение. Сейчас к командам разработки стали прикреплять роль Scram Master. Он отвечает за грамотное применение той или иной гибкой методологии (бывает, что даже той, которая не касается Scrum вообще).

Project Manager (PjM)

Отвечает за старт, ведение и сдачу проектных работ.

Эта роль классического управленца процессами. Работа над проектом начинается с Project Manager’а, ведётся (ставит задачи), контролируется (контроль качества и эффективности) и сдаётся тоже им. В большинстве компаний Project Manager управляет проектным фондом.

Архитектор (Architect)

Ключевая обязанность архитектора — проектирование архитектуры ПО, т. е. принятие ключевых проектных решений относительно внутреннего устройства программной системы и её технических интерфейсов.

Бизнес Аналитик (Business Analyst)

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

Системный аналитик (System Analyst)

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

Технический писатель (Technical writer)

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

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

декан факультета веб-разработки в GeekUniversity

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

Один из самых первых и распространённых до сих пор способов заработка — реклама. Плюс такого способа очевиден — достаточно добавить рекламный блок на сайт, а всё остальное сделает сторонний сервис рекламы (AdWords, Яндекс.Директ и многие другие). На этом плюсы заканчиваются и начинаются минусы. В дизайне необходимо оставлять место для рекламы, а это не всегда уместно. Она часто раздражает ваших пользователей, и они её вполне справедливо блокируют. А самое главное: нельзя полностью полагаться на сторонние сервисы рекламы, там вполне может проскочить непристойный, непозволительный для ваших пользователей контент. Есть и более продвинутый способ — договориться напрямую с рекламодателем. В этом случае вы можете более качественно интегрировать рекламу в ваш сервис, например написать статью со встроенной рекламой, если, конечно, в вашем сервисе есть такая возможность.

руководитель направления маркетинга в студии мобильной разработки Hands App

Общие тенденции развития российского рынка программного обеспечения

В общем объёме российского IT-рынка сегмент разработки программного обеспечения для решения коммерческих задач в компаниях и учреждениях традиционно занимает немалую долю.

Анализируя эту сферу, можно отметить, что пик продаж (в частном и общегосударственном секторе) пришёлся на 2013 год, когда общая выручка составила рекордные пять миллиардов долларов. С 2014 года в связи с резким падением цен на нефть и обострением отношений между Россией и Западом наблюдается резкое падение прибыли (по подсчётам аналитиков, в совокупности рынок продаж коммерческого ПО просел на 40 % в долларовом выражении).

И только с 2017 года наблюдается тенденция постепенного восстановления позиций — доходы российских производителей лицензионного программного обеспечения подрастают на 11 % ежегодно (с учётом заключения контрактов с западными партнёрами). Последние данные за 2018 год показывают: сегодня объём рынка продаж приближается к двум миллиардам долларов в год без учёта теневой сферы контрафакта.

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

Кто выводит на рынок новое ПО и как на этом заработать

Как показывает практика, к наиболее актуальным способам создания ПО относится:

  1. Разработка системной программной среды и вывод на рынок в качестве отдельного, уникального продукта в рамках стартапа.
  2. Создание специализированного программного обеспечения в виде индивидуального корпоративного продукта с дальнейшим расширением функциональности для вывода на широкий рынок.

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

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

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

Внутрикорпоративная разработка и вывод нового продукта на рынок в наших реалиях более актуальны хотя бы потому, что у работающей компании помимо финансовой подушки есть наработанная команда IT-специалистов, проверенные способы маркетинга, да и лояльные к бренду клиенты/партнёры.

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

Актуальные способы монетизации для ПО

Прежде чем говорить о способах заработка на программном продукте, следует отметить, что разработчики ориентируются на три основные платформы:

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

Различаются и варианты монетизации для веба и мобайла.

Так, для web-продуктов характерны следующие типы монетизации:

Для мобайла характерны следующие модели монетизации:

Анализируя все возможности монетизации для программного обеспечения, можно с уверенностью сказать, что заработать даже на свежем, только выходящем на рынок продукте можно. Сам продукт при этом должен быть качественным, востребованным, решающим реальные клиентские потребности. Хорошее, уникальное ПО само по себе позволяет подобрать такие варианты, которые будут максимально гармонировать с функциональностью самой программы, с её маркетинговыми возможностями и ожиданиями целевой аудитории. Ведь в конечном итоге не реклама определяет успех, а продукт — плохой и сырой пользоваться спросом точно не будет.

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

Регламент разработки и внедрения программных продуктов

1. Общие положения

1.2. Основными задачами настоящего регламента в рамках регулирования деятельности по разработке и внедрению программных продуктов являются:

– определение сферы применения;

– описание системы, включая процессы, участников и схему их взаимодействия;

– определение требований к процедурам деятельности;

– разграничение прав и обязанностей участников деятельности;

– закрепление ответственности участников деятельности.

1.3.1. АИС – Информационная система, созданная для решения задач автоматизации деятельности и бизнес-процессов Предприятия, в рамках которой осуществляется внедрение Программного продукта.

1.3.2. Программный продукт – предмет разработки, который может представлять собой часть АИС или целостную АИС.

1.3.3. Проект – задача на разработку и внедрение Программного продукта, регулируемая Техническим заданием.

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

– служебные записки – основания разработки (изменения) Проекта;

– план внедрения Проекта;

– протоколы тестирования Программного продукта;

– акт внедрения Программного продукта;

– иные документы, регулирующие процесс внедрения конкретного проекта.

1.3.5. Техническое задание – основной документ Проекта, содержащий описание задачи, цель и способы ее внедрения, а также требования к Программному продукту и АИС.

1.4. Деятельность Предприятия по разработке и внедрению программных продуктов регулируется:

– утвержденными Техническими заданиями;

– другими нормативными документами Предприятия.

1.5. Участниками деятельности по разработке и внедрению программных продуктов являются:

– лица, заинтересованные в создании (изменении) функционала АИС;

– руководитель деятельности по разработке и внедрению программных продуктов;

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

1.5.2. Руководитель проекта назначается руководителем деятельности по разработке и внедрению программных продуктов и координирует в рамках настоящего регламента деятельность участников внедрения соответствующего Программного продукта.

1.5.3. Администратор АИС – лицо, ответственное за функционирование действующей АИС. Администратор АИС единолично несет ответственность за АИС и в рамках настоящего регламента выполняет следующие задачи:

– при необходимости обеспечивает руководителя проекта и исполнителей работ копиями АИС для разработки Программного продукта;

– интегрирует готовый Программный продукт в АИС.

1.6. Разработка и внедрение программных продуктов включает следующие процедуры:

1) постановка задачи и запуск Проекта;

2) написание и утверждение Технического задания;

3) выполнение работ по проектированию Программного продукта;

4) окончательное тестирование и приемка Программного продукта;

5) внедрение Программного продукта в АИС.

2. Постановка задачи и запуск проекта

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

– АИС, которую необходимо создать (модифицировать);

– деятельность (процессы), подлежащие автоматизации;

– требования к функционалу АИС;

– срочность реализации с указанием обоснования реализации Проекта в срочном порядке;

– другую информацию, способную повлиять на разрабатываемый Программный продукт или АИС.

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

2.2. Сферой действия настоящего регламента является автоматизация следующих задач:

– проекты на разработку и внедрение новых АИС;

– проекты на разработку и внедрение Программных продуктов, существенно изменяющих (дополняющих) функционал действующих АИС.

Разработка отчетов и других объектов, не затрагивающих базу данных АИС, а также работы по разграничению доступа к объектам существующей АИС не входят в сферу действия настоящего регламента, если не являются частью более крупного проекта.

2.3. Основаниями для признания существенными изменений (дополнений) функционала действующих АИС являются следующие условия:

– важность Проекта (о потребностях в реализации Проекта в письменной форме заявило несколько лиц, заинтересованные в создании (изменении) функционала АИС, из различных подразделений Предприятия);

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

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

2.5. Если Проект не попадает в сферу применения настоящего регламента, то принятие решений о реализации Проекта настоящим регламентом не регулируется.

2.6. План внедрения проекта должен содержать, как минимум, следующую информацию:

– ответственных за выполнение работ;

– при необходимости исполнителей работ;

– оценки объема работ в часах;

– нормативные сроки завершения работ.

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

2.7. Руководитель проекта выполняет следующие функции:

– анализ возможностей и способов внедрения Проекта;

– организация процессов, необходимых для внедрения Проекта;

– координация действий участников внедрения Проекта;

– проведение консультаций с участниками внедрения для решения спорных вопросов;

– назначение исполнителей работ по Проекту;

– тестирование Программного продукта.

3. Техническое задание

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

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

3.3. Техническое задание должно содержать в себе, как минимум, следующую информацию:

– наименование и краткую характеристику АИС;

– назначение и функции предмета разработки;

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

– требования к АИС, в т.ч. технические требования (аппаратные и системные требования и т.п.), условия работы (требования к квалификации пользователей, порядок обслуживания и т.п.) и др.;

– требования к информационной и программной совместимости;

– требования к защите информации отдельно для АИС и предмета разработки;

– требования к первичному заполнению информационной базы (по необходимости);

– порядок выполнения работ по Проекту с указанием содержания работ и оценки объема работ (в часах);

– особые требования к проведению приемки работ (по необходимости);

– условия взаимодействия с другими проектами (по необходимости);

– другая необходимая информация.

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

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

3.6. Требования к функциональным характеристикам предмета разработки (Программного продукта) должны содержать, как минимум, следующую информацию:

– перечень автоматизируемых операций;

– создаваемые (модифицируемые) объекты АИС, их состав и правила функционирования;

– методология автоматизации для каждой операции и создаваемого (модифицируемого) объекта АИС;

– принципы организации работы пользователей в АИС, связанные с внедрением Программного продукта.

3.7. Требования к надежности предмета разработки (Программного продукта) должны содержать информацию о принципах организации контроля и об автоматизированных методах предотвращения, выявления и устранения ошибок в АИС, закладываемые в предмет разработки (Программный продукт).

3.8. Требования к справочной информации должны содержать принципы организации справки к предмету разработки (Программному продукту), в т.ч.:

– виды планируемых пользовательских инструкций (руководств);

– планирование встроенной справки для объектов АИС, создаваемых (модифицируемых) предметом разработки (Программным продуктом);

– планирование встроенной справки к АИС в целом.

3.9. Требования к информационной и программной совместимости должны содержать, как минимум, следующую информацию:

– поддерживаемые форматы загрузки и выгрузки данных (требования к выгружаемым и загружаемым файлам);

– правила проведения загрузки и выгрузки данных (поля, отбор, группировка, сортировка таблиц при загрузке и выгрузке);

– единицы измерения, методики расчета числовых показателей и др.

3.10. Требования к защите информации включают следующее:

– правила ограничения доступа к данным для пользователей АИС;

– использование средств криптографической защиты;

– использование защищенных каналов связи для АИС и др.

3.11. Требования к первичному заполнению информационной базы должны содержать указания на информацию, которая подлежат заполнению в автоматизированном режиме до интеграции предмета разработки в АИС. Если первичное заполнение информационной базы проводится на основании нормативных документов, то Техническое задание должно содержать ссылки на такие документы, в остальных случаях информация для ввода в АИС должна прилагаться к Техническому заданию.

3.12. Техническое задание подписывают следующие лица:

– разработчик технического задания (автор);

– руководитель проекта (требуется согласование, если руководитель проекта не является разработчиком технического задания);

– исполнитель (требуется ознакомление, если исполнитель не является руководителем проекта или разработчиком технического задания);

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

4. Порядок выполнения работ и внедрения программных продуктов

4.1. Выполнение работ в рамках настоящего регламента осуществляется назначенными в плане внедрения Проекта исполнителями в оговоренные сроки выполнения. Если исполнитель считает невозможным выполнение работ в оговоренные сроки, то он информирует об этом руководителя проекта, который рассматривает возможности изменения сроков выполнения работ.

4.2. В процессе выполнения работ по разработке Программного продукта необходимо соблюдать требования к разработке и руководствоваться следующими принципами:

– эффективности (экономия рабочего времени пользователей в результате выполнения работ должна существенно превосходить затраты времени разработчика);

– оптимальности (информация в информационной базе должна храниться и структурироваться таким образом, чтобы минимизировать вычислительные ресурсы, требуемые для ее использования);

– быстродействия (программный код процедур и функций на встроенном языке, а также код на языке запросов, должны строиться таким образом, чтобы минимизировать в первую очередь затраты рабочего времени пользователей АИС, во вторую очередь время выполнения автоматизированных операций, в третью очередь сетевой трафик, в четвертую очередь потребление оперативной памяти, в пятую очередь потребление памяти жесткого диска);

– исполнительности (нарушения утвержденного Технического задания допускаются в порядке исключения, если приводят к улучшению характеристик предмета разработки (Программного продукта) относительно запланированных);

– эргономичности (пользовательский интерфейс и диалоговые формы должны быть интуитивно понятными и удобными для пользователя).

4.3. Исполнитель работ по техническому заданию готовит справочную информацию к предмету разработки (Программному продукту), если этого требует Техническое задание. Справочная информация должна включать следующее:

– описание предмета разработки (Программного продукта) и всех его объектов;

– инструкции (руководства) пользователей АИС по эксплуатации предмета разработки (Программного продукта);

– историю изменений Программного продукта от версии к версии.

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

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

4.5. Тестирование, предшествующее приемке Программного продукта, проводит руководитель проекта, который проверяет:

– выполнение требований технических заданий;

– соблюдение общих принципов и требований к разработке, вытекающих из настоящего регламента;

– отсутствие ошибок в работе Программного продукта.

4.6. По итогам проведения тестирования руководитель проекта принимает одно из следующих решений:

– Программный продукт соответствует предъявляемым требованиям и готов к внедрению в АИС (в этом случае следующей процедурой является приемка Программного продукта);

– Программный продукт соответствует предъявляемым требованиям, но существуют основания для его изменения с целью улучшения характеристик (в этом случае определяется перечень необходимых изменений и осуществляется доработка Программного продукта);

– Программный продукт не соответствует предъявляемым требованиям и возвращается на доработку.

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

– заключение о соответствии Программного продукта предъявляемым требованиям;

– наличие необходимости в доработке Программного продукта;

– перечень необходимых исправлений с указанием нарушенных требований (при наличии нарушений);

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

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

4.9. В приемную комиссию могут включаться следующие лица:

– руководитель деятельности по разработке и внедрению программных продуктов;

– лица, заинтересованные во внедрении Программного продукта;

– представители руководства Предприятия.

Руководитель проекта и исполнители работ по проекту в состав приемной комиссии включаться не могут.

4.10. Приемная комиссия определяет пригодность Программного продукта для внедрения в АИС и соответствие функционала Программного продукта предъявляемым требованиям. По результатам приемки приемная комиссия принимает одно из следующих решений:

– Программный продукт допускается к использованию;

– Программный продукт не допускается к использованию.

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

4.12. Интеграция Программного продукта в работающую АИС до завершения процедуры приемки и составления акта внедрения не допускается. По окончании процедуры приемки внедрение Программного продукта в АИС осуществляет администратор АИС.

4.13. Документация проекта сшивается и сдается на ответственное хранение в отдел информационных технологий аппарата управления Предприятия. Хранение документации проекта осуществляется до завершения использования Программного продукта в деятельности Предприятия.


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

Таким образом, программы регистрируют двумя способами:

  • Депонирование программы для ЭВМ или базы данных;
  • Получение патента на концепцию программы.

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

Патент на разработку — защита концепции программы

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

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

Чтобы запатентовать программу для ЭВМ, она должна отвечать правилам патентования:

  • новизна — до подачи заявления вы не должны публиковать программу для ЭВМ или базу данных нигде;
  • применимость — решение должно быть рабочим, зарегистрировать нерабочий код или идею не получится;
  • изобретательность — если ваше ПО не вносит ничего нового в существующий уровень техники или явно следует из существующих разработок, патент не дадут.

Самостоятельно получить патент на программу для ЭВМ или базу данных практически невозможно. Заявители не знают, по каким критериям Роспатент оценивает новизну, по каким базам проверяет. Что нужно написать в заявке, чтобы специалисты по интеллектуальной собственности поняли, как ваше ПО работает и с чем его нужно сравнивать.

Если Роспатенту недостаточно информации для проведения поиска или в базах находятся похожие разработки — присылают отказ.

Если Роспатент прислал отказ — госпошлину в размере от 10 тыс. руб. до 15 тыс. руб. не вернут, а повторно подать заявку на патент нельзя. Нарушен критерий новизны. Повторной заявке противопоставят вашу же первую. Доказать возможность регистрации при повторной подаче заявки крайне сложно.

Чтобы получить патент — лучше сразу обратиться к патентным поверенным. Это специалисты, которые не менее 4 лет работали с интеллектуальной собственностью, потом сдали квалификационный экзамен в Роспатенте. Патентные поверенные знают:

  • по каким базам данных в Роспатенте ищут противопоставления;
  • какие критерии учитывают;
  • что написать в заявке, чтобы специалисты Роспатента смогли провести поиск;
  • как обосновать новизну программы для ЭВМ или БД, если в ходе поиска обнаружены похожие разработки.

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

Если вы изобрели принципиально новое программное обеспечение, приложение для смартфона и не хотите, чтобы ваше решение переписали по-другому и выдали за своё — поможет только патент. Когда ваш патент пройдет регистрацию вы сможете:

Как зарегистрировать программу в реестре отечественного ПО Минкомсвязи

Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации поддерживает разработчиков из России. Чтобы отечественные разработчики имели преимущества перед зарубежными, их программы для ЭВМ и базы данных вносят в реестр Минцифры. Это дает возможность:

  • участвовать в тендерах на поставку ПО для компаний с госучастием и получать преимущества в получении тендера: при равных данных проект отдадут поставщику ПО, который есть в реестре;
  • не платить 20% НДС с продаж своего ПО;
  • участвовать в грантах Минкомсвязи и получать государственное финансирование разработок.

Попасть в реестр могут не все желающие. Условия попадания в реестр:

  • минимум 70% собственников должны иметь российское гражданство;
  • продукт должен быть коробочный, то есть купить его можно по одной ссылке, а не собирать частями;
  • запрещено использовать БД типа Mysql и подобные компоненты.

Большинство SaaS решений не смогут попасть в базу минкомсвязи.

Если компания попала в реестр Минкомсвязи — свидетельства не будет. ПО просто вносится в реестр и по запросу будет видно, что регистрация прошла успешно. С момента регистрации собственники ПО могут пользоваться всеми преимуществами: участвовать в тендерах и грантах, не платить НДС.

Подать заявку на внесение в реестр Минцифры может и физическое лицо, без оформления статуса предпринимателя. Чтобы вести коммерческую деятельность с помощью своего ПО и не платить НДС с продаж достаточно оформиться как самозанятому.

Как подать заявку в Минкомсвязи

Основная сложность при подаче заявки в том, чтобы с первого раза всё правильно оформить. Заявку можно подавать только раз в год. Если в первый раз отказали — попытаться еще раз можно будет только через год, а пока платить НДС.

Самый простой способ — подать заявку через портал Госуслуги. Для этого нужно:

  • иметь подтвержденный аккаунт на Госуслугах, учетную запись правообладателя в ЕСИА;
  • квалификационный сертификат электронной подписи;
  • определить коды ОКВЭД и нужные вам классы программного обеспечения;
  • представить документы и сведения, необходимые для регистрации.

Список документов большой, с ним можно ознакомиться на сайте Минкомсвязи.

Чтобы правильно оформить заявку, лучше обратиться к патентным поверенным, которые работают с программами для ЭВМ и БД. Как правило, эти специалисты имеют опыт и внесения ПО в базы Минкомсвязи. Патентные поверенные правильно оформят заявку и соберут все документы, чтобы ваше ПО попало в реестр и компания не платила 20% НДС.

Как защитить разработку компании от автора этой разработки

При разработке программного обеспечения важно учитывать юридические тонкости 4 части ГК РФ. Например, что автор произведения, то есть программист, который писал код и дизайнер, который рисовал интерфейс, навсегда останутся авторами. Заказчик не имеет права говорить, что он самостоятельно создал ПО, если это не так. А автор, если другого не прописано в договоре, может распоряжаться своим произведением как ему угодно.

По закону авторство неотчуждаемо, но можно заключить договор авторского заказа и ограничить права автора по этому договору. Если разработка, которую ведет автор, является коммерческой тайной компании — нужно заключать договор о коммерческой тайне.

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

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

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

Защита от недобросовестной конкуренции

Если вы зарегистрировали программу для ЭВМ в Роспатенте и конкуренты полностью скопировали ваш код — можно требовать с них компенсацию до 5 млн. руб. Если они используют код или концепцию вашего ПО, на который получен патент, помимо пяти миллионов можно потребовать:

  • сумму упущенной выгоды в двойном размере: если пираты перепродают или раздают ваше ПО, можно требовать в суде двойную стоимость по вашему прайсу с каждого проданного ими экземпляра. Неважно, почем они продавали ваш продукт или раздавали просто так — сколько стоит у вас, столько и вернут х2;
  • возврат суммы контрафактных продаж в двойном размере: если на основе вашего ПО конкуренты создали свою программу для ЭВМ или базу данных и вы смогли доказать это в суде, можете требовать, чтобы они возместили вам в двойном размере стоимость всех проданных копий их ПО

Ноу-хау для программистов!

Если вы хотите зарегистрировать свое ПО, но боитесь раскрыть код даже специалистам Роспатента или патентным поверенным — можно создать объект и зарегистрировать, не раскрывая его код.

Такой объект вы сможете поставить на баланс, передавать по лицензии, продавать.

Регистрируем программу для ЭВМ или базу данных

Способы регистрации программы для ЭВМ и баз данных:

Патент на изобретение. Может защитить не только код, но и концепцию вашего ПО. Если вы получите патент, никто не сможет скопировать вашу идею, переписать или модифицировать код и выдать разработку за свою. Получение патента длится 10-18 месяцев, самостоятельно получить положительное решение практически невозможно, лучше обратиться к патентным поверенным.

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

Когда вы зарегистрировали программу для ЭВМ, можно продавать свою разработку, давать к ней доступ, выпускать продукты на основе своего кода.

Ирина Резникова

Читайте также: