Хакатон. Ничего не понять и почти дойти до финала

Данная статья является ретроспективой нашего участия в хакатоне Optimize & Organize Challenge, неким подведением итогов. Постарался собрать как можно больше разных выводов, артефактов, чтобы наиболее объективно отразить и оценить наш процесс работы в команде.

В то же время без погружения в супер детали и нюансы, поскольку размер статьи увеличился бы в 2-3-4-5-n раз, а пользы от дополнительной информации было бы не сильно больше

Ниже в основном будет освещаться общий алгоритм создания дизайна сервиса

Статья может быть полезна:

1) Продуктовым дизайнерам

2) Для тех, кто собирается принять участие в подобных мероприятиях

3) Для тех, кто уже работает в команде над каким либо продуктом

4) Кому хочется чего то почитать для общего развития, приятно провести время:)

7-10 апреля мы с ребятами принимали участие в хакатоне по разработке концепции сервиса по учету объектов недвижимости и контроля процесса работ на данных объектах

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

Игорь - back-end

Ваня - back-end

Вася - аналитика

Я - UX/UI

Костя - front-end

Ни у кого из участников команды не было опыта участия в хакатонах)

Дальнейшая структура повествования:

Навигация по статье:

Летсгоу:)

Подготовка, распределение задач, формирование базового понимания происходящего

Все началось с того, что в 20:00 по нск организаторы выложили условие задачи (ТЗ)

В условии объяснили:

1) Общие требования к сервису

2) Конкретный список функций, реализовывать все необходимо только для компьютерной версии

3) Критерии оценивания (Бек, фронт, структура проекта на Git, информационная архитектура приложения, качество реализации функций)

По началу у каждого из нас были +- одинаковые задачи:

Также мы договорились провести общий созвон в начале следующего дня (Своего рода дейлик)

После обсуждения и изучения ТЗ с ребятами у меня появилось несколько вопросов для Q/A сессии:

Кто ведёт рабочие группы на объекте? Что имеется под качеством исполнения работ на объекте? Кто контролирует качество исполнения работ на объектах?

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

Сразу скажу, что 2 и 3 пункты не помогли от слова совсем о них расскажу позже)

Начало Q/A сессии. В общей сложности она продлилась около часа, на мои вопросы ответили, также ответы на вопросы других участников помогли мне больше погрузиться в контекст происходящего. Однако на этом этапе вопросов у меня стало ещё больше)

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

На данном этапе имеем следующие типы пользователей:

Госинспекция

Коммерческая организация

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

Режим hard work: on. Собираем бизнес логику «на коленке», оцифровываем требования организаторов и информацию обо всех сущностях воедино

За ночь Игорь и Вася разобрали продукт на основные сущности в беке и приступили к их реализации

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

Слушаем запись вчерашней Q/A сессии, транскрибируем ответы, структурируем ответы по категориям чтобы:

1) Не упустить важных деталей и иметь на руках все CX артефакты

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

Формируется более менее полная картина бизнес процесса (начиная от просмотра обьекта, заканчивая назначения этапа работ на нем)

Получается более точно определиться с ролями в системе и доступным им функциями

Сотрудник ГИН

Орган исполнительной власти

Результат взаимодействия данных пользователей и цикла работы по обьекту: Назначается следующее совещание (рабочая группа) по обьекту либо объект считается закрытым и исключается из реестра ГИН

Теперь мы имеем на руках информацию (Хотя в некоторых местах неполную), с помощью которой можно приступать к созданию прототипа продукта

Созваниваемся с ребятами, синхронизируемся. Обсуждаем как в целом будет работать наш сервис

Продолжаю работу над прототипом

За 7 минут нам надо было презентовать прогресс по беку/фронту, бизнес модель и логику работы интерфейса + задать вопросы

Времени мало, сориентироваться было непросто. Сам чекпоинт получился весьма «скомканный»

