Я тут подумал, что мне есть что сказать на эту тему. Опыт поражений и побед в хакатонах сформировал у меня несколько идей, сформулированных ниже. Думаю, они будут особенно полезны тем, кто учавствует не первый раз и всерьёз хочет победить. Но эти идеи применимы и за пределами хакатонов.
Решение о том, кто займёт призовые места по кейсу компании, принимают её представители. Обычно они уже находятся в контексте задачи и имеют представление о том, каким должен быть победитель. Логично тогда делать так: на протяжении всего хакатона вы подгоняете свой проект под их ожидания, и к концу проект должен максимально с этими ожиданиями совпадать. Далее во время презентации вы показываете суть того, что сделали.
Ну, мне такая модель казалась логичной, и я ей следовал. Да и в целом она работает. Вы можете найти огромное количество статей, которые дают советы в рамках примерно той же модели, и эти советы стоят внимания: больше общайтесь с экспертами, заранее готовьте презентацию, иногда спите, и так далее. Но я из своего опыта заметил, что есть эффекты, которые искажают эту модель. И эти искажения могут стоить вам призового места.
Эффект 1. Разрозненность представителей.
У компании часто несколько представителей на кейс. Построение продукта на основе переговоров с одним экспертом может привести к тому, что результат не будет подходить под видение остальных. Важно учитывать, что у нескольких экспертов нет общего представления о лучшем решении и наборе критериев. Да, они обычно заранее обсуждают критерии между собой, но в итоге вы всё равно общаетесь с конкретным человеком, додумывающим на ходу вещи, с которыми остальные могут не согласиться.
Эффект 2. Искажение критериев.
Эксперт часто не знает, чего хочет. Даже если говорит, что знает. У него обычно есть ясное представление о каком-то аспекте решения: к примеру, каким должен быть UX. Он понимает, как должно быть, почему именно так, и на что нужно смотреть при оценке. И тут всё в порядке. Проблема возникает, когда он начинают говорить о том, чего не понимает.
Вот вы спросили: а каким должен быть код? Вам ответили: код должен быть чистым. Окей, требование от экспертов получено. Вы радуетесь, что прекрасно понимаете, что такое чистый код, и способны в полной мере выполнить это требование. Вы тратите половину рабочего времени на архитектуру и получаете полностью готовый к продакшену продукт. И... эксперты не обращают на это внимания.
Оказывается, тот, кто вам это сказал, хорошо разбирается в UI/UX, но имеет смутное представление об архитектуре ПО. И на самом деле он так сказал потому, что слышал, что чистый код — это хорошо. Или в его понимании чистота неразрывно связана с тем, будет ли приложение глючить или нет.
Эффект 3. Технические ограничения процедуры оценки.
Процедура оценки имеет свои ограничения. Эксперты не могут уделить каждому решению одинаковое количество времени, иначе этого времени не хватило бы, чтобы вникнуть во все решения. Обычно есть шорт-лист интересных проектов, который используется и во время работы над кейсами, и во время принятия решения. Но даже оценка проектов из шорт-листа может сильно искажаться процедурой принятия решений: решение зависит от факторов, которые эксперты не считают важными. В ходе принятия решения эксперты подвержены различным когнитивным искажениям, что демонстрируется в примере.
Представим такой кейс: нужно сделать платформу для автоматической доставки приложений на сервера. В поле зрения экспертов сейчас находится решение конкретной команды. В нём есть возможность установки начального ПО на сервер через веб-интерфейс, через указание пользователя и пароля для подключения по SSH. Эта фича имеет место быть, но она на самом деле достаточно сомнительна: не то чтобы это реально удобнее ручной установки, и при том создаёт на пустом месте дополнительные риски информационной безопасности. Но эта фича показалась экспертам достаточно уместной. Как бы почему нет, пусть будет.
Переходят к следующему проекту. Там тоже эта фича есть. Следующий. А тут этой фичи нет, зато есть другая фича: возможность настроить уведомления о событиях в пайплайне на почту. При оценке проекта бросается в глаза, что нет той фичи, что была у всех предыдущих. Но предыдущие уже были обсуждены, о них сложилось определённое мнение. Будет ли оно изменено из-за того, что тут есть фича, которой не было у них? Вполне просто себе представить, что нет: порядок проектов повлиял на то, какое о них сложилось мнение. И это всё при том, что первая фича не имеет особого смысла, а вторая реально полезна.
Эффект 4. Распределённость процесса оценки.
Как уже стало видно, процесс оценки с точки зрения экспертов сложен даже чисто технически, особенно если они пытаются подойти к оценке объективно. И тут важно понимать, что он распределён на всё время проведения хакатона: питч-сессии и другое общение с экспертами влияют на итоговую оценку. Через взаимодействие во время работы формируется представление о вас, от которого зависит, какое именно место вы будете занимать в процессе принятия финального решения. Шорт-лист обычно сформирован ещё задолго до презентации.
Эффект 5. Влияние среды.
На оценку могут влиять детали, не относящиеся к сути кейса. Например, площадка проведения может просить представителей компаний учитывать участие в сторонних активностях. Я один раз столкнулся с тем, что в этом признались представители. При этом они признали, что не могут публично раскрывать этот слой критериев.
Эти эффекты, как видно, могут ломать описанную схему. И вот вы вроде бы реально сделали крутой продукт. Вам кажется, что эксперты тоже видят хороший результат именно так: они ведь сами говорили, что это действительно важно. Вы максимально эффективно выстроили работу над решением. Но побеждает другая команда.
Что с ними делать?
У меня нет готового решения, позволяющего контролировать каждый из этих эффектов. Но есть некоторые логичные гипотезы:
Нужно учитывать иерархию внутри группы представителей и, если возможно, узнать, как именно происходит принятие решений. Исходя из этого, стоит думать о том, как продвинуть своё решение внутри этой процедуры.
Нужно учитывать каждого представителя: как для прояснения их видения, так и для донесения до них своих идей.
Нужно учитывать, что тот, с кем вы общаетесь имеет отличный от вашего опыт, и одни и те же термины или формулировки могут для него значить одно, а для вас другое. Следует уделять внимание тому, как думает эксперт, кроме того, что он говорит.
Есть смысл выбирать кейс на основе того, насколько вероятны эти эффекты. Например, если представители экспертны в том же, в чём и вы, вам, скорее всего, будет проще найти с ними общий язык, в частности снизив эффект значимости аспектов результата.
Нужно влиять на решение с самого начала до самого конца. Если ваше решение в шорт-листе и его активно сравнивают с другими, даже мелкие детали могут иметь большее значение. Но здесь важно учитывать и остальные эффекты: например, важность детали должна быть понятна экспертам.
Нужно заранее выяснить особенности компании и/или площадки. Возможно, вы сможете из опыта других команд узнать какие-то неочевидные моменты, вроде того, что надо участвовать в ивентах площадки, или что одна из компаний, как правило, не очень ответственно подходит к хакатону, из-за чего описанные эффекты проявляются крайне значительно.
Однако... даже если вы сумели всё это учесть, не факт, что вы победите. Это лишь то, что, по моему опыту, часто влияло на оценку и при этом поддаётся контролю. Есть и такие эффекты, которые почти невозможно контролировать. Пример из моего опыта: иногда из шорт-листа решений выбирает высокопоставленный представитель компании, вроде гендиректора, к общению с которым у вас нет доступа во время работы над кейсом. Так что угадать, что важно в решении именно для него, иногда может быть просто невозможно.
Но не надо думать, что раз всё так сложно, у вас ничего не получится. Если вы честно будете стараться, мне представляется вполне возможным достичь стабильно высокого шанса на победу. Не надо забывать, что конкурируют с вами команды, тоже состоящие из неидеальных людей. Да и опыт попыток понять, как работает эта сложная социальная среда, интересен сам по себе.