Как защитить проект от воровства программистом?

Question

[Qzaur]

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

Answer 1

[Max Kostikov]

Из сегодняшнего поста "Модульбанк" на FB.
Предприниматель сделал приложение, продажи пошли – и тут вдруг разработчики решили, что их обделили и уходят, забрав исходный код. Универсального способа решить проблему нет, но подготовиться к неожиданностям стоит.
Про правильные договоры
– Если разрабатывает ПО ваши сотрудники, убедитесь, что трудовые договоры обязательно (!) предусматривают создание ими так называемых «служебных произведений». Иначе компания остается без прав на созданный программный код.
– Если ПО разрабатывается на стороне, включите в договор условия об исключительных правах вашей компании. После согласования или получения оплаты вы будете законным владельцем ПО. Иначе подрядчик сможет присвоить себе вашу разработку.
Важно: примеры пунктов для договора смотрите здесь — artgorbunov.ru/bb/soviet/20141206
Режим коммерческой тайны
Открытие сведений коммерческой тайны (КТ) карается Уголовным кодексом, можно даже сесть в тюрьму. Пользуйтесь этим. Для этого понадобится:
– составить список информации, составляющей КТ;
– ограничить доступ к КТ;
– вести учет лиц, получивших доступ к КТ;
– подписывать соглашение о неразглашении (NDA) c сотрудниками и контрагентами;
– ставить гриф «коммерческая тайна» на документах.
Важно: делайте бэкапы для себя — если унесут все исходные коды, то у вас будет база для восстановления.
Про кадры
Юрист и правильные документы – залог успеха. Но даже они не спасают на 100%. Честные сотрудники, которые правильно замотивированы и довольны работой, гораздо реже нарушают правила.
Желаем найти именно таких!

Comments

[Qzaur]

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

[Котик Антон]

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

Что помешает подрядчику, получив ТЗ, послать заказчика, не подписывая никаких договоров, а проект сделать для себя. Уж не думаете ли вы, что кто-то будет подписывать договор, не зная, что предстоит разрабатывать?

[Max Kostikov]

27cm: ну панацеи нет. Вот Цукерберг то напарил людей в своё время тоже...

[spotifi]

27cm:
Вы переоценивайте важность голой идеи.
Любой серьезный проект - это куча усилий. Главное - реализация.
А интересных идей вокруг нас порхает стаями.

1. Нужно сначала реализовать за свой счет.
2. Потом раскрутить.

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

[Артем Воронов]

spotifi: в точку. Более того, "гениальная" идея - это галлюцинация, которую надо проверить 1000 раз прежде чем начать что-то разрабатывать.

Answer 2

[Артем Воронов]

Все просто - если ваш программист может сделать этот бизнес без вас, значит любой другой тоже это может сделать\скопировать\разреверсить. От копирования вы уже ничем себя не защитите, можете даже не строить иллюзий - меняется название софта, немного правится интерфейс и, вуаля, другой проект к которому не подкапаешься. Если вас проект легко скопировать, подумайте, а стоит ли вообще им заниматься?

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

Answer 3

[spotifi]

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

Comments

[Артем Воронов]

Надо учитывать, что пункт №1 приводит к излишней сложности в разработке и поддержке. Это ведет к излишним затратам и тормозит сроки релиза. На этапе MVP вообще может загубить проект.

[spotifi]

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

[Артем Воронов]

spotifi: работал над крупных проектами в командах до 6 разработчиков с разным уровнем разделения:
1. Проект под управлением параноика. Весь код разделен на отдельные куски. Исполнители друг друга на знают, получают задания от параноика и ему же сдают их. Доверенное лицо параноика собирается проект из результатов остальных исполнителей. Лютый ад, работать так крайне тяжело, муторно и долго.
2. Каждый исполнитель пилит свой кусок: бэкэнд, мобильное приложение или сайт. Если речь идет о постояннянных сотрудниках, то периодически кто-то будет простаивать в ожидании коллег. ПМ придется долго и муторно разруливать граничные ситуации, когда непонятно где же баг: на бэке или на фронте.
3. Все работают над всеми частами проекта. Разделение задач между исполнителями идет по требованиям\фичам. Тут не получится спихнуть баг на другого - каждый видит и знает код всего проекта. Полкоманды скосил грипп? не проблема, критичные требования будут сделаны в срок, некритичные отложены. Баг в бэкэнде, а человек писавший код в отпуске? не беда, другой член команды поправит его. Закончил со всеми задачами? можно помочь коллегам. Особенно хорошо это работает, когда все части проекта делают на одном стеке. Идеально для Java и .Net.

[spotifi]

Артем Воронов: Есть еще микросервисная архитектура. Дробится на небольшие куски легко и ествественно программируется.

[olezhka2016]

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

[spotifi]

olezhka2016:
Любой стоящий проект - это куча усилий не только программиста.
Голая программа - ничего не дает.