Виктор П.

У вас, судя по всему, очень хороший бекграунд с учетом возраста и статуса школьника. Вообще наличие головы на плечах очень важно в геймдеве, потому что цена каждой ошибки умножается на количество фанатов игры. Ну и если подписывать контракт на миллион долларов (это еще мало), важно его не просрать. Так что хорошие оценки по всем предметам (а не только по точным) - залог успеха в будущем, даже если кажется или если вам говорят, что какие-то предметы не пригодятся.

Однако вы, похоже, не совсем понимаете, что означает "заниматься геймдевом". Это примерно, как строить ракету или космический корабль. Конечно, если это не змейка или пятнашки. То есть свой велосипед или самокат вы сможете собрать из говна и палок, но продать такое не получится. А вот чтобы сделать что-то стоящее, хотя бы разработать автомобиль, нужно уже конкретно в автомеханику, да и то там уже куча моментов, которые один человек не осилит: устройство двигателя, аэродинамика и удобство салона - это абсолютно разные сферы знаний. Добавьте к этому маркетинг и технологии производства, и станет очевидно, что одному человеку такую задачу не решить.

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

Придумайте иконку игры. Казалось бы, просто? Но у специалиста может уйти до 2 недель, если не больше, с учетом А/B тестирования, привлечения экспертов для оценки, собственно самих художников, чтобы ее нарисовать. Хотя я не спорю, иконка, сделанная на коленке за 10 минут, может быть самой удачной, но это уже лотерея, никто не запрещает испытывать судьбу на прочность, это дешево, просто шансы на успех стремятся к нулю.

Процесса разработки самой игры я сейчас даже касаться не буду.

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

Например, в дополнение к классическим художникам и программистам есть такие роли, как геймдизайнер, пм (project manager), продюсер, QA, дизайнер UI/UX, левел-дизайнер, моделлер, аниматор и т.д. Это далеко не все. Соответственно, в крупном проекте будет несколько геймдизайнеров, продюсеров и т.д., то есть там за "роль" отвечает уже целый отдел, в каждом из которых свои более узкие специальности. Ну а в мелком (на 10 человек) у каждого будет по пачке ролей.

P.S. На всякий случай напомню, что релиз игры - это не конец, это только начало. А то в моде заблуждение, что после релиза можно открыть карман для денег и больше ничего не делать. Так что если вы (и ваша команда) вопреки статистике всё же сможете сделать игру, которая кому-то нужна, то "веселье" на этом не закончится.

1. Деньги
2. Отсутствие 2.71банатов среди менеджеров и окружения
3. Работа с этой компанией повышает рыночную стоимость времени специалиста. (n лет пилить сервисы под томкат и больше ничего не делать это риск остатьтся у разбитого корыта)
4. Work-life balance

Эх, читаю ответы и грустно становится. Как говорил мой начальник (на которого я до сих пор работаю) "У меня было много работников, и опытные, и которые только обучались, но никому работа не приносила удовольствие. Они делали это потому что надо, а не потому что хотели."
А как говорил Конфуций: "Выбери себе работу по душе, и тебе не придется работать ни одного дня в своей жизни"
Так вот, я лично занимаюсь IT потому что мне это нравится, это интересно, увлекательно. Да, за бесплатно пахать 8 часов каждый день никто не будет, но деньги вообще не главное в этом профессии, особенно когда и так средняя ЗП хорошая и грех на неё жаловаться.
Я считаю огромным плюсом, это то, что работая IT специалистом, ты можешь посещать другие компании, побывать в них, посмотреть что они делают, как это все работает изнутри. Недавно я конфигурировал сервак за 350к рублей, без надобности покупать его, это же прикольно держать в руках и иметь дело с такими дорогими вещами, не покупая их.
Вообщем мнение своё высказал, а людей которые делают свою работу, лишь потому что это работа, жалко.
Желаю всем найти работу по душе, чтобы вы могли совмещать хобби и работу.

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

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

Как вариант решения: коммитить все миграции, ничего не откатывая. Когда пришла пора мержиться выше (из таск-бранча в стори-бранч, из стори-бранча в фичу, из фичи в девелоп, из девелопа - в релиз/мастер или что у вас там) - приводим в порядок миграции: удаляем промежуточные, делаем одну новую миграцию - финальную и мержим. И так для каждого мержа с изменением схем. Таким образом, у нас каждый мерж в релиз/мастер будет означать максимум одну миграцию, что выглядит вполне адекватно.

Процесс "приведения в порядок" можно закриптовать, поэтому сильно большой проблемой это не должно быть.

Так вы и отправляете пустые данные) вы буквально отправляете null

> Как поддерживать требования к проекту всегда в актуальном состоянии?

Добрый день. Блиц ответ - регулярно обновлять информацию )

> Инструменты?

Сразу к делу - я создатель такого инструмента. Подробности на трибуне vc.ru ->

> Вопрос больше для тех кто собаку съел в управлении проектами.

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

> Суть: есть требования к проекту, сначала в виде обзорного ТЗ, потом в виде задачек в трекере, они постепенно реализуются в разрабатываемой системе (ПО), появляются новые, что-то меняется, что-то заказчик передумывает (часть задач теряют актуальность), и т.д.

Требования всегда будут проявляется потому что внимание ограничено - мы живем и работаем в ситуации аналогичной игр типа "стратегия" - когда карта туманная мы ничего не видим, когда мы "дойдем" и "воочию" увидим что там - мы видим "новые вещи". Были ли они новыми? нет - они новые только в нашем внимании. Вы мыслите верно.

