Сторінки

суботу, 23 квітня 2011 р.

UA Web Challenge 2011

В один из дней марта, не помню точно в какой именно, мне в телефон позвонил некто Игорь и предложил поучаствовать в жюри всеукраинского конкурса разработчиков UA Web Challenge 2011. А я возьми и согласись. Идея конкурса довольно проста и, как по мне, очень своевременна, она полностью отвечает тенденциям рынка труда - нужно дать возможность прежде всего юношам и девушкам, без опыта или с минимальным опытом работы, как проявить себя, так и найти/сменить работу буде у них такое желание есть/появится. Обе цели были достигнуты, участники разделились на две не равные части - большинство получило удовольствие от соревнования, результатов, новых знаний и знакомств; отдельные личности стали брюзжать на форуме DOU.
Соревнование проходило в три этапа - отборочный тур, полуфинал и финал. Изначально предполагалось, что судить жюри будет все этапы, но предварительные обошелся без нас. Чему лично я был очень сильно рад - поездка на JavaOne Moscow, работа и подготовка JEEconf все-таки отнимают много времени и сил.
Из пяти категорий конкурса - web-master, архитектура, алгоритмика, QA и команда - мне досталась архитектура. Работы были как очень сильные, как откровенно слабые, так и вообще не похожие на архитектуру. С другой стороны люди пришли разные, с различным образование и опытом за плечами, так что ничего удивительного.
Оценивать полуфинал было сравнительно легко, потому что из 13 человек в финал должны были пройти 7. Так что достаточно было отсеять наиболее слабые работы и дать шанс проявить себя наиболее сильным ребятам. Однако и здесь не обошлось без сложностей - в силу того, что некоторые полуфиналисты не имели достаточного опыта проектирования, как минимум один очень толковый участник не попал в финал. Отчасти, разумеется, это и моя вина тоже - не рассмотрел потенциала, не понял, что человек хотел сказать. Но теоретическая база по-прежнему важна и нужна.
Финал выдался очень "жарким". Все три призовых места показали очень хорошие результаты. Мое личное мнение, которое я озвучил организаторам в день финала - у меня два финалиста. Работы, занявшие первое и второе место, обе хороши и отдать предпочтение кому-то было очень и очень сложно. Если бы у меня был возможность этого не делать - то я бы отдал первое место обоим. Однако мне необходимо было четко сказать, кто лучше и пришлось разбирать работы очень детально. В итоге, с преимуществом в один балл по стобальной шкале, победила работа Павла Кручины как наиболее плоно удовлетворяющая условиям задачи.
Хотелось бы подробнее остановится на наиболее типичных ошибках участников
  1. Не знание или не достаточное знание теории проектирования. Это касается всех, включая финалистов и призеров. Коллеги, если вы беретесь проектировать систему, то необходимо точно понимать, какие есть для этого инструменты, императивы и диаграммы. Проектирование имеет очень опосредованное отношение к реализации, поэтому ваши навыки в языках программирования тут скорее вредны, чем полезны.
  2. Все архитекторы рассматривали систему с точки зрения реализации. Что и подвело основную массу полуфиналистов. Реализация - это самый нижний слой архитектуры. Сначала необходимо формализовать требования, выделить основные варианты использования системы, определить основные состояния и последовательности взаимодействия, выделить основные компоненты системы. И только потом можно будет говорить о реализации и классах. Участники соревнования решили идти от обратного - от классов реализации к вариантам использования. Нужно ли говорить, что многие не успели?
  3. На проектирование выделялось всего 3 часа времени. В условиях цейтнота не стоит писать пояснительную записку к дипломному проекту или Software Architecture Document - для этого нет времени. Многие же участники пожертвовали диаграммами и описанием систем в угоду описание ценности, важности и необходимости реализации такого проекта, а также проблем и задач, которые перед проектом стоят. Не могу сказать, что такое описание не важно и его не нужно делать. Но категорий "бизнесс-аналитик", "системный-аналитик" и "специалист по продажам" в соревновании не было. Когда в реальном мире начинают проектирование системы, в ее важности и необходимости уже никаких сомнений нет.
  4. Формат документов, архивов и прочего. Я не стал снижать оценки за такие мелочи, но хочу специально их отметить. Обилие платформ и ОС было представлено уже в полуфинале, можно было воочию наблюдать MacOS, Linux, Windows даже на машинах участников соревнования. Коллеги, почему же вы позволяете себе отдавать документы в MS Office/Libre Office форматах, упакованных коммерческим RAR, с кириллическими именами? Не приходила ли вам в голову светлая мысль, что некоторые документы просто не будут прочитаны? Тоже касается файлов Dia, Visio и прочих средств проектирования. В реальном мире никто не будет возиться с установкой архиваторов и конвертацией файлов - ваша работы просто отправится в корзину. ZIP для архивов, PNG для диаграмм и PDF для документов - вот выигрышная комбинация.
Традиционная для моих отзывов Pro & Contra организации
Pro
  1. Главный офис Ciklum - однозначно зачетное место проведения соревнования. Что касается места, интернет, чай-кофе-печеньки - никаких претензий.
  2. Идея питания участников и судей пиццей с соком однозначно зачетная. Питер, Москва - ау! Это не "ланч-пакеты", а гораздо проще, ага.
  3. Доброжелательная обстановка, реальные сроки для участников и гибкий подход, консультации организаторов по ходу соревнования. Мне бы было комфортно в таких условиях. Судя по отзывам - участникам тоже было комфортно.
  4. Возможность подробно разобрать с судейским коллективом ошибки. Система апелляций была бы лучше, но ее не было.
  5. Централизованная развозка участников от/до метро - очень хорошая идея.
Contra
  1. Время и график. Это полный провал, ребята. Кратко можно было бы сказать, что ничего не началось и не закончилось вовремя. Длинно можно описывать долго и красиво, но я постараюсь очень тезисно. Старт полуфинала в 13:00, а по факту в 14:30 - очень плохая идея. В результате лично у меня суббота с 7:30 до 20:00 оказалась мягко говоря не эффективной. Т.е. я конечно погулял по Киеву до 12, но все остальное - перевод времени. 3 часа я тупо убивал время в офисе Ciklum в ожидании результатов, потом еще 2 часа эти результаты собирались. Второй день был по-лучше, 9:30 хорошее время для старта, но мне нужно было сдать квартиру в 12:00. Итого, нужно более тщательно планировать временные рамки присутствия тех или иных людей в офисе.
  2. Транспорт. Кроме централизованной развозки было бы очень круто описать маршруты общественного транспорта.
  3. Субъективность судейства и отсутсвие апелляций. Я судил категорию один и это не правильно. Равно как не правильно отсутствие системы апелляций. Предлагаю сделать следующий полуфинал онлайновым и за неделю-две до финала. Как-раз хватит времени детально разобраться, разобрать апелляции и отобрать действительно лучших.