Ну если только аналитика не показывает тех. проблем

Не согласен, что качество кода не важно для ГК, Да, механики простые, но когда пойдет всякий обвес и итерации, то чем хуже изначально код написан, тем дороже правки вносить.
В итоге эти лишние касты могут многократно перевесить изначальную. экономию.

не всякий джун woodturning или peel good сможет реализовать (за разумные сроки), но это уже холивар, если у вас всё работает - хорошо

@ParadineDev Это понятно, но тогда ты уже будешь знать, что эти косты того стоят. А вот пока не потестил, и не знаешь метрики, нет смысла все вылизывать.

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

Но в итерировании зачем тратить лишние деньги?

+

так разработка начнется с нуля, если прототип, написанный джуном, показал ок метрики

делай говно и бросай его в воду!

выгребет - ок
нет - еще сделаем

абсолютно правильный подход, если что

Мне кажется, что 90% успеха зависит от ГД и арта. Короче от того, что юзер видит. Но при этом на кодере можно сэкономить не 10%, а уже 50% бюджета. Опять же, в итерировании это важнее. А потом уже запускать на полную можно)

торжество аджайла скрама канбана

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

Плохая производительность и баги вылавливаются на локальном тесте и фиксятся) Если кодер не может пофиксить, ищи другого) Тут тот же принцип, что и с ГК, кстати ;)

Тем более я не говорил про плохого кодера, я говорил про джуна) Не все джуны ужасно пишут)

и на CPI все вышеперечисленное не повлияет

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

Если у тебя R1 - 20% и проблем в аналитике не видно, то тут логичнее игру выкинуть. А если R1 - 35% и видно, что средний фпс меньше 30, то тут логичнее просто поправить косяк и запустить тест заново

Для этого есть показатели R0 и длина и количество сессий :)

Alex, если джун хорошо кодит, то я это и называю "прогер, который не ценит свой труд".
Т.е. да, выгодно найти талантливого кодера с маленьким опытом, низкой самооценкой и ипотекой:)

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

Самое важное, минимизировать косты на тесты. Потом уже будет понятно, стоит оно того или нет, вот и все)

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

Ну посмотрим. В любом случае, многие ошибки нужно преодолеть самому ;) А если все будет норм, то мы сэкономим нормально)