Инсайт: если встреча проходит в онлайне, можете выбрать ответственного за конспектирование ответов на вопросы, резюмирование встречи. Ответы на некоторые вопросы могут (забыться + не до конца поняты с первого раза) → быть неверно интерпретированы командой в будущем. Чтобы избежать подобной ситуации можно назначить 1 человека, который где то сохраняет ответы, делает запись встречи

Созваниваемся с ребятами, синхронизируемся. Обсуждаем первичные прототипы каждого сценария сервиса

1. Общие соображения по процессу

Как было у нас:

Обсуждение всех сценариев → Создание прототипов всех сценариев → Обсуждение прототипов сценариев → Создание дизайна всех сценариев → Обсуждение дизайна → Отправка на прод

Как возможно было бы эффективнее:

Обсуждение одного сценария → создание прототипа одного сценария → Обсуждение прототипа сценария→ Создание дизайна одного сценария → Обсуждение дизайна → Отправка на прод → Начало работы над следующим сценарием(Либо работаем параллельно над несколькими сценариями)

Сейчас кажется, что второй вариант работы мог быть более эффективным, поскольку в этот день к 19 часам фронт не мог полноценно начать работать над интерфейсом из за отсутствия понимания, что «рисовать»

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

2. Приоритизация

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

3. Поддержка темпа работы

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

Завершение работ над беком, фронтом и дизайном

Завершаю работу над прототипами, структурирую сценарии

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

1) Отказываемся от логики роадмапа в карточке объекта (Организаторы сказали можно этот элемент не прорабатывать) + На стороне разработке не было необходимой сущности для его реализации

Оставили альтернативный вариант - история принятых решений по объекту

2) Отказываемся от списка поручений и событий в карточке объекта. Недостаточно данных, которые бы позволили сделать вывод о необходимости наличия списка в карточке объекта + время разработки было сильно ограничено, решили отказать от этой идеи

Приступаю к созданию дизайна. У меня на руках была только информация с Q/A, в некоторых местах ее было недостаточно, чтобы принять более осознанное решение в пользу размещения тех или иных вещей на экране. Поэтому действовал по большей части на основе логики и здравого смысла:)

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

Презентовали прогресс по беку, фронту, дизайну. Вопросов на этот раз мы решили не задавать. Также организаторы попросили добавить дашборд на экран реестра объектов

Зачем и почему это надо мы так и не поняли, но в каком то виде все таки решили показать эту фичу

У ребят получилось наладить первый контакт бека с фронтом

Дизайн всех сценариев полностью готов. Добавил урезанную версию дашборда в реестр по просьбе организаторов

Посмотреть финальный дизайн полностью можно тут

Теперь осталось только ждать и надеяться, что фронт хотя бы в каком то виде все вытянет)

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

Отправляем проект организаторам

Структурирую информацию о проекте в презентации, ребята загружают проект и презентацию на сайт организатора. Ждем результатов:)

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

Но)))

Жалко конечно, но как есть так есть. Естественно хотелось получить обратную связь от организаторов. Мы им написали. Вот, что нам ответили

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

Также когда мы задавали вопросы по проекту в течение хакатона, на них нам никто не ответил

На тот момент подумал, что если мы в финал с такой работой не попали, то топ 30 нам не видать даже xd

Но)))

Я был немного удивлён, что от финала нас отделяло буквально 1 место. Все таки все не так уж и плохо xd

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

Всем ребятам большой респект, было видно, что они оч шарят и заряжены на победу. Благодарю Ваню за то, что предложил принять участие в хакатоне. Если ты hr/лид и ищешь себе в команду разрабов, то смело пиши им:)

Ваня

Игорь

Костя

Вася

А если ищешь продуктового дизайнера, то я тут:)

Ещё пишу в телеге оч редко, но метко про софт скиллы и работу над проектами, если интересно заходи)

В целом как то так. Спасибо, что дочитали до конца ❤