Как фаундеру не потерять IT-продукт при уходе CTO: чек-лист контроля разработки

В IT-бизнесе главный актив - это не офис и не бренд.
Это код, архитектура и права на программное обеспечение.

Довольно часто мы видим такую картину:

• в бизнесе два партнёра: один отвечает за продажи, другой — за продукт. Информация между ними о продукте не передаётся, и в случае конфликта один из фаундеров по сути теряет продукт, так как фактически ничего о нём не знает (и, как правило, юридически ничего не оформлено);
• собственник нанимает CTO — звезду, даёт ему опционы и всецело доверяет. И если звезда уходит, собственник снова оказывается в сложной ситуации.

В итоге:

• CTO полностью контролирует разработку;
• код хранится «где-то»;
• документации нет;
• переход прав юридически не оформлен;
• собственник не понимает, что именно происходит в продукте.

И если CTO или ключевая команда уходит - бизнес теряет контроль над продуктом.

Ниже - чек-лист, который поможет собственнику понять, действительно ли он управляет разработкой или просто надеется на порядочность команды.

Почему компании теряют контроль над продуктом

Наиболее частые причины:

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

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

Чтобы этого не произошло, мы рекомендуем:

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

Мы разработали чек-лист, который поможет понять, не потеряли ли вы контроль над ситуацией.

Чек-лист контроля разработки ПО

Блок 1. Управление продуктом

• Команда понимает цель продукта и его целевую аудиторию?
• Вы регулярно видите рабочие демо или версии?
• Результаты спринтов фиксируются и сохраняются?
• Текущая разработка соответствует стратегии компании?

Если вы не видите прогресс - вы не управляете активом.

Блок 2. Контроль версий и качества

• У вас есть доступ к актуальной рабочей версии продукта? ,
• В компании существует процесс тестирования (QA)?
• Критичные ошибки устраняются в приоритетном порядке?
• Есть журнал изменений (change log)?

Прозрачность разработки - это защита от зависимости.

Блок 3. Архитектура, доступы и безопасность

• Весь код хранится в централизованном репозитории (GitHub, GitLab и др.)?
• Репозиторий принадлежит компании, а не физическому лицу?
• Настроен процесс code review?
• У компании есть администраторские доступы?
• Вы знаете, на каких серверах и в каком облаке размещён продукт?
• Есть резервное копирование и процедура восстановления?
• Существует инструкция по развёртыванию системы с нуля?

Блок 4. Юридическая защита и права на код

• В договорах предусмотрено отчуждение исключительных прав на ПО?
• Передача прав оформлена актами?
• Использование open-source библиотек проверено?
• С подрядчиками подписаны NDA и договоры об интеллектуальной собственности?
• Права на домены и аккаунты оформлены на компанию?

Без оформленных прав код юридически может не принадлежать бизнесу.

Блок 5. Команда и зависимость от людей

• Понятно, кто отвечает за архитектуру, тестирование и релизы?
• Нет ли «единственной точки отказа»?
• В случае увольнения ключевого разработчика продукт сможет продолжать развиваться?
• Есть план передачи знаний?

Когда необходим аудит разработки

Юридический и управленческий аудит разработки особенно актуален, если:

• вы привлекаете инвестиции;
• планируется сделка M&A или экзит;
• команда масштабируется;
• используется аутсорс-разработка;
• у вас один сильный CTO и высокая зависимость от него;
• нет прозрачности в правах на код.

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

Что делать, если есть риски

1. Проверить договоры с разработчиками.
2. Убедиться в оформлении перехода исключительных прав.
3. Перевести репозитории и серверы под контроль компании.
4. Зафиксировать архитектуру и документацию.
5. Провести аудит интеллектуальной собственности.

Контроль разработки - это не про IT.

Это про:

• защиту интеллектуальной собственности;
• инвестиционную привлекательность;
• устойчивость бизнеса;
• снижение операционных и юридических рисков.

Если фаундер не понимает, где находится код и кому принадлежат права - он не контролирует главный актив компании.

Нужен аудит?

Мы проводим комплексный аудит разработки и интеллектуальной собственности IT-компаний:

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

Если вы не уверены, что контролируете свой продукт - стоит проверить это до конфликта, а не после. Записаться на консультацию можно по ссылке: - заполнить форму