Конкурсы на создание программ. Что дальше?

[knop.livejournal.com]

Рядышком (http://community.livejournal.com/ru_chgk/290907.html) выложены правила первого конкурса на создание программных средств в помощь детским тренерам, организаторам турниров и прочим активистам движения.

Призовая сумма, указанная там, - это примерно треть от того, что я мог бы позволить себе потратить на обозначенные цели. В связи с этим - несколько вопросов.

1) Какими могли бы быть темы двух следующих конкурсов? Сформулируйте свои предложения, считая, что все конкурсные условия будут аналогичными.
2) Осмысленно ли вообще тратить на это деньги, или достаточно главным призом сделать диплом победителя открытого (если угодно, международного) конкурса?
3) Правильно ли выбраны "рабочие" параметры: срок около трех месяцев на исполнение одним человеком, максимальная свобода в выборе интерфейсов, жесткое ограничение на один игровой конкурс (в данном случае - "Азбуку")?

Спасибо всем, кто включится в обсуждение.

Comments

Касательно пункта 3.

[xanf-ua.livejournal.com]

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

Как по мне - 3 месяца - многовато. Даже с учетом на то что это занятие "для души". Вот разработку "азбуки" я оцениваю часов эдак в 12-18-24, что из расчета хотя бы 4 часа в неделю - от 3 до 6 недель. За 3 месяца может и пропасть интерес.

В дальнейшем, ИМХО, не помешало бы разработать какие нибудь "гайдлайны" как должно все это выглядеть и работать - чтобы при разработке следующего ПО все имело хотя бы приблизительно одинаковый интерфейс с точки зрения юзабилити и какому-нибудь тренеру не приходилось бы изучать особенности мышления кучи разработчиков

Re: Касательно пункта 3.

[knop.livejournal.com]

Пожелание насчет единообразия в "как должно выглядеть", мне кажется, противоречит правильности жесткого ограничения на один игровой конкурс. Все равно разных разработчиков под одну гребенку не причесать...

Re: Касательно пункта 3.

[mkochkin.livejournal.com]

А вот это зря. Я полностью за единообразие. Пусть тогда первый разработчик задаст планку, выложит необходимые элементы дизайна (иконки, бэкграунд, библиотеки, что-то еще) и опишет стиль, которого нужно придерживаться. Кроме всего прочего, это упростит работу последующим разработчикам.