«Если идея становится настолько глупой, что вам за нее стыдно, — вы близки к цели» — как я выигрываю хакатоны

Алексей Тактаров
Алексей Тактаров

Кофаундер Resume.io, один из создателей сообщества Code Hipsters

Расскажите друзьям
Виктория Кравченко

Кофаундер Resume.io, один из создателей сообщества Code Hipsters и победитель хакатона Open Fights Codility Алексей Тактаров делится своим опытом участия в хакатонах и объясняет, чем они могут быть полезны именно вам.

Когда я не уверен в своих силах, иду на хакатон

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

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

Свой первый хакатон я посетил в 2013 году, когда учился в Швеции. Он назывался Protothon и был посвящен только набирающей обороты теме интернета вещей. Я увидел объявление на фейсбуке и решил подать заявку, а через две недели меня пригласили поучаствовать.

Скажу честно: пока я ехал на утреннем автобусе в Стокгольм, переживал, что не справлюсь и не смогу написать работающий код из-за волнения. Оказалось, что напрасно — участникам было запрещено программировать! Нас объединили в команды и предложили показать, как умные устройства могут быть интегрированы в повседневную жизнь. В конце дня мы представили идею интерактивного экрана, которым можно управлять, лежа в кровати. Звучит безумно, и мы вряд ли бы успели сделать прототип, однако презентации было достаточно.

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

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

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

Правило 1. Фокусируйтесь на главном

Все просто! Когда мы рисуем идею в своей голове, мы не специально добавляем лишние детали. Они мешают нам выбрать правильный фокус и начать работать.

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

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

Если идея становится настолько глупой, что вам за нее стыдно, — вы близки к цели! Проблема в том, что мы склонны планировать гораздо больше, чем способны сделать, особенно в сжатые сроки.

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

Вы вряд ли успеете за два дня реализовать функционал, на который у инженеров Airbnb ушли годы.

Вместо этого введите искусственные ограничения:

  • Пусть ваш сервис ищет только квартиры для двух человек, которые путешествуют на выходных и останавливаются на 2-3 дня. Далее вы осознаете, что вам нужно сделать бек-офис для владельца квартиры, мобильное приложение, отмену заказа, оплату, групповой платеж…

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

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

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

Правило 2. Используйте проверенные инструменты и команду

Перед хакатоном я часто слышу от участников: «в своем проекте мы будем использовать Elm/Elixir/Redux/Meteor.js, потому что это язык/технология/стек, в котором мы давно хотели разобраться». Это опасное решение. Нет ничего плохого в том, чтобы применить новую для себя технологию, но это повышает риск не получить результат вовремя.

Лучше, если вы будете использовать инструменты, в которых вы уверены. Фронтендеры наверняка слышали шутку про команду, которая неделю настраивала Webpack, прежде чем начать работать.

Такие технические сложности принесут вам новый опыт, но не приблизят к цели — быстро получить прототип, иллюстрирующий идею. Это распространяется и на команду: отдавайте предпочтение людям, с которыми вы раньше уже работали. Оптимальный размер команды 2-3 человека, дальше начинаются сложности коммуникации и делегирования обязанностей.

Недавно команда Intercom выпустила книгу, где был описан тип людей, которых стоит нанимать на ранних стадиях компании — «генералисты» (generalist).

Такие сотрудники отличаются способностью переживать за весь продукт вместе с вами и выходить из зоны своих способностей при необходимости. Работая с генералистами на хакатоне, вы сможете продолжать горизонтально делегировать задачи и при этом рассчитывать на помощь своих коллег. Будьте и сами готовы примерить разные роли: написать скрипт для демо, подрисовать дизайн или провести интервью с целевой аудиторией.

Правило 3. Как можно раньше получайте результат

Научитесь разбивать свой прогресс на небольшие законченные результаты. Под давлением дедлайнов на хакатонах царит хаос: многие команды не успевают собрать прототип, который можно показать к финалу. Движение итеративными шагами дает преимущество в виде запасного плана, если что-то пойдет не так.

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

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


Рубрика «Инновации в корпорациях» выходит при поддержке Spinon.


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

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

Этот принцип используют реальные продуктовые команды, знакомые с Lean и Agile, а также дизайнеры, применяющие подход Human-Centered Design (если вы незнакомы с этим термином, посмотрите короткий ролик от Vox про двери Нормана).

Правило 4. Применяйте сторителлинг

Запомните: вы работаете на презентацию. Продукт или идею, которую вы делаете на хакатоне, придется показывать реальным людям. Безусловно, не многие умеют выступать на публике, но это порог, через который придется переступить.

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

Люди любят истории. Расскажите, как ваше решение решает проблему людей и будьте очень внимательны к деталям. Опишите на примере пользователя, придумайте ему имя и предысторию.

Например: «Павел уже два года управляет командой дизайнеров. Его уважают, он хорошо понимает процессы компании. Павел использует почту как инструмент общения с коллегами: отправляет комментарии к макетам, высылает список правок. Ежедневно он отправляет порядка 40-50 писем. Это отнимает много времени, а еще иногда происходит рассинхронизация в команде. Мы предлагаем упростить жизнь Павла: представляем DesignBoard — контроль версий для дизайнерских команд».

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

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

Среди презентаций проектов на Open Fights Codility мне особенно запомнилось выступление девушки Яны, которая в одиночку запрограммировала веб-сервис для учета персональных расходов. Ее приложение, кроме всего прочего, содержало чат-бота по имени Паша Кирпич, который случайным образом предлагал купить валюту и время от времени делал нецензурные замечания. Примечательно, что на этом функции бота заканчивались, но такая мелочь сделала презентацию интересной и запоминающейся.

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

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

***

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

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


Материалы по теме:

«Глупо надеяться на лайки и шеры, если вы не вкладываетесь в раскрутку» – как мы запустили корпоративный блог

«Даже лучшие бизнес-аналитики и маркетологи могут выдать только гипотезу. Поэтому появился agile»

Как развивать корпоративные инновации: кейсы, которых на рынке не так много

Как мы запустили технологичное производство в России (и это выгоднее, чем работа с Китаем)


Самые актуальные новости - в Telegram-канале Rusbase


Комментарии

Комментарии могут оставлять только авторизованные пользователи.
IT Synergy
23 ноября 2017
Ещё события


Telegram канал @rusbase