Как сделать разработчикам приятно — опыт Netpeak

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

Зачем кодить вне работы?

У нас в Netpeak есть собственная ERP/CRM система (да, хвастаемся). Ее задача — автоматизировать бизнес-процессы агентства. Как это работает? Человек заполняет заявку на нашем сайте и система ведет его через целый набор сервисов. Она распределяет работу с нашим потенциальным клиентом в планировщик. ERP/CRM система автоматизирует составление документации для работы, интегрируя финансовые данные с 1С и многое другое.

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

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

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

Какие задачи мы ставили:

1. Обучение программистов, их профессиональное развитие.
2. Обмен/приобретение опыта вне рамок внутренних регламентированных команд.
3. Возможность поработать с технологиями, с которыми они раньше не сталкивались.
4. Попробовать новый формат тимбилдинга.

Как проходил первый хакатон Netpeak

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

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

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

Это, конечно, тоже рабочее пространство, но не наше. Поэтому ребята смогли абстрагироваться и расслабиться, почувствовать, что участвуют в каком-то необычном интересном ивенте.

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

Мы выбрали проекты и разделились на команды, у каждой было 40 минут, чтоб подготовить бриф по своей задаче. Что в брифе: рассказать, что хотим делать, зачем это нужно, как планируем реализовать, какой результат получить к концу дня. Затем приступили к работе.

Кто-то занимался парным программированием (вдвоем за одним монитором), кто-то поделил работу на зоны ответственности и каждый делал свою. В конце дня все еще раз собрались и каждый рассказал, что у него получилось сделать, показал рабочую (или нерабочую) модель, рассказал о том, с какими трудностями столкнулся, что удалось решить, что нового узнал.

Одна команда выбрала самый непростой путь и осваивала новый для себя язык программирования

Что получилось:

1. Создать душевную атмосферу с интересными сложными задачами.
2. Развить навыки, решая задачи, с которыми не сталкиваешься в работе.
3. Обменяться опытом. Даже джунам есть чему друг у друга поучиться: у них может кардинально отличаться подход к решению одних и тех же задач.
4. Познакомиться поближе, сплотиться. Это особенно важно для тех ребят, которые по работе никак не пересекаются.
5. Провести ивент, который хочется повторить в более грандиозном масштабе.

Что не получилось:

• получить на выходе готовые рабочие прототипы. Только одна команда сумела предоставить зародыш плагина для трекинговой системы задач, который худо-бедно работал. Остальные не продвинулись до той стадии, когда им мог бы понадобиться QA;
• сделать соревновательный эффект между командами.

Плюшек все-таки больше

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

Во-первых, сменили обстановку. Это очень важно, так как вариант «вне офиса» создает особую атмосферу ивента. Соответственно вдохновляет сотрудников и увеличивает их продуктивность.

Во-вторых, решили новые задачи. Ребята столкнулись с тем, чего никогда не делали и глубже поняли процесс разработки. О чем речь: рядовой Junior не сталкивается со стеком серверных технологий. Он выполняет задачу, отдает тимлиду, и не знает, как в дальнейшем проходит работа с ней. Тем более он плохо знаком с задачами, которые покрывают серверные администраторы. На хакатоне ребята самостоятельно выполняли работу коллег.

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

Что еще? Переложили теорию на практику: накануне сотрудники делали доклад по одной из новых технологий, которую мы использовали на хакатоне.

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

Плюс — вкусно поели: организовали кейтеринг.

Как провести хакатон без факапов?

Главное, что мы вынесли из собственных просчетов в планировании и организации нашего ивента — выделили слишком мало времени на него и выбрали не самый лучший день (многие сотрудники не смогли участвовать). Отсюда и трудности, о которых пойдет дальше речь.

Вместо одного дня нужно два-три

Мы запланировали 12 рабочих часов, но по факту: минус полчаса пока все собрались, минус час на пиццу и пиво, минус час на презентацию в начале и в конце. Итого, рабочего времени около 9,5 часов. Этого мало, чтобы разработать продукт от идеи до воплощения.

Кроме того, много времени ушло на то, чтобы поднять себе среду.

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

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

Что решили на будущее: время на поднятие среды выделять перед хакатоном. Тогда ребята гораздо дальше продвинутся на самом ивенте. Плюс — продлить мероприятие на два-три дня (сотрудники только за).

Офис — плохая идея

Нам нужно было выжать из одного дня максимум, а значит — хакатонить без передышки. Итог: до 18.00 все были в хорошем рабочем состоянии, а потом наши мозги вскипели.

Обычно для подобных мероприятий арендуют дом с зонами отдыха, развлечений. Почему? Когда прогеры не могут решить какую-то задачу, они делают перерыв. И в беседе на кухне, во время игры в настольный теннис, находят неожиданное решение — тут же идут его реализовывать.

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

Во-вторых, чтобы устроить зоны развлечений и отдыха. Из развлечений планируем приставку с файтером ПВП, теннисный стол. Обязательно выделим зоны для сна. Чтобы в любой момент можно было отключиться и разгрузить голову.

Так удастся асинхронизировать процесс: один работает, другой спит, потом меняемся. Больше времени, неформальная обстановка, дистанцирование, на наш взгляд, еще больше сплотит команду.

Мало участников и не было призов

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

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

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

Готовый продукт — довольная команда. Ведь разработчикам очень хочется довести начатое до конца.

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

И напоследок, вместо выводов: что нужно, чтобы организовать качественный хакатон:

1. Подходящее помещение — не офис, достаточно места, хороший Wi-Fi.
2. Запас времени и желание разработчиков потратить это время.
3. До начала мероприятия участники подняли себе окружение.
4. Зоны отдыха от умственной деятельности.
5. Достаточно опытных разработчиков для комплектации команд.
6. Кейтеринг.
7. Накануне хакатона — вводная лекция по необходимой технологии.
8. Соревнование команд на ивенте.