Как сократить время разработки до двух дней — опыт участия в хакатоне RailsRumble

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

Сейчас популярны хакатоны. Это соревнования, в ходе которых за минимальное время и с минимальными ресурсами нужно создать рабочее веб-приложение. Конечно же, не просто рабочее, а инновационное, с прекрасным интерфейсом и чистым кодом. Словом, всё как в обычной жизни. Кстати, в Facebook с завидной регулярностью проводятся внутренние хакатоны, и некоторые из самых интересных фич появились именно благодаря
им
, — например, кнопка Like.

В мире Rails-разработчиков самым известным хакатоном считается
RailsRumble
, который вот уже шесть лет собирает разработчиков со всего мира и мотивирует их писать код. По правилам конкурса участники должны за 48 часов создать полностью готовое веб-приложение с оригинальной и новаторской идеей. В этом году участвовало 500 команд и более 1500 человек. Cреди них — наша команда.

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

Устроили мозговой штурм, среди вариантов несколько раз упоминались спортивные приложения. Это соответствовало нашим критериям — быть интересным не только нам, быть полезным не только для хакатона. Так появился сервис для футбольных болельщиков
Sport for Social Fans
. Идея простая: на одной странице автоматически собираются и обновляются все новости твоего клуба/игрока в социальных сетях. Данные подтягиваются из официальных аккаунтов и по хештегам пользователей Facebook, Twitter и Instagram.

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

Мы подготовили прототип на
uxpin
(сервис для коллективного создания прототипов). Он был достаточно простой — только самые основные элементы, провязки между страницами, никаких деталей и контента. На этом этапе у нас совсем не было разногласий: нам казалось, что все всё поняли, и всё работает. Все остальные сюрпризы ждали нас после начала марафона.

Несмотря на подготовительные работы, окончательное видение сервиса сложилось только к середине первого дня. Такова селяви, как говорится: особенность всех прототипов в том, что большинство ошибок и неточностей нельзя разглядеть, пока не начнешь собирать живую картинку и подтягивать реальный контент. Когда мы начали прорисовывать прототип, мы выяснили, что информационный блок про команду слишком большой, а сами посты — маленькие, и нужно их обязательно разбавлять картинками. Мы перекомпоновали макет сразу на уровне отрисовки интерфейса. Переделки вызвали волну обсуждений — пришла новая волна идей, совсем не похожих на те, что мы обсуждали до начала марафона. В какой-то момент мы начали захлебываться от желания «всё переделать по-нормальному». К счастью, марафон задает такой темп, что переделывать что-либо существенно нет времени. Приходится сразу писать на чистовик. Поэтому мы постарались вернуться к первоначальному плану, а все новые идеи отложить на будущее.

Перед началом хакатона мы отдельно проговаривали распределение ролей. Конечно, это не бином Ньютона — дизайнер занимался дизайном, а программисты кодом. Но все очень зависят друг от друга, и мы заранее постарались выстроить последовательность действий так, чтобы никого не поставить в тупик «не могу продолжать, пока Вася не закончит». У нас было большое преимущество — все ребята работают удаленно в разных частях света. За счет разницы во времени всегда есть кто-то, кто может работать, пока остальные спят. При этом никаких проблем с коммуникацией — команда сыгранная. Для связи — Basecamp для глобальных обсуждений и «многабукв», Skype для непрекращающихся разговоров.

Судили
нас заслуженные народные кодеры, менеджеры, руководители стартапов и просто гики. В результате они должны были отобрать лучшие (по их мнению) десять проектов-победителей. Теоретически, это должны были быть инновационные (ну хоть чуть-чуть) приложения, которые меняют жизнь к лучшему и просветляют карму. В действительности, понять логику отбора трудно. Сейчас сложилось субъективное ощущение, что выиграли проекты более яркие визуально, при этом не обязательно технически совершенные. Например, в этом году в десятку вошла игра
Llama or Alpaca
– очень приятное фановое приложение с нулевым коэффициентом полезного действия.

Теперь подробнее про ошибки и как на них научиться. До начала отрисовки макета мы были полностью уверены, что на уровне планирования сделали всё, что могли. Но никогда нельзя верить этому ощущению. Да, 100% будущих ошибок нельзя заметить на уровне макета, и все же мы могли сделать их меньше, если бы приложили к макету живые данные. Или написали пользовательские сценарии, чтобы понять конкретнее, что пользователь будет хотеть от сервиса. Конечно, в сроки разработки всё равно стоит закладывать время, которое уйдет на новые уточнения и дополнения. В идеальных неземных условиях они должны быть незначительными. В реальной жизни вам, скорее всего, захочется переделать всё. Если у вас есть только 48 часов, приоритезируйте  желания и отказывайте себе во всем, кроме самого главного. Всю красоту можно будет добавить в следующих итерациях.

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

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