> И потом бац - а цельной-то картины и нету, приходит например новый разработчик на проект или даже новый менеджер, начинает потом у народа спрашивать, а как вообще надо чтобы работало ? Тестировщик приходит - "меня прислали потестировать, а скажи как оно вообще должно работать ?".

Как оно должно работать - определяется в самом начале, но об этом лучше погрузиться в систему, есть все ответы на то как появляется это знание о результате и как передается и как хранится.

Также эффект в игре-стратегии такой же, я называю его "эффект фонарика" - куда "светите" там и все вам видно, а вот в другом углу куда не светите (нет фокуса) уже не видно.

Как и в стратегии - когда уходите с места событий и нет ваших юнитов на карте - там "фиксируется" ваше последнее "видение места", и по факту оно снова будет отличаться когда вы туда вернетесь.

> Ребята, кто какие системы применяет для управления требованиями к ПО, что вы там храните? - задачи, или UserStories? Куда ткнуться почитать как это вообще по-уму реализовать ?

Инструментов нет и не появляется в течение 15 лет, я не знаю с чем это связано, хотя вопрос на поверхности - я поэтому сделал свой продукт, для себя и для друзей - а вырос чуть в большее.

Короткий ответ в группе уже дал на разницу Jira / Тимсити / Трелы и прочее:

// цитата

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

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

Но так как я на этой почве проживаю давно то скажу так - смена сотрудников это такая милая история про которую рассказывают на конференциях - и как с ней бороться с помощью вики и конфлюенса.

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

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

// конец цитаты

> Я не ПМ, знаю что нужно пинать ПМа, но реально пока не понимаю, он что, должен это тупо вручную отслеживать, и документацию в вики или в гугл-доке?

Попробуйте, у меня есть видосы в группе телеграма где я разбираю по шагам как идет разработка

> Всем заранее спасибо.

Надеюсь не забанят - вроде бы прямой ответ на вопрос.

Возьмите готовый шаблонный проект (фреймворк) где все уже есть - авторизация, бд, сервер и так далее.
Если нет подходящего - то потратьте пару дней и сделайте один раз.

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

Это эффект стремления к немедленной гратификации. Присущ избалованным детям. Нужно осознать и привыкнуть к тому, что жизнь вообще сравнительно редко "весела и интересна", а обычно состоит из рутины. Те, кто это не могут осознать, заканчивают либо бомжами, либо наркоманами.

Поделитесь опытом, какой способ вы используете для своей разработки?

Лично мы используем такой способ:
1. Есть мастер ветка, туда попадает только полностью оттестированный код (обратите внимание - не в конце какого-то спринта; не после того, как на горе рак свистнет; а после прохождения всех этапов тестирования)
2. Есть dev-ветка, ею заведует старший разработчик и по мере необходимости "подливает" туда фиче-ветки.
3. Есть много фич-веток, в которых работают отдельно взятые личности, при этом откуда они будут брать кодовую базу для доработки - их личная трагедия. Если при слиянии возникают конфликты - есть старший разработчик, если ему что-то непонятно - есть авторы кода, которых можно позвать и спросить "какого тут происходит?".

Лучшая формула работы, из моего личного опыта - это "думать головой", а не слепо следовать какому-то набору правил.

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

В мобильной версии навигация по меню недоступна, блоки не раскрываются,
В десктопе тоже лажа, все пляшет, аккордеон "играет" без аккордиониста, открывается / закрывается при любом движении.
При переключении из мобильного в десктоп меню дублируется.
Мета дескрипшн и кейвордс нет.
Конечные элементы "ПРОЕКТЫ ДОМОВ" - отдельные проекты, не имеют своих страниц, только попап.

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

Это за 5 минут что видно, плюс дизайн конца 2000х...

UPD: обратный звонок - маркетинговый козырь - засунут в такую ж***, что я вообще его нашел только случайно...

По рекламе, 1 человек прошел квиз и оставил данные

я его вообще не нашел...

MS Outlook -> Календарь

Блевотное слово "митап" повторяется у вас 4 раза. Так, к слову.

MS Outlook, например, для напоминалок.

входных данных для оценки трудозатрат мало. "модуль" - значит куда-то встраивается ? куда ? как ? какие требования в дизайну ? к коду ? к комментариям ? к тестам ? и вообще - что вам в итоге надо ? Java - серверная часть - а что там ? или Java на локальном хосте в окошках? или это JavaScript ?

не зная всего этого я бы тоже "заломил" 3 недели. хотя, возможно, ваша задача решается за 3 часа.

p.s. 8*15 = 120 часов... а какой тариф у разработчика в час ? :)

Невозможно сказать без уточнения:
Какие последствия если зафакапить дедлайн?
Какие последствия если выбор будет неправильный?
Какая цена изменения решения на другое потом?

Если кто-то умеет от пропуска дедлайна лучше решить как-то потом переделать. Если кто-то умрёт от неправильного решения лучше профакапить дедлайн.

Можно ли как-то подготовиться к замене решения на верное?

А мне нужно чтобы была возможность в любой день взять какую-нибудь подработку на 1-2 т.р.

Влажная мечта любого фрилансера.
Не думаю, что такое возможно, если, конечно, вы не очень везучий человек.