Comments 59
1. Когда человеку реально наплевать выстрелит он или нет и он делает то, что нужно лично ему. Но делает хорошо с любовью, со вниманием к мелочам. И в итоге получается продукт, которым он сам пользуется с удовольствием, и который показать не грех…
2. Когда человек больше «продажник», а не разработчик. Когда он знает как раскручивать, как продавать. Где и как размещать рекламу, как правильно сделать иконку и визуальное оформление, как наилучшем образом потратить рекламный бюджет и что этот рекламный бюджет ДОЛЖЕН быть… Такой человек делает в общем любой крепкий средний продукт и просто его ПРОДАЕТ.
Не читал еще ни одной истории, что бы условный «разработчик», который «мечтал создать генерирующий прибыль онлайн-проект, стремясь к финансовой независимости и творческой свободе» (т.е. который хотел не сделать продукт своей мечты, а ПРОДАТЬ миру хоть что-нибудь собственной разработки) добился чего-то вразумительного. ( Если ты сейлс, которые немного может в разработку (или умеет найти тех, кто может) — вполне. Но не разработчик.
Разработчик должен хотеть что-то СДЕЛАТЬ. Что-то гениальное, не имеющее аналогов… Продать это и заработать на этом — вторично… Такие истории, когда люди что-то делали для себя, но выяснилось, что и другим это нужно — были (хоть и не так уж много). Но у вас или главная мотивация — заработать, или «мотивация исчерпалась довольно быстро»… ( Я вас не критикую — у самого куча незаконченных (да местами толком и не начатых) проектов… Таков расклад просто.
Да, всё так. Помимо этого ещё надо учитывать, что если продавать какашку, даже выстраивая отличную маркетинговую компанию, то может получится так, что затраты на рекламу не окупятся. Ну и обратное верно - без маркетинга даже отличный продукт не продашь.
Если у игры качественный графоний и более менее интересный геймплей, то можно вкладывать деньги в раскрутку. Если графика унылая, то какой бы бомбический не был геймплей, вкладывать деньги в рекламу глупо - времена тетриса прошли безвозвратно.
Разработчик Dwarf Fortress, как и Нотч, изначально взяли более сильную идею и не сдавались после первого года разработки
"Адамс начал работу над Dwarf Fortress в октябре 2002 года...
в 2006 году
"Адамс ожидал, что он потратит свои сбережения в размере 15 000 долларов в течение года, а затем ему придется найти работу, чтобы прокормить себя, потому что игра еще не была выпущена. Разработка продолжалась до 8 августа 2006 года, когда была выпущена версия 0.21.93.19a. В последующие месяцы пожертвования достигли 800–1000 долларов, и эта средняя сумма постепенно увеличивалась, пока не стала финансово стабильной"
"Адамс считает Dwarf Fortress делом своей жизни и в 2011 году заявил, что не ожидает выхода версии 1.0 еще как минимум двадцать лет, и даже после этого он все равно продолжит ее обновлять."
Помимо этого ещё надо учитывать, что если продавать какашку, даже выстраивая отличную маркетинговую компанию, то может получится так, что затраты на рекламу не окупятся.
"Те люди, которых дельфины подталкивали к берегу, рассказывают всем, какие дельфины добрые и как он их спасли. Те люди, которых дельфины подталкивали ОТ берега, уже никому ничего не расскажут."
Я понимаю, что это лишь аналогия и популярное высказывание, но...
Разве эта идея не дурацкая? Ну что, за много тысяч лет ни один человек после того, как дельфины толкали его от берега, не выжил и не рассказал остальным, что дельфины могут быть опасными? За все время никого не смогли подобрать и спасти на проплывающий мимо корабль? Есть люди выжившие после нападения акул, но ни одного после дельфинов! Невозможно. А это высказывание про дельфинов везде и всюду пишут...
Статистика.
Ну выжил один, его подобрали, он рассказал. Ну ок, стало известно, что существуют дельфины-убийцы, но статистически же добрых дельфинов больше!
Делается вывод, добрый дельфин - правило, злой - исключение (больной/бешеный/свой вариант).
Касательно ошибки выжившего мне больше нравится пример с самолётом, который описан на вики.
Кстати у топикстрартера есть похожая в рассуждениях:
Не читал еще ни одной истории, что бы...
То есть он делает выводы на основе личного опыта. Но если он не читал о таких случаях, это не значит, что их нет.
И третий: человек понимает, что в современном онлайне уже сложно строить в одиночку. И что его компетенции и время ограничены.
Формирует команду из квалифицированных специалистов в своих областях. Выстраивает процессы. Драйвит.
ну, да, и чаще 2 пункт. сколько я работал на разных дядь, постоянно удивлялся что они такое делают, почему какой-то бутстрап или типа того, кто купится на это каркасное бездизайновое чудо, но оказалось только так, потому что делали нишевые вещи, функциональные и всем плевать на то как оно выглядит, лишь бы решало задачи и приносило пользу, просто заказчики знали что и для кого делать
Вариант 3, тоже распространенный. Делали проект для заказчика, но по дороге поняли, что можно продать другим с небольшими изменениями. Проект превратился в продукт.
Как там было: тот кто придумал получает $10, кто сделал, получает $100, кто продал - $1000.
Чтоб делать финансово успешные продукты, начинать надо не с разработки и не с MVP.
Нужно убедится что продукт действительно нужен (причина фейлов №1). Например через касдев (и не вздумайте спрашивать "купите ли вы продукт"). Или через маркетинговые тесты с лэндингом.
Иначе это просто убитое время.
У меня никогда не стреляли хобби проекты. Я человек стеснительный и порой боюсь показать. Порой находит вдохновение и я могу буквально за ночь написать годный MVP. Пару проектов даже доводил до ума. Но свет их так и не увидел - я мог написать о них пару постов в фейсбуке но дальше продвигать боялся
Более или менее годные было:
Игра кликер на android, которая даже набрала 100 с чем-то скачиваний. Коллеги на работе хвалили, предлагали фитчи, а я тихонько отшучивался и убегал. Покликали и бросили
Увидел как тестировщики используют для генерации тестовых данных какое-то гуано и обнаружил что особых альтернатив в виде онлайн сервисов нет. Запилил сервис - им понравилось, предлагали что можно добавить. Но то времени не хватало, то то то cе. В общем вырубил - на меня еще и обижались
Я сделал один вывод - хобби проекты это невыполнимы пока они остаются хобби. Для воплощения проектов в жизнь нужно собрать денег и платить их самому себе, пилить их не в дополнение к работе а на работе. Также мне явно необходим менеджер, который будет заниматься продвижением, продажами и всем не ИТ
Но пока я таких проектов, которые бы стоили этого не придумал. Да и боюсь что если прогорю то смогу ли я с такой же как раньше мотивацией вернутся к дяде на фуллтайм
1 из 20 . 5 не показатель. Продолжайте. А реальный успех 1 из 100.
Для приложения ваша теоретическая аудитория должна быть 10+ млн человек. Если меньше, то это просто хоби проект.
Например, самозанятых 3,3 миллиона. Чек в виде бумажки возможно захочет напечатать один из 10 тысяч. 330 человек.
Прога в плее 3-й месяц. 189 установок. 59 пользователей.
Писал ее как бесплатную без рекламы. Чисто в образовательных целях.
А как Вы оценивали это самое «возможно захочет»?
И какой процент потенциальных пользователей знают о вашей программе?
Цифры выше мое глубокое имхо. У новичков слишком розовые надежды. Достичь ARPU рубль и выше сложно.
Если пытаться предлагать каждому, то CPI > ARPPU и просто уйдешь в минус.
Понятное дело, что бизнес - воронка: LTV - CAC > 0 - можно думать.
Концепцию партизанского маркетинга можно рассмотреть.
Вкинуть рекламу в профильные каналы тг ради оценки конверсии с поста. Тогда будет понятнее потенциальная аудитория. Ну или найти относительно небольшие чаты, где можно просто задать вопрос: «а что вам нужно?»
Забавно. "Подписывайтесь на мой twitter", чтоб узнать как не надо работать? Альфа-банк рассчитывает привлечь армию лузеров?
Ну на самом деле "узнать как не надо работать" - это таки полезная штука.
Потому что истории победителей читать обычно бесполезно - там одна большая систематическая ошибка выжившего, невозможно понять, какие действия действительно были необходимы для успеха, а где просто повезло (возможно даже вопреки действиям). Читать все эти "истории 100 успешных стартапов" имеет смысл разве что для мотивации.
А вот истории провалов гораздо полезнее, там как правило четко можно увидеть ошибки, приведшие к неудаче, и попытаться их избежать.
Это не хобби проекты. Это работа на дому.
не нужен барабан, там атака размазана. нужен четкий клик. а лучше еще и с записью и анализом попадания или непопадания
Похоже, что это нужно только вам, любой софтовый секвенсер имеет метроном с блэкджеком и настройками. Я пользуюсь Ableton-ом к примеру.
Потому что для вас это было хобби. Вы создавали продукты через программирование, а не использовали его как средство достижения цели. Если хочется повысить процент успешности, то непосредственно кодинг стоит на последнем месте.
Продуктовую часть можно годами обдумывать, чтобы определить видение продукта, который будет действительно лучше решать проблемы пользователей/клиентов. И этого самое начало.
Да и по срокам. 3 недели part-time для MVP? Я столько времени подбирал технологический стек для фронта, формировал зачатки архитектуры.
Да и по срокам. 3 недели part-time для MVP? Я столько времени подбирал технологический стек для фронта, формировал зачатки архитектуры.
Сроки вообще ни о чём не говорят. Есть проекты, где можно и за неделю MVP сбацать, а есть такие, для которых и месяца мало будет. Речь про одного разработчика, конечно.
У меня есть один проект, MVP для которого я сделал за пару недель и это было несколько лет назад. До сих пор куча людей пользуется.
Зато есть новый проект, где я сделал оценку создания MVP примерно в два месяца и это ещё сильно сокращено по фичам, так как есть некие сроки, в которые хочется уложиться.
Да игру вообще можно было в конструкторе каком-нибудь сделать. Для игр главное - это маркетинг. Сами игры итак уже везде валяются. Играть в них уже просто некому. Скоро доплачивать начнут игрокам такими темпами.
Так и есть. Несколько лет назад общался с программистом из копании по разработке игр для смартфонов. Там конвейер. Штампуют игры с одним уровнем, ту что выстрелила начинают развивать. Выстреливает очень редко, при том, что у них маркетинг.
После этого, слова о том что кто то пишет игру и собирается на ней заработать вызывают иронию.
Хотя навыки и опыт, то же капитал.
Продуктовую часть можно годами обдумывать, чтобы определить видение продукта, который будет действительно лучше решать проблемы пользователей/клиентов. И этого самое начало.
Да можно, конечно. А можно потратить минимум времени на создание mvp, собрать реакцию, исправить ошибки, и максимально быстро донести продукт до пользователей. Пусть несовершенный, но зато уже сегодня решающий их проблемы, а вам — приносящий доход.
И по моему опыту, продукты, создаваемые по второму сценарию, выживают на порядок чаще. Я, например, могу предположить, что в природе существуют кейсы, для которых можно потратить недели на подбор технологического стека. Но я не могу себе представить такого кейса в известной мне части вселенной (за 21 год работы — достаточно разношёрстная часть: Delphi, всякого рода CRM, банковские системы, ERP, веб, дотнет), где подбор технологического стека не может решиться в течении одного митинга команды, или одной чашки кофе, если это личный пет-проект. Подозреваю, если вы тратите на это несколько недель, то вы это время тратите не на выбор технологического стека, а на чтение всяких статей-обзоров разных новых тулзовин/фреймворков, ну т.е. занимаетесь расширением собственного кругозора, а не проектом.
стека, а на чтение всяких статей-обзоров разных новых тулзовин/фреймворков
Так и есть. А как по-другому? Если нет опыта полного цикла создания продукта из сопоставимого домена, то садишься изучать. Мы же про парт-тайм говорим? Да, в часах это не так много, но здесь у меня есть правило: решение должно «настояться». К нему стоит вернуться через какое-то время, что взглянуть под другим углом.
Ну это не просто подбор: это формирование всего фронтового окружения, с туллингом и набросками кода. Это оценки роста, анализ опенсорных решений: как принимают PRs, как работают с issue, мощность сообществ и т.д.
Ну и это же фронт - если сейчас не возьмёшь новое, то через 1-2 года будешь думать: почему я решил использовать старый стек? И ведь я это много раз видел.
Это из разряда: долго запрягаем, но быстро едем. Ну и плоды это дало: в подходящем под конкретный проект окружении эффективность была на высоте: через месяц был готов MVP, подобный которому делали 3 месяца 2 разработчика.
Я просто не рассматриваю это, как пет-проект: это вторая работа со всей серьёзностью, это инвестиции.
Ну и не каждый проект можно выкатить для «собрать реакцию». Если на рынке есть конкурент, то реакция не нужна, но нужны бабки на продвижение.
А как по-другому? Если нет опыта полного цикла создания продукта из сопоставимого домена, то садишься изучать.
Хм. А что за «другой домен» такой может быть, что ваш текущий стек для этого не подходит на все 100 процентов? Я понимаю, например, если это совсем другая технологическая область, грубо говоря, если вы из мира веба хотите перепрыгнуть в мир STM32 или там в мир геймдева. Но раз мы говорим про фронтэнд, то речь ведь идёт просто о другой предметной области в рамках веба, верно? Значит, стек вообще менять нет смысла, ваш текущий стек гарантированно решит задачу ничуть не хуже какого-либо другого, даже лучше его, ибо на хорошо знакомом у вас продуктивность повыше будет.
Ну и это же фронт — если сейчас не возьмёшь новое, то через 1-2 года будешь думать: почему я решил использовать старый стек?
Сейчас наверное нет. Даже на фронте эпоха быстрой смены всего и вся в течении пары лет, к счастью, уже прошла. Если вы используете что-то массовое и проверенное вроде react или там vue, вы вряд ли что-то потеряете и через год, и через два. Не говоря уже о том, что из вариантов «запустить сейчас, а через два года переписать полностью» и «запустить через полгода, а переписать через четыре года» первый обычно выгоднее :)
По моему опыту, начинать проект с новых незнакомых/малознакомых инструментов, это неэффективно. А если они ещё и малораспространённые, это вообще ходьба по краю — т.к. это практически гарантия того, что у них там вылезет куча подводных камней в самых неудобных местах. Оптимально, это когда используешь знакомый стек, можно в него ввести пару новых тулзовин «для развития», не больше. А всё остальное изучение нового — это факультатив, не нужно его вмешивать в те процессы, от которых требуется какое-то стабильное получение результата в ожидаемые сроки и с ожидаемым бюджетом.
Если рассматривать фронт, то так можно сказать "так везде же js/ts - какая разница, любой разберется как писать".
Но дьявол кроется в деталях.
Предметная область определяет PWA/SPA/классика, b2b/b2c тоже вносят свои коррективы. Нужен ли SSR для SPA? А может SSR+PWA? И ведь на старте это предусмотреть легко. А нужен ли будет browser extension?
Вопрос необходимости держать полноценную мобильную версию (адаптив) определяет многие нюансы архитектуры, а также накладывает свои ограничения на готовые наборы ui-компонентов. Которые, в свою очередь, должны быть расширяемы и качественно поддерживаться сообществом и мейнтенерами. Локализация, вроде просто, но самая популярная на vue либа по локализации не поддерживает стандарт ICU Message (и это просто фейл). И внедрить локализацию в самом начале почти ничего не стоит. А уже потом - дорого. Но мало кто об этом думает.
А предусмотреть возможность завернуть в мобильное приложение через cordova или аналог? В начале пути это возможно и не сложно. Потом - не уверен, что вообще возможно.
Плюс доменная область может определять различные ACL, существование многообразие интерфейсов-клонов, темы оформления, частные эксперименты, стратегию mobile/desktop first, клиентские устройства и т.д.
Если резюмировать, то цели такого подхода:
- максимизация эффективности использования opensource;
- максимизация эффективности непосредственно кодинга;
- прогнозированый рост сложности с ростом кодовой базы;
- простота вхождения новых разработчиков в проект;
- минимизация "пустого кода" с минимальным ущербом;
- обеспечить кайф от разработки.
Т.е. сделать все дёшево(быстро), но эффективно и круто.
Все проекты, в которых я работал, имели проблемы: заброшенные либы (плохой анализ), самописный сложный тулинг (который есть готовый, но о нем не знали), провалы в архитектуре (сложность работы росла значительно быстрее, чем должна), несвоевременная/заброшенная локализация и т.п. Все это можно было предусмотреть и вовремя предотвратить, при наличии опыта. Но этот тех.долг заливается деньгами, по сути.
-
За пару лет меняются опенсорсные зависимости. Останавливается поддержка, появляются более эффективные инструменты. TS во vue появился фигурально вчера с выходом третье версии, а это ведет к обновлению всей экосистемы. Брать вторую уже не смысла, значит нужно проанализировать экосистему.
В реакте тоже свои нюансы, но он лучше работает с концепцией эволюционного развития. Ну и тоже: что взять? create-react-app и допиливать его нормального вида? сторонние бойлерплейты, которые дадут чуть больше из коробки и больший контроль, но большую сложность? архитектуру своего текущего проекта? nuxt? Вопросов много.
Тут нужно соблюсти баланс нового и проверенного. Понятное дело, что сырое или неизведанное брать не эффективно.
Но старье брать нельзя, я уже видел примеры, когда стартап переписывал бэк, потому что "старое надежное" было серьезно дороже: на работе в компаниях они этого не замечали, потому что все заливалось деньгами. А новое, в их понимании, авангардом уже считается "старым". Недостаток компетенций, который можно было восполнить не бросаясь с места в карьер, потратив некоторое время на обдумывание
-
Речь про то, что лучше потратить сейчас лишние 3 недели, чтобы можно было написать отличный код, который не нужно переписывать через 2 года. И который не потребует рефакторинга уже через месяц из-за переосмысления.
Да и с таким подходом (сугубо - имхо, исходя из опыта) - MVP получается значительно быстрее. Как минимум потому, что не отвлекаешься на смену контекста: есть готовая инфраструктура, определенное видение архитектуры и нужно просто кодить. А еще получаешь кайф от ощущения: "какой я молодец, все продумал". Положительные эмоции от процесса - это лучший рецепт от выгорания.
Цель же проста: с минимальными усилиями получить отличный результат с большим удовольствием от процесса.
-
Проверить гипотезу через MVP - это, на мой взгляд, не самый способ "прощупать рынок" для одного человека или маленькой команды: есть другие подходы, инструменты, которыми можно воспользоваться с меньшими затратами. Это просто дорого и сильно бьет по мотивации, если не взлетит. А не взлететь может по очень разным причинам, не обязательно идея плохая. В ряде ситуаций лучше начать поиск клиентов/аудитории до того, как приступить к реализации.
Честно говоря, не могу представить проекта, для которого MVP (кривой-косой, но с работающим базовым функционалом) нельзя было бы слепить за месяц. Я в такие сроки делал демки чего угодно - от игр до машинлернинга, от пешеходной навигации до алгоритмического проектирования городских районов. Да, потом на доделку полного функционала может еще год уйти или больше, но первая рабочая версия любого алгоритма за несколько недель вполне пишется в объеме, достаточном для проверки гипотезы нужности.
Если не брать железнячные проекты, где приходится работать с объектами материального мира. Там все может задерживаться из-за долгой доставки, сложных техпроцессов, которые не выполнишь за чашкой кофе в полночь после основной работы, и т.п.
Мне кажется, что вы говорите про PoC, а не MVP. Здесь, действительно, можно быстро сделать быстро. И я так делал.
Ваши вопросы были «а технически это возможно?», «а нужно ли это пользователям?».
MVP: «а как на этом заработать» (или достичь другой цели: помочь людям, прославиться и т.д.)? Про поиск работающей бизнес-модели и создание создание продукта, который подходит под требования этой самой потенциальной модели.
А если это не создание новых рынков, п инновация: делаем что-то, что лучше других. Мы четко представляем себе бизнес-модели, нужность и т.д. Нужно только сделать, запустить и быстро расти.
—
Ваши демки взлетели? Зарабатываете на них?
На мой взгляд высказывания
Как я провалил 5 хобби-проектов за 6 лет и заработал 0 долларов
и
Это история о том, как я мечтал создать генерирующий прибыль онлайн-проект, стремясь к финансовой независимости и творческой свободе.
немного противоречат друг-другу. Надо либо крестик снять, либо трусы одеть. То есть оно конечно вполне себе бывает что хобби приносит деньги и даже много денег. Но если изначально цель именно "генерировать прибыль", то это не хобби.
Хвалю рассказ не за содержание, а за "историю неуспеха". Слишком много в интернетах историй успеха, что формирует неправильную картину мира.
Спасибо автору за выбор именно этой статьи для перевода.
Интересный опыт. Спасибо, что поделились!
Planetoid очень похож по смыслу на игру Eufloria, которая мне в своё время безумно нравилась, как "залипаловка" после тяжелого дня :)
Так и должно быть - у начинающих программистов должны быть пет-проекты безприбыльные. И у меня много таких, например ICQ-мессенджер который работает без интернета (но в глобальной сети интернет всё равно, через бесплатные SMS) :-) - никому не нужен.
На тему мол надо не хобби, а чтобы бизнес был - я так как то как раз в Альфа-Банке кредит на миллион более ценных чем нынче денег взял и ООО открыл, сначала полгода работая параллельно с работой, а потом фирма и кредит, под бизнес... и закрылся через полгода потому что у меня было ровно 0 платных клиентов и 4 примерно бесплатных, при том что там первый месяц было всё бесплатно, а потом условные 500р, но даже в таком виде проект был никому не нужен, и да - с платной рекламой и всяким таким - тоже, а расчет был на сотни платных клиентов в начале. А результат 0 платных, 4 бесплатных, успешненько... Не повторяйте моих ошибок :) Нужно много простых и не затратных тестов бизнеса прежде чем рваться в бой, иначе это просто потраченное время и деньги.
Как эти проекты вообще могли обеспечить финансовую независимость?
Чтобы проект стрельнул без денег, нужно чтобы его кто-то любил и заряжал всех остальных... Деньги может придут, а может и нет. Но всем будет в кайф. А в противном случае, нужны планы, KPI, сотрудники, зарплаты - бизнес, в общем. Тоже не факт, что стрельнет, но без планов и запасов на пару лет раскачки он будет обречен в самом начале.
Было бы интересно почитать, насколько проекты были затратными
Как я провалил 5 хобби-проектов за 6 лет и заработал 0 долларов