Хакатон как ускоренный курс по менеджменту
На прошлых выходных я первый раз участвовала в серьезном хакатоне (соревнований по разработке) внутри нашего банка, который длился полтора дня. Хакатон - это такая вещь, которая в короткий срок показывает твои слабые и сильные стороны: вы разрабатываете продукт не за полгода, а за короткий срок, и все принимаемые решения дают эффект сразу.
Есть несколько вещей, которые все считают очевидными при реализации проекта, но мало кто действительно их делает, и мы на эти грабли тоже наступили (причем, кажется, на все).
— Единое понимание того, что мы делаем. Несмотря на то, что у нас четко были прописаны функции и юзеркейсы, каждый из нас понимал все немного по-своему. Если бы мы потратили лишние пару часов в начале, чтобы удостовериться, что у всех единое понимание "зачем мы это делаем" и "как этим пользоваться", не возникло бы многих разногласий в процессе.
— Расстановка приоритетов. У нас было задумано 5 функций в программе и было понимание, как делать каждую, но не было приоритетов, т.к. мы думали, что мы успеем все. В итоге у нас были готовы все функции на 80%, но ни одной по факту пользоваться было нельзя. Если бы мы изначально подумали о том, какой минимальный набор задач надо сделать, мы бы смогли презентовать продукт с минимальным набором функций, но работающий.
— Координация команды. Пока фронт делал одну функцию, бэк готовился под другую. Если бы мы каждый час обсуждали статус нашего проекта (аналог ежедневных митингов), мы бы полностью этого избежали.
— Понимание, что это всего лишь прототип. Большую часть времени ребята потратили на выстраивание правильной и красивой архитектуры (кое-кто под утро даже рефакторил код соседа, потому что он ему не понравился). На самом деле, чтобы сделать MVP (minimum viable product) и доказать, что идея работает и нравится пользователям, не нужно пытаться построить идеальную архитектуру, надо просто быстро сделать прототип.
Если вы делаете продукт не день, а полгода, то в конечном итоге и приоритеты выстраиваются, и команда обретает единое понимание, но только на примере однодневного хакатона можно понять, сколько на самом деле теряется времени, если с самого начала все это не учесть. Это здорово показывает, как на самом деле обстоят дела - и в команде, и в вашем понимании процесса разработки продукта.
Поэтому, если можете в них участвовать, то обязательно участвуйте. Узнаете про себя много нового.
На прошлых выходных я первый раз участвовала в серьезном хакатоне (соревнований по разработке) внутри нашего банка, который длился полтора дня. Хакатон - это такая вещь, которая в короткий срок показывает твои слабые и сильные стороны: вы разрабатываете продукт не за полгода, а за короткий срок, и все принимаемые решения дают эффект сразу.
Есть несколько вещей, которые все считают очевидными при реализации проекта, но мало кто действительно их делает, и мы на эти грабли тоже наступили (причем, кажется, на все).
— Единое понимание того, что мы делаем. Несмотря на то, что у нас четко были прописаны функции и юзеркейсы, каждый из нас понимал все немного по-своему. Если бы мы потратили лишние пару часов в начале, чтобы удостовериться, что у всех единое понимание "зачем мы это делаем" и "как этим пользоваться", не возникло бы многих разногласий в процессе.
— Расстановка приоритетов. У нас было задумано 5 функций в программе и было понимание, как делать каждую, но не было приоритетов, т.к. мы думали, что мы успеем все. В итоге у нас были готовы все функции на 80%, но ни одной по факту пользоваться было нельзя. Если бы мы изначально подумали о том, какой минимальный набор задач надо сделать, мы бы смогли презентовать продукт с минимальным набором функций, но работающий.
— Координация команды. Пока фронт делал одну функцию, бэк готовился под другую. Если бы мы каждый час обсуждали статус нашего проекта (аналог ежедневных митингов), мы бы полностью этого избежали.
— Понимание, что это всего лишь прототип. Большую часть времени ребята потратили на выстраивание правильной и красивой архитектуры (кое-кто под утро даже рефакторил код соседа, потому что он ему не понравился). На самом деле, чтобы сделать MVP (minimum viable product) и доказать, что идея работает и нравится пользователям, не нужно пытаться построить идеальную архитектуру, надо просто быстро сделать прототип.
Если вы делаете продукт не день, а полгода, то в конечном итоге и приоритеты выстраиваются, и команда обретает единое понимание, но только на примере однодневного хакатона можно понять, сколько на самом деле теряется времени, если с самого начала все это не учесть. Это здорово показывает, как на самом деле обстоят дела - и в команде, и в вашем понимании процесса разработки продукта.
Поэтому, если можете в них участвовать, то обязательно участвуйте. Узнаете про себя много нового.