Блиц-опрос: Что делать если идея проекта появляется без разработчиков в команде?
Мы часто слышим истории успеха интернет стартапов, которые были разработаны «на коленках». Facebook, Twitter, PayPal, Airbnb — в командах со-основателей этих проектов были разработчики. Когда же в со-основателях нет программиста, предпринимателю нужно принять одно из важнейших решений: с кем разрабатывать проект. Есть 3 базовых решения: отдать разработку аутсорсинговой компании, нанять человека в штат, взять разработчика в соучредители, разделив с ним долю в проекте.
В каждом решении есть свои риски. Человек, работающий за долю, может ставить работу над проектом не на первое место, затягивать сроки, и, в конце концов, у него может пропасть интерес. Не всегда легко набрать в штат хороших, добросовестных и самоорганизованных сотрудников, которые готовы на первых этапах работать больше, тестировать самостоятельно, работать без технического руководителя. А аутсорсинговые компании просто не ваша команда. Они часто думают не об успешности проекта, а о выполнении четко поставленных задач.
Для раскрытия темы, я попросил 2х предпринимателей поделиться опытом.
Максим Школьник, Основатель и СЕО проекта Address.ua
Есть такая фраза «do what you do best and outsource the rest». По правде говоря, когда мы начинали проект, то взяли разработчиков в штат. Но, несмотря на то, что в команде разработчиков тогда работали хорошие ребята, мы через какое-то время поняли, что не готовы нести финансовые риски, связанные со срывом сроков разработки. В такой ситуации R&D (Research & Development) бюджет становится очень сложно прогнозировать. В этой связи мы приняли решение привлечь профессионального разработчика по модели coding for equity, который бы взял на себя этот риск.
При работе с аутсорсинговой компанией есть множество нюансов, как и везде. Основной, конечно, касается объемов выполняемых работ. Не могу сказать, что у меня с текущей командой разработчиков были какие-то критические трудности. Главным фактором стабильности, думаю, является доверие между партнерами и желание искать компромисс.
В будущем я некоторые вещи возможно бы делал по другому, но в целом поступал бы также. Более того, скорее всего, я работал бы с той же группой разработчиков из компании X-tend Software Development, если бы они согласились :). Они же сейчас и работают над address.ua.
Стоит ли работать с аутсорсинговой командой при разработке стартапа? Однозначно да. Но есть один очень важный момент — выбрать правильного партнера это очень сложная задача. «Что значит «правильного»?», — спросите вы. На этот вопрос нет однозначного ответа. Это как ответить на вопрос «как выбрать правильную жену \ мужа?». Можно говорить о критериях порядочности, обязательности и т.д., есть много качеств. Но еще сложнее распознать эти качества. В общем одни партнерства приводят к развалу проекта, а другие приводят к созданию успешных бизнесов.
Алексей Орап, Основатель и СЕО проекта YouScan
В команде нашего проекта почти с самого начала был CTO, который нашел независимую команду разработчиков, создавшую по нашему ТЗ прототип системы. На первых порах мы работали с командой разработчиков по принципу fixed cost — фиксированная стоимость за выполнение определенной части ТЗ на прототип. Уже через несколько месяцев стало понятно, что «все серьезно», проект имеет перспективы, и мы будем посвящать ему все свое время, оставив свою предыдущую работу. Также стало ясно, что нам с разработчиками надо общаться каждый день, определяя и корректируя планы разработки — а следовательно, нужна собственная команда, которая будет развивать продукт. Мы пригласили ребят в штат проекта, и они согласились заниматься дальше разработкой на постоянной основе.
Совсем однозначного ответа на вопрос, стоит ли привлекать аутсорсинговую компанию для разработки в стартапе, нет, поскольку все проекты имеют свои особенности. На мой взгляд, есть несколько основных факторов, от которых зависит целесообразность работы с аутсорсинговой компанией:
- Фаза проекта. Когда у вас есть только идея — у вас обычно еще нет привлеченных в проект денег, чтобы платить аутсорсинговой компании. Чем ближе к прототипу/бета-версии продукта вы можете подойти самостоятельно — тем больше ваши шансы привлечь первую инвестицию в проект, отдав при этом меньшую часть собственности. Другими словами, стоимость вашего проекта на момент получения начальной инвестиции тем выше, чем глубже вы смогли продвинуться в разработке продукта за счет собственных средств и усилий. Если проект уже получил серъезные инвестиции — отдавать часть разработки на аутсорсинг более реально.
- Наличие хорошо стандартизированных задач. Вполне возможно, какая-то не ключевая часть вашего продукта совершенно стандартна, по ней просто сформулировать четкое ТЗ, она не требует итеративной доработки. Такую разработку можно отдать на аутсорсинг.
- Наличие у аутсорсинговой компании специфичных компетенций. Возможно, аутсоринговая компания имеет определенные ноу-хау или наукоемкие технологии, которые нужны вашему проекту, и заказать разработку определенной части продукта проще у нее, чем долго (а значит дорого) разрабатывать самостоятельно.
В целом, я не вижу большой целесообразности привлечения аутсорсинга в веб-стартап. Продукт в типичном стартапе разивается методом проб и ошибок, тестирования предположений и быстрых итераций на основе обратной связи пользователей, в особенности, если ваш продукт инновационный и не имеет аналогов на рынке. Такой процесс создания продукта будет очень сложно отдать на аутсорсинг. В лучшем случае вы потратите на аутсорсинг те же деньги, на которые можно было бы содержать собственную команду разработчиков; в худшем — потеряете не только деньги, но также и гибкость и скорость разработки, и в конечном счете не достигните своих целей в планируемые сроки.
В идеале, в команде стартапа один из основателей должен быть техническим специалистом, и желательно при этом, чтобы он мог на начальном этапе сам писать код. Ведущие разработчики должны быть собственные, и должны иметь опцион в компании, собственность в бизнесе — самый мощный мотиватор в стартапе. Только неключевые задачи или такие, которые требуют специфичных компетенций, которые отсутствуют в вашей команде, в некоторых случаях можно отдавать на аутсорсинг.
Анализируя опыт собственного проекта, ошибкой было то, что наш CTO на этапе запуска не писал код самостоятельно. Это привело к тому, что он не был задействован в проекте full-time, в отличии от остальных сотрудников и партнеров, и в итоге в определенный момент наши пути разошлись. Впрочем, это не помешало нам развиваться дальше, поскольку его функции взяли на себя наши ведущие разработчики, на тот момент уже ставшие партнерами в проекте.
Уверен, что у многих из вас есть свой успешный или не успешный опыт по этому вопросу. Поделитесь своей историей с читателями AIN в комментариях. Лучшие из них мы добавим в статью.
Комментарии | 48
Когда разрабатывали софт для создания фотокниг (Finebook.com.ua), мы пошли рискованным путем — через объявление на сайтах вакансий и фриланса. Составили описание проекта, чего мы хотим, требования, условия. Начали знакомства с командами разработчиков. В некоторой степени нам повезло — удалось найти хорошую команду, с которой и сейчас работаем. Понимаем друг друга быстро и с полуслова. Ребята привнесли много своих идей в наше видение. Ну а в самом первом нашем проекте все начиналось с покупки книги а-ля «PHP для чайников» на Петровке, но так делать не следует точно :)) Нам просто хотелось поскорее сделать первую версию сайта, поэтому рассчитывали на свои силы. Потом уже появился программист на зарплату.
А за что платите? За часы?
Да, поэтапно за часы. Оцениваем, например, этап в 320 часов. Получаем логически завершенный модуль, рассчитываемся.
Наличии в штате сильно знавшего программиста тоже иногда вредно… Создание прототипа превращается в создание полноценной, навороченной, мега правильной, сбалансированной, защищенной (много других эпитетов) системы.
В результате стартап занимается не поиском бизнес модели, а тратой времени на выпуск никому не нужного комбайна 🙂
Иногда может и вредно, но без оного программиста — практически невозможно. Программисты склонны преувеличивать значение технологий — это да. Но люди бизнеса — тоже склонны преувеличивать значение идеи, канала продаж, маркетинга и т.д.
Проблема в том, что является первичным, а что вторичным. Первичным, все-таки, является продукт (сервис). Когда он есть — то его уже можно продавать, продвигать и т.д. А когда он нет, будь ты мега-супер-крутой sales — все равно ты ни хрена не продашь т.к. продавать нечего.
Поэтому ИТ-стартапы только с программистами, но без бизнес-пиплов подняться в принципе смогут (примеров масса), а вот наоборот — фигушки.
Ты противоречишь Всемирной истории (с) Банк Империал.
Только селес-пипл и может сделать успешный стартап. Технарь просто сделает сервис и никуда его не продаст…
«Технарь просто сделает сервис и никуда его не продаст…» 50/50, всё индивидуально. Главное чтоб башка была и думала.
Поэтому ИТ-стартапы только с программистами, но без бизнес-пиплов подняться в принципе смогут (примеров масса), а вот наоборот — фигушки.
какая хорошая фраза для начала холивара ))
вспомним истины: «Титаник строили профессионалы», «Альберт Эйнштейн был троешником» или Ричард Бренсон, который ни разу не авиаконструктор.
Эйнштейн не был троешником.
Когда я работал сэйлом в одном интернет проекте, то мы продавали рекламное размещение холодными звонками, и первую продажу я совершил ДО старта проекта, так что можно поспорить 🙂
отлично! я только вчера читал у Крайнова в блоге о том, как продукт стартапа все еще не готов, а первые продажы были сделаны 6 месяцев назад на $100k
вот это правильный стартап ! так как успешный стартап — проданный стартап
Артем, она сделали продажу своего продукта, который не закончили до сих пор. Деньги заканчиваются, собираются прикрывать стартап. Ничего успешного я в этом не вижу.
а сколько было вложено в этот стартап ?
300k долларами, кажется. Подробностей не знаю. У Крайнова в блоге описано.
ну в таком случае фейл. я думал что они вааще еще ничего не разрабатывали, а только бизнес план пишут и вложили скажем 10К денег 😉
…-предоплаченный стартап
С одной стороны ты прав, «Создание прототипа превращается в создание полноценной, навороченной, мега правильной, сбалансированной»
Но когда такого человека нет, то ТЗ у неопытного предпринимателя может превратится в: «было бы классно, если бы эта штука вот так разворачивалась и делала вот так» или «о, классно, хочу чтобы и у нас так было» )))
актуальный вопрос
Если отвечать на вопрос, заданный в заголовке, то ответ будет «Привлекать разработчиков в команду». Для интернет-стартапа другого варианта нет, в чем я убедился на собственном опыте.
Сам я большой фанат аутсорсинга, и всегда был убежден, что разработчики в штате не нужны, и разработку не только можно, но и нужно отдавать на аутсорсинг. В пользу этого решения говорила логика: ведь редко когда бывает, что твои разработчики загружены на 100% — обычно либо они недозагружены, но ты все равно должен платить им зарплату, либо задач столько, что их не хватает, и все равно приходится привлекать сторонних разработчиков. Однако мой личный опыт заставил признать меня, что я был неправ, и я полностью изменил свое мнение по этому поводу. И вот почему.
Любой стартап построен на куче предположений. На то это и стартап, а не ларек, где куча людей уже прошла точно такой же путь много раз, выявив все возможные грабли на нем. В стартапе все по-другому: когда вы только запускаетесь, ваша цель — как можно быстрее проверить ваши предположения, быстро подумать, как можно что-то изменить, если что-то работает не так, как вы предполагали, очень быстро внедрить изменения, снова посмотреть — и так по кругу. Такова природа стартапов, и именно поэтому, кстати, не стоит откладывать запуск, вылизывая все придуманные вами фичи, и, тем более, увеличивая их количество — все равно большинство из них вам придется менять, поскольку вы увидите, что нужно сделать, чтобы они работали лучше, или же работали вообще. Поэтому откладывать запуск ради вылизывания продукта и добавления второстепенных фич — это почти такая же глупость для интернет-стартапа, как и аутсорсинг разработки.
Но вернусь снова к аутсорсингу. Когда мы запустили Покупатор.ру 1 декабря 2008 г., то уже утром 2 декабря мы знали, что нужно в нем изменить. К 3 декабря список доделок и передлок разросся уже до десятка, 4 декабря их было еще больше — и т.д. Но мы не занимались улучшением продукта — ведь мы аутсорсили разработку. Разработка по предыдущему ТЗ была завершена, а для того, чтобы начать внедрять все изменения, которые были нужны, требовалось сначала подробно описать их в ТЗ (подробно — иначе подрядчик не смог бы просчитать цену своих услуг), потом разработчик бы оценивал стоимость доработок, затем нужно было поторговаться, затем заключить договор или дополнение к предыдущему договору — и только потом началась бы снова разработка. Поскольку все изменения были очень мелкими (но от этого не менее критичными для жизнеспособности стартапа), то мы накапливали их, поскольку если делать все по отдельности, то стоимость проведения описанной выше подготовительной работы увеличила бы стоимость каждой нужной нам фичи на порядок. При этом для полноты картины представьте, что нам всю эту бюрократию (без которой, увы, не обойдешься во взаимоотношениях с подрядчиками) нужно было делать в двойном размере, поскольку у нас был отдельный подрядчик на дизайн, и отдельный на разработку.
Будь у нас собственные программисты в команде, 80% изменений мы могли бы производить чуть ли не в тот же день, когда мы понимали, что они необходимы — повторюсь, что большинство из них были небольшими, но критичными для сервиса. Не факт, что эти изменения давали бы запланированный эффект (это опять же были предположения, которые необходимо было проверять в боевых условиях), но мы бы осуществляли их проверку очень быстро, и так же быстро внедряли бы следующие изменения, оперативно проверяя следующие предположения. А так весь декабрь мы только собирали необходимые изменения в кучу, и только после Нового Года сели за их описание, потом разработчики считали цену и уточняли ТЗ и т.д., я все это уже описывал выше. Фактически, первые изменения у нас были внедрены только к концу февраля 2009 г. Как это обычно бывает, часть из новых предположений оказались также ложными (это вполдне нормально для стартапов, но только в том случае, если скорость внедрения изменений высокая), мы снова начали накапливать фичи для доработок… Все это время стартап не развивался, а только жрал деньги в ожидании проверки новых предположений, но цикл проверки гипотез был необоснованно длинным.
У стартапа нет другого варианта, как действовать по lean-технологии. Он должен быть очень гибким. В основе Lean лежит так называемый цикл Деминга, или PDCA — Plan => Do => Check => Act (планируй => внедряй => анализируй результаты => принимай решение, подтвердмлось ли предположение, либо следует вернуться к началу цикла). При этом цикл должен быть максимально коротким по времени — это ведь стартап, у которого, в отличие от обычных компаний, нет уже налаженного бизнеса, приносящего прибыль, за счет которой можно экспериментировать с побочными направлениями.
В заключение хочу посоветовать пост известного американского венчурного инвестора Фреда Уилсона на эту же тему: http://www.avc.com/a_vc/2010/09/outsourcing.html
Вот его финальный вывод:
I am a fan of outsourcing in general. I believe companies should develop those skills and functions that are their core competency and outsource the skills and functions that are not. I believe that the US should invest in outsourcing instead of demonizing it. I believe there is a lot of opportunity for economically weak regions of the US to use outsourcing to build their economies and grow.
But for startups, outsourcing is a tricky issue. You should not outsource those things that are core competencies or critical feedback points. If you don’t have the skills on your founding team to do that work, go find people who do and either hire them or bring them onto the founding team.
Артур, спасибо за ответ. Гибкость и возможность быстрой реакции, действительно, самое важное при разработке, тестированию и первых этапах запуска (особенно работе с инноваторами и ранними адапторами)
Но как бы ты поступил, нанял программиста(ов) в штат, или искал партнера в долю проекта?
Разработчики должны работать в стартапе. На каких условиях — не так важно.
например, на условиях аутсорсинга )))) Работая по agail-методологии, можно рассчитывать на довольно оперативное внесение изменений.
Юрий, вы мыслите как разработчик, а не как подрядчик. Перечитайте мой комментарий и вы поймете, почему.
У нас аутсорсинг в украинских стартапах сводиться к наему максимально дешевых фрилансеров на фрилансе, которые в свою очередь ищут максимально простой проект на максимально быстрый срок. А вы аутсорсьте DDC и опачивайте часы , а не ТЗ и будет вам щастье.
Очень интересный коммент.
Мне кажется Вам изначально нужен был хороший менеджер проекта.
Или консультант, который подсказывал хотя бы возможные варианты и их логику, а решения Вы принимали бы сами.
Думаю, что для каждого отдельного случая и человека приоритетна своя стратегия сотрудничества с разработчиками. Если ценность Вашего бизнеса в большей мере — технологичность и сложность продукта, то, возможно, сотрудничество с разработчиками за долю имеет смысл, — в таком случае они действительно заинтересованы в том, чтобы сделать продукт хорошо. Если суть более в бизнес-модели, продажах, маркетинге — заказывайте программинг на аутсорсинге. Выберите наиболее подходящую Вам команду девелоперов, насобирайте/заработайте/одолжите денег — в перспективе Вы получите больше, чем если бы отдали долю, пусть и небольшую.
Не нужно заниматься сложными рассчетами, чтобы понять, что финансово такой вариант более выгоден (если Ваш план прибыли действительно динамичный, и цели амбициозны!), к тому же, Вы полностью застрахованы от случая «А Баба Яга против» — когда девелопер/теперь уже Ваш партнер хочет видоизменить Вашу чудесную бизнес-модель и идею бизнеса до неузнаваемости.Конечно же, возможны и успешные случаи синергии разработчика и идеолога — но, уверена, они встречаются гораздо, гораздо реже. И рассчитывать на них не стоит.
Я же уверена в том, что минимум совладельцев бизнеса — один из залогов его успеха. Поэтому, если есть возможность _не_вводить_ ещё одного партнера в долю — не стоит этого делать. Если Вы можете не привлекать инвестора — не нужно этого делать. Не отдавать долю за разработку/продажи/маркетинг/консалтинг — аналогично.Опять-таки, рассуждать о плюсах и минусах введения/невведения разработчиков в долю можно бесконечно, и все вышеперечисленные коллегами аргументы имеют смысл. Однако, если Вы самодостаточный менеджер и уверены в успехе своей идеи — найдите лучше деньги на разработку и оптимальную девелоперскую команду.
Татьяна, а beintrend.com/ разрабатывался в аутсорсинговой компании, или нанимались разработчики?
Аутсорсинговая компания.
Grammar Nazi негодует… Фахивци, блин.
Игорь, таким комментариям тут не рады. Если вы видите ошибку или опечатку — выделяйте и нажимайте контрл+ентер, ее исправят. От этого польза будет. А от таких комментариев — нет.
Приношу свои извинения, Артур. Впредь буду толерантнее.
Если ты не технический человек, то рано или поздно наступает момент, когда тебе нужно начать доверять кому-то из технического мира. Мне, в какой-то мере повезло, у меня брат программировал с детства, потом был PM в большой международной компании, я знал про него всё: склонности к точным наукам, отношение к качеству, ответственность, у меня просто не было повода не доверять ему и/или его мнению. Скажу честно, у меня так и не получилось найти разработчиков, код которых он бы оценил на 5ть по 5тибальной системе, но тем не менее я получал оценку адекватности кода. Если вы не можете оценить качество кода, то брать человека в штат очень рискованно, рано или позно человек может уйти, а вот дальше поддерживать продукт будет практически невозможно, прийдётся всё переделывать.
В любом случае, в дальнейшем вы должны доверять либо своему сотруднику, либо аутсорсинговой компании. Например, вы решили создать интернет магазин: писать с нуля, использовать движок или какой-то SAAS — решать уже не вам, ну или вам на человеческом языке должны озвучить все плюсы и минусы каждого решения, после чего вы уже сможете выбрать направление развития.
Если всё-таки решено держать свою команду, то команда — это должно быть не менее двух людей, и оба должны быть в курсе всего кода, иначе риски слишком велики (при одном программисте, автобус-риск вашей компании — единица, что очень плохо ))) )
Ещё один аргумент против своей команды разработчков: вы должны создавать действительно технически интересный продукт, иначе сильные разработчики скорее всего не проработают у вас долго, а нужны ли вам слабые разработчики? Стоит учесть, что уровень разработки в большой аутсорсинговой компании в среднем выше, т.к. программисты общаются с большим количеством коллег, всегда есть у кого спросить, и всегда есть опытный тим-лид, ПМ и тд.
Выбирая аутсорсера, пытайтесь найти того, который уже реализовывал похожую задачу, который знаком с подводными камнями того или иного продукта, будь то соц.сеть, интернет магазин или ещё что-то, иначе рискуете потерять как деньги, так и время.
Главное помнить, что это как женитьба, когда успех компании (семьи) зависит от всех участников процесса, а не от какого-то одного отдела.
да, к сожалению очевидные вещи, следующие к примеру из того что продуктовые компании не получается заказать на аутсорсе иначе бы инвесторы нанимали бы проджект-менеджеров и те заказывали бы бизнес. Но я бы подчеркнул один момент, что до того момента пока ты не знаешь что нужно сделать чтобы получить деньги нужно делать это в команде, в идеале в долях, иначе есть риск что человек верит в деньги а не в дело. А вот как только точно стало известно что нужно сделать и как это должно работать, можно побаловаться аутсорсом, но здесь опять же таки если брать интернет который быстро меняется, то врядли 100% аутсорс вообще возможен
как показывает практика 2 украинца = 3 гетьмана, а работать то кому-то надо. поэтому скорее наоборот, минимальная команда заказывает на аутсорсе, а уж как получили инвестици можно и вштат кого-то искать, есть аутсорсеры были слабенькими
Вначале аналитика.На веблансе, фрилансе:- найти копирайтера (мотивационный продающий текст. на самом деле не простая задача.) — найти дизайнера- найти веб-мастераОбъяснить суть задумки и совместными услиями сделать Одну ХТМЛ страниу, которая будет отображать суть проекта. (прототип)Показать страницу 10 друзьям знакомым. Переделать страницу 5-6 раз.Найти интернет-маркетолога: — к созданной странице подключить ГуглАналиткс- настроить цели (что бы отследить конверсию-желаемое действие, которое должен совершить посетитель странички)- выделить бюджет на рекламу и настроить рекламу в (Гугл Адвордс, ФБ-покликово с переходом на прототип, ВКонтакте с переходом на страницу прототип)Рекламу запустить макисмальную. Что бы за 3-5 дней страницу-прототип посетило как можно больше людей.Снять первую статистику. И тогда поймешь, стоящая идея или нет.Если идея стоящая. Делаем полноценный сайт. (программеров находим на сайте фриланс и подобным)p.s.при выборе подрядчика на Фрилансе не гонитесь за маленькими ценами, а выбирайте подрядчика с опытом подобной Вашей задачи
начинать саегда надо с БИЗНЕСА а не с исходного кода, с этим согласен.
И именно поэтому важно еще добавить бизнес план, после осознования того, что идея у вас стоящая.
Очень толковые мнения экспертов.
Добавлю и от себя «пять копеек».
Я принимаю участие уже в четвёртом по счёту стартапе, набил немало шишек и делюсь исключительно своими наблюдениями:
Веб-стартап стоит начинать исключительно по lean-методологии. Обязательно стоит читать Бленка, Ash Maurya, Эрика Риса.
В проект со старта нужен CTO или lead developer (он должен отвечать за всю тех часть проекта, начиная от администрирования и заканчивая «фиксином багов»)
Этот человек должен сам писать код (аутсорсеры или фрилансеры вполне могут быть «на подхвате»)
Если тех специалист «не справляется», коммуникация не клеится, сложно вместе работать – нужно быстро с ним расходиться и искать другого (hire fast – fire fast). С первого раза найти идеального тех спеца невероятно сложно.
На первом этапе качество кода, выбранная технология, не играет роли. Главная цель – быстро сделать прототип, выпустить его на рынок, получить обратную связь, проверить ранее выдвинутые гипотезы (fail fast).
Дальше необходимо строить свою техническую команду, которая головой и деньгами отвечает за продукт, переживает за него, работает на выходных, общается с клиентами
Лично моё мнение – если нет возможности заинтересовать тех специалиста хорошей и стабильной зарплатой, комфортным офисом с мягкими креслами рядом с метро, тогда нужно с ним делиться «equity». Просто нет другого выбора, ведь при найме сотрудников мы конкурируем с крупными аутсорсинговыми компаниями. У хороших спецов всегда есть много соблазнительных предложений со стороны.
Опцион в стратапе – самый лучший инструмент привлечения и удержания хороших специалистов.
Не думаю, что в Украние толковых девелоперов можно завлечь «на опцион».
Если конечно есть противоположные кейсы, жду примеры. CV спеца, стартап, опцион.
Ты несколько раз тут рекламировал себя и свою команду, как аутсорсеров, рассматривающих работу за опцион. Или не прокатило?
Хорошо будем на ТЫ.
Я рекламировал только это — http://www.abdesign.kiev.ua/ru/razrabotka_startapov/ Разработку стартапов как-раз НЕ за опцион, а в формате DDC (Dedicated Development Center). Другими словами аутсорсинг и ауттаффинг за деньги.Если же это камень в мой огород «прокатило или нет». Личный реактивный самолет я пока не купил, но 3 украинских клиентских стартапа в разработке имею.
Никаких камней. Но точно помню твои рассказы про долевое участие где-то в комментах.
меня часто об этом спрашивают 😉
Пример:Клиент Мол мы создаем супер мега стартап, НО у нас нет денег и программитов. А давай своих программистов, помещения , ресурсы, а мы тебе долю 😉
Я:
Не вопрос, можно , НО вы должны оплатить по скромному рейту, скажем 20 у.е./час в любом случае + доля. А просто доля УВЫ и ОДНАКО (с) 😉
То есть, за долевое участие, (например, 10-20%) ты готов снизить стоимость разработки аж до $20 за человекочас?) Где же тогда твои риски, как партнера стартапа? Ты покрываешь зарплату сотрудников, зарабатываешь, да еще и получаешь долю в проекту с возможностью сорвать куш при его продаже или инвестициях. Не вижу логики.
У меня есть повышенные риски в моих стартапах.
ИНФО: Без «зарпалты» самого программиста, если он работает от предприятия (а не сидит из дома) себестоимость 1 часа будет от 10 до 18 у.е в зависимости от уровня предприятия. Заработок тут где?, скорее покрытиые расходов. А вот на продаже проекта уже и заработаем.
У тебя все участники команды получают ЗП 25000 гр-н в месяц? Уважаю) Хоть это не логично и комменты (даже хорошие) в по всему интернету говорят о другом (я им никогда не верю).
Все равно, даже при всех этих реальных фактах, ты покрываешь расходы и зарабатываешь(хоть эти 2 доллара в час:) ) а самое главное, не рискуешь. Я бы не брал в долю стартапа человека(команду), кто не хочет нести со мной вместе риски.
1 рабочее место для программиста в предприятии в Укриане это:
амортизация мебели
амортизация ПК
лицензионное ПО (амморт)
Часть ЗП уборщицы
Часть ЗП охарнника (если его нет в БЦ)
Часть ЗП офис менеджера
Часть ЗП HRа/рекрутера
Часть ЗП PM который курирует программиста
Часть ЗП бухгалтера
Часть ЗП сисадмина
Часть ЗП юриста или юр зпщиты от произвола налоговиков, рейдеров и прочих.
Часть ЗП СЕО, CFO и т.д. если наемные
4-7 квадратных метра офиса
Часть комунальных платежей за офис
Налоги
Затраты на маркетинг (часть конечно)
Затраты на рекламу (часть конечно)
Затраты на связь, интернет и прочее
Форс мажеры (пришли например пожарники, пусть у тебя 10 раз все будет хорошо, но не даш денег запломбируют усе)
Взятки (мы опять же живем у Украине)
Организация соц.программы (даже банальная передевалка и комната для приема пищи)
Обедв, печеньки.
Оплата простоев по кзоту — гос праздники , не более 8 часов в день работа и .т.д.
Даже если все это МЕГО ОПТИМИЗИРОВАТЬ дешевле 10 баксов за час девелопера, без его ЗП не выйдет. А в крупных предприятиях уходит и все 15-30 у.е.
Ну и теперь прибавляем стоимость рук специалиста.
Мнения разделились.. И с аутсорсерами морока и доли раздавать жалко.. Короче надо лавировать лавировать и глядишь не потонешь.. Спасибо за интересный материал!