Как пилить стартап с хакатона в свободное время
Вы знаете, что такое линия Кармана? Я вот не знал, пока не вступил в команду с таким названием. Команду на финале хакатона Цифровой прорыв 2019, на котором нам удалось одержать победу по треку Минздрава. Про этот самый финал написано не менее десятка статей, а я хотел бы рассказать, что было с нами после, и поделиться парой лайвхаков, как не забросить проект и не растерять команду.
Картинка для привлечения внимания. Источник: Expedition 22 Crew, NASA
Пара вводных:
Нас в команде четверо, все устроены на фуллтайм, проект попиливаем в свободное время
В команде проджект-менеджер, дизайнер, фуллстек-программист и я — немного программист, немного копирайтер, много ленивец
Познакомились на хакатоне, заготовок не было, опыта в ML (про который проект) — никакого, опыта в IT вообще — дофига, за счёт этого и вывезли (и пара жертв богу рандома)
Приложение пока чисто десктопное, другие платформы в планах (читай: в мечтах)
Кратко о проекте
Нашей задачей было трекать неправильную осанку за компьютером. Но за полтора года, последовавшие за хакатоном, концепция стала более общей и цельной. Мы решили делать цифрового ассистента, который будет помогать пользователю следить за здоровьем. И не пассивную Сири/Алису/Алексу, послушно выполняющую твои желания и заказывающую тебе пиццу, а наоборот, активно вмешивающуюся в твою жизнь, теребящую неудобными вопросами и мешающую эту самую пиццу заказать, если она явно лишняя.
У помощника (не буду называть её имя, поскольку это не рекламный пост) есть несколько пресетов — наборов правил, описываемых хитрым JSON-подобным DSL. Пользователь может включить любой из пресетов, будь то слежение за осанкой, за питьём воды, за количеством сна (с будильником на «пора спать»). Идей для пресетов у нас десятки, но каждый из них — большой труд, даже с DSL. Помимо описания функциональной логики, мы также ищем научные источники, обосновывающие действия ассистента, и приводим их в описании пресета. А то вдруг держать спину прямой на самом деле-то бесполезно?
Спойлер
Нет, всё же полезно, но сомневаться нужно всегда и во всём!
Для наших любимых параноиков есть возможность отключить использование камеры и даже отправку анонимной статистики, прямо во время туториала и потом в настройках. И всё честно, метрики полностью отключаются, юзер для нас становится невидимкой. Но стоит отметить, что снимки с камеры и так никуда не отправляются, потому что мы запихали нейросеть непосредственно в дистрибутив, всё распознаётся на компьютере у пользователя. Нехило поработали и над тем, чтобы всё это не пожирало проц и память как не в себя во время работы, потому что в первых версиях было именно так.
Пока непонятно, нужен ли такой продукт кому-то, кроме нас. Мы пытались делать «кастомер девелопмент» несколько раз и разными способами. И вроде как интерес есть, «да-да-да», но в реальности продуктом не пользуются. Платить за него тем более не готовы. Но всё же мы лелеем надежду отыскать, что же нужно пользователям, и, желательно, как это монетизировать. Любая обратная связь была бы бесценна!
Есть информация из неплохих источников, что проекты про астрологию продаются на порядок лучше, чем проекты про здоровье с научным подходом. Но это не про нас. Лучше уж закрыть проект, чем зарабатывать на лжи.
Про разработку в режиме «сорян, ничего не сделал»
У меня есть опыт разработки относительно большого коммерческого проекта в свободное время. Когда-то мы пилили игру для В Контакте с тремя друзьями. Я буквально работал над ней в метро и на ходу с ноутом наперевес, пока шёл на работу и обратно. Мы прошли все круги ада, характерные для такой разработки: многомесячные трясины, запары на основной работе, потерю мотивации, бессонные ночи и так далее. Тем не менее, игру мы запустили и какие-то деньги она какое-то время зарабатывала. Не выстрелила, но и не копейки. Но главное, мы довели её до релиза, до игроков, и те пользовались продуктом, были счастливы и благодарны. Образовалось мощное коммьюнити, которое существовало годами, и игроки сами поддерживали игру. Многие из них до сих пор пишут мне и вспоминают игру. Кое-кто нашёл в игре свою половинку, а кого-то она отвлекала в самые тяжёлые жизненные моменты. Это ни с чем не сравнимое чувство, и оно того стоило.
Но это тема для отдельной статьи. В проекте с хакатона я учёл все полученные уроки, поделился ими с коллегами, поэтому проблем было гораздо меньше. И вот самое ценное, о чём я хотел бы рассказать.
Не делайте проект в одиночку
Я даже комментировать это особо не буду, поскольку из сломанных копий об этот вопрос можно построить пирамиду Хеопса.
Просто не делайте этого. Никогда.
Да, я слышал об успешных случаях. Я вы слышали о неуспешных? Их 99,9%. Вы можете уменьшить вероятность провала в разы, если найдёте единомышленников. Сделать это несложно, даже если вы — социофоб в третьем поколении. Перестаньте искать оправдания и попробуйте.
Не делайте несколько проектов параллельно
Это не железное правило, но всё же. Чаще всего, если у вас несколько пет проджектов, качественно сфокусироваться на каждом не получится.
В какой-то момент вам наверняка станет скучно заниматься текущим проектом, появится идея для нового. Это нормально. Запишите новую идею и положите её в специальную папку. Она дождётся вас, правда. Она не протухнет, и Илон Маск не реализует её раньше вас, скорее всего. Пусть полежит, пройдёт проверку временем и свежим взглядом, а пока займитесь текущим проектом. Один реализованный проект, даже если он плохой и не выстрелил, на десять миллиардов процентов ценнее любого количества недоделок.
Я не всегда соблюдал это правило, но я делаю успехи. Сейчас папочка с идеями у меня как никогда пухлая. И она покорно ждёт своего часа, а наш проект идёт (ползёт) вперёд.
Коммуникации — это всё
Я знаю многих людей, которые считают, что главное — это код. Что нужно пилить его днями и ночами, и всё сложится. Что все эти ваши эджаэлы — это смузи для миллениалов. Я сам таким был. Я также знаю людей, которые уверены, что главное — это миллионы долларов, которые маячат на горизонте, и этой мотивации достаточно. Я знаю фантазёров, которые строят в своей голове воздушный замок и потом воплощают его в реальность, забывая как о пресловутом «кастомер девелопмент», так и о мнении остальной команды. Так вот, что я вам скажу. It«s a bullshit.
Главное — это общение. С пользователями и с командой. Первое — чтобы понимать, как они используют твой продукт, чего они хотят и за что готовы платить. Чтобы не делать бесполезную работу, ведь на проекте, который пилишь в свободное время, цена этого времени многократно выше, и тут ещё нужнее давать пользователям мокапы до того, как начинать фигачить функционал. Большая контора с кучей программистов на фуллтайме может позволить себе сделать фичу за неделю и потестить сразу в бою. На парттайме смело умножайте неделю на десять, добавьте пару нервных срывов и делайте выводы.
Но гораздо важнее второе: общение с командой. Я знаю, что множество программистов считают, что все эти «дейли митинги» нужны лишь для того, чтобы отнимать бесценное время от кодинга и кормить бездельников-менеджеров. Я сам так считал. Но жизнь научила меня простой истине: люди разные. Не все заряжены настолько, чтобы кодить в свободное время без внешней подпитки. А если и заряжены, надолго ли хватит батарейки? Не все достаточно дисциплированы, чтобы начать что-то делать без дедлайна (или с дедлайном, который выдумал сам и никому не рассказал). И уж точно не все одинаково представляют продукт, который вы пилите. Созвоны нужны, и они должны быть регулярными. Никаких «ребят, сегодня запара, давайте завтра» — если хотя бы двое из команды готовы, нужно созвониться, а остальные пусть напишут текстом, но это должно быть исключением. Нужен именно голос, а не переписка. Голос увеличивает эмоциональное вовлечение, что для сохранения мотивации критично. Видео — это уже лишнее. Раз в неделю — оптимально. Нужно определить день и время, и каждую неделю начинать звонок по будильнику. Допустимо подождать опаздывающих или перенести на полчасика. На созвоне нужно дать голос каждому. Спич бодрого менеджера и молчащие программисты — это всё равно что отсутствие созвона. Пусть каждый скажет, что он успел и что планирует сделать, какие возникли проблемы. Если человек ничего не сделал за неделю — это норма. Так будет в 70%-90% случаев. Но нужно это проговорить и спланировать, как всё же сделать что-то за следующую неделю. Ни в коем случае нельзя никого шеймить за это. Как бы банально это ни звучало, токсичность для пет проджектов многократно вреднее, чем в компаниях. Ведь на таких проектах вы не просто команда — вы заговорщики, которые решили свергнуть «дядю». Доверие и открытость при таком раскладе — это крайне важно.
Именно созвоны сохранили нашу команду с момента завершения хакатона. Худший период был именно тогда, когда созвоны заглохли. Но мы вовремя спохватились и восстановили режим. Да, бывают пропуски, но это не страшно. Действительно важно — придерживаться концепции never miss twice.
Чего мы хотим?
Для чего вообще люди делают пет проджекты? Ответ, опять же, сводится к вышеупомянутой истине: люди разные, и цели у них разные. Финансовая независимость, попробовать новые технологии, воплотить мечту детства, сделать мир лучше — популярные, но далеко не единственные виды мотивации, ради которых люди впрягаются в проект и пилят его вместо просмотра очередной серии «Игры ведьмаков». Вам можно, но всё же необязательно знать мотивации ваших коллег. Они могут соврать, а могут и сами не понимать до конца. Может, они так травму закрывают. Это их личное дело.
Но есть общее дело: это цель, с которой все должны быть согласны. Самая оптимальная цель для пет проджекта — выйти в продакшен и найти первого пользователя со стороны (то есть не маму и не кота). В этот момент проект можно будет смело вписывать в резюме и с гордостью говорить о нём на собеседованиях. Из всего моего десятилетнего опыта в программировании на каждом собеседовании всех больше всего интересует мой стартап с игрой, о которой я писал выше.
Договоритесь с командой, что релиз — это главное. Режьте фичи без жалости. Составьте список на «после релиза» и отправляйте туда все буйные фантазии. Когда появятся пользователи, появится и лучший на свете критерий по просеиванию фич для разработки. Сфокусируйтесь на базовой ценности вашего продукта. Если это игра — на геймплее. Метаигру можно будет накрутить и поменять в любой момент, но если геймплей плох, никакая мета не спасёт. Если это софт для конечного пользователя, как у нас сейчас — сфокусируйтесь на той боли, которую ваш софт помогает устранить. В нашем случае это боль в спине. ;) А также множество других проблем со здоровьем и work-life balance.
В больших компаниях можно сделать плохой продукт, завернуть его в красивую обёртку и бухнуть миллионы долларов в маркетинг — это сработает. У вас этого миллиона, вероятнее всего, нет и не будет. Ваш единственный шанс — создать ценность для пользователя.
Да, я говорю о прописных истинах. Но поверьте, люди разные. И в своё время я бы много отдал за такую вот статью с «прописными истинами».
На текущем проекте в какой-то момент мы сказали фичам «стоп» и чётко разделили список на «до» и «после» релиза. Прям сделали галочки и заморозили этот список. Открывали его каждый созвон и видели, сколько осталось до релиза. Галочка за галочкой, мы добрались до заветной черты.
Д — дисциплина
Я уже говорил о регулярности созвонов, и это базовый кирпичик дисциплины. Но есть и другие:
Документация. Звучит смешно для пет-проджекта? Как бы не так. Прежде всего я говорю о дизайн-документе. Это документ, где должно быть чётко прописано, что вы делаете, зачем и для кого. Роли в команде, роли пользователей (если применимо), базовые юзкейсы. Этот документ все участники должны прочитать, и вам нужно достигнуть единогласного принятия. В дополнение к дизайн-документу стоит в целом вести базу знаний, куда можно накидывать идеи, ссылки и так далее. Мы используем GitLab Wiki.
Roadmap. Я, в целом, против того, чтобы указывать конкретные даты (потому что это будет сильно демотивировать, когда вы в них не уложитесь), однако ключевые фичи, которые нужно реализовать, чтобы перебраться на следующий этап, должны видеть все. Для нас составление конечного списка пунктов с галочками стало поводом для самого большого буста энтузиазма.
Регулярность работы. Выберете день и время, когда вы точно будете заниматься проектом. Лучше всего рано утром или поздно ночью, когда вероятность срыва планов меньше. Например, «каждый вторник я буду посвящать проекту час перед сном». Это мой кейс. Не всегда получается, иногда сдвигается, но я стараюсь всеми силами. Можно работать и больше, но это время — святое, его нужно посвятить проекту даже через «не хочу». Заведите будильник или другую напоминалку. А ещё не забывайте оставлять себе-из-будущего подсказки, когда завершаете работу. Чтобы через неделю или больше, вернувшись к проекту, не пришлось тратить полчаса на попытки вспомнить, на чём вы остановились.
Порядок в коде. Используйте репозиторий, пишите внятные сообщения в коммитах, комментарии к сложным функциям и интерфейсам, а также, желательно, пишите тесты хотя бы на типичные позитивные кейсы. Притворяйтесь, что вы делаете большой серьёзный проект, и вы сами в это поверите. :) Аналогичное применимо и для дизайна, и для других ролей. Почему это важно для пет-проджекта? Потому что вы будете возвращаться к работе не каждый день, как на основной работе, а время от времени. Каждый раз придётся восстанавливать в памяти всю картину. Когда проект хорошо структурирован и задокументирован, это будет не только быстрее, но и, что немаловажно при таком характере разработки, приятнее, а значит, вам будет проще заняться делом вместо прокастинации.
Упрощайте
Это очень банальный пункт, но я наблюдаю, как люди совершают одну и ту же ошибку снова и снова, чуть ли не на каждом проекте, которого я касался. Предварительная оптимизация и стремление сделать «как у больших дядь» убили больше стартапов, чем экономический кризис. Например, вы — высококлассный программист. Вы знаете, как сделать кеширование. Отлично! Вы молодец! А теперь не делайте его. То есть вообще не надо, совсем, никакого кеширования. Не ставьте Memcached и не интегрируйтесь с CDN, не используйте мемоизацию, не надо! Вы знаете, как кластеризовать или шардировать базу так, чтобы ваш стартап выдержал миллион пользователей онлайн? Прекрасно! Расскажите об этом на собеседовании. Но не делайте этого в пет проджекте. Даже если вы очень крутой и можете сделать это «за пять минут». Не надо, это очень плохая идея. У любого технического усложнения есть своя цена, есть «шлейф поддержки», который на парттайме умножается на двузначный коэффициент. И главное, вы решаете проблему, которая не просто не существует, а рискует никогда не реализоваться именно из-за того, что вы её решаете.
Поверьте, если ваш проект упадёт в первую же секунду после старта из-за наплыва пользователей, это будет замечательно! В этот момент вы поймёте, что проект востребован, забросаете текущее решение серверами, затем наймёте роту программистов, выбросите свой прототип и напишете highload-решение с нуля. Это же явно лучше, чем если вы сделаете проект, рассчитанный на миллион онлайн, но на запуске в него не зайдёт никто, кроме вас, не так ли?
Я наблюдал, как люди пытаются сразу делать микросервисы там, где монолит ускорил бы разработку многократно и давно бы уже показал, что они делали проект, не нужный людям. Всё освободившееся время они потратили бы на то, чтобы сделать другой проект, который уже был бы нужен людям. Ровно та же история с дизайном, чрезмерной безопасностью или сверх-хитрой схемой монетизации и распространения.
Пройдя через десятки бекэнд- и фронтэнд-фреймворков я пришёл к тому, что свои новые эксперименты я начинаю с одного-единственного файлика для бека и чистой html с инлайн-js+css для фронта. Иногда этого достаточно, а иногда я переползаю на фреймворк, но только тогда, когда вижу, что я столкнулся с проблемой, которую тот решает.
Именно такой стратегии мы придерживались в нашем проекте. Мы взяли Electron и готовые нейросети, наверстали с html+css красивый, но всё же прототипный дизайн с заимствованиями, добавили несколько чисто js-ных функций с «читерской» математикой для детекта осанки и получили цельный, продуманный, удобный прототип, с которым победили на хакатоне. Уже в процессе дальнейшей проработки мы встретились с усложнением продукта и перешли на Svelte. Но если бы мы взялись за Svelte сразу, мы бы точно не успели сделать прототип на хакатоне и не смогли бы победить, и наш проект, скорее всего, никогда не дожил бы до релиза.
Заключение
Благодарю за внимание всех, кто дочитал эту статью. Буду надеяться, что она оказалась кому-то полезной. Также я буду рад любым комментариям, исправлениям, критике. Поделитесь вашим опытом и вашими лайфхаками — я хотел бы улучшить свой подход. :) И конечно, мы были бы рады узнать ваше мнение о продукте. Стали бы вы пользоваться подобным ассистентом? На какой платформе и для каких целей по здоровью? Готовы ли платить? Да, это маленький кусочек «кастомер девелопмента», не обессудьте. :)
