История одной фичи или зачем хакатон программисту

в 13:03, , рубрики: история, опыт, хакатон, Хакатоны

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

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

Расскажу свою историю и, возможно, она убедит вас в обратном.

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

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

Как мы не хотели участвовать в хакатоне

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

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

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

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

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

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

Цель проста: дать пищу для анализа, чтобы понять где кроются проблемы и какие есть точки улучшения.

История одной фичи или зачем хакатон программисту - 2

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

На первый взгляд данных не так уж много: мы знаем какие задачи были поставлены человеку и знаем успел ли он их сделать в срок. Но что если попробовать собрать метрики «верхнего» уровня и дать возможность дойти до исходных данных. Должно быть интересно и с точки зрения результата, и с точки зрения разработки. Почему бы и нет?

Ну что ж, идея есть, отлично! Осталось найти команду.

Это, как ни странно, оказалось самой легкой частью. Мне повезло, что вместе со мной работают легкий на подъем программист Саша (@MonkAlex) и опытный, но все еще готовый к любому экшену, аналитик Владимир. Обсуждаем детали, решаем с чего будем начинать и в каком формате работаем. Придумываем название – «Мониторинг и анализ».

История одной фичи или зачем хакатон программисту - 3

Поехали…

О том, как мы не победили в хакатоне

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

Работать решили гибко, главным и единственным критерием было сделать что-то работающее к концу хакатона. Первым делом мы нарисовали карту фич. Дальше отметили приоритетом [0] то, без чего вообще нет смысла идти на демонстрацию – в нашем случае это была стартовая страница с набором виджетов. Потом прикинули, что будем делать, если останется время (в итоге половину из этого сделали, а половину представили, как потенциальные пути развития). И начали «пилить».

История одной фичи или зачем хакатон программисту - 4

Примерно час потратили на поиск готовых компонентов, параллельно развернули тестовую инфраструктуру.

Начали с «бублика» исполнительской дисциплины. Сделали его парно с Сашей – так было проще вникать в новую тему. Заодно накидали «скелет» для остальных виджетов. Форма с единственным виджетом, работающая на более-менее реальных данных была готова уже через три часа.

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

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

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

История одной фичи или зачем хакатон программисту - 5

Кроме нас из 7 команд-участников только у двух получилось довести идею до работающего прототипа. В итоге все три команды и стали призерами, а нам досталось почетное второе место.

Мы уступили ребятам, которые сделали анализатор входящих сообщений с преобразованием в элементы ToDo-листа. Объективно, у них был более серьезный технологический стек, больше команда (7 человек) и идея, пожалуй, была интереснее.

Как из идеи вырастает фича

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

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

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

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

Начали с проектирования:

  • Выкинули фичу «Анализ согласования», так как с ней точно не успели бы закончить в срок.
  • Убрали лишнее с главной страницы.
  • Проработали страницы с детализацией.
  • Решили, что 5 самых загруженных сотрудников – это мало и увеличили их количество вдвое.

И мы в итоге успели. По факту могу сказать, что итоговая реализация стоила примерно в 10 раз дороже прототипа.

Так выглядела главная страница:

История одной фичи или зачем хакатон программисту - 6

А так детализация по людям и временной шкале:

История одной фичи или зачем хакатон программисту - 7

Фича вошла в продукт и ей начали пользоваться. Не очень активно, но мы изначально понимали, что в таком виде это штука не массовая и ее целевая аудитория – это несколько людей в компании.

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

Казалось бы, простая вещь, но тем не менее с помощью нее можно отслеживать массу тенденций. Чтобы донести это до пользователей и с целью пиара новой темы, и чтобы пояснить что это такое и зачем написали статью Развитие интерактивных инструментов СЭД для анализа эффективности работы сотрудников.

Фидбек в целом был положительным, но фича не стала массовой и осталось ощущение незаконченности.

Как фича живет и развивается

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

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

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

История одной фичи или зачем хакатон программисту - 8

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

История одной фичи или зачем хакатон программисту - 9

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

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

Почему вам стоит поучаствовать в хакатоне

В заключение хочу поделиться теми выводами, которые я сделал для себя за этот год:

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

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

3. Хакатон – отличный способ донести идею до руководства
Как правило решения о том, как будет развиваться продукт принимает руководство. Но заказчикам и product owner’ам тоже требуется помощь в выборе фич. В рамках ограниченных ресурсов всегда хочется выбрать фичи максимально полезные и для пользователей и для компании-разработчика. Убедить кого-то в своей правоте на словах не просто, но когда вы покажете реально работающий прототип — ваши шансы сильно возрастают.

4. Решения с хакатона могут быть успешно интегрированы в реальные продукты
Да, на это потребуется время не соизмеримое с тем, за сколько вы это сделали на хакатоне, и в результате от вашего прототипа останется только общее направление, но тем не менее это возможно.

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

Вместо заключения

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

История одной фичи или зачем хакатон программисту - 10

Фича вызвала положительный фидбек у руководства и возможно она тоже когда-нибудь будет полноценно реализована в продукте.

Для себя я твердо решил, что если предложат еще раз принять участие в хакатоне – обязательно соглашусь. А что по этому поводу думаете вы?

Автор: dkiz

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js