Подключение сторонних разработчиков в стартап?

Question

[kalnin_yuri]

Собираемся подключать фрилансеров к проекту, не совсем хочется отдавать все исходники проекта разработчикам, понятно, что можно заключить договор и прочее, но это не особо обнадёживает. Что мешает человеку поднять проект и пользоваться? Ничего. Первое, что пришло в голову, вынести ядро сервиса в пакет композера, покрыть код событиями которые будут использовать разрабы, а ядро разрабатывать абфусцировать как-то.

Как это вообще по уму делают?

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

Comments

[jazzus]

По уму не работать с фрилансом) лучше 1го в офис чем 10 фрилансеров хз где и как

[Иван Шумов]

jazzus, спорное утверждение

[jazzus]

Иван Шумов, стартапы лучше делать в небольшой команде единомышленников без напряга и контроля. Чтобы атмосфера была соответстсвующая. А шаблонный интернет-магазин и визитку - да можно заказать на фриленсе ну это какбы мое мнение я не настаиваю)

[Иван Шумов]

jazzus, стартап стартап рознь)

[Константин Нагибович]

Что мешает человеку поднять проект и пользоваться?

Вы уверены, что ваш проект будет нужен фрилансеру?

Answer 1

[juxifo]

ОЧЕНЬ люблю таких ребят :)

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

таких вопросов уже была уйма, но специально для тебя вкратце напишу еще раз: ЛЮБАЯ ИДЕЯ НИЧЕГО НЕ СТОИТ. любой код достаточного объема, увы, имеет кучу костылей и спорных решений, поэтому легче написать с нуля свое, чем взять код из готового проекта.

кроме того, во-первых, 90+% трат — маркетинг и продвижение, код (тем более, идея) — вторичен, во-вторых, что будем делать, когда конкуренты на коленке запилят клоны, м? любая коммерчески выгодная идея будет скопирована сотни раз, запатентовать такие вещи нельзя по большому счету.

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

Comments

[juxifo]

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

[Sergey В.]

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

[Sanes]

BasiC2k, на Laravel сделать модульно целая история.

Answer 2

[Иван Шумов]

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

Один нюанс - нужен сильный архитектор из вашего домена)

Answer 3

[Robur]

Как это вообще по уму делают?

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

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

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

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

Answer 4

[Александр Павлють]

Микросервисы - многие не в курсе что это не "опимизация технического решения" а оптимизация "управления техническим решением".

Контроль и управляемость повышается не только на:
- скорости выкладки
- безопасности связанности сервисов (один упал - второй работает)
- скорости (от простоты) разработки и тестирования
- более точного мониторинга.

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

Такой метод использовался всегда в военной и космической отрасли в США (и по всему миру дальше) сразу после второй мировой - нужно делать что-то большое и сложное, при этом управлять подрядчикам и поставщиками, чтобы все в итоге было секьюрно и безопасно.

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

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

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

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

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

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

Решения есть - важно понимать что вы "потяните" сами.

Если у вас как и говорят "мега идея но вы ничего не можете сами" - вы и не сможете без зависимости от внешних талантов.

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

Готов ответить детально на каждый вопрос всем желающим в комментариях.

Answer 5

[xmoonlight]

Изоляция модульных блоков через заранее созданный интерфейс-"клей".

Answer 6

[CityCat4]

О, тут как раз недавно был вопрос, чем svn отличается от git. Так вот, он отличается тем, что несколько поможет в решении данной задачи.
Хотя конечно вопрос организационный.
Проект делится на модули.
Взаимодействие модулей четко прописывается. Ядро проекта (которое собирает работу всех модулей) - либо пишете сами, либо пишет чел с нулевым уровнем допуска :)
На разработку каждого отдельного модуля привлекается отдельный чел, он получает отдельное ТЗ - где четко происано, что у него на входе, что на выходе.
Вы спросите - а причем же тут svn? А он при том, что в нем можно давать доступ к части репозитория.

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