Нужно понимать, чего именно жюри ожидают увидеть на питче и стараться превзойти их ожидания. Нужно быть кратким, но тезисно-ёмким. Оставлять пространство для вопросов, не пытаясь осветить на 100% все аспекты проекта. Важно быть уверенными в своих силах, в противном случае жюри тоже не поверят. На самом деле все это – целая наука. А еще это один из моментов, который отличает разработчика senior-уровня, от уровня lead и выше. Участники действительно редко уделяют этому должное внимание, что является частой ошибкой. Одна из задач эксперта, работающего с командами — поделиться своим опытом в том числе в данном аспекте. Скорректировать питч, провести репетиции, помочь расставить акценты, выделив сильные стороны решения и усилив потенциально слабые.
Я многократный участник (и призёр) хакатонов, как русских, так и зарубежных. Моя команда выиграла одну из номинаций на самом первом Цифровом Прорыве, например. Ещё выигрывали Яндекс, VK, Volvo, участвовали в Junction.
Есть моменты в статье, с которыми я согласен: в команде действительно очень важен лидер и важно хорошее распределение компетенций. Команды из 2 человек действительно имеют сильно меньше шансов по сравнению с командами из 3-4.
Но есть вещи, с которыми я бы поспорил:
1. На фактически реализованный проект смотрят очень мало. Можно прикрыть моками данные, можно заюзать внешние решения. Я знаю случаи, когда хакатон выигрывали люди, просто соединившие две готовые чужие библиотеки. Питч решает прям очень много, к сожалению. Многие хакатоны это не конкурс разработчиков, а конкурс специалистов по презентации.
2. После хакатона проекты никому не нужны практически никогда. Многие компании (в том же Цифровом Прорыве) на хакатон представляют просто вымышленную задачу, чтобы оценить разработчиков. Я из сотен случаев знаю 1-2, когда проект хоть куда-то дальше шёл, но и там обычно всё печально.
Комментарий недоступен